Editorial by Matt Bush, Security Consultant.
In news to virtually nobody, another worm leveraging the Eternalblue exploit has hit the news. Contrary to popular opinion, NotPetya’s use of Eternalblue was not what made it so dangerous. NotPetya also abused credential reuse and token impersonation, which made it possible for the worm to propagate through many fully patched organisations.
In the majority of internal penetration tests, our security consultants are able to gain control of Active Directory environments without leveraging sophisticated remote exploits like Eternalblue or even with local privilege escalation exploits. Often we can simply abuse the very same credential theft techniques automated by NotPetya.
During penetration tests, once we gain Local Administrator privileges on a single workstation or server, we are typically able to extract user credentials. We usually extract domain account credentials from memory using tools such as Mimikatz, or we simply dump the local Windows SAM file for local user credentials that may be reused across multiple hosts.
Stolen passwords might be in plaintext or in the form of NTLM hashes. NTLM hashes are functionally equivalent to plaintext passwords. For this reason, I have opted to write about preventing the use of credential theft as a means for attackers to move through networks, rather than yet another article about “stopping pass-the-hash”. The possibility of authentication with NTLM hashes as easily as with passwords is a consequence of how authentication works for core protocols in Windows domains.
In cases where we can’t extract passwords or hashes, such as when Credential Guard is in use, or when an account is protected by membership of the “Protected Users” security group, we can impersonate the targeted user’s access token (usually) to the same effect.
The next stage for us is user hunting, wherein we query Active Directory to identify privileged groups and users, and then we search for hosts that we have local administrator rights on and where interesting users have active sessions.
Once we find an accessible host that has an interesting user logged in, we will typically compromise that host with our stolen credentials and repeat the process of stealing that user’s credentials. With our new privileges, we can continue to hunt users with greater privileges within the domain, or those who have access to any restricted resources we might be targeting. We can repeat the cycle of user hunting and credential theft until we own a domain. If the domain we end up owning is a part of a forest, we can then own the forest with an easily executed Kerberos hack (unless SID filtering between trusts is in use, but this is unsupported and it pays to remember that the forest, not the domain, is the trust boundary).
Easy privilege escalation via credential theft within Active Directory environments is all too common, and it is how most organisations get compromised by seasoned penetration testers, advanced threat actors, and more disturbingly, increasingly by script kiddies and worms such as NotPetya.
It is possible for organisations to make the process of owning an entire forest harder (and more fun!) for us by implementing several controls.
Sorting out account security within Active Directory can be a long and painful process. In the meantime, administrators can apply some fixes to minimise the risk of falling victim to this attack chain. Initially, you should aim to prevent it from getting off the ground, since it is much harder to stop once an attacker has full control of multiple hosts.
- Enforce User Access Control (UAC) for all hosts. Thanks to this patch, UAC prevents stolen credentials and impersonated tokens from being abused by attackers to execute commands and code on remote via Psexec, WMI, and other methods (aside from Remote Desktop). Set UAC to “Always Notify” for this and other reasons. Alternatively, you can disable the ADMIN$ share in Group Policy, which will likely break things in unpredictable ways, so it is better to go with strict UAC.
- Even when UAC is enabled, attackers can still abuse a remote host’s built-in Local Administrator account (with a relative identification number of 500) to execute code over the network. We often find this account enabled in organisations, and we tend to find that the password is the same on every host (or at least every workstation), making lateral movement trivial. Either disable this account, or ensure that each host with the account enabled has a different password. Do this with Microsoft LAPS or a more comprehensive solution like CyberArk. Custom solutions to control these accounts are rarely effective.
- Restrict users from having local administrator access on their own workstations where feasible. Privileged users should favour the use of unprivileged accounts where possible, and avoid using their privileged domain accounts except when necessary.
Combined with prompt security patching, implementing these recommendations will go a long way toward preventing worms such as NotPetya from being able to propagate through your environment.
Implementing these basic recommendations is far from a comprehensive fix; there are many ways for creative attackers to work around the defences outlined, and every environment is different. Our own specialist security consultants can simulate how advanced attackers operate in networks hardened against such attacks.
Our new ASD Top 4 as a Service (#ASD4aaS) mitigates up to 85% of all cyber crime, learn more.
Call 1300 865 865 to find out about our Security services.
