Active Directory (AD) is the heart of identity in most companies: it controls who each user is, which resources they can access and under what conditions. Compromising AD is, in practice, compromising the entire organization. That is why the Kerberos protocol, the foundation of AD authentication, has become one of attackers' favorite targets. This article explains how Kerberos works, maps the classic attacks against AD and details the hardening that separates a fragile domain from a resilient environment.
The role of Active Directory in the corporate network
Active Directory Domain Services (AD DS) is Microsoft's directory service that centralizes authentication, authorization and management of objects (users, groups, computers, policies). The Domain Controllers (DCs) host the directory database and process logon requests. Practically every internal resource — file shares, application servers, workstations, on-premises email — relies on AD to answer the question "who are you and what can you do?".
This centralization is a double-edged sword. It simplifies operations but concentrates risk: an attacker who obtains domain administrator privileges can move laterally, create persistent accounts, read any data and disable defenses. In ransomware incidents, the pattern is almost always the same — the attacker compromises a workstation, escalates privileges, takes over AD and only then triggers mass encryption. Understanding and protecting AD is not an ancillary IT task; it is first-order corporate risk control.
How Kerberos works
Kerberos has been AD's default authentication protocol since Windows 2000. It avoids transmitting passwords over the network by using encrypted tickets and a trusted third party. The core components are:
- KDC (Key Distribution Center)
- Service that runs on each Domain Controller. It splits into two roles: the Authentication Service (AS) and the Ticket-Granting Service (TGS).
- TGT (Ticket-Granting Ticket)
- Ticket obtained at logon that proves the user's identity to the KDC. It is encrypted with the krbtgt account key and has limited validity (typically 10 hours).
- TGS (Ticket-Granting Service ticket, or service ticket)
- Ticket specific to accessing a service (e.g., a share or a SQL Server), encrypted with the hash of the service account associated with the SPN.
- SPN (Service Principal Name)
- Unique identifier that ties a service to an account in AD. It is what allows the KDC to know which key to use to encrypt the service ticket.
The flow, simplified, has three exchanges:
- AS-REQ / AS-REP: the client requests a TGT from the AS. By default, with pre-authentication enabled, it sends a timestamp encrypted with its own password; the KDC validates it and returns the TGT.
- TGS-REQ / TGS-REP: holding the TGT, the client requests a service ticket for a specific SPN from the TGS. The KDC returns a ticket encrypted with the service account key.
- AP-REQ / AP-REP: the client presents the service ticket directly to the target service, which validates it and grants access — without ever consulting the user's password.
This elegant design has a dangerous side effect: any authenticated user can request a service ticket for any SPN, and that ticket is encrypted with the hash of the service account's password. It is exactly this property that enables Kerberoasting.
Classic attacks against AD and Kerberos
The attacks below are mapped in the Credential Access tactic of MITRE ATT&CK and are routinely observed in real intrusions. Understanding them is a prerequisite for detecting them.
Kerberoasting
The attacker, already authenticated as a regular user, requests service tickets for service accounts (which have an SPN) and extracts the encrypted tickets. Offline, they brute-force the hash until they discover the service account's password. Service accounts frequently have weak, old passwords with excessive privileges — ideal fuel. Mapped to T1558.003.
AS-REP Roasting
When an account has Kerberos pre-authentication disabled, the KDC returns in the AS-REP material encrypted with the hash of the user's password, even without proof of identity. The attacker collects this material and cracks it offline. Mapped to T1558.004.
Pass-the-Hash (PtH)
Instead of discovering the cleartext password, the attacker reuses the NTLM hash captured from memory (LSASS) to authenticate to other systems. It does not involve Kerberos directly, but it is the classic bridge to lateral movement. Mapped to T1550.002.
Pass-the-Ticket (PtT)
The attacker extracts valid Kerberos tickets (TGT or TGS) from memory and injects them into another session to impersonate the victim. Mapped to T1550.003.
Golden Ticket
If the attacker obtains the hash of the krbtgt account, they can forge arbitrary TGTs — for any user, with any privilege, with a validity they define. It is near-total domain persistence: as long as the krbtgt password is not rotated twice, the forged ticket remains valid. Mapped to T1558.001.
Silver Ticket
A more surgical variant: with the hash of a specific service account, the attacker forges service tickets for that service, without going through the KDC. Harder to detect because it does not generate TGS traffic on the DC. Mapped to T1558.002.
DCSync
Abusing the replication protocol (MS-DRSR), an account with the "Replicating Directory Changes" replication rights can ask the DC to hand over the password hashes of any account — including krbtgt and administrators. It is the cleanest way to exfiltrate credentials without touching LSASS. Mapped to T1003.006.
DCShadow
An evasion and persistence technique: the attacker registers a rogue Domain Controller and injects malicious changes into the directory (e.g., adding SID History or altering ACLs) that replicate as legitimate, bypassing many audit controls. Associated with T1207.
Attack map: technique, MITRE ATT&CK and detection
| Attack | What it exploits | MITRE ATT&CK | Detection signal |
|---|---|---|---|
| Kerberoasting | Service tickets from accounts with SPN | T1558.003 | Event 4769 in volume, RC4 cipher (0x17) |
| AS-REP Roasting | Accounts without pre-authentication | T1558.004 | Event 4768 with pre-auth disabled |
| Pass-the-Hash | Reused NTLM hash | T1550.002 | Logon 4624 type 3/9 with anomalous NTLM |
| Pass-the-Ticket | Tickets injected into memory | T1550.003 | TGS without matching TGT; atypical lifetime |
| Golden Ticket | krbtgt account hash | T1558.001 | TGT with anomalous lifetime; krbtgt anomaly |
| Silver Ticket | Service account hash | T1558.002 | Service access without 4769 on the DC |
| DCSync | Replication rights (MS-DRSR) | T1003.006 | Replication from a non-DC host (4662) |
| DCShadow | Rogue DC registration | T1207 | Unexpected new nTDSDSA object; GC SPN |
Privilege tiering: the Tier 0/1/2 model
The most important structural defense of AD is the administrative tiering model, recommended by Microsoft in the Enterprise Access Model. The idea is to prevent privileged credentials from being exposed on lower-trust systems.
- Tier 0
- Assets that control identity: Domain Controllers, AD CS, Domain/Enterprise Admin accounts, PAM systems. Compromising them = compromising everything.
- Tier 1
- Business servers and applications, corporate data. Administered by Tier 1 accounts, never with Tier 0 credentials.
- Tier 2
- Workstations and end-user devices, where most of the phishing risk lives.
The golden rule: a higher-tier credential must never perform an interactive logon on a lower-tier system, because its hash/ticket would be exposed in that host's memory. Privileged Access Workstations (PAWs) reinforce this separation.
Administrative accounts, LAPS and gMSA
Three practical controls drastically reduce the surface:
- Dedicated administrative accounts: separate the daily-use account from the privileged account. Minimize members of Domain Admins, Enterprise Admins and Schema Admins — ideally emergency accounts used only under break-glass.
- LAPS (Windows LAPS): automatically randomizes and rotates each machine's local administrator password, eliminating the reused local password that enables mass Pass-the-Hash.
- gMSA (Group Managed Service Accounts): service accounts with long passwords (240+ bytes) managed and rotated automatically by AD. They make Kerberoasting practically infeasible, since there is no weak password to crack.
Detection: Windows and AD events in the SIEM
AD generates rich events that, fed into a SIEM, allow hunting for the attacks above. The main identifiers:
- 4768 — Kerberos AS (TGT requested): monitor accounts with pre-authentication disabled (AS-REP Roasting) and anomalous issuance patterns.
- 4769 — Kerberos TGS (service ticket requested): spikes of requests by a single user for many SPNs, especially with Ticket Encryption Type 0x17 (RC4), are a strong indicator of Kerberoasting.
- 4624 — Successful logon: logon types 3 (network) and 9 (new credentials) with NTLM help flag Pass-the-Hash and lateral movement.
- 4662 / 5136 — directory object access: replication operations (DCSync) from hosts that are not Domain Controllers.
- 4738 / 4670 — changes to accounts and permissions: suspicious changes to ACLs and to SID History.
Effective detection is not about collecting everything — it is about correlating the right events with identity context. An isolated 4769 is noise; a hundred 4769 from the same user in RC4 within seconds is an attack.
Forward the logs from the DCs and Tier 0 servers to a SIEM with adequate retention, enable advanced auditing (Advanced Audit Policy) and build correlation rules based on MITRE ATT&CK. Identity-specific detection solutions (such as Microsoft Defender for Identity) complement the SIEM with behavioral analytics.
Hardening: closing the doors
Hardening AD combines configuration, credential hygiene and reduction of legacy protocols. Priorities, aligned with CIS Benchmarks and Microsoft's security guidance:
- Protected Users: place privileged accounts in the Protected Users group, which blocks NTLM, DES, RC4 and credential caching — neutralizing much of PtH and roasting.
- Disable RC4 (and DES): force AES on Kerberos tickets. RC4 is what makes Kerberoasting fast; its removal greatly raises the attack's cost. Make the transition while monitoring 4769 by cipher type.
- MFA for privileged access: require multi-factor authentication for administrators and remote access. A compromised password is no longer enough.
- Least privilege and SPN review: remove excessive privileges from service accounts, migrate to gMSA and eliminate orphaned SPNs.
- Double rotation of krbtgt: rotate the krbtgt account password periodically (twice, respecting the replication interval) — essential to invalidate Golden Tickets post-incident.
- Harden replication: restrict who has "Replicating Directory Changes" rights and monitor replications from unexpected sources to block DCSync/DCShadow.
- Credential hygiene: Credential Guard, Tier 0 logon restriction, PAWs and LAPS on all workstations and servers.
Reference frameworks such as NIST SP 800-63 (digital identity) and the CIS Microsoft Windows Server / CIS Benchmarks offer auditable baselines. The secret is to treat AD security as a continuous program, not a one-off project: the environment changes, new accounts appear, and configuration drift reopens doors.
References
- Microsoft — Best Practices for Securing Active Directory
- Microsoft — Enterprise Access Model (tiering)
- MITRE ATT&CK — Credential Access (TA0006)
- CIS Microsoft Windows Server Benchmarks
- NIST SP 800-63 — Digital Identity Guidelines
How Decripte protects your corporate identity
At Decripte, we treat Active Directory as a critical asset of any company — from 1 to more than 100,000 employees. We assess your domain's posture (tiering, privileged accounts, SPNs, Kerberos ciphers), implement hardening aligned with CIS and Microsoft, and connect the right events (4768/4769/4624) to continuous monitoring to detect Kerberoasting, DCSync and Golden Ticket attempts before they become an incident. Identity cybersecurity for every size — from the smallest business to enterprise.
Want to see where your environment is exposed? Start free through our Intelligence Center and discover your identity risk, or explore the plans to put your AD protection on autopilot.