Active Directory underpins identity management in roughly 90% of enterprise Windows environments. Every domain logon, every file share access, every email authentication, every VPN session – in most organizations, all of it routes through AD. Which makes it the single most valuable target in a Windows network, and the one that attackers consistently go after first.
The credential breach numbers are consistent across every major threat intelligence source. Verizon’s 2025 Data Breach Investigations Report found stolen credentials in 22% of all confirmed breaches – the leading initial access vector for the second consecutive year. CrowdStrike’s 2025 Global Threat Report documented that identity-based attacks grew 60% year-over-year, with adversaries consistently targeting Active Directory as the path to domain-wide access. The pattern isn’t random: compromise AD, and you effectively own the network.
What’s less often discussed is how those credentials are used after they’re obtained – and why conventional password controls don’t stop the techniques that actually work against AD.
The anatomy of AD credential attacks
Understanding the specific techniques attackers use against Active Directory matters because each one exposes a different gap in password-only defenses.
Kerberoasting
Kerberoasting exploits the Kerberos service ticket mechanism. Any authenticated domain user – including low-privilege accounts – can request a Kerberos TGS (Ticket Granting Service) ticket for any service registered with a Service Principal Name (SPN). The ticket is encrypted with the service account’s password hash. Once the attacker has the ticket, they take it offline and crack the password hash using tools like Hashcat or John the Ripper, without generating any further authentication traffic on the network.
The attack is particularly effective against service accounts because they often have elevated privileges (sometimes Domain Admin or near-equivalent), use passwords set years ago that haven’t rotated, and generate only normal Kerberos authentication events that are not suspicious by themselves when the TGS ticket is requested — requesting a service ticket is a normal Kerberos operation, logged as Event ID 4769 (Kerberos service ticket operation) but not flagged as suspicious without specific detection rules.
The discovery step is trivial: setspn -T domain.local -Q */* returns every SPN-registered account in the domain, and tools like BloodHound enumerate them with additional context on their privilege levels.
Pass-the-Hash
Pass-the-Hash (PtH) attacks bypass password knowledge entirely. When a user authenticates on a Windows system, their NTLM hash is cached in the LSASS (Local Security Authority Subsystem Service) process. An attacker with local admin rights on that machine can extract the hash using tools like Mimikatz (sekurlsa::logonpasswords) and then use the hash directly to authenticate to other systems and services that accept NTLM – without ever knowing the plaintext password.
Windows authentication accepts the hash as proof of identity. So a credential extracted from one workstation can authenticate to file servers, domain controllers, and AD-integrated applications on other machines across the network. This is lateral movement without cracking anything.
NTLM authentication events appear in logs as Event ID 4624 (successful logon) with Logon Type 3 (network logon) – indistinguishable from a legitimate logon unless behavioral analysis flags the source IP, time, or pattern.
DCSync
DCSync is a post-exploitation technique that uses the Directory Replication Service (DRS) protocol to impersonate a domain controller and request password hashes for any or all domain accounts. An attacker with replication permissions – which can be obtained through delegated replication permissions, ACL misconfigurations, or by compromising an account that already has them – can pull the NTLM hash for every account in the domain, including KRBTGT, which enables Golden Ticket attacks.
DCSync doesn’t require a foothold on the domain controller itself. It can run from any machine in the domain with the right permissions. Event ID 4662 logs the directory service access, but only if auditing is configured on the domain controller – which it often isn’t by default.
Brute Force Against AD-Integrated Services
Exposed AD-integrated services – LDAP (port 389/636), SMB (445), Kerberos (88), RDP, VPN gateways with NTLM authentication – all accept direct credential attempts. Automated tools cycle through credential lists, spray common passwords across large user populations, and test breach dumps against AD-backed login surfaces. The attacks are low-and-slow by design to stay under lockout thresholds. A spray of one common password across 10,000 accounts generates one failed logon per account – well below the typical 5-attempt lockout threshold.
Why password policies don’t stop these attacks
The standard response to AD credential risk is stronger password policy: longer minimum length, complexity requirements, regular rotation, banned password lists. These controls have real value. They don’t address the attacks described above.
Kerberoasting doesn’t require a stolen password. The attacker uses a legitimate low-privilege account (often obtained through a single phishing email) to request service tickets. The cracking happens offline against the ticket encryption, not against AD’s lockout policy. A 20-character complex password on a service account is a harder cracking target — but the attack still works if the hash is exposed.
Pass-the-Hash doesn’t use the password at all. The hash is the credential. Password rotation invalidates the old hash, but if the endpoint remains compromised, the hash of the new password can be extracted the next time the user authenticates. Complexity requirements are irrelevant — the hash doesn’t need to be cracked.
DCSync operates within Kerberos/NTLM by design. It uses legitimate replication protocols. From Active Directory’s perspective, a DCSync request made by an account with replication permissions is treated as a legitimate replication operation.
Lockout policies don’t stop password spraying when the threshold is set for usability. A 5-attempt threshold with a 30-minute reset counter means an attacker can try 5 passwords per account every 30 minutes indefinitely. Against a population of 500 users with “Summer2025!” as a common seasonal password, that’s more than enough.
The gap is architectural: all of these attacks succeed because a valid password (or its hash) is sufficient to authenticate to Active Directory. Adding a second factor at the endpoint – a VPN gateway, a workstation login screen – doesn’t change that. The directory itself accepts single-factor authentication from anything with valid credentials.
Directory-level MFA as an architectural response
The only control that directly addresses credential-based AD attacks is enforcing strong authentication at the directory authentication layer itself – not only at the endpoint that sits in front of AD, but at the point where AD actually validates credentials.
Multi-factor authentication at the directory level means that authentication requests reaching Active Directory require a current, time-based OTP password – not just a reusable password or hash. This changes the attack calculus for every technique described above.
A Kerberoasted hash that’s been cracked offline can’t be used to authenticate if authentication requires a current OTP that isn’t stored in the hash. A pass-the-hash attack using an extracted NTLM hash fails because authentication requires the current time-based OTP password. A DCSync pull extracts hashes that are no longer sufficient to authenticate on their own.
This isn’t just a policy layer applied at specific endpoints. The protection applies wherever Active Directory authentication is used – whether the request comes from a VPN client, an RDP connection, or a mapped drive.
How this works without agents on every endpoint
The natural concern with any directory-level MFA approach is deployment complexity. If it requires agent software on every domain controller and every workstation, the operational overhead can exceed the security benefit.
The dynamic strong password authentication approach addresses this directly. Instead of adding an MFA layer on top of existing AD authentication, DSPA replaces static passwords with dynamic, time-based one-time passwords at the directory level itself. The static password that would otherwise be extractable via NTLM hash becomes a rotating OTP that’s only valid for its current 30-second interval.
No agent is required on endpoints. The authentication behavior change happens at the directory level, not on every machine that authenticates against it. Users enroll their Protectimus SMART app or MFA chatbot once, and dynamic authentication is automatically applied to subsequent Active Directory authentication across connected services.
Group-based deployment is supported, which matters for phased rollout. Organizations typically enforce directory-level OTP for privileged accounts, domain administrators, and high-value service accounts first – the accounts most targeted in Kerberoasting and DCSync attacks – then extend to broader user populations as the enrollment process matures.
ADFS and federation scenarios
For organizations using Active Directory Federation Services (ADFS) to provide single sign-on to cloud applications, SaaS platforms, or partner environments, directory-level MFA extends naturally to federated authentication.
ADFS issues tokens based on Active Directory authentication. If AD authentication requires an OTP password at the directory level, every ADFS-issued token is issued only after that requirement has been satisfied, regardless of whether the consuming application natively supports MFA. This closes a gap that often exists in ADFS deployments where MFA is enforced at the application layer but not at the directory layer that ADFS draws from.
For organizations evaluating ADFS two-factor authentication setup specifically — including the integration between ADFS claims rules and directory-level OTP authentication — the dedicated ADFS page covers the implementation path.
Conclusion: What to check in your AD Environment
The attacks described here – Kerberoasting, Pass-the-Hash, DCSync, and credential spraying – are not theoretical. They’re the standard post-compromise toolkit documented across the IR cases published by every major threat intelligence firm. They work because Active Directory, in most organizations, accepts valid credentials as the sole proof of identity.
Before the next breach notification, it’s worth answering three questions about your environment:
- How many accounts in your domain have registered SPNs – and when were their passwords last rotated?
- Are your domain controllers generating and forwarding Event ID 4662 (directory service access) logs to a SIEM with alerting for DCSync signatures?
- Does your AD authentication require a dynamic OTP password at the directory level – or only at specific endpoints in front of it?
The third question is the one that most organizations haven’t answered yet.
Leave a Reply