A red team does not start with a zero-day. It starts with a low-privilege domain account and a list of settings it expects you to have left alone. In a recent penetration test summarized by Web Asha, a red team reached domain admin in under two hours using Kerberoasting and Pass-the-Hash, with no MFA on the accounts and simple service account passwords. Nothing in that chain was a software flaw. Every step relied on a default Active Directory setting that the organization had never changed.
That is the uncomfortable truth about AD security. The techniques that dominate real intrusions in 2026 (Kerberoasting, Pass-the-Hash, NTLM relay, resource-based constrained delegation) are not exploits against broken code. They are the intended behavior of a directory service designed for compatibility first and security second, running with the defaults it shipped with. You close them not by patching but by making the configuration decisions Microsoft deliberately left open.
This walks through six of those decisions. For each one you get the dangerous default, the hardened value with the exact command, how to audit your own domain, and the specific attack it stops. None of them requires new licensing. Most take minutes. All of them are still wrong in the majority of environments we assess.
Local administrator passwords: stop sharing one across the fleet
The single most valuable thing an attacker can steal early in an intrusion is a local administrator password that works on more than one machine. Compromise one workstation, dump the local admin hash, and if that hash is valid on the next host, you have lateral movement with no further cracking required. This is Pass-the-Hash, and it is only devastating because so many environments image every machine with the same local admin credential.
Windows LAPS is the fix, and if you are still running the legacy Microsoft LAPS MSI in 2026, you are running a deprecated product. Microsoft deprecated legacy LAPS as of Windows 11 23H2 and blocks its installer on newer builds. Windows LAPS is native to the OS, delivered through Windows Update since April 2023, and available on Windows Server 2019, 2022, and 2025 with that update applied. It randomizes the local administrator password on every managed device, rotates it on a schedule, and backs it up to Active Directory or to Microsoft Entra ID.
The security improvement that matters is encryption. Legacy LAPS stored the password in cleartext in a computer attribute; anyone with read rights on that attribute read the password. Windows LAPS, when you enable password encryption, writes ciphertext to msLAPS-EncryptedPassword and only members of a nominated decryptor group can read it. The nuance worth internalizing: Domain Admins are not implicitly authorized to decrypt. That is a feature. It means a compromised helpdesk account with directory read access cannot harvest every local admin password in the domain, which is exactly the harvesting move Pass-the-Hash depends on.
Deploying it is a schema extension plus a GPO. From a domain controller, extend the schema and grant devices the permission to write their own password back:
Update-LapsADSchema Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=corp,DC=lab"
Then configure the Windows LAPS policy under Computer Configuration > Policies > Administrative Templates > System > LAPS (note the path moved; legacy LAPS lived directly under a LAPS node). Set the backup directory, enable password encryption, and nominate the authorized decryptor group. To audit whether it is actually working, pull a stored password and confirm the attribute is populated and encrypted:
Get-LapsADPassword -Identity "WS-NGE-MCR-014" -AsPlainText
If that returns a value for your managed hosts, LAPS is live. If it errors or returns blank on machines you expect to be managed, the GPO has not applied or the schema permission is missing. One more setting worth enabling on Windows Server 2025 and Windows 11 24H2: OS image rollback detection, which forces an immediate password rotation if a machine is reverted from a snapshot or backup, closing the window where a restored image reintroduces a known-stale password.
NTLM and unsigned channels: close the relay
Authentication relay is the attack behind AD CS ESC8, PetitPotam, and a long list of domain-compromise chains. The mechanics are simple: an attacker coerces one machine into authenticating, forwards that live authentication to a service that will accept it, and acts as the coerced machine. NTLM is the protocol that makes this trivial, because NTLM authentication carries no proof of who the client intended to talk to. Signing and channel binding are what add that proof.
Microsoft's own December 2025 guidance on critical AD threats is direct about the remediation: deprecate and disable NTLM wherever possible, enforce SMB signing and LDAP channel binding, and use Extended Protection for Authentication. The good news is that the direction of travel has moved to your advantage. In Windows Server 2025, SMB signing and LDAP channel binding are enabled by default. The bad news is that most domains are not running domain controllers on Server 2025 yet, which means on your existing DCs these are still settings you have to turn on.
Enforce LDAP signing and channel binding on domain controllers through Group Policy under Domain Controller: LDAP server signing requirements (set to "Require signing") and the channel binding token requirements policy (set to "Always"). Enforce SMB signing through Microsoft network server: Digitally sign communications (always). Before you enforce, audit what your DCs are currently accepting. Unsigned LDAP binds are logged, and you can surface the clients still using them so you fix them before you break them:
Event
| where EventLog == "Directory Service"
| where EventID in (2886, 2887, 2889)
| project TimeGenerated, DomainController = Computer, EventID,
Detail = RenderedDescription
| sort by TimeGenerated desc
Event 2887 tells you how many unsigned binds a DC accepted in the period; Event 2889 names the client IP and account making them. Work that list to zero, then enforce. Turning on signing before you have cleared 2889 events is how you take down authentication for a legacy appliance nobody remembered, so audit first.
Service accounts: kill Kerberoasting with managed accounts
Any authenticated user can request a Kerberos service ticket for any account that has a Service Principal Name. That ticket is encrypted with the service account's password hash. The attacker takes it offline and cracks it at their leisure. That is Kerberoasting, and it remains, in Microsoft's words, a low-tech, high-impact attack because the ingredients are a weak service account password and an encryption type that is cheap to crack.
Two settings defang it. First, encryption: RC4 is the crackable type, and while modern AD prefers AES, RC4 is still enabled by default, so an attacker can request an RC4 ticket even when AES is available. Microsoft has stated it intends to disable RC4 by default in a future update to Windows 11 24H2 and Windows Server 2025; until that reaches your DCs, set the msDS-SupportedEncryptionTypes on service accounts to AES-only. Second, and more powerful: stop using user-based service accounts with static passwords at all.
Group Managed Service Accounts solve the password problem by design. A gMSA has a 120-character, randomly generated, automatically rotated password that no human ever sets or knows. There is nothing crackable to Kerberoast. Create one, scope it to the hosts allowed to use it, and confirm those hosts can retrieve it:
New-ADServiceAccount -Name "gmsa-sql01" -DNSHostName "gmsa-sql01.corp.lab" `
-PrincipalsAllowedToRetrieveManagedPassword "SQL-Servers" `
-KerberosEncryptionType AES256
Test-ADServiceAccount -Identity "gmsa-sql01"
Windows Server 2025 introduces Delegated Managed Service Accounts, which go further: the secret is machine-bound and held only on the domain controller, so it cannot be stolen from the host the way a gMSA password theoretically can, and dMSA supports seamless migration of an existing service account without breaking the service. Here is the practitioner caveat that the marketing will not give you: dMSA introduced its own attack path. The technique named BadSuccessor abuses the dMSA migration mechanism for domain-wide privilege escalation, because writing the migration attributes on a dMSA object grants the successor everything the predecessor could access. dMSA is the right direction, but treat write access to dMSA objects as a privileged operation and audit it, or you will trade Kerberoasting for something worse.
For any legacy service account you cannot migrate yet, the interim fix is a genuinely long password. Set it to 30 characters of random complexity; at that length offline cracking stops being economical, which is the entire point of the attack.
Privileged accounts: make your admins undelegatable
Kerberoasting and relay give an attacker a foothold. Delegation abuse is how that foothold becomes domain admin. If a privileged account can be impersonated through Kerberos delegation, then compromising a single delegated service lets the attacker request a ticket as that admin. The defense is to make your most valuable accounts impossible to delegate or impersonate in the first place.
The Protected Users group is the blunt instrument, and it is effective. Membership forces Kerberos-only authentication (no NTLM), disables delegation, and blocks weak encryption for those accounts. Add your Domain Admins and other tier-zero identities:
Add-ADGroupMember -Identity "Protected Users" -Members "j.admin","svc-break-glass-review" Get-ADGroupMember -Identity "Protected Users" | Select-Object name, objectClass
There is a hard rule here that breaks environments when ignored: never add computer accounts or service accounts to Protected Users. The group's restrictions break the way those accounts authenticate, and you will take down services. Protected Users is for interactive human privileged accounts only.
Alongside group membership, set the account-level flag that specifically blocks impersonation. Marking a high-value account as sensitive and unable to be delegated stops it being impersonated through any S4U delegation mechanism, which is the exact primitive the next attack relies on:
Set-ADUser -Identity "j.admin" -AccountNotDelegated $true
Get-ADUser -Filter {AdminCount -eq 1} -Properties AccountNotDelegated |
Where-Object { $_.AccountNotDelegated -eq $false } |
Select-Object Name, SamAccountName
That second query is your audit: it returns every privileged account (AdminCount 1) that is still delegable. Every name it returns is an account an attacker can impersonate if they find one delegation path. The list should be empty.
Machine account quota: take away the attacker's building block
Resource-based constrained delegation abuse is one of the cleanest paths from a low-privilege user to full compromise of a target machine, and it hinges on a setting almost nobody changes. The ms-DS-MachineAccountQuota attribute controls how many computer accounts an ordinary domain user can create. The default, unchanged since Windows Server 2000, is 10. That means any authenticated user, with no special rights, can create machine accounts, and a machine account is the building block RBCD needs.
The attack chain is documented in detail across the offensive tooling: an attacker with write access to a target computer object (a common consequence of ACL drift) creates a machine account using the quota, writes it into the target's msDS-AllowedToActOnBehalfOfOtherIdentity attribute, and then uses the S4U2Self and S4U2Proxy Kerberos extensions to obtain a service ticket as any user, including a domain admin, against that target. As the Misconfiguration Manager project puts it, the default quota presents attackers with a trivial path of least resistance.
Setting it to zero removes that path. Legitimate domain joins should run through a delegated, audited provisioning process, not through every user's implicit right to create ten machines:
Get-ADObject -Identity ((Get-ADDomain).DistinguishedName) `
-Properties ms-DS-MachineAccountQuota
Set-ADDomain -Identity "corp.lab" -Replace @{"ms-DS-MachineAccountQuota"="0"}
If the first command returns 10, you are running the insecure default. After setting it to zero, only administrators and explicitly delegated accounts can create computer objects. Note the newer variant this also constrains: beyond RBCD, attackers now chain machine account creation with Shadow Credentials (writing key material to msDS-KeyCredentialLink) for certificate-based authentication abuse. Removing the free machine account raises the cost of both.
The detection layer: audit the events that actually matter
Every setting above is prevention. Prevention fails, configurations drift, and a new Server 2025 dMSA feature turns into BadSuccessor. The difference between a hardening checklist and a defended environment is that you are watching the events these attacks generate. Three matter most, and two of them are not audited by default.
Kerberoasting shows up in Event ID 4769, a Kerberos service ticket request. This event is one of the highest-volume in any domain (expect 10 to 20 per user per day), which is why it is often not logged, but the signal is the encryption type. A ticket requested with RC4, ticket encryption type 0x17, when your environment is otherwise AES, is the tell. Filter aggressively so the volume is manageable:
SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"
| where ServiceName !endswith "$"
| summarize RC4Requests = count(),
Services = make_set(ServiceName, 20) by Account, IpAddress, bin(TimeGenerated, 1h)
| where RC4Requests > 5
| sort by RC4Requests desc
That excludes computer and managed accounts (names ending in $, which legitimately use varied encryption) and flags a single account requesting RC4 tickets for many services in an hour, which is the Kerberoasting pattern rather than normal ticket activity.
RBCD abuse is quieter, because it is an attribute write, not an authentication. Modifications to msDS-AllowedToActOnBehalfOfOtherIdentity are not alerted on by default. You have to enable Directory Service Changes auditing to get Event ID 5136 (or 4662) on that attribute:
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable
Once that is on, any write to the delegation attribute is a high-fidelity signal. Legitimate writes to msDS-AllowedToActOnBehalfOfOtherIdentity are rare and change-controlled; an unexpected one on a member server is an attacker configuring their impersonation path. In Sentinel, hunt the directory-change stream for it:
SecurityEvent
| where EventID == 5136
| where AttributeLDAPDisplayName == "msDS-AllowedToActOnBehalfOfOtherIdentity"
| project TimeGenerated, DomainController = Computer,
TargetObject = ObjectDN, ModifiedBy = SubjectUserName,
OperationType
| sort by TimeGenerated desc
The third signal, AS-REP roasting, appears as Event ID 4768 with a pre-authentication type of 0. If you run Microsoft Defender for Identity, most of this is surfaced for you: it alerts on suspicious authentication patterns, lateral movement, and NTLM relay attempts directly, which is the fastest route to coverage if you have the license. Whether you use Defender for Identity or raw event logs, the principle is the same: the prevention settings close the doors, and the detection layer tells you when someone tests the handle.
What to do this week
- Audit machine account quota first, because it is one command and one fix. Run the
Get-ADObjectquery above. If it returns 10, set it to 0 today. This is the single highest-value-to-effort change in the list, and it removes the building block for RBCD and Shadow Credentials in one line. - Find your delegable admins. Run the
AccountNotDelegated -eq $falseaudit against AdminCount 1 accounts. Every name it returns is a domain admin an attacker can impersonate through delegation. Set the flag and add them to Protected Users (humans only, never service or computer accounts). - Inventory your SPN accounts and check their encryption. List every user account with a Service Principal Name and confirm none are RC4-only with a short password. Migrate the ones you can to gMSA; set a 30-character password on the ones you cannot yet migrate.
- Confirm LAPS is real, not assumed. Run
Get-LapsADPasswordagainst a sample of workstations and servers. If it returns blank on machines you believe are managed, your GPO or schema permission is broken and you have shared local admin passwords you think are protected. - Turn on the two audits you are almost certainly missing. Enable Directory Service Changes auditing so writes to
msDS-AllowedToActOnBehalfOfOtherIdentitygenerate Event 5136, and confirm your DCs log Event 2889 so you can find unsigned LDAP binds before you enforce signing. Prevention you cannot see failing is prevention you cannot trust.
Every attack in this article was a default setting, not a vulnerability. That is the good news and the hard news at once: nobody is going to patch these for you, because there is nothing broken to patch. The domain does exactly what it was configured to do. Hardening AD is the work of making the configuration decisions the installer left open, and the attackers already know which ones you skipped.