Defuse an Active Directory Attack in Progress
Earlier this year, I was immersed in the intense drama of helping a European company defuse an ongoing attack that targeted the Active Directory (AD) environment. In this article, I’ll go over the details of the attack and our remediation efforts to help other IT and security teams refine their incident response plans.
When I arrived at the scene (virtually, along with the business partner and other members of the Semperis team), the intruder had already used credential theft tools and had successfully hijacked one company domain administrator passwords. The attacker then used the compromised account to create a new dedicated account and join it to the Domain Admin group of the compromised domain. In making this decision, the attacker followed a common playbook on how to attack an AD domain and stay persistent.
The company’s security team had already been alerted to ongoing threats in their environment from security tools running on their endpoints. But they didn’t have specific tools in place to protect their DA from within; for example, to undo any unauthorized changes to the Domain Admins group. However, they responded quickly to the notification of suspected credential theft activity and the warning about a newly created domain administrator account. They immediately disabled the attacker’s accounts, created new administrator accounts in each of their forests, and disabled their previous privileged accounts.
The network team traced the culprit to an Internet-connected virtual machine (VM) which the intruder was able to access via Remote Desktop Protocol (RDP). The attacker had previously “called home” an IP address belonging to Russia and was downloading ransomware containing an encryption DLL. The team immediately shut down that virtual machine’s network – another smart move.
Current threat assessment
First on the agenda was to understand how far the attacker has come and how best to protect against further damage. At that time, no one knew if another malicious time bomb had ever been placed on other systems in the environment. Would a crypto-locker process still be launched and encrypt their entire infrastructure, potentially including all of their AD domain controllers, as was the case during the NotPetya attack on Maersk a few years ago? When did the intrusion start? Were clean backups available from each domain in each AD forest? Was a disaster recovery plan available?
We have checked a list of actions that would further secure the environment in case the adversary is still active in the environment:
- Provided SID filtering was active in all trusts between AD forests: This setting prevents cross-forest attacks by adding a privileged group to the SID history of an account in the already compromised domain.
- Reset the KRBTGT account in each domain and did it twice (ensuring forced replication between each reset): This reset procedure prevents attackers from creating Kerberos Ticket Granting Tickets (TGT), aka “Golden Tickets”, if they have already compromised the KRBTGT account.
- Disabled on Windows Print Spooler Service on all domain controllers: Disabling this service prevents the attacker from forcing a domain controller to authenticate with another client compromised via the “printer bug” (and since PrintNightmare was discovered, a disabled printer spooler is the best practice anyway).
- Adding all privileged users to the Protected Users group in their respective domains: This protection will reduce the exposure of credentials for these accounts by no longer allowing authentication through NTLM (Kerberos only) or by using DES or RC4 for Kerberos pre-authentication. Users in this group also cannot be delegated with constrained or unconstrained delegation.
- Ensured that a recent backup of each domain in each forest was securely stored on an offline repository: You need these backups for forest recovery if an encryption lockdown process is initiated in the environment.
We then used the Purple Knight Security Assessment Tool (www.purple-knight.com) to uncover weaknesses that might still exist in the company’s AD forests, resulting in a long list of security indicators to be resolved, in particular:
- Computers configured with unconstrained delegation – a valuable target for attackers
- Various risky permissions configured at the domain level
- Administrative accounts with passwords that had not changed for many years
Fully restored Active Directory brings peace of mind
The final step in helping this customer respond to the attack was the notoriously difficult process of fully recovering their Active Directory forests. We’ve helped them set up tamper-proof and resilient backups to deliver true peace of mind.
For any business facing an on-going attack, these practical tips provide practical advice on mitigating damage immediately, assessing environmental vulnerabilities, and achieving fast, clean AD recovery that does not risk not to introduce malware.