Active Directory Attacks & Detection

Kerberoasting

Kerberoasting targets the ticket-granting service exchange that Chapter 3 walked through in detail. Once a user holds a valid TGT, they can request a service ticket (TGS) for any resource by presenting that TGT to the KDC and naming the Service Principal Name (SPN) they want to access. The KDC does not verify that the requester actually needs that service, it simply encrypts the resulting TGS using the target service account's password hash and hands it back.

That single design detail is what makes Kerberoasting possible: any authenticated domain user, with no special privileges at all, can request a TGS for every SPN-registered account in the domain. The attack itself has no exploitation step in the traditional sense.

The Attack, Step by Step

1. Enumerate SPNs. The attacker queries Active Directory, typically through an LDAP query against the servicePrincipalName attribute, to find every account registered to a service.
2. Request a TGS for each SPN. Using an already-authenticated session, the attacker requests a service ticket for every SPN found, generating no failed-logon events in the process.
3. Take the ticket offline. Because the TGS is encrypted with the service account's NTLM password hash, the attacker walks away with ciphertext to crack independently, with no further contact with the domain controller.
4. Crack it. If the offline cracking succeeds, the attacker now holds the plaintext password for that service account.

Why Service Accounts Are Prime Targets

Service accounts tend to have the weakest passwords in the environment. They are often created once during an application deployment and never rotated again, because rotating them risks breaking whatever service depends on them. Some are decades old.

Many run with elevated privileges, including Domain Admin membership in poorly segmented environments, because it was easier to grant broad rights during initial setup than to scope permissions correctly. An attacker does not need to crack every roasted ticket, they only need one weak service account to open a path to real privilege.

Mitigation

The most direct mitigation is using Group Managed Service Accounts (gMSAs), which have long, automatically rotated passwords that are never known to a human and therefore effectively resist offline cracking.

Where legacy service accounts cannot be converted to gMSAs, enforcing long randomly generated passwords and requiring AES rather than RC4 ticket encryption removes most of the practical risk, since RC4-encrypted tickets crack dramatically faster than AES-encrypted ones.

AS-REP Roasting

AS-REP Roasting is Kerberoasting's companion technique. It targets an earlier point in the same exchange, the initial AS-REQ/AS-REP step that produces the TGT in the first place, rather than the TGS step.

Normally, Kerberos pre-authentication requires a client to prove knowledge of the account's password before the KDC will issue anything, by encrypting a timestamp with the account's password hash. Some accounts have this pre-authentication requirement explicitly disabled, usually to support a legacy application that cannot perform the pre-auth handshake correctly.

How the Attack Works

1. Identify pre-auth-disabled accounts. The attacker only needs a valid username, no password, no authenticated session at all.
2. Request an AS-REP directly. The KDC returns the AS-REP without ever asking for proof of the password.
3. Extract the encrypted portion. Part of that response is encrypted with the account's own password hash.
4. Crack it offline. The attacker takes the ciphertext away and cracks it exactly the way they would a roasted TGS.

AS-REP Roasting vs Kerberoasting

The critical difference is the starting requirement. Kerberoasting needs a valid, authenticated session first. AS-REP Roasting needs nothing but a valid account name, which makes it viable very early in an intrusion, often straight after basic domain user enumeration.

Finding and Fixing Vulnerable Accounts

Finding vulnerable accounts is trivial for an attacker with any domain visibility. The "Do not require Kerberos preauthentication" setting is a single readable UserAccountControl flag on the account object.

Defensively, the fix is usually just as simple. Disabling pre-authentication should be treated as an exception that requires justification and periodic review, not a default anyone can toggle without oversight.

DCSync

DCSync does not exploit a bug. It abuses a legitimate, necessary piece of Active Directory's own architecture: domain controllers replicate directory data, including password hashes, between each other constantly using the Directory Replication Service Remote Protocol (DRSUAPI).

How Replication Is Abused

1. Normal replication. A domain controller that wants a copy of another DC's data, including password hashes, simply requests it as part of routine replication.
2. Impersonation. DCSync works by having a compromised account issue that same replication request, impersonating a peer domain controller even though it is not one.
3. Hash retrieval. The receiving DC responds as it would to any peer, handing back password hash data for the requested account.

In practice, an attacker reaches this point either by compromising an account already in one of those privileged groups, or by finding a misconfigured ACL where the replication rights were granted too broadly. That second path happens more often than it should, usually through delegated administration mistakes.

Why It's Equivalent to Full Domain Compromise

Once an attacker can pull arbitrary password hashes on demand, they can retrieve the krbtgt account's hash directly. That is the single most damaging piece of data in the domain, because it enables the Golden Ticket attack described next.

They can also pull hashes for every privileged account, every service account, and every domain controller's machine account, all without deploying any malware or touching disk on a single additional host. It is quiet, it is fast, and it requires nothing more than a network path to a domain controller and the right permissions.

Because DCSync rides on a protocol domain controllers use with each other constantly, the defensive question is never "did replication happen," it is "who initiated it and does that make sense." That distinction drives the detection approach covered later in this chapter.

Golden and Silver Tickets

A Golden Ticket is the endgame of a krbtgt compromise. The krbtgt account's password hash is what the KDC uses to sign every TGT it issues, and an attacker who obtains that hash, typically via DCSync, can forge a TGT for any account, including accounts that do not exist, entirely offline.

There is no request to a domain controller involved in creating the forged ticket at all. The attacker builds the ticket data themselves, signs it with the stolen krbtgt hash, and it will be accepted as legitimate by any domain controller because cryptographically it is indistinguishable from a ticket the KDC actually issued.

A Silver Ticket is the more surgical sibling of the same idea. Instead of forging a TGT signed with the krbtgt hash, the attacker forges a TGS directly, signed with a compromised service account's own password hash, the same hash targeted by Kerberoasting.

Because a Silver Ticket is scoped to one specific service, it grants access only to that service rather than the whole domain. It comes with a meaningful advantage for the attacker: since it never requires contact with a domain controller at all, not even the initial forgery step, there is effectively no domain controller Kerberos event generated for its creation or use.

Golden vs Silver Ticket

Same Root Cause

Both techniques share the same root cause. Once an attacker holds the right symmetric key, whether that is krbtgt for domain-wide forgery or a single service account's hash for scoped forgery, Kerberos has no mechanism to distinguish a forged ticket from a genuine one at the cryptographic level.

Defense has to happen at the level of protecting those keys and detecting anomalous consequences of their misuse, not at the protocol level.

Detection Strategy for Each Attack

Chapter 6 covered the Windows Security event logging pipeline in depth, and every one of these attacks leaves a signal somewhere in that pipeline. Even with Silver Tickets, the signal is largely an absence rather than a presence.

The common thread across all four techniques is that none of them are a single alertable event on their own. A single 4769 is normal domain activity thousands of times a day. What matters is volume, pattern, and context around the baseline your environment actually produces.

What Each Attack Looks Like in the Logs

• Kerberoasting: an unusual concentration of 4769 (Kerberos Service Ticket Operations) events, particularly one account requesting TGS tickets for many distinct SPNs in a short window, especially when the ticket encryption type field shows 0x17 (RC4) rather than AES, since attacker tooling has historically defaulted to the weaker encryption type to speed up offline cracking.
• AS-REP Roasting: 4768 (Authentication Ticket Request) events for accounts that never generate a corresponding 4771 pre-authentication failure, correlated with 4625 failed logons or account enumeration activity that typically precedes an attacker identifying which accounts have pre-auth disabled.
• DCSync: 4662 (An operation was performed on an object) events carrying the Replicating Directory Changes or Replicating Directory Changes All extended right GUIDs, sourced from an account or host that is not a domain controller. This is the single highest-fidelity signal in this entire chapter, because that combination almost never has a legitimate explanation.
• Golden Ticket use: less a single event, more an inconsistency: TGTs with lifetimes that exceed policy, 4624 logon events tied to tickets whose issuing domain controller cannot be corroborated, authentication for accounts deleted or disabled after the krbtgt hash was likely stolen, and PAC validation failures where a domain controller cannot verify the privilege data embedded in a presented ticket.

The Silver Ticket Exception

Silver Tickets deserve a special note here because they are the exception to "check the event log." Since the forged TGS never touches a domain controller, there may be no anomalous Kerberos event at all on the DC side.

Detection shifts to the target service itself: unusual PAC contents in the ticket presented to the application, service-level authentication logs that do not correlate with any domain controller ticket issuance, and endpoint telemetry showing the tooling used to forge the ticket in the first place.

This is a good reminder that log-based detection is only as strong as the logging surface an attack actually touches. Building detection coverage means thinking about where in the exchange each technique deliberately avoids leaving evidence.

Where This Module Fits in H3AD-LEARN

This chapter is a capstone, not an endpoint. The four attacks covered here are exactly the kind of activity the rest of the platform assumes you can recognize by name.

Threat Hunting

The Threat Hunting module's hypothesis-driven methodology is precisely how a hunter would go looking for the DCSync and Kerberoasting patterns described in this chapter. That means forming a specific, falsifiable hypothesis about anomalous replication traffic or an SPN enumeration spike, then pivoting through logs to confirm or rule it out, rather than waiting for a signature-based alert to fire.

LOLBAS

The LOLBAS module covers the living-off-the-land binaries that attackers frequently pair with these Active Directory attacks once they have working credentials or a forged ticket in hand. Gaining domain-level access is rarely the final objective, it is the enabler for lateral movement using tools already present on the target systems.

Understanding both halves, how the credential was obtained and how it gets used to move, is what turns an isolated detection into a full incident narrative.

Threat Intelligence and Networking

The Threat Intelligence module's actor-profiling content is what turns a raw finding like "someone performed a DCSync operation" into something genuinely actionable: "this replication pattern, combined with this ticket lifetime and this lateral movement tooling, matches a known APT group's documented TTPs." Detection tells you something happened. Intelligence tells you who is likely behind it and what they typically do next.

The Networking module's Kerberos-on-the-wire content, sibling material to its TLS chapter, gives you the network-level view of the exact same protocol this module has covered from the Windows host and domain controller side. Seeing both views, the packet capture and the Security event log, is what makes Kerberos anomalies obvious instead of theoretical.

The Technical Baseline

Taken together, the Fundamentals module, the Networking module, and this Windows module form the technical baseline underneath nearly every specialization on this platform.

Whichever direction you take next, threat hunting, threat intelligence, cloud security, or living-off-the-land detection, you will be drawing on the ticket exchange, the logging pipeline, and the attack patterns this module built from the ground up.