Earlier this year, I was plunged into the intense drama of helping a European company defuse an in-progress attack that targeted the Active Directory (AD) environment. In this article, I will walk through the attack details and our remediation efforts to help other IT and security teams hone their incident response plans.
When I arrived on the scene (virtually, along with the company’s partner and other Semperis team members), the intruder had already run credential theft tools and successfully hijacked one of the company’s domain admin 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 move, 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 the ongoing threats in their environment from security tools running on their endpoints. But they did not have any specific tools in place to protect their AD from the inside; for example, to undo any unauthorized change to the Domain Admins group. However, they responded quickly to the notification of the suspected credential theft activity and the warning about a newly created domain admin account. They immediately disabled the attacker’s accounts, created new admin 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) that the intruder was able to access through Remote Desktop Protocol (RDP). The attacker had already “called home” to an IP address belonging to Russia and was in the process of downloading ransomware containing an encryption DLL. The team immediately cut off the network of that VM — another smart move.
"First on the agenda was understanding how far the attacker had come and how best to protect against more damage"
Assessing the Current Threat
First on the agenda was understanding how far the attacker had come and how best to protect against more damage. At this time, nobody knew whether another malicious time bomb had already been planted on other systems in the environment. Would a crypto-locker process still be kicked off and encrypt their whole infrastructure, potentially including all of their AD domain controllers, as was the case in the NotPetya attack on Maersk a few years back? When did the intrusion begin? Were clean backups available from every domain of every AD forest? Was there a disaster recovery plan available?
We checked off a list of actions that would further secure the environment in case the adversary was still active in the environment:
- Ensured SID-Filtering was active across all the trusts between the AD forests: This setting prevents attacks from one forest to the other by adding a privileged group to SID-history of an account in the already compromised domain.
- Reset the KRBTGT Account in every domain and did so twice (ensuring forced replication between each reset): This reset procedure prevents attackers from creating valid Kerberos Ticket Granting Tickets (TGT), aka “Golden Tickets,” if they have already compromised the KRBTGT account.
- Disabled the Windows Print Spooler service on all domain controllers: Disabling this service prevents the attacker from coercing a DC to authenticate to another compromised client via the “printer bug” (and since PrintNightmare was discovered, a disabled printer spooler is best practice anyway).
- Added all privileged users to the Protected Users group in their respective domains: This safeguard will minimize credential exposure of these accounts by no longer allowing authentication via 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 every domain of every forest was safely stored on an offline repository: You need these backups for a forest recovery if a crypto-locker process is kicked off in the environment.
We then used the security assessment tool Purple Knight (www.purple-knight.com) to uncover weaknesses that might still exist in the company’s AD forests, which yielded a long list of security indicators to resolve, including:
- Computers configured with unconstrained delegation — a valued target for attackers
- Various risky permissions configured at the domain level
- Administrative accounts with passwords that had not changed in many years
Fully Restored Active Directory Brings Peace of Mind
The last step in helping this client respond to the attack was the notoriously difficult process of fully recovering their Active Directory forests. We helped them configure tamper-proof and resilient backups to give true peace of mind.
For any company facing an in-progress attack, these real-life tips provide practical guidance on immediately mitigating the damage, assessing the environment for vulnerabilities, and conducting a fast, clean recovery of AD that doesn’t risk introducing malware.
