Domain Admin Through Social Engineering
Monday 26th June, 2017 22:41
A long time ago in a job far, far away, there was an occasion where I managed to gain Domain Admin access without using any special tools, and then abused trust relationships to move around their entire network. The vulnerability was simple, but exploiting it quickly was more difficult. I had to trick someone.
After using VPN credentials to gain access to an internal network, I had an IP address, details of their DNS servers, a gateway, and that was about it. The VPN credentials were also Windows domain credentials. I scanned the network ranges I could see for RDP ports and found a few servers, but my low privileged domain user wasn't allowed to log in. I persevered and eventually logged into a host: a Citrix host.
I poked around the host and spotted that several applications had been installed on D drive. This included files used by Citrix when you logged in, intended to help the user experience. Thankfully I was the only user on the host at the time so I was able to kill the process for my own user and then replace the executable with my own file. To help evade AV, I went with a simple batch file and converted it to an executable using an application. Lazy, but effective.
But in order to escalate my privileges, I needed an admin to log into the host. I needed them to do it quickly as it was a short engagement. I decided to give them a reason to look into the host, but without being too obvious.
I copied CPU Burn-in onto the host, renamed the binary to match another process that was currently running, then set the priority to idle so as not to affect other users. Then I went home.
The next morning, I logged back onto my Citrix box to discover the process was no longer running. I ran a quick net command to confirm that my simple batch file had been executed. The user existed on the domain. I ran another net command. The user was now a member of Domain Admins. It seems that an admin spotted the high CPU usage and logged into the host to investigate, and based on the uptime they rebooted the server to fix the fault.
The moral of this story is don't use your Domain Admin account to log into misbehaving servers. Also, if you install applications to the non-system drive, make sure you modify the default NTFS permissions.
Creating a new Domain Admin account isn't the subtlest of things. It'd make sense to use tools like Mimikatz to get cleartext credentials, but back then it was only a standalone application and hard to interact with.
After using VPN credentials to gain access to an internal network, I had an IP address, details of their DNS servers, a gateway, and that was about it. The VPN credentials were also Windows domain credentials. I scanned the network ranges I could see for RDP ports and found a few servers, but my low privileged domain user wasn't allowed to log in. I persevered and eventually logged into a host: a Citrix host.
I poked around the host and spotted that several applications had been installed on D drive. This included files used by Citrix when you logged in, intended to help the user experience. Thankfully I was the only user on the host at the time so I was able to kill the process for my own user and then replace the executable with my own file. To help evade AV, I went with a simple batch file and converted it to an executable using an application. Lazy, but effective.
But in order to escalate my privileges, I needed an admin to log into the host. I needed them to do it quickly as it was a short engagement. I decided to give them a reason to look into the host, but without being too obvious.
I copied CPU Burn-in onto the host, renamed the binary to match another process that was currently running, then set the priority to idle so as not to affect other users. Then I went home.
The next morning, I logged back onto my Citrix box to discover the process was no longer running. I ran a quick net command to confirm that my simple batch file had been executed. The user existed on the domain. I ran another net command. The user was now a member of Domain Admins. It seems that an admin spotted the high CPU usage and logged into the host to investigate, and based on the uptime they rebooted the server to fix the fault.
The moral of this story is don't use your Domain Admin account to log into misbehaving servers. Also, if you install applications to the non-system drive, make sure you modify the default NTFS permissions.
Creating a new Domain Admin account isn't the subtlest of things. It'd make sense to use tools like Mimikatz to get cleartext credentials, but back then it was only a standalone application and hard to interact with.
