Active Directory Attacks Explained: Four Identity Paths Defenders Should Understand

Active Directory attacks are often described as a bag of tools. The more useful view is a set of identity and protocol conditions: reusable secrets, legacy authentication, overprivileged accounts, weak service credentials, and trust relationships that turn one foothold into another.

This article explains four frequently confused techniques. The examples are conceptual and intended for defensive learning and authorized laboratories.

The four techniques at a glance

1. Kerberoasting

Kerberos uses Service Principal Names to associate services with accounts. A domain user with a valid ticket-granting ticket can request a service ticket for an SPN. Part of that ticket is protected using key material derived from the service account’s secret, allowing an attacker to perform offline password guessing against the captured ticket.

MITRE classifies Kerberoasting as T1558.003. Its guidance highlights RC4 exposure, strong service-account passwords, AES support, minimal privileges, and group managed service accounts as relevant mitigations.^[1]

Important boundaries:

• Requesting a service ticket is normal domain behavior.
• The attack value comes from taking ticket material offline and guessing the service account secret.
• A cracked low-privilege service account is not automatically domain compromise.
• Service account permissions and reachable systems determine impact.

Defensive priorities

• Prefer group managed service accounts where supported.
• Use long, randomly generated service-account secrets.
• Remove unnecessary SPNs and privileged group membership.
• Prefer modern Kerberos encryption and reduce RC4 dependence.
• Baseline service-ticket requests and investigate unusual volume or targets.

2. AS-REP roasting

Kerberos normally requires a client to prove knowledge of its secret before the Key Distribution Center returns authentication material. If “Do not require Kerberos preauthentication” is enabled for an account, an attacker can request an AS-REP response without first proving knowledge of that account’s password. The returned material can be tested offline.

This differs from Kerberoasting in both target and request:

• Kerberoasting targets accounts associated with SPNs and usually begins with a valid domain context.
• AS-REP roasting targets accounts with Kerberos pre-authentication disabled and may permit collection without valid credentials, depending on enumeration and reachability.

Defensive priorities

• Find and eliminate unnecessary accounts with pre-authentication disabled.
• Apply strong, unique secrets to any unavoidable exception.
• Monitor relevant Kerberos authentication events and unusual AS-REQ patterns.
• Investigate why the exception exists instead of treating the flag alone.

3. Pass-the-hash

Pass-the-hash uses a stolen password hash to authenticate without recovering the original password. MITRE describes it as alternate authentication material used for lateral movement and distinguishes it from “overpass the hash,” where hash material helps obtain a Kerberos ticket.^[2]

This is why “the password was never cracked” is not comforting. In protocols that accept hash-derived proof, the hash functions like a reusable secret.

Pass-the-hash generally requires:

• access to valid hash material;
• a protocol and service that accepts the relevant authentication;
• network reachability;
• privileges granted to that account on the destination.

Defensive priorities

• Prevent credential material from being extracted through endpoint hardening.
• Use unique local administrator passwords through managed rotation.
• Restrict administrative logons and lateral management protocols.
• Segment privileged workstations and administration paths.
• Reduce NTLM use and monitor lateral authentication.
• Apply least privilege so one reused identity has a small blast radius.

4. NTLM relay

NTLM relay is not password cracking. An attacker causes or waits for a victim to authenticate, captures the live exchange, and forwards it to a service that will accept it. The attacker is effectively standing between the client and another service.

Whether relay succeeds depends on protocol protections, signing, channel binding, target configuration, identity privileges, and whether the destination prevents the same authentication from being used out of context.

Name-resolution poisoning and coerced authentication are common ways to obtain an exchange, but they are not the relay itself. This distinction helps defenders break the chain at several points.

Defensive priorities

• Require SMB signing where compatible and enforce it through policy.
• Use Extended Protection for Authentication and channel binding for supported services.
• Disable or restrict legacy name-resolution protocols where they are unnecessary.
• Reduce NTLM and audit remaining dependencies before enforcement.
• Prevent outbound authentication from sensitive systems to arbitrary destinations.
• Separate administrator identities and limit where they may authenticate.

Why tool-focused defenses fail

Blocking a filename or one executable does not remove the protocol condition. Attackers and authorized testers can implement the same behavior through different tools.

A stronger investigation asks:

What credential material exists?
  → Where can it be obtained?
  → Which services accept it?
  → Where can the identity log on?
  → What privileges and relationships follow?

That produces durable controls: protected credentials, constrained protocols, signing, segmentation, least privilege, and useful telemetry.

A safe lab learning order

1. Learn normal Kerberos and NTLM authentication flows.
2. Observe successful and failed logons in event data.
3. Create deliberately weak laboratory accounts.
4. Execute one authorized technique and follow its artifacts.
5. Apply the mitigation.
6. Repeat the test and verify both security and legitimate access.

Do not begin by downloading a large attack framework into a business network. A lab should isolate test identities and hosts, avoid real credentials, and have snapshots or a rebuild path.

Detection should describe behavior

Useful detection hypotheses include:

• one account requests an unusual number of service tickets;
• RC4 service tickets appear where AES is expected;
• accounts without pre-authentication receive unusual requests;
• privileged identities authenticate laterally from unexpected systems;
• a workstation sends NTLM authentication to an unusual service;
• the same identity reaches many hosts over a short interval.

Context matters. Vulnerability scanners, administration systems, and normal service activity can create volume. Combine authentication events with process, host, network, and asset context.

Report the attack path, not just the technique

“Kerberoasting possible” is incomplete. A useful finding states which account is affected, why ticket material is crackable in practice, what access the account has, what evidence was safely obtained, and which control change breaks the path.

For example:

Any domain user
  → requests RC4 service ticket for legacy-backup
  → weak service secret recovered offline in lab validation
  → account is local administrator on 18 servers

The remediation may require a managed service account, privilege reduction, stronger encryption, and monitoring—not merely a one-time password reset.

Sources