m365expertise MICROSOFT SECURITY EXPERTISE
Active Directory

The first 48 hours of an Active Directory compromise: contain, preserve, take back control

m365expertise·26 September 2026·9 min·2,011 views

When an attacker has obtained elevated rights in Active Directory, the first hours often decide the outcome. Act too fast and you destroy evidence and tip off the adversary without having dislodged them; act too slowly and you let them consolidate their grip. This framework sets out the order of priorities as we apply it. It does not replace a response plan prepared in calmer times.

First of all: do not improvise alone

The first decision is not a technical one. It is to activate the crisis team, decide who is in charge, and involve management and, depending on the context, insurers, legal counsel and the relevant authorities. A compromise of the authentication directory is a major incident: it potentially affects every system that relies on it. Trying to deal with it quietly between administrators is the most common and most costly mistake.

Preserve evidence before cleaning up

The temptation is to reset, reboot and delete straight away. Yet these actions erase precisely what will let you understand the extent of the intrusion and be sure it is truly over. Before any remediation:

  • secure a copy of the relevant logs (domain controllers, firewalls, detection systems) out of the attacker's reach, because local logs can be wiped;
  • preserve the state of suspect machines (memory and disk images) where possible, rather than reinstalling them immediately;
  • keep a timestamped timeline of events and of the actions taken: it will be essential for analysis and, often, for third parties.

Preservation and containment are not in conflict: a machine can be isolated from the network while its state is kept for analysis.

Contain without deluding yourself

Containment aims to strip the attacker of their access and footholds. The levers: isolate the affected segments, cut remote access, suspend the accounts that are clearly compromised. But keep a cautious working assumption: once Tier 0 rights may have been obtained, you must assume the attacker had access to all of the domain's secrets, including the account database. Disabling a few accounts is then not enough; all secrets must be treated as exposed.

The administration workstation must be trustworthy. All remediation must be carried out from machines you are confident are not compromised, with accounts dedicated to the crisis. Running the recovery from an infected machine is working under the attacker's gaze.

Reset privileged secrets, in the right order

Taking back control involves a large-scale secret reset, carried out methodically: administrative accounts (domain, enterprise, Tier 0), privileged service accounts, then the rest of the database according to the risk assessment. Two points of care: resetting a service account without having prepared the applications that use it causes cascading outages, and overlooking a low-visibility privileged account leaves a door open. Hence the importance of a privileged account inventory drawn up before the crisis.

The double krbtgt reset

The krbtgt account encrypts all of the domain's Kerberos tickets. If it has been extracted, an attacker can forge tickets that give them lasting access, independent of passwords. Neutralising it means resetting its password twice, because the account keeps its previous password, which is still accepted for ticket validation.

The timing is delicate. The two resets must not be chained too quickly: between them, replication must propagate to all domain controllers and current tickets must be allowed to expire, otherwise legitimate authentications fail. But they must not be too far apart either, because a single reset still leaves valid the tickets forged with the old key. This operation is planned, ideally with the help of a purpose-built tool, and fits into a sequence in which access control has first been regained; doing it too early, while the attacker is still present, merely signals to them that they have been spotted.

Clean up or rebuild?

Then comes the hardest question. After a Tier 0 compromise, you can never prove that an environment has become fully clean: the attacker may have left discreet persistence mechanisms, in the directory or on the controllers. Three paths exist: clean in place, rebuild certain elements (controllers, the administration model), or rebuild the forest from clean backups. The choice depends on the depth of the intrusion, the trust you can place in the backups and the time available. A forest rebuild is heavy, but it is sometimes the only way to start again on a foundation you can trust. This decision benefits enormously from having been anticipated: knowing in advance that a rebuild procedure exists and has been tested changes everything.

Communicate, during and after

Controlled communication, internal and external, is part of the response. Internally, teams need to know what to do and what not to do, without the information reaching the attacker if they are still present. Externally, legal notification obligations may apply depending on the data involved. Finally, once the incident is closed, the lessons-learned review is what turns a crisis into lasting improvement: it feeds the correction of root causes, often the same weaknesses an audit would have flagged.

What an audit checks

  • The existence of an incident response plan specific to Active Directory, and whether it has been tested.
  • The availability of trustworthy backup administration workstations and accounts.
  • An up-to-date inventory of privileged and service accounts.
  • Centralisation and retention of logs out of an attacker's reach.
  • Knowledge of the double krbtgt reset procedure and its timing.
  • The existence and testing of a forest rebuild procedure, and of offline backups.
Was this article useful?
4.4 / 5 · 109 ratings