← Back to Home

Yesterday's Compatibility,
Tomorrow's Exploit

In nuclear physics, half-life measures decay. In Active Directory, it measures how long Microsoft keeps insecure defaults for backwards compatibility. Spoiler: decades. Welcome to the time capsule... it's a little dusty.

Core AD Vulnerabilities Attack Research Tools
Core AD
1987

LAN Manager: The Authentication Protocol That Won't Die

Microsoft and 3Com announce LAN Manager (LanMan) as a network operating system for OS/2, with 1.0 shipping to OEMs in 1988. Its authentication protocol introduces the LM hash—a password storage mechanism designed for convenience, not security. The LM hash algorithm: convert the password to uppercase, pad or truncate to exactly 14 characters, split into two 7-character halves, and use each half as an independent DES key to encrypt a fixed constant ("KGS!@#$%"). The result is two 8-byte blocks concatenated into a 16-byte hash. This design has catastrophic security implications that would haunt Windows authentication for the next 30+ years.

Uppercase Only (Case-Insensitive) Split Into Two 7-Char Halves DES With Fixed Known Plaintext 14-Character Max Password
  • Why LM Hashes Are Terrible: By converting to uppercase, the character space drops from 95 to 69 printable ASCII characters. By splitting into two 7-character halves, a "14-character password" is really two independent 7-character passwords—each crackable separately. A 7-character password with 69 possible characters = ~7.5 trillion combinations per half. Modern GPUs crack both halves in seconds.
  • Fixed Plaintext Attack: Both halves encrypt the same known constant ("KGS!@#$%"), making this a known-plaintext attack. Rainbow tables for the entire LM hash keyspace have existed since the early 2000s.
  • The Legacy: Windows stored LM and NT hashes by default through Windows XP and Server 2003. Vista and Server 2008 changed the default so LM hashes were no longer generated when passwords were set or changed, effectively ending routine LM hash storage—20 years after the protocol shipped. NTLM's name reflects its lineage: NT LAN Manager was Microsoft's successor to the original LAN Manager authentication system, retaining LM compatibility for legacy reasons.
  • Challenge-Response: The LM challenge-response is equally weak. The 16-byte LM hash is split into three parts (7+7+2 bytes, last padded to 7), each used as a DES key to encrypt the server's 8-byte challenge. The third key has only 2 bytes of entropy—trivially brutable.
  • Sources: OS/2 Museum — LAN Manager 2.0 history · OS/2 Museum — 3+Open LAN Manager 1.1 (1989) · Jesper Johansson — "The Most Misunderstood Windows Security Setting of All Time" (TechNet Magazine, August 2006)
Core AD
1988-1996

AD Pre-History: From 3Com to Exchange

According to Don Hacherl, one of AD's original developers, the oldest traceable code started at 3Com in 1988-1989 as an incomplete X.500-ish directory with custom protocols, built on C-Tree database under 16-bit OS/2. In 1990, the code moved to Microsoft as part of a deal when 3Com abandoned network software efforts. The LAN Manager group planned to include it in LanMan 3.0, porting it to JET Blue (ESE) with an X/Open XDS API RPC front end. In early 1991, Jim Allchin cancelled LanMan 3.0 and its directory project, creating the Cairo project instead. The Exchange email group then picked up the DS code, ported it to Windows NT, added MAPI RPC, query engine, KCC, modifiable schema, and the link table. This shipped as the DSA in Exchange 4.0 (1996). The week after Exchange 4.0 shipped, two developers copied the DS sources and moved to the Windows group—where it was rechristened "Active Directory."

X.500 Origins JET Blue (ESE) Database Exchange DSA Lineage
  • Key Fact: "AD is a direct descendant of the DSA in Exchange 4.0" — Don Hacherl. Cairo's directory service was cancelled in late 1995; AD filled the gap using Exchange code, not Cairo.
  • LAN Manager Legacy: The "LM" in NTLM authentication comes from this LAN Manager heritage (see 1987 entry above). The networking group's authentication protocol would outlive LanMan itself by decades.
  • Source: Don Hacherl's account on joeware blog (August 2008) — primary source from AD's actual dev lead.
Core AD
1983-1993

Kerberos: From MIT to Internet Standard

Kerberos development began at MIT as part of Project Athena in the mid-1980s, creating a network authentication protocol based on symmetric-key cryptography and a trusted third party (the Key Distribution Center). After versions 1–3 remained internal, Kerberos v4 saw wide deployment in the late 1980s. Kerberos v5—addressing v4's limitations including support for multiple encryption types, cross-realm authentication, and forwardable/proxiable tickets—was published as RFC 1510 in September 1993. Microsoft would later adopt Kerberos v5 as the default authentication protocol for Active Directory in Windows 2000, using the RC4-HMAC encryption type to maintain compatibility with NT hashes.

Mutual Authentication Ticket-Based Protocol RFC 1510 (September 1993) Single Point of Trust (KDC)
  • Design: Client authenticates to KDC → receives Ticket-Granting Ticket (TGT) → presents TGT to request service tickets → authenticates to services without sending passwords over the network. Mutual authentication ensures both client and server verify identity.
  • AD Impact: Microsoft's Kerberos implementation chose RC4-HMAC as the default encryption type because it reuses the NT hash as the Kerberos key—enabling seamless upgrades from NT4 domains without forcing password resets. This convenience decision created the foundation for Kerberoasting, Golden Tickets, and Silver Tickets decades later.
  • Source: RFC 1510 (September 1993), RFC 4120 (July 2005, obsoletes 1510)
Core AD
1993

Windows NT & NTLMv1 Authentication

Windows NT 3.1 introduced NTLMv1 (NT LAN Manager version 1) authentication protocol, replacing the earlier LAN Manager. NTLMv1 stores passwords as unsalted MD4 hashes (the "NT hash"), a 16-byte value vulnerable to rainbow tables and pass-the-hash attacks. The challenge-response mechanism uses DES: the 16-byte NT hash is split into three parts (7 bytes + 7 bytes + 2 bytes), with the third part padded with 5 null bytes to reach 7 bytes. Each 7-byte segment becomes a 56-bit DES key that encrypts the server's 8-byte challenge.

DES Encryption (56-bit keys) No Salt in Password Hashes MD4 Hash Algorithm
  • NTLMv1 Design Flaw: The third DES key has only 2 bytes of real entropy (2^16 = 65,536 possibilities), making NTLMv1 responses crackable in milliseconds. Attackers can recover the full NT hash from captured responses.
  • LM Hash Legacy: Windows NT continued storing the weak LM hash (see 1987 above) alongside the new NT hash for backward compatibility. Both hashes were stored in the SAM database, meaning even NT systems remained vulnerable to LM hash cracking until LM storage was disabled.
  • Weakness: No mutual authentication. Vulnerable to man-in-the-middle and relay attacks. NTLMv1 remained enabled by default until Windows Vista/2008.
Attack Research
April 1997

Pass-the-Hash Technique Published

Paul Ashton posted to NTBugtraq the theory and exploit code for "Pass the Hash"—a modified Samba SMB client that accepts LM hashes instead of cleartext passwords to authenticate to Windows NT systems. This foundational technique would influence Windows security for decades.

Foundational Attack Technique No Password Cracking Required
  • Technique: Attackers with captured NTLM hashes can authenticate to remote hosts without knowing the cleartext password—bypassing the need to crack the hash.
  • Impact: This technique remains viable today against systems that support NTLM authentication. It spawned decades of credential theft research.
  • Source: Exploit-DB archive (April 8, 1997)
Core AD
October 1998

NTLMv2: The 10-Year Wait for a Default

Microsoft introduces NTLMv2 with Windows NT 4.0 Service Pack 4, replacing NTLMv1's weak DES-based challenge-response with HMAC-MD5 and adding a variable-length client challenge with timestamps to mitigate replay attacks. NTLMv2 was a significant cryptographic improvement—but Microsoft shipped it as an option, not a default. The LmCompatibilityLevel registry key controlled which protocol clients and servers used, and it defaulted to 0 (send LM and NTLM responses). It would take a full decade—until Windows Vista and Server 2008—before NTLMv2 became the default authentication level for even new clients.

HMAC-MD5 Challenge-Response Client Challenge + Timestamps Not Default Until 2008 LmCompatibilityLevel 0
  • The Default Problem: NT 4.0 SP4 shipped NTLMv2 but defaulted LmCompatibilityLevel to 0, meaning clients still sent both LM and NTLMv1 responses. Attackers could downgrade authentication to the weakest protocol. Administrators had to manually enforce NTLMv2 via Group Policy.
  • Same NT Hash: Despite the improved challenge-response, NTLMv2 still uses the same underlying NT hash (unsalted MD4) as NTLMv1. This means pass-the-hash and relay attacks work against NTLMv2 just as well—the hash is the credential.
  • Timeline: October 1998 (available in NT 4.0 SP4) → February 2000 (available in Windows 2000, still not default) → February 2008 (finally default on Vista/Server 2008 clients only). A 10-year gap between availability and default enforcement.
  • Source: Microsoft Learn — LmCompatibilityLevel
Vulnerability
March 1999

Melissa Virus: The Email Explosion

The Melissa virus emerges on March 26, 1999—a Word macro virus that hijacked Microsoft Outlook to email itself to the first 50 addresses in victims' address books. Created by David Lee Smith, it became the fastest-spreading infection at the time, causing an estimated $80 million in damages and prompting the FBI to create its Cyber Division.

Fastest-Spreading Virus (1999) $80 Million Damages Mass-Mailing Macro Worm
  • Mechanism: VBA macro in Word document harvested Outlook addresses and mass-mailed infected documents. Spread exponentially—100,000+ computers in 300+ organizations within days.
  • AD Relevance: Demonstrated how Microsoft's tight Office/Outlook integration created attack surfaces. Foreshadowed future threats exploiting Windows ecosystem trust relationships.
  • Source: FBI, Microsoft Security Alert (March 1999)
Core AD
February 2000

Windows 2000 Server: Active Directory Debuts

Active Directory debuts as Microsoft's first true enterprise directory service, replacing Windows NT Domain architecture. Released to manufacturing December 15, 1999; retail release February 17, 2000. Kerberos v5 becomes the default authentication protocol, but NTLM remains fully supported for backward compatibility—and Windows 2000 defaults LmCompatibilityLevel to 0 ("Send LM & NTLM responses"), meaning clients still send both LM and NTLMv1 responses even though NTLMv2 is available. Windows 2000 uses RC4-HMAC as the default Kerberos encryption type—chosen because it uses the same NT hash as NTLM, enabling seamless NT4 domain upgrades without password resets.

Unconstrained Delegation by Default LmCompatibilityLevel 0 (LM+NTLMv1) NTLMv2 Supported but Opt-in No Credential Protection RC4 Encryption Default
  • Dual Authentication: Kerberos v5 is default, but NTLM remains enabled for backward compatibility. With LmCompatibilityLevel at 0, clients send both LM and NTLMv1 responses—the weakest possible NTLM configuration. NTLMv2 (available since NT 4.0 SP4 in 1998) is natively supported but completely off by default. Admins had to manually set LmCompatibilityLevel to 3+ via registry or Group Policy to enforce NTLMv2—most never did.
  • Unconstrained Delegation: Allows services to impersonate ANY user to ANY service in the domain without restriction. TGTs cached in LSASS memory.
  • Source: Microsoft Learn — LmCompatibilityLevel defaults
Tools
March 2001

SMBRelay and SMBRelay2 Released

Sir Dystic of Cult of the Dead Cow (cDc) releases SMBRelay and SMBRelay2—tools that capture and relay SMB authentication, enabling man-in-the-middle attacks against Windows systems. This marked the beginning of NTLM relay attacks.

NTLM Relay Pioneer Man-in-the-Middle
  • Impact: SMBRelay demonstrated that NTLM authentication could be captured and forwarded to other systems without cracking the hash—a technique that evolved into modern relay attacks.
Tools
~2002-2003

Impacket: The Protocol Foundation

Impacket—originally developed by Alberto Solino at Core Security Technologies (now maintained by Fortra)—is a collection of Python classes for working with network protocols that became foundational to AD security tooling. Scripts like secretsdump.py, ntlmrelayx.py, GetUserSPNs.py, and psexec.py are used in virtually every AD pentest.

Protocol Implementation Library Foundation for AD Tools
  • Origins: Copyright strings date to 2002. A 2003 Core Security advisory explicitly references Impacket as their "free, open source" DCE RPC implementation.
  • Key Scripts: secretsdump.py (credential extraction), ntlmrelayx.py (NTLM relay attacks), GetUserSPNs.py (Kerberoasting), getST.py (S4U abuse), psexec.py/wmiexec.py/smbexec.py (remote execution).
  • Impact: Used as the foundation for countless tools including CrackMapExec/NetExec. Provides SMB1-3, MSRPC, Kerberos, and LDAP implementations used by the entire AD security community.
Core AD
April 2003

Windows Server 2003: Constrained Delegation

Microsoft introduces constrained delegation via S4U2Self and S4U2Proxy Kerberos extensions to limit delegation abuse. LmCompatibilityLevel default raised from 0 to 2—dropping LM responses (the weakest protocol) but still defaulting to NTLMv1, not NTLMv2. NTLMv2 had been available since NT 4.0 SP4 (1998) but remained opt-in. Cross-forest trust capabilities expanded attack surface.

Constrained Delegation Available LM Responses Dropped (Level 0→2) NTLMv1 Still Default
  • Constrained Delegation: Admins can restrict delegation to specific services via msDS-AllowedToDelegateTo attribute. Much safer than unconstrained, but requires manual configuration.
  • LmCompatibilityLevel 2: Server 2003 raised the default from 0 (send LM+NTLM) to 2 (send NTLM only). This dropped the weakest LM responses but still used NTLMv1—not NTLMv2. Administrators had to manually set level 3+ to enforce NTLMv2, which had been available since 1998.
  • Why This Matters: LM responses (see 1987 entry) were the weakest link in the authentication chain—uppercase-only, split into crackable 7-char halves, trivially rainbow-tabled. Dropping them was long overdue, but NTLMv1's DES challenge-response remained the default. It would take another 5 years (Vista/2008) for Microsoft to finally default to NTLMv2.
  • NTLMv1 Still Weak: NTLMv1's DES-based challenge-response has a fatal flaw: the third DES key uses only 2 bytes of real entropy (65,536 possibilities), making captured responses crackable in milliseconds. NTLMv2 replaced this with HMAC-MD5 and variable-length challenges—but both versions share the same underlying NT hash (unsalted MD4), so pass-the-hash and relay attacks work against either.
  • Source: MSDN Magazine (April 2003)
Vulnerability
August 2003

MS03-026: Blaster Worm

CVE-2003-0352—RPC DCOM buffer overflow on port 135/TCP. Patch released July 16, Blaster worm hit August 11 (26 days later). Hundreds of thousands infected. Microsoft took the unusual step of emailing ALL customers warning of the vulnerability.

CVE-2003-0352 Wormable RCE Port 135/TCP
  • Impact: First major Windows worm demonstrating how quickly unpatched systems could be compromised at scale. Affected Windows NT 4.0, 2000, XP, and Server 2003.
  • AD Relevance: Wormable RCE provides initial foothold → credential theft → lateral movement → domain compromise.
Vulnerability
April 2004

MS04-011: Sasser Worm

CVE-2003-0533—LSASS buffer overflow. Patch released April 13, Sasser worm hit April 30 (only 17 days!). Major impact on airlines, hospitals, and businesses globally. Delta Air Lines cancelled flights; British Coastguard systems went down.

CVE-2003-0533 LSASS Buffer Overflow 17-Day Exploit Window
  • Impact: Demonstrated shrinking window between patch release and weaponization. LSASS crash caused system reboots, disrupting critical infrastructure.
  • AD Relevance: LSASS is the Local Security Authority Subsystem—the same process that stores credentials in memory. Attacking LSASS became a recurring theme.
Core AD
December 2005

ADFS 1.0: Federated Identity Arrives

Active Directory Federation Services debuts in Windows Server 2003 R2 (released December 6, 2005), enabling Single Sign-On and claims-based authentication across organizational boundaries. ADFS security hinges on the token signing certificate private key—a weakness exploited in 2020's Golden SAML attacks.

Claims-Based Authentication Cross-Org SSO Token Signing Keys Critical
  • ADFS Evolution: 1.0 (Dec 2005) → 2.0 (2009, SAML 2.0) → 3.0 (2012 R2, OAuth) → 4.0+ (2016+, modern auth).
  • Security Model: Compromise of the token signing certificate private key enables forging authentication tokens for any federated user—a threat realized with Golden SAML in 2020.
Core AD
February 2008

Windows Server 2008: AES, RODC & NTLMv2 Default

Windows Vista and Server 2008 clients finally default LmCompatibilityLevel to 3 ("Send NTLMv2 response only"), making NTLMv2 the default—a full decade after it shipped in NT 4.0 SP4. However, this change only applies to Vista/2008 machines themselves. Legacy clients still present in the same environment (Windows XP, Server 2003) continue to default to NTLMv1, meaning mixed environments remained vulnerable to downgrade attacks. AES128/AES256 encryption support added for Kerberos. Read-Only Domain Controllers (RODCs) introduced for branch offices. RC4 remains the default Kerberos encryption type when msDS-SupportedEncryptionTypes is unset—planting the seed for Kerberoasting.

NTLMv2 Default (Vista/2008 Only) AES Encryption Support RODC Introduction Legacy Clients Still NTLMv1 RC4 Still Default (Kerberos)
  • Mixed Environment Risk: Only Vista and Server 2008 clients default to NTLMv2 (LmCompatibilityLevel 3). Windows XP and Server 2003 clients in the same domain still default to LmCompatibilityLevel 0 (send LM & NTLMv1). Attackers could target legacy clients for weaker authentication, or downgrade attacks remained possible until all pre-Vista systems were retired.
  • AES Keys Requirement: When DFL is raised to 2008+, the KRBTGT password auto-resets generating AES keys. But individual accounts only get AES keys when their passwords are reset after the DFL upgrade—accounts with unchanged passwords only have RC4 keys.
  • Kerberoasting Seed: Despite AES support, RC4 remains default for service tickets. Attackers can request RC4-encrypted tickets and crack them offline. This vulnerability persisted until November 2022 (KB5021131).
  • RODCs: Cache limited credentials, never replicate secrets outbound. If compromised, attackers only get cached credentials, not domain-wide access.
  • Source: Microsoft Learn - RODC
Tools
July 2008

Pass-the-Hash Toolkit for Windows

Hernan Ochoa publishes the Pass-the-Hash Toolkit—the first implementation of pass-the-hash for the Windows platform itself (previous implementations used modified Samba clients). This tool later evolved into Windows Credentials Editor (WCE) and inspired the creation of Mimikatz.

Native Windows PtH Mimikatz Inspiration
  • Innovation: First tool allowing pass-the-hash attacks using standard Windows authentication APIs rather than third-party SMB implementations.
  • Legacy: Evolved into WCE (2010) and directly inspired Benjamin Delpy's Mimikatz development.
Vulnerability
October 2008

MS08-067: Conficker Worm

CVE-2008-4250—Critical RPC vulnerability in Server service allowing remote code execution. The Conficker worm exploited this flaw, infecting an estimated 9-15 million systems globally. One of the largest botnet infections in history.

CVE-2008-4250 Wormable RCE 9-15 Million Infected
  • Impact: Affected Windows 2000, XP, Vista, Server 2003, and Server 2008. The worm spread via SMB and USB drives, persisting for years in enterprise networks.
  • AD Relevance: Conficker demonstrated how quickly wormable vulnerabilities spread within AD environments, bypassing perimeter defenses entirely.
Tools
March 2010

Windows Credentials Editor (WCE)

Hernan Ochoa releases Windows Credentials Editor at RootedCon, evolving from the Pass-the-Hash Toolkit. WCE was the first tool that could dump in-memory credentials without running code inside LSASS—a capability that fundamentally changed Windows credential theft.

In-Memory Credential Dumping No LSASS Code Injection
  • Impact: WCE demonstrated that Windows stored recoverable credentials in memory—knowledge that became foundational for all subsequent credential theft tools.
Tools
May 2011

Mimikatz First Release

Benjamin Delpy releases Mimikatz publicly after Microsoft dismissed his 2011 disclosure of the WDigest credential storage vulnerability. Mimikatz would become one of the most influential security tools ever created, used in nearly every major breach and red team operation.

Credential Dumping Revolution WDigest Exploitation LSASS Memory Attacks
  • Impact: Used in DigiNotar hack (September 2011), NotPetya, BadRabbit, Carbanak, Bundestag cyberattack, and countless other incidents.
  • Source: GitHub
Vulnerability
2012

Group Policy Preferences Password Exposure

Emilien Giraul and Chris Campbell publish research on Group Policy Preferences (GPP) password storage. GPP stored local admin passwords in SYSVOL using AES-256 encryption—but Microsoft published the decryption key in MSDN documentation, making all GPP-stored passwords trivially recoverable by any domain user.

Encryption Key Published Domain-Wide Credential Exposure
  • MS14-025: Microsoft patched in May 2014, but existing cpassword attributes in SYSVOL remain—requiring manual cleanup. Many organizations still have exposed GPP passwords years later.
Tools
October 2012

Responder Released

Laurent Gaffie releases Responder v1—a tool that poisons LLMNR, NBT-NS, and MDNS responses to capture password hashes on the network. Responder became a standard tool for internal network penetration testing.

Network Hash Capture LLMNR/NBT-NS Poisoning
  • Technique: When Windows fails DNS resolution, it falls back to LLMNR/NBT-NS multicast. Responder answers these queries, redirecting victims to the attacker and capturing NTLM hashes.
Core AD
2012

Azure AD Launch & Hybrid Identity Era

Microsoft launches Azure Active Directory as a cloud-native identity service for Office 365. Organizations begin the complex journey of hybrid identity—running parallel systems across on-premises AD and cloud. Azure AD Connect's sync service account (MSOL_*) gets DCSync-equivalent privileges by default in Express installation.

Cloud-Native Identity Hybrid Identity Complexity Sync Account Privileges
  • Renamed: Azure AD was renamed to Microsoft Entra ID in July 2023.
  • AAD Connect Risk: Express installation grants MSOL_* account Replicating Directory Changes All—compromise of AAD Connect server = domain compromise. Custom installation allows least-privilege configuration.
  • Seamless SSO Risk: AZUREADSSOACC$ computer account's Kerberos key never auto-rotates. If compromised, attackers can forge cloud authentication tickets indefinitely.
Core AD
October 2013

Windows Server 2012 R2: Protected Users Group

Introduction of the Protected Users security group and Resource-Based Constrained Delegation (RBCD). Protected Users prevents credential caching, disables NTLM/DES/RC4, and restricts delegation—but requires manual enrollment.

Protected Users Group RBCD Available 4-Hour TGT Lifetime Opt-In Only
  • Protected Users: Members cannot use NTLM, DES, or RC4. Credentials not cached. Cannot be delegated. TGT lifetime capped at 4 hours. Forces Kerberos-only (requires FQDN, not IP/NetBIOS).
  • RBCD: Target resource controls who can delegate TO it via msDS-AllowedToActOnBehalfOfOtherIdentity. Powerful but creates new attack vectors exploited in 2019's "Wagging the Dog" research.
  • Source: Microsoft Docs
Tools
~2014

PowerView: AD Reconnaissance Revolution

Will Schroeder (@harmj0y) develops PowerView as part of PowerSploit—a PowerShell toolkit for Active Directory enumeration that enabled easy domain reconnaissance. PowerView became foundational to BloodHound's data collection and modern AD attack methodology. Formally integrated into PowerSploit v3.0.0 in 2016.

AD Enumeration PowerShell-Based BloodHound Foundation
  • Capabilities: Domain/forest enumeration, user/group/computer discovery, GPO analysis, ACL enumeration, trust mapping, session hunting, and Kerberoast target identification.
  • Impact: Original BloodHound ingest was built on PowerView. Will Schroeder's work laid the foundation for graph-based AD attack path analysis.
  • Source: harmj0y blog
Attack Research
August-September 2014

Golden Tickets, Silver Tickets & Kerberoasting

Benjamin Delpy and Skip Duckwall present "Abusing Microsoft Kerberos Sorry You Guys Don't Get It" at Black Hat 2014, introducing Golden Tickets and pass-the-ticket. Tim Medin presents Kerberoasting at DerbyCon. These presentations revolutionized AD offensive security.

Golden Ticket Silver Ticket Kerberoasting
  • Golden Ticket: Forge TGT using KRBTGT hash. Valid for 10 years by default. Survives password resets.
  • Silver Ticket: Forge service ticket without contacting KDC.
  • Kerberoasting: Request service tickets for SPNs, crack offline. Still one of the most successful AD attack techniques.
  • Source: ADSecurity Golden Ticket article
Vulnerability
November 2014

MS14-068: PAC Signature Vulnerability

Critical Kerberos vulnerability (CVE-2014-6324) allowing any domain user to forge a Privilege Attribute Certificate and elevate to Domain Admin. Worse than Golden Ticket because no KRBTGT hash needed. Exploit tools released publicly.

CVE-2014-6324 Domain Admin from Any User No KRBTGT Hash Needed
  • Root Cause: Kerberos KDC failed to properly validate PAC signatures. Attackers could forge group membership in Kerberos tickets.
  • Patch: KB3011780 released November 18, 2014.
  • Tools: PyKEK, kekeo
Core AD
May 2015

Microsoft LAPS Released

Microsoft LAPS (Local Administrator Password Solution) released as a separate downloadable tool. Automatically generates, rotates, and stores unique local admin passwords in AD, finally addressing the decades-old problem of shared local admin passwords enabling lateral movement.

Unique Local Admin Passwords Automatic Rotation Requires Schema Extension
  • Design: Stores password in ms-Mcs-AdmPwd attribute with ACL-protected access. Default 30-day rotation.
  • Windows LAPS: Built into Windows Server 2019+ and Windows 10/11 April 2023+ as "Windows LAPS" with additional features like Azure AD backup.
Attack Research
August 2015

DCSync: Remote Credential Extraction

Vincent Le Toux and Benjamin Delpy add DCSync to Mimikatz—allowing attackers to remotely extract password hashes from domain controllers using Microsoft's official replication APIs (MS-DRSR). No malware needed on the DC. DCSync represented a strategic shift in AD attacks.

No DC Access Required Uses Legitimate Replication APIs Replicating Directory Changes All
  • Requirements: Attacker needs Replicating Directory Changes and Replicating Directory Changes All permissions (default for Domain Admins, MSOL_* accounts).
  • Source: ADSecurity DCSync article
Tools
September 2015

CrackMapExec: The Swiss Army Knife

Marcello Salvati (byt3bl33d3r) releases CrackMapExec v1.0.0—a post-exploitation tool that became legendary in the AD security community. CME combined credential testing, command execution, and lateral movement into a single powerful framework that became a standard part of every pentester's toolkit.

Multi-Protocol Attacks Credential Spraying Lateral Movement
  • Capabilities: SMB/WinRM/LDAP/MSSQL/SSH protocol support, credential validation, command execution, Mimikatz integration, SAM/LSA/NTDS dumping, and modular attack framework.
  • Legacy: Maintained by @mpgn_x64 from 2019-2023. Project forked to NetExec in October 2023 after development disputes.
  • Impact: Used by APT39, Chafer, FIN8, and countless red teams. One of the most widely deployed AD attack tools ever created.
Tools
August 2016

BloodHound Released at DEF CON 24

BloodHound released at DEF CON 24 by Andy Robbins, Rohan Vazarkar, and Will Schroeder. Using graph theory to reveal hidden attack paths in Active Directory, BloodHound revolutionized both offensive and defensive AD security.

Attack Path Discovery Defensive Analysis Graph Theory Applied to AD
Core AD
October 2016

Windows Server 2016: Credential Guard

Windows Defender Credential Guard introduced, using virtualization-based security (VBS) to protect credentials in isolated memory. Prevents pass-the-hash and pass-the-ticket attacks—but requires specific hardware and is NOT enabled by default.

Credential Guard (VBS) Just Enough Administration Requires Hardware Support
  • Requirements: UEFI Secure Boot, TPM (1.2 or 2.0, with 2.0 recommended), VT-x/AMD-V with SLAT.
  • Limitation: Protects DERIVED credentials only. Does NOT protect credentials used for authentication—attackers can still capture credentials before they're protected.
  • Source: Microsoft Learn - Credential Guard
Vulnerability
March-May 2017

MS17-010: EternalBlue / WannaCry / NotPetya

CVE-2017-0144—SMBv1 vulnerability weaponized after NSA exploit "EternalBlue" was leaked by Shadow Brokers. WannaCry (May 12, $4B damages) and NotPetya (June 27, $10B damages) caused unprecedented global destruction.

CVE-2017-0144 Wormable SMBv1 RCE $14B+ Combined Damages
  • Timeline: MS17-010 patch released March 14, 2017. Shadow Brokers leak April 14. WannaCry hit May 12. NotPetya hit June 27.
  • AD Relevance: NotPetya specifically targeted AD environments—using EternalBlue for initial spread, then Mimikatz-style credential theft for lateral movement. Demonstrated how wormable RCE + credential theft = total domain compromise in hours.
  • Impact: Maersk, Merck, FedEx, Mondelez, and countless others suffered catastrophic damage. Led to widespread SMBv1 deprecation efforts.
Attack Research
January 2018

DCShadow: Rogue Domain Controller Attack

Vincent Le Toux and Benjamin Delpy present DCShadow at BlueHat IL 2018. This attack allows attackers with DA credentials to register a rogue domain controller and replicate malicious objects—bypassing most SIEM logging.

Rogue DC Registration Bypasses SIEM Logging Persistence & Backdoors
  • Technique: Create nTDSDSA object + set required SPNs → Push malicious changes via replication → Remove rogue DC objects. Changes appear as normal replication.
  • Note: Post-exploitation attack requiring existing Domain Admin access.
Tools
September 2018

Rubeus: C# Kerberos Abuse

Will Schroeder releases Rubeus as part of GhostPack—a C# port and expansion of Kekeo's Kerberos functionality. Rubeus became the go-to tool for Kerberos attacks including AS-REP roasting, Kerberoasting, ticket manipulation, and delegation abuse.

Comprehensive Kerberos Attacks C# for Evasion GhostPack Suite
  • Capabilities: AS-REP roasting, Kerberoasting, S4U abuse, ticket harvesting/renewal, constrained/unconstrained delegation exploitation, and more.
  • Source: SpecterOps blog
Attack Research
January 2019

Wagging the Dog: RBCD & S4U Abuse

Elad Shamir (@elad_shamir) publishes "Wagging the Dog," demonstrating that RBCD combined with S4U2Self/S4U2Proxy creates devastating attack chains—even against Protected Users members. MachineAccountQuota exploitation becomes standard technique.

RBCD Abuse S4U2Self/S4U2Proxy Weaponized MachineAccountQuota Exploitation
  • Key Discovery: RBCD does NOT require a forwardable TGS when invoking S4U2Proxy, unlike traditional constrained delegation.
  • Attack: Any domain user can create up to 10 computer accounts by default (MAQ). Create machine account → configure RBCD on target → S4U2Self + S4U2Proxy → impersonate ANY user.
Vulnerability
May 2019

CVE-2019-0708: BlueKeep

BlueKeep—a wormable RDP vulnerability (CVSS 9.8) affecting Windows XP, Windows 7, Server 2003, Server 2008, and Server 2008 R2. Microsoft took the rare step of issuing patches for out-of-support Windows XP and Server 2003.

CVE-2019-0708 Wormable RDP RCE CVSS 9.8
  • Impact: Pre-authentication vulnerability in Remote Desktop Services. NSA issued an advisory urging immediate patching—a rare move.
  • AD Relevance: RDP is commonly exposed on domain-joined systems. Wormable RCE + AD = mass domain compromise potential. Estimated ~1 million internet-facing systems vulnerable at disclosure.
Vulnerability
August 2020

Zerologon: Cryptographic Catastrophe

Secura researcher Tom Tervoort discovers CVE-2020-1472 "Zerologon"—allowing any attacker with network access to a DC to become Domain Admin in approximately 3 seconds. No credentials required. CVSS 10.0.

CVE-2020-1472 (CVSS 10.0) Unauthenticated Domain Takeover ~3 Seconds to DA
  • Root Cause: Microsoft's AES-CFB8 implementation in Netlogon used a fixed, all-zero IV. Attackers could authenticate with all-zero credentials after ~256 attempts.
  • Attack: Authenticate as DC's machine account → Set DC password to empty → DCSync all credentials.
  • Impact: Demonstrated that a single cryptographic error could bypass 20+ years of AD security.
Attack Research
December 2020

Golden SAML & SolarWinds Attack

The SolarWinds supply chain attack (SUNBURST/NOBELIUM) reveals nation-state use of "Golden SAML" techniques. Attackers who compromise ADFS token signing certificates can forge authentication for any federated user—bypassing MFA.

Golden SAML SolarWinds/NOBELIUM MFA Bypass
  • Technique: With ADFS token signing certificate private key, attackers forge valid SAML tokens for ANY user to ANY federated service—no password, no MFA.
  • Microsoft Response: Accelerated push toward "ADFS-less" architectures. Microsoft now recommends migrating from ADFS to Entra ID.
Attack Research
June 2021

Shadow Credentials: Key Trust Abuse

Elad Shamir (@elad_shamir) publishes "Shadow Credentials," demonstrating how attackers with write access to msDS-KeyCredentialLink can add a malicious public key credential and authenticate via PKINIT Key Trust—bypassing passwords entirely. Works on both USER and COMPUTER accounts, and survives password resets.

msDS-KeyCredentialLink Abuse Password-Less Authentication Survives Password Resets
  • Technique: Write malicious public key to msDS-KeyCredentialLink → Authenticate via PKINIT Key Trust → Obtain TGT without knowing the account's password.
  • Key Trust vs Certificate Trust: This attack abuses Key Trust (raw public keys in msDS-KeyCredentialLink), NOT Certificate Trust (which uses ADCS-issued certificates). Key Trust was introduced for Windows Hello for Business passwordless authentication.
  • Requirements: Domain functional level does NOT matter. Attack works as long as WHfB schema extensions exist (msDS-KeyCredentialLink attribute present). Schema extension typically added when any DC runs Server 2016+.
  • Tools: Whisker (C#), pyWhisker (Python)
  • Detection: Event ID 5136 (Directory Service Changes) for msDS-KeyCredentialLink modifications. Legitimate writers: MSOL_* (Azure AD Connect), ADFS service accounts.
Vulnerability
July 2021

CVE-2021-34527: PrintNightmare

PrintNightmare—critical Print Spooler RCE vulnerability allowing authenticated users to execute code as SYSTEM on any Windows host with Print Spooler running, including Domain Controllers. Exploit code leaked before patches were available.

CVE-2021-34527 RCE as SYSTEM DC Compromise Vector
  • Impact: Print Spooler was enabled by default on DCs. Any authenticated domain user could achieve SYSTEM on the DC. Led to widespread recommendations to disable Print Spooler on all servers.
  • Related: Part of a series of Spooler vulnerabilities including CVE-2021-1675 and earlier PrinterBug/SpoolSample coercion techniques used in NTLM relay chains.
Attack Research
July-August 2021

PetitPotam & Certified Pre-Owned (ADCS)

PetitPotam authentication coercion released. Combined with SpecterOps' "Certified Pre-Owned" ADCS research (ESC1-ESC8), coercion + NTLM relay to ADCS = instant Domain Admin.

PetitPotam (MS-EFSRPC) ESC1-ESC8 Techniques NTLM Relay to ADCS
  • Attack Chain: Coerce DC authentication (PetitPotam) → Relay to ADCS HTTP enrollment → Request certificate as DC → Request TGT → DCSync = full compromise.
  • ESC1: Misconfigured templates allowing SAN specification—request certs for any user including Domain Admins.
  • Tools: Certify, Certipy
Vulnerability
November 2021

sAMAccountName Spoofing (noPac)

CVE-2021-42278 (sAMAccountName spoofing) and CVE-2021-42287 (KDC PAC confusion) combine to create another "any domain user to Domain Admin" attack. Nicknamed "noPac," exploitation takes seconds.

CVE-2021-42278 + CVE-2021-42287 Any User to Domain Admin Trivial Exploitation
  • Attack: Control machine account → Rename sAMAccountName to "DC01" (no $) → Request TGT → Rename back → Request S4U2self → KDC finds DC01$ → Returns DC-privileged ticket → DCSync.
  • Prerequisites: Control over machine account. Common via MAQ > 0, compromised computer, or delegated rights.
Tools
April 2022

KrbRelayUp: Local Privilege Escalation

KrbRelayUp released by Dec0ne, combining Kerberos relay with RBCD to achieve local privilege escalation on domain-joined systems—from regular user to SYSTEM without touching the network.

Local Privilege Escalation Kerberos Relay + RBCD
  • Technique: Relay local Kerberos authentication to LDAP → Configure RBCD on local machine → S4U2Self to get SYSTEM ticket → Local SYSTEM access.
Core AD
November 2022

KB5021131: Kerberos RC4 Hardening

Microsoft finally addresses RC4 downgrade attacks with KB5021131 (CVE-2022-37966). DCs now return tickets using the HIGHEST encryption the account supports, ignoring client downgrade requests. New accounts prefer AES. However, RC4 remains ENABLED for backward compatibility with accounts that only have RC4 keys.

RC4 Downgrade Blocked AES Preferred for New Accounts RC4 Still Available
  • Timeline: 2008: AES available → 2008-2022: Clients could request RC4 → November 2022: Downgrade blocked → Ongoing: RC4 enabled for backward compatibility.
  • Remaining Work: Accounts with passwords unchanged since 2008 still only have RC4 keys. Password rotation required for full AES protection.
Tools
October 2023

NetExec: CME's Community Successor

NetExec (nxc) released as the community-maintained successor to CrackMapExec after byt3bl33d3r archived the original repository. Continues active development of the CME codebase.

CME Continuation Active Development
  • Maintainers: NeffIsBack, Marshall-Hallenbeck, zblurx, and community contributors.
  • Note: Fully open source with merged community contributions that were pending in the original CME repository.
Vulnerability
May 2025

BadSuccessor: dMSA Privilege Escalation

Akamai researcher Yuval Gordon discloses "BadSuccessor"—a privilege escalation vulnerability in Windows Server 2025's delegated Managed Service Account (dMSA) feature. Any user with CreateChild on an OU can escalate to Domain Admin. In 91% of environments tested, non-admin users had required permissions.

CVE-2025-53779 91% of Environments Vulnerable Any User to Domain Admin
  • Technique: Create dMSA → Set msDS-ManagedAccountPrecededByLink to target account → Set msDS-DelegatedMSAState to 2 → Request TGT → dMSA inherits target's privileges.
  • Patched: CVE-2025-53779 patched August 2025 Patch Tuesday. KDC now requires mutual pairing (target must reference dMSA).
  • Source: Akamai blog, GitHub
Core AD
2025

Windows Server 2025: Modern Hardening by Default

Microsoft's most security-focused AD release. NTLMv1 is fully removed from the codebase. RC4 encryption disabled by default, SMB signing mandatory, LDAP signing and channel binding enforced by default, and Credential Guard enabled by default on systems with supported hardware. Delegated Managed Service Accounts (dMSAs) introduced. NTLMv2 remains enabled for backward compatibility—full NTLM deprecation (disabling NTLMv2 by default) is planned for the next major Windows Server release.

NTLMv1 Removed RC4 Disabled by Default SMB/LDAP Signing Enforced Credential Guard Default (If Hardware) NTLMv2 Still Enabled Breaking Changes for Legacy
  • NTLMv1 Removed: NTLMv1 has been completely removed from the Windows Server 2025 codebase. Systems can no longer fall back to NTLMv1 authentication under any circumstances—eliminating DES-based challenge-response and the weak third-key vulnerability for good.
  • NTLMv2 Still Enabled: NTLMv2 remains available and enabled by default for backward compatibility. Microsoft has announced that disabling NTLM entirely (including NTLMv2) by default is planned for the next major Windows Server release, not Server 2025.
  • RC4 Deprecation: RC4 disabled by default for Kerberos. AES is now the default. RC4 remains AVAILABLE for backward compatibility but must be explicitly re-enabled.
  • Credential Guard: Enabled by default IF hardware meets requirements: UEFI Secure Boot, TPM (1.2/2.0), VT-x/AMD-V with SLAT. Systems without compatible hardware are not affected.
  • dMSAs: New account type for service account management. Introduced BadSuccessor vulnerability (patched August 2025).
  • Source: Microsoft Learn - What's new in Server 2025