How Active Directory Attacks Work

Active Directory attacks work by obtaining a credential, escalating to a privileged account, and then modifying the directory or its domain controllers to establish control that survives remediation. Almost every step uses valid authentication and legitimate administrative tooling, which is why AD compromise is usually discovered through the modifications it leaves rather than through the authentications themselves.

Getting the first credential

Nothing exotic is required. Phishing, password spraying against exposed authentication endpoints, a credential in a script on a file share, a service account password that has not rotated since 2019, or a foothold on a workstation where an administrator recently logged in.

What matters is that the credential is real. From this point forward the attacker is authenticating correctly, and most of the defensive difficulty follows from that fact.

Finding the path to privilege

An attacker with any domain credential can read a great deal of AD. Group memberships, trust relationships, service principal names, delegation settings, ACLs on objects. This is by design, because the directory has to be readable to function.

Attack path mapping tooling turns that readable structure into a route: this account can reset that account’s password, that account is in a group with rights over a third, and four hops later you are a domain administrator. These paths accumulate over years of delegation nobody revisited, and most large environments have several.

Common escalation techniques include Kerberoasting service accounts with weak passwords, abusing unconstrained or constrained delegation, exploiting ACL misconfigurations, and certificate services misconfigurations that let a low-privileged account request a certificate for a privileged one. For the host-to-host mechanics behind each hop, see how attackers move laterally.

Establishing control

This is where the attack becomes durable, and it is also where it becomes visible if anything is watching the right thing.

• Credential material extraction. Dumping the AD database from a domain controller, or extracting the KRBTGT hash to forge Kerberos tickets that remain valid until the account is reset twice.
• Directory modification. Adding accounts to privileged groups, altering group policy to push changes estate-wide, modifying ACLs to grant durable rights, changing service account configuration.
• Domain controller modification. Writing binaries, creating or altering services, adding scheduled tasks, changing registry keys. This is host-level change on the most privileged servers in the environment.
• Techniques designed to leave no log. DCShadow registers a rogue domain controller to inject changes through replication rather than through a logged administrative action, which is specifically built to evade log-based auditing.

Why the identity layer struggles here

None of this is a failure of identity tooling. It is a description of the boundary each control was designed to hold.

Configuration assessment finds the paths before they are used. Tools that scan AD for misconfigurations and attack paths are genuinely valuable and underdeployed. They reduce how many routes exist. They do not evaluate what happens once an attacker is on one.

Identity threat detection recognizes abnormal behavior. Behavioral analytics catch a meaningful share of credential compromise, particularly password spraying and unusual authentication patterns. The limit is that a privileged account doing privileged things is not abnormal, and a patient attacker operating within normal working hours through expected paths produces a weak signal.

Access controls decide whether a login proceeds. Risk-based access and conditional policy raise the cost of using a stolen credential considerably. They evaluate the authentication event. They do not evaluate the twenty administrative actions taken after a session is established.

Change auditing records what happened. AD auditing tooling produces the record that makes investigation and compliance possible, and the better implementations read the replication stream specifically because it captures changes that log-based approaches miss. Auditing is a record of a change that occurred.

Recovery restores the directory afterward. Forest recovery is a hard engineering problem and the products that solve it are valuable. It is also, by definition, something you use after the attack succeeded.

The step that is a host change

Follow the sequence and one thing stands out. The credential theft is a credential problem. The escalation is a configuration problem. But establishing durable control almost always requires changing a host, and usually a domain controller.

Writing a binary to a DC. Registering a service. Adding a scheduled task. Modifying a registry key. These are not identity operations. They are file, process, service and registry modifications on a server, and a server has an authorized operating state that can be described.

That framing changes the question from whether the actor was legitimate, which is unanswerable once a real credential is in play, to whether this specific change belongs on this specific system, which is answerable.

Mimic profiles protected systems including domain controllers in their authorized state and evaluates changes at the kernel before they execute, which means a valid domain administrator credential confers no authorization for a change outside that baseline. The general principle holds regardless of tooling: if nothing evaluates the change on the host, a stolen privileged credential is an unconditional grant.

The mechanism underneath is known-good enforcement, and the same checkpoint anchors ransomware defense. For what this looks like in a production environment, see how REI defended its Active Directory. For the wider framing of who can act versus what can change, start with Active Directory security.