Let's Talk About the Breach You Haven't Found Yet
I was on a purple team engagement last year where the client — a mid-sized financial services firm, 3,000 endpoints — had just passed their SOC 2 audit. Clean bill of health. Their CISO was proud. Within four hours of getting credentials for a standard domain user account, we had a path to Domain Admin. Not because they hadn't patched. Not because their firewall was misconfigured. Because their Active Directory looked like it had been set up in 2009 and then mostly left alone.
This is not a rare story. It's practically the default.
Active Directory is still the authentication and authorization backbone for the overwhelming majority of enterprise environments. Microsoft's own estimates put it north of 90% of Fortune 1000 companies. And yet it remains one of the most persistently misconfigured, under-monitored, and frankly disrespected components in the security stack. You'll have a six-figure SIEM deployment and a dedicated threat intel team, and your KRBTGT password hasn't rotated since Obama's first term. Something's off.
Kerberoasting Is Still Working. In Your Environment. Right Now.
Let's be direct about Kerberoasting because I'm still seeing it succeed on engagements in 2024 and I'm tired of acting like it's an edge case. If you have service accounts with SPNs registered and those accounts are using RC4 encryption — and you almost certainly do — attackers with any domain user credentials can request service tickets for those accounts and take them offline to crack. No elevated privileges required. No special tooling. Rubeus.exe kerberoast and you're done.
The detection signal you want is Event ID 4769 with an encryption type of 0x17 (RC4-HMAC). AES-encrypted tickets are 0x12 or 0x11. If you're seeing 4769 events with RC4 for service accounts, especially in rapid succession or from a workstation that has no business touching that service, you've got a problem. The fix on the detection side is straightforward: build that alert. The fix on the hardening side is enforcing AES-only on your service accounts and, ideally, moving to Managed Service Accounts or Group Managed Service Accounts so the passwords rotate automatically and are 120 characters long by default. Attackers can't crack what they can't crack.
Closely related and somehow even more neglected: AS-REP roasting. This targets accounts with "Do not require Kerberos preauthentication" enabled — a setting that should essentially never be on for real user accounts. When it is, you can request an AS-REP for that account without any credentials at all, and the response contains material encrypted with the account's password hash. Same offline cracking situation, zero authentication required. Run this query in your environment right now:
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth
If that returns anything other than an empty result and you can't immediately justify why, fix it before you finish reading this.
DCSync and Why Your Domain Admins List Is Probably Lying to You
DCSync is the attack that keeps me up at night more than almost anything else in an AD environment. The short version: if an account has Replicating Directory Changes All and Replicating Directory Changes permissions on the domain object, that account can ask a Domain Controller to replicate credentials — including NTLM hashes for every account in the domain, including KRBTGT — without ever touching the DC directly. Mimikatz makes this embarrassingly simple: lsadump::dcsync /domain:corp.local /user:krbtgt. You now have the keys to forge Golden Tickets. Game over.
The scary part isn't that the technique exists. The scary part is that Azure AD Connect — which many organizations have deployed for hybrid identity — requires those replication permissions to sync. The sync account, typically named something like MSOL_xxxxxxxx, has DCSync rights by design. If you compromised that account, you own the domain. How is that account protected? Is it in a Tier 0 OU? Does it have a 60-character random password? Is it monitored for any logon outside of the sync process? In most environments I've assessed: no, no, and absolutely not.
Here's how to enumerate who actually has those replication rights in your domain — don't assume it's only Domain Admins:
(Get-Acl "AD:\DC=corp,DC=local").Access | Where-Object {$_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"}
That GUID is the DS-Replication-Get-Changes-All right. Any principal showing up there that isn't a DC computer account or your documented sync account is a finding. A serious one.
You Have BloodHound. Are You Actually Using It Defensively?
BloodHound and SharpHound have been around since 2016. The red team community adopted them immediately and has been using them to find attack paths to Domain Admin ever since. The blue team adoption has been... slower. Much slower.
Here's the thing — BloodHound is as useful for defenders as it is for attackers, arguably more so, because you can run it against your own environment continuously and find paths before someone else does. SharpHound collects the data (ACLs, group memberships, session information, trust relationships), BloodHound visualizes the attack graph. The query "Shortest Paths to Domain Admins" is brutal. You will find paths you didn't know existed. A helpdesk account that can reset the password of a server admin, who has a session on a box where a Domain Admin has also logged in. Boom. That's a lateral movement chain that no spreadsheet-based access review was ever going to catch.
PingCastle and Purple Knight are worth running regularly as well — they give you a scored AD health assessment against known misconfigurations and attack paths. PingCastle in particular maps well to the ANSSI AD security framework and will surface things like unconstrained delegation, excessive AdminSDHolder propagation, and accounts outside of Protected Users that probably should be in it. These aren't replacements for BloodHound's graph analysis, but they're fast and they speak the language of risk scoring that security leadership actually responds to.
The honest answer is that most organizations run these tools during a pentest, have a moment of panic, generate a finding report, and then don't run them again for 18 months. By which point the environment has changed substantially and the new paths are invisible again. Make it continuous. Schedule SharpHound collection weekly. Diff the results. Alert on new paths to Tier 0 assets.
The Tiering Model Nobody Actually Implements Properly
Microsoft's Active Directory tiering model — Tier 0 for domain controllers and their management assets, Tier 1 for servers, Tier 2 for workstations — is the right architectural answer to credential theft and lateral movement. The concept is simple: credentials at a higher tier should never touch a lower tier. A Tier 0 admin account should never be used to log into a workstation. A Tier 2 admin account should never have rights on a server. The separation is enforced through GPOs that restrict logon rights (specifically Deny log on locally, Deny log on through Remote Desktop Services, and Deny access to this computer from the network for out-of-tier accounts).
In practice, what I see is organizations that have read about tiering, maybe even started implementing it, but have exceptions. So many exceptions. "Just this one account because the tool requires it." "The vendor said they need Domain Admin." "We'll fix it after the migration." Those exceptions are the attack paths. The model only works if it's actually enforced, and enforcement requires someone to say no — to vendors, to developers, to other admins who want convenience. That's a harder problem than the technical implementation, and it's why tiering projects stall.
AdminSDHolder deserves specific attention here because it's one of the most commonly abused AD features that most admins don't think about. AdminSDHolder is a template object that automatically propagates its ACL to all protected groups (Domain Admins, Enterprise Admins, Schema Admins, etc.) and their members via a process called SDProp, which runs every 60 minutes. If an attacker can write an ACE to the AdminSDHolder object, that permission will propagate to every protected account in the domain within an hour. This is a persistence technique, not just an escalation path, and it survives account cleanup if you don't also clean the AdminSDHolder object itself. Monitor that object. Alert on any ACL modification to CN=AdminSDHolder,CN=System,DC=corp,DC=local.
KRBTGT Hasn't Rotated and You're Fine With That, Apparently
The KRBTGT account's password is the root of Kerberos trust in your domain. If an attacker gets the NTLM hash of KRBTGT — via DCSync, via a compromised DC, whatever — they can forge Kerberos tickets for any account, with any group membership, valid for any duration. That's a Golden Ticket attack, and it's essentially game over for the domain as long as that KRBTGT password remains valid. Microsoft's guidance is to rotate it at least annually, and twice in succession after any suspected compromise (because there are two stored versions of the password and both need to change for old tickets to be invalidated).
Go check yours. Actually go check. In most environments I've looked at, the KRBTGT password was last set when the domain was built, or when someone ran the rotation script once after a breach scare five years ago. There's a reason Microsoft built the KRBTGT rotation script and documented it — because the operational risk of not rotating it is severe and the operational risk of rotating it (temporary Kerberos disruptions if not done carefully) is manageable.
While you're in that mindset: Protected Users security group. This is a feature that's been available since Server 2012 R2 and is wildly underused. Accounts in Protected Users cannot authenticate with NTLM, cannot use DES or RC4 in Kerberos, cannot use unconstrained delegation, and have ticket lifetimes capped at four hours. Put your Tier 0 and Tier 1 admin accounts in there. Now. The main thing that stops people is breakage with legacy applications that require NTLM, which is a real concern — but it's also a sign that you have other problems that need fixing.
Your Event Logs Are Telling You Everything. Nobody Is Listening.
Active Directory generates incredibly rich telemetry. The problem isn't availability — it's that most organizations aren't collecting the right events, or they're collecting them and not alerting on anything meaningful.
Event ID 4672 (Special privileges assigned to new logon) fires whenever a privileged account logs on. You should know every time a member of Domain Admins, Schema Admins, or Enterprise Admins authenticates anywhere. If that's noisy, your privileged access model is broken. 4624 and 4625 (successful and failed logon) are table stakes, but the value comes from enriching them — which accounts are logging on interactively to servers they have no business touching? Which service accounts are logging on from workstations? Pattern analysis, not just alerting on individual events.
LAPS — Local Administrator Password Solution — is another thing that should be universally deployed and often isn't. The local administrator account on workstations and servers is a lateral movement superhighway when it has the same password everywhere, which is still common. LAPS rotates the local admin password per-machine and stores it in AD (or, in the newer Windows LAPS, in Azure AD), retrievable only by authorized principals. If you don't have LAPS deployed, you have pass-the-hash risk across your entire endpoint fleet. There's no good excuse not to have it — Microsoft released it for free, and Windows LAPS is now built directly into Windows 10 22H2 and Server 2022 and later.
GPO abuse for lateral movement is the last thing I'll call out specifically. GPOs are enormously powerful and their ACLs are frequently wrong. If a non-Tier-0 account has write permissions to a GPO that applies to Domain Controllers, that's a direct path to domain compromise. BloodHound will find these — look at the "GPO Abuse" edges in the graph. The principle is the same as every other AD attack: excessive rights, misconfigured ACLs, and nobody checking until something goes wrong.
Run PingCastle. Run BloodHound. Check your KRBTGT age. Look at who has DCSync rights. Put your privileged accounts in Protected Users. Do it this week, not next quarter. Your AD is either hardened or it's a waiting room for threat actors, and the difference is almost entirely operational discipline.
