How to protect Active Directory during an ongoing attack

Active Directory is often the control centre of an enterprise environment. It governs authentication, access to file shares, cloud applications, servers, endpoints and administrative tools. When an attacker gains a foothold, the directory can quickly become the mechanism that turns one compromised account into a business-wide incident.

Protecting Active Directory during an ongoing attack requires a different mindset from routine hardening. Security teams must preserve enough identity infrastructure for essential operations while restricting the paths an intruder uses to expand access. Every change should be deliberate, logged and reversible where possible.

The first priority is to understand whether the attacker has reached domain administrator, enterprise administrator, federation, certificate or backup privileges. A compromised standard user account is serious, but a stolen privileged token or forged authentication ticket can change the response entirely. Treat identity telemetry, endpoint evidence and network activity as one investigation.

Australian organisations also need to account for local operating conditions. A business with teams in Sydney, Melbourne and Perth may have different support rosters and time zones, while a regional hospital, mining company or utilities provider may have limited tolerance for shutting down authentication services. The response must therefore combine containment with continuity planning.

Establish an accurate view of the attack

Begin by identifying the assets that can issue or validate identity: domain controllers, read-only domain controllers, federation servers, synchronisation tools, privileged access workstations, certificate authorities and backup systems. Confirm their locations, operating status and dependencies. A flat list of servers is less useful than a map showing which systems authenticate to which domain controllers and where privileged administration occurs.

Use security information and event management, endpoint detection and response, directory auditing and network telemetry together. Look for unusual logon times, authentication from unfamiliar hosts, new service accounts, group membership changes, replication activity, remote service creation and attempts to access the NTDS database. PowerShell, Windows Remote Management and remote desktop activity deserve particular scrutiny when they appear outside normal administrative patterns.

Preserve evidence before making broad changes. Export relevant logs to an isolated destination, record the current membership of sensitive groups and capture the configuration of trust relationships. If an attacker is still active, avoid relying exclusively on systems that may have been altered. A clean administrative workstation and an independent communication channel are valuable safeguards.

Email and identity signals can reveal the wider campaign. A sudden wave of password-reset messages, fake Microsoft 365 alerts or unusual outbound mail may indicate that the attacker is using compromised accounts for further access. Monitoring sender reputation checks can add useful context when suspicious messages, spoofing or account takeover are part of the incident.

Contain identity-based movement

Containment should focus on the attacker’s ability to authenticate, escalate and move laterally. Disable confirmed-compromised accounts, revoke active sessions and invalidate tokens where the identity platform supports it. Resetting a password alone may not remove a stolen session, cached credential, access token or Kerberos ticket.

Apply restrictions in stages. Block known malicious source addresses, isolate affected endpoints, remove compromised machines from privileged administration paths and limit remote management to approved jump hosts. If a domain controller is suspected of compromise, do not treat it as a trusted source for password changes or forensic conclusions. A clean domain controller or carefully prepared recovery environment may be required.

Privileged groups need immediate review. Check Domain Admins, Enterprise Admins, Administrators, Account Operators, Backup Operators, Server Operators, delegated groups and custom groups with access to critical systems. Look for recently added members, nested group changes and accounts that have acquired rights through permissions rather than obvious group membership.

Where possible, separate emergency accounts from ordinary administrator accounts and protect them with strong, unique credentials. Do not use a shared “break glass” password across several systems. Store emergency credentials in a controlled vault, restrict who can access them and create an alert for every use.

Protect the domain controllers and trust paths

Domain controllers should be treated as high-value infrastructure during an incident. Restrict interactive logon, remote desktop and administrative protocols to authorised management networks. Remove unnecessary internet access, verify security tooling is functioning and check that time synchronisation remains reliable. Kerberos depends heavily on accurate time, so uncontrolled clock changes can create both outages and investigative confusion.

Inspect replication health and configuration. Attackers may exploit replication permissions to obtain credential material without logging directly into a domain controller. Review accounts with directory replication rights, unexpected replication partners and changes to site or subnet configuration. A clean domain controller should be compared with known-good baselines rather than assumed to be trustworthy because it has not raised an alert.

Certificate services and federation infrastructure require special attention. A compromised certificate authority can allow an intruder to create authentication certificates that survive password resets. Federation servers and synchronisation agents can provide a bridge between on-premises identity and cloud services. Their service accounts should be assessed, and secrets should be rotated from a clean administrative environment.

Use network controls to protect authentication traffic. Segmentation between user networks, server networks and domain controller networks reduces the attacker’s options. For Australian enterprises operating across offices, warehouses and remote sites, this may require temporary rules that preserve business-critical links while blocking administrative protocols between locations.

Recover credentials and restore trust

Credential recovery must be systematic. Reset privileged accounts first from a trusted device, then service accounts, automation identities and standard users according to the level of exposure. A broad reset can cause operational failures when applications rely on stored credentials, so maintain an inventory of dependencies and rotate secrets in a controlled sequence.

If there is evidence of domain compromise, consider a coordinated reset of the Kerberos service account and other high-impact secrets. This requires careful planning because incorrect sequencing can disrupt authentication across the environment. The response team should document each change, test essential services and retain a path to reverse or remediate failed changes.

Backups deserve the same suspicion as production systems. Verify that backup consoles, repositories and service accounts were not reachable by the attacker. Prefer offline, immutable or logically separated copies, and test restoration in an isolated environment. A backup that restores encrypted systems but also restores malicious scheduled tasks or compromised accounts is not a dependable recovery point.

The Australian Signals Directorate’s Essential Eight provides a useful baseline for reducing future exposure, particularly around multi-factor authentication, privileged access management, application control, patching and regular backups. Organisations covered by sector obligations, including parts of the critical infrastructure market, should also align incident decisions with internal reporting procedures and relevant regulatory requirements.

Recovery should include a decision about whether the existing domain can be trusted. If attackers held privileged access for an unknown period, rebuilding selected identity components or creating a new forest may be safer than repeatedly cleaning the old one. That decision depends on forensic evidence, business impact, available backups and the confidence of the response team.

Coordinate response and make the next incident faster

A directory attack is rarely confined to the identity team. Security operations, infrastructure, cloud administrators, legal advisers, communications staff, business owners and managed service providers may all need to act within minutes. Establish one incident lead, define who can approve disruptive containment and record decisions in a shared timeline.

Use an incident response platform or coordinated case process to connect endpoint findings, identity events, network blocks and recovery tasks. CARM Security, for example, is designed to bring together technologies from multiple security vendors for post-breach identification, containment, response and remediation. That model is valuable when separate tools produce important evidence but no single console shows the complete attack path.

Run exercises before the next emergency. An emergency response drill can expose practical weaknesses such as unavailable contacts, unclear authority to disable accounts, missing break-glass credentials or recovery steps that depend on the compromised domain. Exercises should include a realistic decision about whether to keep authentication online, isolate a site or move critical users to an alternate process.

The exercise should reflect local operating realities. A Melbourne head office may have a different escalation path from a mine site in Western Australia, while an outsourced service desk may operate on a separate schedule. Include public holidays, after-hours coverage, supplier dependencies and the possibility that telecommunications or cloud access is degraded. Clear handover notes are especially important when teams work across Australian time zones.

The following framework helps teams choose a response proportionate to the evidence and business risk:

Situation	Immediate control	Identity action	Recovery priority
Compromised standard account with no privilege escalation	Isolate affected device and block suspicious sessions	Disable account, revoke sessions and reset credentials	Validate endpoint and review recent activity
Suspicious privileged group change	Restrict administrative access and preserve logs	Remove unauthorised membership and rotate exposed credentials	Review all privileged accounts and delegation
Suspected domain controller compromise	Segment controller and restrict administration	Reset high-value secrets from a trusted environment	Validate or rebuild directory services
Possible replication abuse	Block unusual replication paths and protect clean controllers	Remove unauthorised replication rights	Reassess forest trust and credential exposure
Ransomware affecting identity and servers	Isolate infected networks while preserving safe communications	Use clean emergency accounts and controlled resets	Restore identity, backups and critical services in order
Cloud and on-premises identity both affected	Revoke risky sessions and suspend unsafe synchronisation	Rotate federation, synchronisation and privileged credentials	Re-establish trusted connections and enforce MFA

Active Directory protection during an attack is a sequence of controlled decisions: establish what is trusted, restrict how the intruder can authenticate, protect the systems that issue identity, rotate credentials from a clean position and restore services in a tested order. The practical takeaway is to keep an isolated administrative path, current privileged-access records, protected backups and a rehearsed response process ready before a live incident makes every minute expensive.