Recovering Domain Controllers After a Kerberos Attack
A Kerberos attack can leave an organisation with functioning logins and a deeply compromised identity system. That combination is dangerous: users may still access email, file shares and business applications while an intruder holds forged tickets, stolen credentials or replication privileges. Recovery therefore requires more than restarting a domain controller or changing an administrator password.
The safest approach treats the Active Directory forest as a security incident first and an infrastructure outage second. Teams must contain the attacker, preserve evidence, determine whether the KRBTGT account or domain controllers were compromised, and then restore trusted identity services in a controlled sequence. In Australia, that work may involve an internal security team, an MSSP, a specialist incident responder and compliance stakeholders across Sydney, Melbourne, Brisbane or regional offices.
| Situation | Immediate priority | Recovery direction |
|---|---|---|
| Suspicious Kerberos tickets but no evidence of domain compromise | Contain affected accounts and hosts | Investigate ticket use, reset credentials and monitor |
| Golden Ticket or KRBTGT compromise suspected | Assume domain-level compromise | Perform a controlled forest recovery or rebuild |
| Domain controller malware or tampering confirmed | Isolate affected controllers | Rebuild from trusted media and clean credentials |
| DCSync, NTDS.dit theft or privileged credential theft | Treat identity secrets as exposed | Reset privileged accounts, KRBTGT and service credentials |
| Recovery backups cannot be trusted | Avoid restoring blindly | Build clean domain services and migrate systems carefully |
Understand The Type Of Kerberos Compromise
Kerberos uses tickets so that authenticated users and services can access resources without repeatedly sending passwords. An attacker who steals a valid ticket may use it until it expires. A more serious compromise occurs when the attacker obtains the KRBTGT password hash, which can be used to forge Ticket Granting Tickets. These forged “Golden Tickets” may grant long-lived or effectively unrestricted access within the domain.
Silver Ticket attacks target service accounts and forge service tickets for particular services, such as CIFS file shares or SQL Server. They can be harder to detect because authentication may occur without a normal domain controller exchange. DCSync activity is another major warning sign: an attacker with suitable directory replication rights can request password data as if they were a domain controller.
Evidence of these attacks may include unusual ticket lifetimes, authentication from unexpected hosts, logons by disabled accounts, privileged group changes, replication requests from workstations, or access to domain controllers by systems that have no administrative role. A successful login does not prove that the environment is healthy. In a suspected Golden Ticket case, assume that ordinary password changes alone will not remove attacker access.
The scope also matters. A single application server with a stolen service account requires a different response from a compromised forest root. Document the affected domains, trusts, sites, domain controllers, privileged groups, service accounts and connected identity platforms. This inventory prevents a recovery team from cleaning one Sydney-based controller while a forgotten read-write controller in a Brisbane office remains under attacker control.
Establish Control Before Touching The Directory
Begin by separating compromised systems from systems that must remain available for evidence and business continuity. Isolate suspected domain controllers and high-value administrator workstations using network controls, while avoiding an indiscriminate shutdown that destroys volatile evidence or interrupts essential operations. Block unnecessary east-west traffic, restrict remote administration and prevent compromised hosts from reaching clean domain controllers.
Create a small, trusted recovery administration path. Use clean workstations, clean accounts and a controlled management network. Do not use an administrator laptop that has logged on to a suspect domain controller. If privileged credentials may have been captured, disable or quarantine them and create temporary recovery accounts according to the incident response plan. Keep emergency access separate from normal enterprise identity services.
Preserve event logs, memory captures, disk images, ticket data and firewall records before remediation changes erase useful clues. Record times in Australian Eastern, Central or Western time as appropriate, and correlate them with UTC in the case file. That detail is practical when a response team spans Perth, Canberra and an overseas security operations centre.
For organisations covered by the Australian Privacy Act or the Notifiable Data Breaches scheme, suspected exposure of personal information should be assessed alongside technical recovery. APRA-regulated entities also need to consider CPS 234 obligations and evidence that security controls were effective. A specialist responder can help maintain forensic integrity while the infrastructure team works to keep critical services running.
Confirm Whether Existing Domain Controllers Are Trustworthy
A domain controller should be considered untrusted if an attacker had administrative control, accessed its system state, altered security settings or deployed malware. Review endpoint detection data, Windows security events, PowerShell logs, directory changes, scheduled tasks, services and network connections. Pay close attention to Event IDs associated with account use, group membership changes, Kerberos service ticket activity and directory replication.
Check for compromised privileged groups, including Domain Admins, Enterprise Admins, Administrators, Account Operators and custom groups with delegated replication or Group Policy rights. Search for accounts with unusual service principal names, weak or non-expiring passwords, interactive logons by service accounts and recent changes to delegation settings. Attackers often establish persistence through a new account, a modified Group Policy Object or a service account that looks operationally legitimate.
Review backups before restoring anything. A system-state backup is useful only if it predates the compromise and can be linked to reliable monitoring evidence. A backup created after an attacker obtained domain administrator access may contain backdoors, altered policies or stolen secrets. The same caution applies to virtual machine snapshots; rolling back a compromised controller can reintroduce malware and create directory replication problems.
Organisations mapping dependencies across identity, endpoint and network layers may find a security navigation guide useful as a planning reference, but it should supplement incident evidence rather than replace Microsoft recovery guidance or forensic validation. The central decision is simple: restore a known-clean controller, or rebuild the identity foundation because no existing controller can be trusted.
Rebuild The Forest In A Controlled Sequence
If the domain or forest is compromised, a clean forest recovery is usually safer than attempting to clean every controller in place. Prepare trusted installation media, a hardened recovery network, documented naming and addressing information, DNS requirements, time sources and a list of applications that depend on Active Directory. Confirm which backup is clean before it enters the recovery environment.
A typical sequence begins with a clean forest root or the authoritative domain, followed by DNS, the appropriate Flexible Single Master Operations roles, global catalogue services and additional domain controllers. Restore only the required system state from an approved backup, or build new controllers and recreate directory objects when the backup cannot be trusted. Keep recovered controllers isolated until replication, DNS registration and security baselines have been checked.
Do not restore all domain controllers simultaneously. That can replicate bad data or make it difficult to identify which system reintroduced a compromise. Recover one authoritative controller, validate it, then introduce additional controllers one at a time. Disable unnecessary services, apply current patches, enable secure administration and restrict domain controller logon rights before reconnecting production networks.
The KRBTGT account requires particular care. In a confirmed or strongly suspected ticket-forgery incident, reset its password twice, allowing sufficient time for replication and for existing tickets to expire between resets. The exact interval depends on the environment, ticket lifetimes and Microsoft’s current forest recovery guidance. Resetting too quickly, or resetting it before replication is healthy, can cause authentication failures without removing every forged-ticket risk.
Reset Trust Across Users, Services And Systems
Resetting the domain administrator password is only one part of credential recovery. Change passwords for Enterprise Admins, Domain Admins, delegated administrators, backup operators, virtualisation administrators, database administrators and emergency accounts. Perform these changes from clean devices and review authentication logs after each stage.
Service accounts deserve a separate workstream. Inventory traditional accounts, group Managed Service Accounts, scheduled tasks, IIS application pools, database services, backup agents and integrations that use domain credentials. Rotate their secrets, update dependent services and remove unnecessary interactive logon rights. A forgotten service account can give an attacker a reliable route back into the rebuilt environment.
Re-establish machine trust gradually. Rejoin servers and workstations only after malware checks, local administrator password rotation, patching and endpoint protection validation. Where appropriate, reset the computer account or remove and rejoin the device rather than assuming its secure channel is sound. Pay particular attention to jump servers, software deployment systems, hypervisors and management platforms because they often hold broad access.
Review trust relationships with other forests, suppliers and cloud identity services. Conditional access, federation certificates, synchronisation accounts and application secrets may have been exposed even if the on-premises domain appears clean. Australian organisations commonly rely on a mixture of Microsoft 365, outsourced payroll, managed infrastructure and state-based offices, so recovery must include those external dependencies rather than stopping at the domain boundary.
Validate Recovery And Make It Durable
Validation should test security and business function together. Confirm that users receive fresh tickets, service accounts authenticate as expected, DNS resolves correctly, time remains synchronised and replication is healthy. Test file shares, applications, remote access, printing, backup, monitoring and privileged access from clean systems. A controller that passes a ping test but issues invalid tickets is not recovered.
Use detection rules for Golden Ticket indicators, unusual ticket lifetimes, abnormal encryption types, DCSync behaviour, privileged group changes and authentication from unexpected locations. Compare the rebuilt environment with known-good baselines. Keep enhanced logging in place for longer than the immediate incident window because an attacker may wait for normal operations to resume before attempting re-entry.
The recovery report should explain the initial access, affected identities, systems rebuilt, credentials rotated, backups used, evidence retained and residual risks. It should also record decisions about notification, regulators, customers and insurers. For teams working under the Essential Eight, the incident is a useful test of whether privileged access management, application control, patching, backups and multifactor authentication operate as designed during a real disruption.
Future resilience comes from rehearsing the procedure before an emergency. Maintain offline or otherwise protected backups, clean administrative workstations, current forest documentation and tested contact paths for internal teams and external responders. Run exercises that include a failed domain controller, a compromised cloud synchronisation account and a regional office losing connectivity. The practical goal is a recovery process that works on a busy Tuesday in Melbourne, not just in a quiet lab.
A Kerberos incident should be treated as a possible identity-system compromise until evidence proves otherwise. Preserve first, isolate carefully, rebuild from a trusted foundation when necessary, reset the secrets that issue and protect tickets, and reconnect services in measured stages. The key point to remember is that restoring domain controllers is successful only when the identity they provide is trusted again.