Three weeks ago, on the internal bank infrastructure pentest, we got Domain Admin in 47 minutes. The chain is banal to the limit: Responder in custom VLAN, NTLMv2-hash service accounting via LLMNR reporting (T1557.001), hashcat, lateral movement via CrackMapExec with a common password of the local admin - Pass the Hash (T1550.002) at each working station, LSASS dump, DA. On the next project - about the same scale, the same Windows Server stack - on the fourth day we still collected the BloodHound graph in search of at least some way to Tier 0. The difference is not in the budget for EDR. The difference is Protected Users, Active Directory Tiering Model and LAPS. Three measures that turn the Hardening Active Directory from a paper recommendation into a real headache for the attacker.
According to the IBM X-Force Threat Intelligence Index 2025, the increase in attacks using Valid Accounts (T1078) is 71% year-on-year. CrowdStrike Global Threat Report 2025 confirms that 75% of the incursions in 2024 were based on valid creeds, and the average time of the lateral movement after initial access is 62 minutes. Credential-based attack is the main vector. And it is on them that the khardening should be focused.
Below - analysis of each of the three measures from the point of view of the attacker: what it breaks in the standard chain, how to check its presence from grey box and what Event IDs give you to SIEM.
Choosing an Attack Vector: Decisionatory tree for Active Directory Pentest
The first 15 minutes of internal pentest determine the strategy. That's what to check before the launch of the first tool - and as a result changes the vector.
Context of Applicability: The table works for an internal pentest in grey box (there is a Domain User level domain record) or black box (received initial access through a physical connection to VLAN). For an external pentest, these measures are irrelevant until the moment of fixing inside the perimeter.
Active Directory Tiering Model: Tier 0, Tier 1, Tier 2 and lateral movement
Tiering Model is the division of the AD environment into three levels with tight restrictions on the logogs between them. For the attacker, the essence is simple: the compromising user's workstation (Tier 2) no longer gives a direct path to Domain Admin (Tier 0).
How to break the standard attack chain without tiering
Classical scenario of the internal pentest, which I watch repeatedly:
1. Initial access via phishing or physical connection → Tier 2
2. LSASS Dump on a compromised workstation
3. In the dump - the hash Domain Admin, which "for a moment" logged into this station
4. Pass the Hash on DC → DCSync → Full control
Step 3 is possible only because DA logs to the Tier 2 car. Tiering Model removes this step through GPO: Deny log on locally, Deny log on through Remote Desktop Services, Deny access to this computer from the network for DA/EA on all machines except DC and Privileged Access Workstation (PAW). The way GPO: Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment.
What is Tier 0 besides domain controllers
According to data from the radar.com, Tier 0 is not just DC. And here begins the most interesting - often missed systems:
• Backup servers with DC backup tasks - restore backup DC = domain ownership. It is almost always forgotten.
• Azure AD Connect / Entra ID Connect - synchronization of credos with the cloud.
• SCCM, if you can press packages on DC - execute code on DC via deployment. On one project, it was through the SCCM that I came in when the straight path was closed.
• PAM servers (CyberArk, BeyondTrust, Delinea), which store DA-creeds - compromising vault = all DA-passwords at once.
• IGA-platforms (SailPoint, Savyynt), which can create DA-mechanics.
On the pentest, run BloodHound with --CollectionMethods All and look for Shortest Path to Domain Admins. There are often paths through Tier 1 systems that are actually Tier 0, but have not been classified as such.
Where tiering is incomplete: typical finds on pentests
According to the experience, the full Tiering Model is a rarity. Here's what I find regularly:
• Service accounting with DA-rights on Tier 1-servers. One compromised service accounting on the web server = DA. Verification: Get-ADGroupMember "Domain Admins" -Recursive- interposingly compare each DA with the accounts that have SPN (service accounting = Kerberoasting target).
• One-tracked administrators for all levels. GPO bans DA logon at the station, but “admin_ivanov” in ordinary groups has DCSync rights through ACL – and is used everywhere. According to the documents - tiering introduced. In practice, a hole the size of a gate.
• Jump servers without MFA - RDP sessions for DC are available to any server admin. Formally, there is a jump-server, in fact - just a proxy without protection.
Context: Tiering Model is relevant for corporate AD from 100+ hosts. In small environments, formal tiering is excessive, but the principle of "DA does not login to workstations" is mandatory on any scale.
LAPS Customization and Audit: End of the Same Local Admin Passwords
Without LAPS, the password of the local administrator is the same on all workstations - is set through an image or worse, through Group Policy Preferences (GPP). Let me remind you: 32-byte AES-keye to decrypt GPP cpassword is published by Microsoft in the [MS-GPPREF] §2.2.1.1.4 - encryption is useless. MS14-025 banned the creation of new GPP passwords, but the already existing cpassword in SYSVOL remains decryptible by any domain user. One intercepted hash via PtH (T1550.002) opens access to each machine in the domain.
LAPS generates a unique password of the local admin on each host, rotates it according to the schedule and stores it in the attribute ms-Mcs-AdmPwd computer object in AD.
ACL-misconfigurations: when LAPS does not save
LAPS is open - great. Who can read the passwords? Check the ACL for each OU:
(Get-ACL "AD:\OU=Workstations,DC=domain,DC=com").Access | Where-Object { $.ActiveDirectoryRights -match "ReadProperty" -and $.ObjectType -eq "ms-Mcs-AdmPwd" } | Select-Object IdentityReference
If the list is a group wider than dedicated helpdesk bands (for example, Domain Users or all Tier 1-admins), an attack with low-privcent can read LAPS passwords of all cars in OU. In practice, this makes LAPS protected a convenient password guide. I have seen this more than once - LAPS is unfolded, ACL is not configured, and any domain user dumbly reads the passwords of local admins through the LDAP.
Windows LAPS vs Legacy LAPS
Starting with Windows Server 2019 (and especially in 2022), Microsoft has turned on Windows LAPS naïtically in the OS. Key difference for the attacker: the password in AD can be encrypted with a key available only to authorized principals. Password encryption requires DFL 2016+ and the presence of KDS root key in the domain (the same as used for gMSA); without KDS root, encryption will not start. Without encryption Windows LAPS works on any supported DFL, but the password is stored in plaintext, as in Legacy LAPS. Password history and integration with Azure AD are also maintained. If the customer on Windows LAPS with encryption - a simple reading of the attribute is no longer working.
To check the Windows LAPS cover: Get-LapsADPassword -Identity "WORKSTATION01" -AsPlainText - if the command returns the password, then your accounting has access; if not - ACL is configured correctly.
Detecting Active Directory Attacks through Event Log and AD monitoring via SIEM
Each technique described above leaves footprints in Windows Event Log. The question is whether SIEM is set to process them and whether the SOC team understands what it sees.
Key Event ID for monitoring AD-attacks
Sigma-rules from SigmaHQ
From the SigmaHQ repository, ready-made rules for specific techniques are available:
• Pass the Hash (T1550.002): win_security_potential_pass_the_hash.ymland win_security_pass_the_hash_2.ymlEvent 4624 Type 9 with LogonProcess seclogo
• LLMNR Poisoning (T1557.001): driver_load_win_windivert.yml- download WinDivert-driver used by Inveigh
• PetitPotam / Forced Authentication (T1187): win_security_petitpotam_network_share.ymland zeek_dce_rpc_potential_petit_potam_efs_rpc_call.yml- DCE/RPC-detect
Example of Sigma-rules for PTH (adapted from SigmaHQ):
YAML:
title: Potential Pass the Hash Activity
logsource:
product: windows
service: security
detection:
selection:
EventID: 4624
LogonType: 9
LogonProcessName: 'seclogo'
AuthenticationPackageName: 'Negotiate'
condition: selection
level: medium
The rule works on the Event 4624 Type 9 with the secgo process - a typical PtH pattern through sekurlsa:
th (Mimikatz) or Impacket. Converted to the Splunk or Microsoft Sentinel request via sigma-cli. Limitation: false positive with the legitimate runas /netonly. In environments with AD FS and SSO scenarios, whitelist tuning is required.
OPSEC: how to stay quiet as an attacker in a pret Chartered environment
• RC4 queries in an environment with Protected Users - if all preferred accounting in AES-only, any RC4 request to KDC will fall into the correlation. Kerberoasting through AES generates less noise, but it is more difficult to break the tickets. A double-edged sword.
• NTLM for DA is an attempt by NTLM-auth to record from Protected Users will generate Event 4776 with an error code. Direct alert in any customized SIEM. If the SOC does not sleep, you will be noticed.
• BloodHound - mass LDAP queries do not trigger standard rules, but advanced SIEM (Microsoft Sentinel with UBA, Splunk ES) correlate the volume of requests from a single source. The option is quiet - --CollectionMethods DCOnly.
• DCSync - Event 4662 with reference to DS-Replication-Get-Changes-Allfrom non-DC source. Windows is impossible to bypass Windows; the only way is SIEM compromise or log cleansing. You can't call it an elegant solution.
Chardening Checklist Active Directory for Pentest Report
Each point is a specific action. The format is suitable for transmitting sysadmin or included in the application to the report.
Priority 1 - closes the main credential-based vectors:
• All DA, EA, Schema Admins Accounts Added to Protected Users
• LAPS will be deployed on all workstations and servers (Cover check: Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwd)
• LLMNR disable via GPO (key EnableMulticast = 0in HKLM\Software\Policies\Microsoft\Windows NT\DNSClient)
• NBT-NS is disconnected via NodeType = 2 (HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters)
• GPO User Rights Assignment: Deny voln locally / Deny RDP / Deny network access for DA/EA on all non-DC/PAW hosts
Priority 2 - closes the lateral movement:
• ACL on ms-Mcs-AdmPwdlimited to dedicated group, not Domain Users
• Service accounting is removed from Domain Admins, replaced by gMSA
• Unconstrained delegation only on DC (PrimaryGroupID 516)
• AS-REP Roastable Accounting: 0
• Credential Guard on Windows 10+ / Server 2016+
Priority 3 - monitoring and detecting:
• Auditette Event ID 4768, 4769, 4624, 4776, 4662 included on all DCs
• Sigma-rules for PtH and DCSync imported into SIEM
• Alert on NTLM-audination for accounting from Protected Users
• Regular (once a quarter) BloodHound to find new paths to Tier 0
Of the dozens of internal AD pentests over the past two years, I have seen a steady pattern: organizations buy EDR and SIEM without implementing basic free measures. EDR regularly detects Mimikatz - well done - but the DA-hash already lies in the LSASS work station of an accountant, because the administrator logged "for a minute to watch the printer." Tiering Model costs zero rubles and requires only GPO, but it is not implemented, because it is “inconvenient” for sysadmins to keep individual records. Protected Users are not included because “whatever something breaks down” – and not even tested on a pilot group. As a result, the privileged access of Active Directory is formally protected, and the real path from the user VLAN to DCSync is laid at lunchtime. According to the experience, the organization that has at least implemented Priority 1 of the checklist above increases the time of pentest from days to weeks - and this is without a single new product in the stack.
According to the IBM X-Force Threat Intelligence Index 2025, the increase in attacks using Valid Accounts (T1078) is 71% year-on-year. CrowdStrike Global Threat Report 2025 confirms that 75% of the incursions in 2024 were based on valid creeds, and the average time of the lateral movement after initial access is 62 minutes. Credential-based attack is the main vector. And it is on them that the khardening should be focused.
Below - analysis of each of the three measures from the point of view of the attacker: what it breaks in the standard chain, how to check its presence from grey box and what Event IDs give you to SIEM.
Choosing an Attack Vector: Decisionatory tree for Active Directory Pentest
The first 15 minutes of internal pentest determine the strategy. That's what to check before the launch of the first tool - and as a result changes the vector.
Context of Applicability: The table works for an internal pentest in grey box (there is a Domain User level domain record) or black box (received initial access through a physical connection to VLAN). For an external pentest, these measures are irrelevant until the moment of fixing inside the perimeter.
Active Directory Tiering Model: Tier 0, Tier 1, Tier 2 and lateral movement
Tiering Model is the division of the AD environment into three levels with tight restrictions on the logogs between them. For the attacker, the essence is simple: the compromising user's workstation (Tier 2) no longer gives a direct path to Domain Admin (Tier 0).
How to break the standard attack chain without tiering
Classical scenario of the internal pentest, which I watch repeatedly:
1. Initial access via phishing or physical connection → Tier 2
2. LSASS Dump on a compromised workstation
3. In the dump - the hash Domain Admin, which "for a moment" logged into this station
4. Pass the Hash on DC → DCSync → Full control
Step 3 is possible only because DA logs to the Tier 2 car. Tiering Model removes this step through GPO: Deny log on locally, Deny log on through Remote Desktop Services, Deny access to this computer from the network for DA/EA on all machines except DC and Privileged Access Workstation (PAW). The way GPO: Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment.
What is Tier 0 besides domain controllers
According to data from the radar.com, Tier 0 is not just DC. And here begins the most interesting - often missed systems:
• Backup servers with DC backup tasks - restore backup DC = domain ownership. It is almost always forgotten.
• Azure AD Connect / Entra ID Connect - synchronization of credos with the cloud.
• SCCM, if you can press packages on DC - execute code on DC via deployment. On one project, it was through the SCCM that I came in when the straight path was closed.
• PAM servers (CyberArk, BeyondTrust, Delinea), which store DA-creeds - compromising vault = all DA-passwords at once.
• IGA-platforms (SailPoint, Savyynt), which can create DA-mechanics.
On the pentest, run BloodHound with --CollectionMethods All and look for Shortest Path to Domain Admins. There are often paths through Tier 1 systems that are actually Tier 0, but have not been classified as such.
Where tiering is incomplete: typical finds on pentests
According to the experience, the full Tiering Model is a rarity. Here's what I find regularly:
• Service accounting with DA-rights on Tier 1-servers. One compromised service accounting on the web server = DA. Verification: Get-ADGroupMember "Domain Admins" -Recursive- interposingly compare each DA with the accounts that have SPN (service accounting = Kerberoasting target).
• One-tracked administrators for all levels. GPO bans DA logon at the station, but “admin_ivanov” in ordinary groups has DCSync rights through ACL – and is used everywhere. According to the documents - tiering introduced. In practice, a hole the size of a gate.
• Jump servers without MFA - RDP sessions for DC are available to any server admin. Formally, there is a jump-server, in fact - just a proxy without protection.
Context: Tiering Model is relevant for corporate AD from 100+ hosts. In small environments, formal tiering is excessive, but the principle of "DA does not login to workstations" is mandatory on any scale.
LAPS Customization and Audit: End of the Same Local Admin Passwords
Without LAPS, the password of the local administrator is the same on all workstations - is set through an image or worse, through Group Policy Preferences (GPP). Let me remind you: 32-byte AES-keye to decrypt GPP cpassword is published by Microsoft in the [MS-GPPREF] §2.2.1.1.4 - encryption is useless. MS14-025 banned the creation of new GPP passwords, but the already existing cpassword in SYSVOL remains decryptible by any domain user. One intercepted hash via PtH (T1550.002) opens access to each machine in the domain.
LAPS generates a unique password of the local admin on each host, rotates it according to the schedule and stores it in the attribute ms-Mcs-AdmPwd computer object in AD.
ACL-misconfigurations: when LAPS does not save
LAPS is open - great. Who can read the passwords? Check the ACL for each OU:
(Get-ACL "AD:\OU=Workstations,DC=domain,DC=com").Access | Where-Object { $.ActiveDirectoryRights -match "ReadProperty" -and $.ObjectType -eq "ms-Mcs-AdmPwd" } | Select-Object IdentityReference
If the list is a group wider than dedicated helpdesk bands (for example, Domain Users or all Tier 1-admins), an attack with low-privcent can read LAPS passwords of all cars in OU. In practice, this makes LAPS protected a convenient password guide. I have seen this more than once - LAPS is unfolded, ACL is not configured, and any domain user dumbly reads the passwords of local admins through the LDAP.
Windows LAPS vs Legacy LAPS
Starting with Windows Server 2019 (and especially in 2022), Microsoft has turned on Windows LAPS naïtically in the OS. Key difference for the attacker: the password in AD can be encrypted with a key available only to authorized principals. Password encryption requires DFL 2016+ and the presence of KDS root key in the domain (the same as used for gMSA); without KDS root, encryption will not start. Without encryption Windows LAPS works on any supported DFL, but the password is stored in plaintext, as in Legacy LAPS. Password history and integration with Azure AD are also maintained. If the customer on Windows LAPS with encryption - a simple reading of the attribute is no longer working.
To check the Windows LAPS cover: Get-LapsADPassword -Identity "WORKSTATION01" -AsPlainText - if the command returns the password, then your accounting has access; if not - ACL is configured correctly.
Detecting Active Directory Attacks through Event Log and AD monitoring via SIEM
Each technique described above leaves footprints in Windows Event Log. The question is whether SIEM is set to process them and whether the SOC team understands what it sees.
Key Event ID for monitoring AD-attacks
Sigma-rules from SigmaHQ
From the SigmaHQ repository, ready-made rules for specific techniques are available:
• Pass the Hash (T1550.002): win_security_potential_pass_the_hash.ymland win_security_pass_the_hash_2.ymlEvent 4624 Type 9 with LogonProcess seclogo
• LLMNR Poisoning (T1557.001): driver_load_win_windivert.yml- download WinDivert-driver used by Inveigh
• PetitPotam / Forced Authentication (T1187): win_security_petitpotam_network_share.ymland zeek_dce_rpc_potential_petit_potam_efs_rpc_call.yml- DCE/RPC-detect
Example of Sigma-rules for PTH (adapted from SigmaHQ):
YAML:
title: Potential Pass the Hash Activity
logsource:
product: windows
service: security
detection:
selection:
EventID: 4624
LogonType: 9
LogonProcessName: 'seclogo'
AuthenticationPackageName: 'Negotiate'
condition: selection
level: medium
The rule works on the Event 4624 Type 9 with the secgo process - a typical PtH pattern through sekurlsa:
th (Mimikatz) or Impacket. Converted to the Splunk or Microsoft Sentinel request via sigma-cli. Limitation: false positive with the legitimate runas /netonly. In environments with AD FS and SSO scenarios, whitelist tuning is required.OPSEC: how to stay quiet as an attacker in a pret Chartered environment
• RC4 queries in an environment with Protected Users - if all preferred accounting in AES-only, any RC4 request to KDC will fall into the correlation. Kerberoasting through AES generates less noise, but it is more difficult to break the tickets. A double-edged sword.
• NTLM for DA is an attempt by NTLM-auth to record from Protected Users will generate Event 4776 with an error code. Direct alert in any customized SIEM. If the SOC does not sleep, you will be noticed.
• BloodHound - mass LDAP queries do not trigger standard rules, but advanced SIEM (Microsoft Sentinel with UBA, Splunk ES) correlate the volume of requests from a single source. The option is quiet - --CollectionMethods DCOnly.
• DCSync - Event 4662 with reference to DS-Replication-Get-Changes-Allfrom non-DC source. Windows is impossible to bypass Windows; the only way is SIEM compromise or log cleansing. You can't call it an elegant solution.
Chardening Checklist Active Directory for Pentest Report
Each point is a specific action. The format is suitable for transmitting sysadmin or included in the application to the report.
Priority 1 - closes the main credential-based vectors:
• All DA, EA, Schema Admins Accounts Added to Protected Users
• LAPS will be deployed on all workstations and servers (Cover check: Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwd)
• LLMNR disable via GPO (key EnableMulticast = 0in HKLM\Software\Policies\Microsoft\Windows NT\DNSClient)
• NBT-NS is disconnected via NodeType = 2 (HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters)
• GPO User Rights Assignment: Deny voln locally / Deny RDP / Deny network access for DA/EA on all non-DC/PAW hosts
Priority 2 - closes the lateral movement:
• ACL on ms-Mcs-AdmPwdlimited to dedicated group, not Domain Users
• Service accounting is removed from Domain Admins, replaced by gMSA
• Unconstrained delegation only on DC (PrimaryGroupID 516)
• AS-REP Roastable Accounting: 0
• Credential Guard on Windows 10+ / Server 2016+
Priority 3 - monitoring and detecting:
• Auditette Event ID 4768, 4769, 4624, 4776, 4662 included on all DCs
• Sigma-rules for PtH and DCSync imported into SIEM
• Alert on NTLM-audination for accounting from Protected Users
• Regular (once a quarter) BloodHound to find new paths to Tier 0
Of the dozens of internal AD pentests over the past two years, I have seen a steady pattern: organizations buy EDR and SIEM without implementing basic free measures. EDR regularly detects Mimikatz - well done - but the DA-hash already lies in the LSASS work station of an accountant, because the administrator logged "for a minute to watch the printer." Tiering Model costs zero rubles and requires only GPO, but it is not implemented, because it is “inconvenient” for sysadmins to keep individual records. Protected Users are not included because “whatever something breaks down” – and not even tested on a pilot group. As a result, the privileged access of Active Directory is formally protected, and the real path from the user VLAN to DCSync is laid at lunchtime. According to the experience, the organization that has at least implemented Priority 1 of the checklist above increases the time of pentest from days to weeks - and this is without a single new product in the stack.
