{"id":2661,"date":"2026-08-03T20:44:29","date_gmt":"2026-08-03T18:44:29","guid":{"rendered":"https:\/\/extendsclass.com\/blog\/?p=2661"},"modified":"2026-08-03T20:35:18","modified_gmt":"2026-08-03T18:35:18","slug":"active-directory-under-attack","status":"publish","type":"post","link":"https:\/\/extendsclass.com\/blog\/active-directory-under-attack","title":{"rendered":"Active Directory Under Attack: Kerberoasting, Pass-the-Hash, and Why Password-Only AD Is a Liability"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">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 &#8211; 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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The credential breach numbers are consistent across every major threat intelligence source. Verizon&#8217;s 2025 Data Breach Investigations Report found stolen credentials in 22% of all confirmed breaches &#8211; the leading initial access vector for the second consecutive year. CrowdStrike&#8217;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&#8217;t random: compromise AD, and you effectively own the network.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">What&#8217;s less often discussed is how those credentials are used after they&#8217;re obtained &#8211; and why conventional password controls don&#8217;t stop the techniques that actually work against AD.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_47_1 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\">Table of Contents<\/p>\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"ez-toc-toggle-icon-1\"><label for=\"item-6a72948be9e74\" aria-label=\"Table of Content\"><span style=\"display: flex;align-items: center;width: 35px;height: 30px;justify-content: center;direction:ltr;\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/label><input  type=\"checkbox\" id=\"item-6a72948be9e74\"><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/extendsclass.com\/blog\/active-directory-under-attack\/#The_anatomy_of_AD_credential_attacks\" title=\"The anatomy of AD credential attacks\">The anatomy of AD credential attacks<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/extendsclass.com\/blog\/active-directory-under-attack\/#Kerberoasting\" title=\"Kerberoasting\">Kerberoasting<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/extendsclass.com\/blog\/active-directory-under-attack\/#Pass-the-Hash\" title=\"Pass-the-Hash\">Pass-the-Hash<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/extendsclass.com\/blog\/active-directory-under-attack\/#DCSync\" title=\"DCSync\">DCSync<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/extendsclass.com\/blog\/active-directory-under-attack\/#Brute_Force_Against_AD-Integrated_Services\" title=\"Brute Force Against AD-Integrated Services\">Brute Force Against AD-Integrated Services<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/extendsclass.com\/blog\/active-directory-under-attack\/#Why_password_policies_don%E2%80%99t_stop_these_attacks\" title=\"Why password policies don&#8217;t stop these attacks\">Why password policies don&#8217;t stop these attacks<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/extendsclass.com\/blog\/active-directory-under-attack\/#Directory-level_MFA_as_an_architectural_response\" title=\"Directory-level MFA as an architectural response\">Directory-level MFA as an architectural response<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/extendsclass.com\/blog\/active-directory-under-attack\/#How_this_works_without_agents_on_every_endpoint\" title=\"How this works without agents on every endpoint\">How this works without agents on every endpoint<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/extendsclass.com\/blog\/active-directory-under-attack\/#ADFS_and_federation_scenarios\" title=\"ADFS and federation scenarios\">ADFS and federation scenarios<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/extendsclass.com\/blog\/active-directory-under-attack\/#Conclusion_What_to_check_in_your_AD_Environment\" title=\"Conclusion: What to check in your AD Environment\">Conclusion: What to check in your AD Environment<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"The_anatomy_of_AD_credential_attacks\"><\/span>The anatomy of AD credential attacks<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Understanding the specific techniques attackers use against Active Directory matters because each one exposes a different gap in password-only defenses.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Kerberoasting\"><\/span>Kerberoasting<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Kerberoasting exploits the Kerberos service ticket mechanism. Any authenticated domain user &#8211; including low-privilege accounts &#8211; 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&#8217;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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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&#8217;t rotated, and generate only normal Kerberos authentication events that are not suspicious by themselves when the TGS ticket is requested \u2014 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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Pass-the-Hash\"><\/span>Pass-the-Hash<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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 &#8211; without ever knowing the plaintext password.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">NTLM authentication events appear in logs as Event ID 4624 (successful logon) with Logon Type 3 (network logon) &#8211; indistinguishable from a legitimate logon unless behavioral analysis flags the source IP, time, or pattern.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"DCSync\"><\/span>DCSync<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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 &#8211; which can be obtained through delegated replication permissions, ACL misconfigurations, or by compromising an account that already has them &#8211; can pull the NTLM hash for every account in the domain, including KRBTGT, which enables Golden Ticket attacks.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">DCSync doesn&#8217;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 &#8211; which it often isn&#8217;t by default.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Brute_Force_Against_AD-Integrated_Services\"><\/span>Brute Force Against AD-Integrated Services<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Exposed AD-integrated services &#8211; LDAP (port 389\/636), SMB (445), Kerberos (88), RDP, VPN gateways with NTLM authentication &#8211; 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 &#8211; well below the typical 5-attempt lockout threshold.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Why_password_policies_don%E2%80%99t_stop_these_attacks\"><\/span>Why password policies don&#8217;t stop these attacks<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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&#8217;t address the attacks described above.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Kerberoasting doesn&#8217;t require a stolen password.<\/strong> 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&#8217;s lockout policy. A 20-character complex password on a service account is a harder cracking target \u2014 but the attack still works if the hash is exposed.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Pass-the-Hash doesn&#8217;t use the password at all.<\/strong> 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 \u2014 the hash doesn&#8217;t need to be cracked.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>DCSync operates within Kerberos\/NTLM by design.<\/strong> It uses legitimate replication protocols. From Active Directory&#8217;s perspective, a DCSync request made by an account with replication permissions is treated as a legitimate replication operation.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Lockout policies don&#8217;t stop password spraying when the threshold is set for usability.<\/strong> 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 &#8220;Summer2025!&#8221; as a common seasonal password, that&#8217;s more than enough.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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 &#8211; a VPN gateway, a workstation login screen &#8211; doesn&#8217;t change that. The directory itself accepts single-factor authentication from anything with valid credentials.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Directory-level_MFA_as_an_architectural_response\"><\/span>Directory-level MFA as an architectural response<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The only control that directly addresses credential-based AD attacks is enforcing strong authentication at the directory authentication layer itself &#8211; not only at the endpoint that sits in front of AD, but at the point where AD actually validates credentials.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><a href=\"https:\/\/www.protectimus.com\/mfa-for-active-directory\/\">Multi-factor authentication at the directory level<\/a> means that authentication requests reaching Active Directory require a current, time-based OTP password &#8211;  not just a reusable password or hash. This changes the attack calculus for every technique described above.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A Kerberoasted hash that&#8217;s been cracked offline can&#8217;t be used to authenticate if authentication requires a current OTP that isn&#8217;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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This isn&#8217;t just a policy layer applied at specific endpoints. The protection applies wherever Active Directory authentication is used &#8211; whether the request comes from a VPN client, an RDP connection, or a mapped drive.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"How_this_works_without_agents_on_every_endpoint\"><\/span>How this works without agents on every endpoint<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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&#8217;s only valid for its current 30-second interval.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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 &#8211; the accounts most targeted in Kerberoasting and DCSync attacks &#8211; then extend to broader user populations as the enrollment process matures.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"ADFS_and_federation_scenarios\"><\/span>ADFS and federation scenarios<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For organizations evaluating ADFS two-factor authentication setup specifically \u2014 including the integration between ADFS claims rules and directory-level OTP authentication \u2014 the dedicated ADFS page covers the implementation path.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Conclusion_What_to_check_in_your_AD_Environment\"><\/span>Conclusion: What to check in your AD Environment<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The attacks described here &#8211; Kerberoasting, Pass-the-Hash, DCSync, and credential spraying &#8211; are not theoretical. They&#8217;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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Before the next breach notification, it&#8217;s worth answering three questions about your environment:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>How many accounts in your domain have registered SPNs &#8211; and when were their passwords last rotated?<\/li>\n\n\n\n<li>Are your domain controllers generating and forwarding Event ID 4662 (directory service access) logs to a SIEM with alerting for DCSync signatures?<\/li>\n\n\n\n<li>Does your AD authentication require a dynamic OTP password at the directory level &#8211; or only at specific endpoints in front of it?<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">The third question is the one that most organizations haven&#8217;t answered yet.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Learn how Kerberoasting, Pass-the-Hash, DCSync and password spraying compromise Active Directory, and how directory-level MFA with dynamic OTP protects credentials.<\/p>\n","protected":false},"author":1,"featured_media":2662,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_sitemap_exclude":false,"_sitemap_priority":"","_sitemap_frequency":"","footnotes":""},"categories":[5],"tags":[],"class_list":["post-2661","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-break"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/extendsclass.com\/blog\/wp-json\/wp\/v2\/posts\/2661","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/extendsclass.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/extendsclass.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/extendsclass.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/extendsclass.com\/blog\/wp-json\/wp\/v2\/comments?post=2661"}],"version-history":[{"count":1,"href":"https:\/\/extendsclass.com\/blog\/wp-json\/wp\/v2\/posts\/2661\/revisions"}],"predecessor-version":[{"id":2663,"href":"https:\/\/extendsclass.com\/blog\/wp-json\/wp\/v2\/posts\/2661\/revisions\/2663"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/extendsclass.com\/blog\/wp-json\/wp\/v2\/media\/2662"}],"wp:attachment":[{"href":"https:\/\/extendsclass.com\/blog\/wp-json\/wp\/v2\/media?parent=2661"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/extendsclass.com\/blog\/wp-json\/wp\/v2\/categories?post=2661"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/extendsclass.com\/blog\/wp-json\/wp\/v2\/tags?post=2661"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}