Pentesting Stories: Errors and limited hygiene lead to full domain compromise
Blog by Danut Niculae, Security Consultant Operations Center
This story begins with a large services business, moving some of its customer-facing operations to a private cloud. SecureLink was asked to focus on this cloud infrastructure in its testing. Ultimately, we found a chain of vulnerabilities and misconfigurations that would have allowed a full domain takeover.
As a first step we did a quick scan of inventory web applications and their configuration. Here we found one application with a management interface which was open to the world.
2. FILE UPLOAD
The second link in the chain was an unrestricted file upload interface. Using this we uploaded a Web Application Resource file (WAR) containing an admin web shell. We then used this shell for initial access to the back-end.
3. BACK DOOR
Any regular user can execute the WAR file via the shell, thereby opening a back-door for our pentesters.
4. ACCES AND SCAN
Using the back door, we were able to access and scan local files. In one of the log files, we found an error related to NT Lan Manager (NTLM) hash negotiation. This error, in clear text, showed the username and password.
5. INTERNAL IP ADDRESS
Unprivileged users were able to access the admin interface on the application. There we couldn’t edit anything, but much information was visible, including an internal IP address. We used this address to connect via a remote desktop.
6. ADMIN ACCESS
After logging in with the credentials found earlier, we saw we were part of the admin group. This indicated a clear lack of privilege segregation. As we now had admin access to the domain, we could fully compromise the domain, by creating a ‘golden ticket’. This allowed full access to any service or system connected to the domain.
7. FULL DOMAIN COMPROMISE
On top of this, a large number of domain admins were found within the organisation. This meant there were numerous alternative tracks to follow. One could safely say that, after the initial compromise, the chance of gaining persistent access was high.
The Golden Ticket attack is used by threat actors to obtain domain persistence. The technique leverages the lack of validation on the Kerberos authentication protocol in order to impersonate a particular user, valid or invalid. This is due to the fact that users who have a Ticket-Granting Ticket (TGT) in their current session are considered trusted by Kerberos and therefore can access any resource in the network.
The organisation had invested a lot of effort to protect the external facing web application. However a combination of factors led to this fairly easy compromise. Additionally, outbound communication was unrestricted which is an ideal scenario for any attacker wishing to exfiltrate data.
- Ensure web applications restrict file uploads unless strictly necessary and in which case limit them to specified file types.
- Always limit access. A first step is to limit access to internal IP addresses.
- Avoid giving privileges to people that don’t require them. Keep good security hygiene.
- While the root cause was a misconfiguration in one single application, a combination of other factors resulted in this breach being extensive.
- Had the attack been real, the damage would have been significant. Recovery from a full compromise is extremely difficult requiring vast amounts of time. A likely scenario is that a victim may need to rebuild the domain from scratch.