Connectivity
The Wi-Fi network of the organisation was protected using RADIUS and client certificates, a very security conscious approach that prevents anyone being able to connect to the Wi-Fi purely with the PSK. Luckily for us though, every desk had its own ethernet cable available, so people could come and go with their laptops and get hooked up quickly. Differing to the wireless network which employed strong authentication mechanisms, it was found that with direct ethernet access there was no further checks such as 802.1x or NAC. Ultimately this meant that we were assigned an IP address through DHCP and we could start assessing the environment.
It should be noted that the client had put a large amount of effort into ensuring that all devices were patched and appropriately firewalled from one another. Initial port scans confirmed this, with minimal results and nothing to indicate that workstations were outdated or obviously insecure in any other way.
WPAD
Our first thought was to run Responder, a fantastic tool that lets us poison all kinds of protocols in an attempt to eventually have access to plaintext credentials, NTLM hashes, etc. One protocol that Responder coerces is WPAD. If you’ve never heard of Web Proxy Auto Discovery (WPAD), it’s a method builtin to Windows that allows for machines to automatically discover web proxy configurations. If your organisation has a web proxy, rather than manually configuring the proxy via a group policy or manually, you can set up WPAD so that your machine automatically looks up the proxy configuration.
The issue with this however, is that if a WPAD server is not explicitly configured via DHCP, Windows will then search via DNS and then Link-Local Multicase Name Resolution (LLMNR) and/or NetBIOS will be used. And luckily for us, these are the exact protocols that Responder can poison and serve malicious responses for. If a machine is to request a WPAD configuration, our machine can reply to it and simultaneously ask for their credentials, so we can “verify who they are.” In reality, this means that the machine gives us a Net-NTLMv2 hash to authenticate. As this hash is derived from the user’s password, we can then load up our password cracking rig and attempt to bruteforce it.
We ran this for a couple of hours and ended up getting five or six hashes that we could crack:
Password Policy
The organisation had a fairly strong password policy, minimum of 14 characters, at least one uppercase, one lowercase and one punctuation mark. But as with many security policies, people will always take the shortest way around it. In this case, this was users choosing an average 7-8 character password, and simply repeating it to satisfy the length requirement.
Of the hashes that we were able to capture, we were able to crack one within a very short time:
This was performed on a moderately powerful cracking rig, consisting of five 30 series GPUs:
Credential Gathering
While the organisation enforced MFA on their user accounts for Office 365, this was only enforced when accessing O365 from an untrusted external address (e.g. at home) and not from the office. As we were in the office, we were able to login to the compromised user’s Office 365 account.
This gave us access to the organisation’s Sharepoint (typically always a gold mine for credentials) but also a number of external services as they were using Single Sign On to authenticate across these. We enumerated their Sharepoint and Slack channels, finding a number of passwords for other production systems, but nothing that could let us escalate our privileges.
As stealth was not a factor in this engagement, we also ran a password spray using the previously identified password of “Password!password!”. To our surprise, of the 250 users we sprayed this password against, it worked for 30 of them. During the debrief session with the client, we found that this was the default password given to people in password resets and changing it was not enforced upon first login.
As a result, we now had 30 users to enumerate, all with access to different Sharepoint content, Slack content and most importantly for us, password manager access.
Password Manager
Password managers are fantastic tools for personal usage, eliminating the need to remember 20 different passwords and instead remember a single strong password and use completely random passwords elsewhere. Likewise, enterprise password managers are fantastic in that they can help organisations store passwords for all their production systems, external services, etc. and users can be given access based on their job role. For example, it’s useful for finance to be able to access their Amazon account but they probably don’t need access to the domain controller administrator account.
But the most important thing to be aware of is that a password manager’s greatest advantage is also its greatest disadvantage. If your master password gets leaked, an attacker now has access to all of your passwords. Likewise in an enterprise solution, if someone’s account is somehow compromised, they then have access to all the passwords that the individual has access to.
So how were we able to compromise this organisation’s entire domain? Firstly, the password manager was configured to use LDAP authentication rather than Office 365 OAuth. As a result, no MFA was required to login as it wasn’t bound by the existing SSO authentication protections. What was almost unbelievable to us was the fact that not only was there no MFA, but the authentication page to the service was publicly accessible over the internet.
One of the individuals using the default password (Password!password!), was employed as a “Product Specialist” and for some reason had been given access to the “IT” folder within their password manager account. The “IT” folder contained all passwords for almost all of the domain admin accounts, website servers and a number of other highly privileged user accounts.
Final Compromise
With access to domain administrator credentials obtained from the above attack path, we ultimately had access to the client’s entire infrastructure. We performed a DC Sync attack to obtain NTLM hashes for all domain users, which could then be used to authenticate throughout the environment. We could have also performed a golden ticket attack, added new highly privileged users or any combination of post exploitation activities. We of course opted for the exceptionally technical and advanced technique of changing our point of contact’s Slack image for a nice PoC (
).
Through further enumeration of the password manager we found multiple AnyDesk addresses and credentials. AnyDesk is a remote access tool, similar to TeamViewer that allows for remote control of a host. Enumerating these further showed that these AnyDesk sessions were started on workstations within trusted environments, such as the “user network” that was initially physically plugged in to.
If you can see where we are going with this – ultimately this meant that there was a potential for the whole above attack path to take place entirely remotely, without any MFA prompts or need for physical access.
- Compromise credentials via phishing or other means.
- Authenticate to the remote password manager with these credentials, without the need for MFA.
- Potentially identify that the user has overscoped access, and has access to AnyDesk and/or privileged accounts.
- Use AnyDesk (out of hours to minimise detection) to have a foothold on the internal environment.
- Perform a Responder based attack as was seen above, or simply use existing privileged accounts to authenticate to the domain to a highly privileged user.
- Compromise the domain, exfiltrate sensitive data, compromise payroll systems, change Slack images etc…
- Profit.
Conclusion
In conclusion, it was possible to compromise the entire clients infrastructure through an insecure WPAD configuration, weak credentials and a lack of MFA across key services. Permissions within the password manager software was also very lax, meaning that a large portion of users had largely overscoped access to accounts and details that they did not need. A potential lack of security training may have also been to blame for the internal IT staff, as when account resets were requested, not only was the same password provided to everyone – it was not enforced to be changed on first login.
In a real world attack this could have been performed entirely remotely, without any MFA prompts or any form of alerting from their third party SOC. If this was a real attack, this would have severely crippled the organisation as the ICO fines alone for the amount of sensitive data that was accessed would have been enormous. This along with a complete lack of faith from potential and existing customers would have left the organisation in a very poor state.
Key Takeaways
- Regular penetration testing is essential.
- Enforce password changes when resetting user accounts, make sure user’s aren’t simply appending a “1” to the end of it. (We found 2 users were doing this).
- Do not host sensitive services, such as password managers publicly. Instead require access through VPN.
- Enforce MFA throughout the environment and across every service that supports it.
- Give access to credentials and elevated permissions on a granular level, most users do not need this.
- Work with us to perform regular active directory password audits and internal infrastructure penetration tests.
