Recovering Domain Controller Credentials After a Golden Ticket Attack

Recovering domain controller credentials after a Golden Ticket attack is a trust-restoration exercise, not a simple password change. An intruder who obtains the KRBTGT account hash can forge Kerberos ticket-granting tickets, potentially creating long-lived access to domain resources without logging in through normal authentication paths.

The priority is to contain the breach, establish which systems and accounts may be compromised, and rebuild authentication from a trustworthy state. That usually involves resetting privileged credentials, rotating the KRBTGT secret twice, checking domain controllers for persistence, and validating every important dependency before services return to normal.

Australian organisations also need to consider operational and regulatory realities. A hospital in Melbourne, a miner operating across Western Australia, and a financial institution in Sydney may have very different recovery windows, identity architectures and reporting obligations. APRA-regulated entities, for example, need clear evidence that security controls and incident response processes remain effective under CPS 234.

The work is rarely handled by one administrator in isolation. It typically involves the internal identity team, a managed security operations centre, incident responders, infrastructure owners and senior decision-makers. Coordinated response matters because a rushed reset can lock out applications, while a narrow reset can leave an attacker’s access intact.

Why A Golden Ticket Changes The Recovery Task

A Golden Ticket is a forged Kerberos TGT created with the secret material associated with the domain’s KRBTGT account. It may contain a chosen username, group memberships and a long validity period. Once accepted by domain controllers, the ticket can allow access to services across the domain without the attacker possessing the legitimate user’s password.

This means a single account reset cannot be treated as full remediation. Even if a domain administrator password is changed, a forged ticket may continue to work until it expires or the KRBTGT secret is changed. The attacker may also have used the original access to create additional privileged accounts, alter group membership, deploy scheduled tasks or compromise backup infrastructure.

The objective is therefore to invalidate forged tickets and remove the conditions that enabled them. Treat the domain as potentially untrusted until evidence supports a narrower assessment. This is especially important in hybrid environments where on-premises Active Directory synchronises identities to Microsoft Entra ID and cloud applications.

A Golden Ticket can also obscure the original entry point. The compromise may have begun with a phished administrator, an exposed remote service, a vulnerable application or stolen credentials from a workstation. Recovering authentication without addressing that entry point risks a second compromise shortly after the first recovery.

Confirm Scope Before Changing Secrets

Begin by preserving evidence and building a timeline. Secure logs from domain controllers, identity providers, endpoint detection platforms, VPN concentrators, firewalls, privileged access systems and backup consoles. Export relevant data to protected storage so an attacker cannot alter the working evidence during containment.

Look for unusual ticket lifetimes, authentication from unexpected hosts, privileged group changes, directory replication activity and logons involving accounts that do not normally administer the domain. Events associated with Kerberos service ticket requests, account management and directory replication can help identify suspicious activity, although the absence of a useful event does not prove that no abuse occurred.

Identify every domain controller, including read-only domain controllers, virtual machines, disaster recovery instances and recently decommissioned systems that may still contain sensitive material. Confirm their operating system versions, patch levels, replication health and physical or cloud locations. A forgotten controller in a Brisbane office or a remote mining site can undermine an otherwise careful reset.

Containment should be proportionate and controlled. Isolate confirmed compromised hosts, restrict administrative access to clean jump servers, block known command-and-control paths and protect backups from alteration. Avoid indiscriminately powering off controllers before collecting volatile evidence or checking whether critical services depend on them.

Reset Trust At The Domain Level

The most important remediation step is rotating the KRBTGT password twice. The first reset invalidates tickets signed with the previous secret after replication and ticket lifetimes are considered. The second reset invalidates tickets that may have been created using the previous current and historical keys. Microsoft guidance and approved recovery tooling should determine the interval between resets for the organisation’s topology.

Do not treat this as a quick console exercise. Verify that domain replication is healthy before the first reset, record the sequence and allow sufficient time for the new secret to replicate. In a multi-site Australian network, latency between Sydney, Perth and remote operational locations may affect the schedule. The identity team should monitor replication rather than relying on an assumed delay.

Reset all potentially exposed privileged accounts, including Domain Admins, Enterprise Admins, administrators of virtualisation platforms, backup operators and accounts used for directory synchronisation. Machine account passwords, service accounts, local administrator credentials and certificates may also require rotation when their secrets could have been accessed.

Credential recovery does not mean recovering the old passwords. It means returning the environment to a state where only verified identities, devices and applications can authenticate. Review service dependencies before changing non-interactive accounts, and use a controlled maintenance window where possible. Guidance on credential sharing risks is also relevant because reused or casually shared passwords can widen the impact of a domain compromise.

Hunt For Persistence Beyond Kerberos

After rotating domain secrets, investigate how the attacker maintained access. Examine new and modified users, privileged groups, access control entries, Group Policy Objects, logon scripts, scheduled tasks, Windows services, startup locations and remote management configurations. Pay particular attention to changes made shortly before or after suspicious ticket activity.

Check for DCSync-capable permissions, unconstrained delegation, unusual constrained delegation settings and service principal names that do not match documented applications. Review domain trusts and external identity synchronisation. Certificate services deserve special attention because a compromised certificate authority or dangerous certificate template can provide an alternative route to privileged authentication even after password resets.

Hunt across endpoints for credential dumping tools, remote administration utilities, unusual PowerShell activity and malware associated with the initial access. Validate that endpoint security agents are healthy and that exclusions have not been created for attacker-controlled directories. A domain controller that looks clean at the operating system level may still be exposed through a compromised management server.

Backups require separate scrutiny. A clean backup is valuable only if its creation date and integrity are understood. Restoring a domain controller or system-state backup that contains the attacker’s modifications can reintroduce persistence. Keep recovery media isolated, test it in a controlled environment and document which systems are approved as the source of truth.

Operational Checklists

Validate The Rebuilt Identity Plane

Recovery is complete only when authentication and business services behave as expected under controlled testing. Start with core functions such as domain logon, DNS, Group Policy, file services, virtualisation management, backup operations and endpoint management. Then test applications that depend on LDAP, Kerberos, NTLM, service accounts or directory synchronisation.

Use clean administrative workstations and separate privileged accounts for verification. Confirm that old tickets are rejected, unexpected privileged access has disappeared and normal users have the minimum access required. Monitor for renewed authentication from isolated hosts, fresh account creation, abnormal replication requests and attempts to access sensitive shares.

A coordinated incident response model is particularly useful for large Australian organisations. A national retailer may need to align stores, distribution centres and a cloud service provider, while a local council may rely on a managed service provider for after-hours monitoring. Clear ownership prevents the familiar arvo scramble in which several teams make untracked changes to the same identity environment.

Notify relevant stakeholders according to the confirmed impact. The Office of the Australian Information Commissioner may need to be considered under the Notifiable Data Breaches scheme, while sector-specific regulators, insurers, customers or law enforcement may have separate expectations. Keep technical findings distinct from assumptions, and preserve a defensible record of what was known at each decision point.

Compare Recovery Paths And Build Resilience

The correct recovery path depends on the degree of compromise, the quality of evidence and the importance of domain-dependent services. A limited incident with a trustworthy controller fleet may be remediated in place. A widespread compromise involving domain controllers, certificate services or backup systems may justify rebuilding the forest or establishing a clean domain and migrating workloads.

Forest recovery is disruptive but can provide stronger assurance when administrators cannot establish which controllers or privileged accounts remain trustworthy. In-place remediation is faster and may be appropriate where the attack path is understood, evidence is reliable and the identity team can validate every critical component. The decision should be recorded and approved at the right business level.

Recovery approach Best suited to Main advantage Primary risk
Targeted in-place remediation Confirmed, contained compromise Faster return to service Hidden persistence may survive
Full credential and trust reset Domain-wide Golden Ticket activity Invalidates forged authentication paths Service disruption and dependency failures
Clean forest or domain rebuild Extensive controller or certificate compromise Strongest trust reset Long migration and operational impact
Hybrid recovery with staged migration Complex enterprises with critical legacy systems Balances assurance and continuity Requires careful coexistence controls

Long-term resilience comes from reducing the value of any single credential. Use phishing-resistant multifactor authentication for privileged access where supported, tier administration between workstations and servers, restrict domain controller access, deploy privileged access management and monitor directory changes. The Australian Cyber Security Centre’s Essential Eight provides a practical baseline, while organisations subject to APRA requirements should map recovery evidence to their broader information security governance.

Review identity architecture after the incident. Separate high-risk service accounts, remove stale trusts, enforce strong administrative boundaries and improve alerting for replication abuse and unusual Kerberos activity. In hybrid environments, protect synchronisation servers and cloud administrator accounts as carefully as domain controllers. A recovery exercise should prove that the organisation can restore identity services without restoring attacker access.

The practical takeaway is straightforward: isolate the breach, preserve evidence, rotate KRBTGT twice, reset every exposed trust relationship, verify clean infrastructure and test business services before declaring recovery. Treat domain credentials as part of a wider identity system, because durable remediation depends on removing the attacker’s access paths rather than changing passwords in isolation.