7 min read

Reconnaissance

User Hunting

Identify where high-value users are logged in, find admin sessions on compromisable systems, and map user-to-system relationships for targeted attacks.

User hunting: identify high-value users, find where they hold sessions, locate a system you can reach, then plan the path

Identifying Target Users

High-Value Targets

high-value-targets.ps1
# PowerView - Domain Admins
Get-DomainGroupMember -Identity "Domain Admins" -Recurse

# Enterprise Admins
Get-DomainGroupMember -Identity "Enterprise Admins" -Recurse

# Backup Operators (can extract NTDS.dit)
Get-DomainGroupMember -Identity "Backup Operators" -Recurse

# Users with adminCount (protected users)
Get-DomainUser -AdminCount | Select-Object samaccountname

Service Accounts

service-accounts.ps1
# Find service accounts - often overprivileged
Get-DomainUser -SPN | Select-Object samaccountname, serviceprincipalname, memberof

# Accounts with password never expires
Get-DomainUser -PasswordNeverExpires | Select-Object samaccountname, memberof

# gMSA accounts (PowerShell AD module)
Get-ADServiceAccount -Filter *

Session Enumeration

Warning

Session enumeration requires local admin on target systems or specific permissions. This generates logs and may be detected.

Danger

This is the first phase that acts on named people. Enumerating where Domain Admins are logged on produces a list of workstations associated with individuals, and running Find-DomainUserLocation or nxc --sessions estate-wide puts a query on every host it reaches — including the laptops of staff who are not part of the test. Filter the target list against the exclusion list before the run, keep the output to account names rather than personal detail, and if an excluded host answers, note it and drop the row rather than reporting it.

PowerView Session Hunting

session-hunting.ps1
# Find where domain admins are logged in
Find-DomainUserLocation -UserGroupIdentity "Domain Admins"

# Find sessions for specific user
Find-DomainUserLocation -UserIdentity "administrator"

# Check specific computers
Get-NetSession -ComputerName "WORKSTATION01"

# Get logged on users
Get-NetLoggedon -ComputerName "WORKSTATION01"

# Find local admin access - where current user is admin
Find-LocalAdminAccess

nxc Session Enum

nxc-sessions.sh
# Enumerate sessions (requires admin)
nxc smb targets.txt -u user -p password --sessions

# Find logged on users
nxc smb targets.txt -u user -p password --loggedon-users

# NetExec version
nxc smb targets.txt -u user -p password --sessions
nxc smb targets.txt -u user -p password --loggedon-users

BloodHound Queries

Information

BloodHound Cypher queries help identify attack paths. Run these in the BloodHound GUI Raw Query box. Use the built-in queries for common searches.

Common BloodHound pre-built queries:

  • Find all Domain Admins
  • Find Shortest Path to Domain Admins
  • Find Computers where Domain Users are Local Admin
  • Shortest Path from Owned Principals
  • Find users with foreign domain group membership

Local Admin Hunting

Find Where You Have Admin

local-admin-hunting.ps1
# PowerView - Check admin access
Find-LocalAdminAccess -Verbose

# Threaded version (faster)
Find-LocalAdminAccess -ComputerFile computers.txt -Threads 20

# nxc spray for admin access
nxc smb targets.txt -u user -p password

# NetExec
nxc smb targets.txt -u user -p password

Local Admin Group Members

local-group-members.ps1
# Who is local admin on a computer
Get-NetLocalGroupMember -ComputerName "WORKSTATION01" -GroupName "Administrators"

# Find computers where a specific user is local admin
Get-DomainGPOUserLocalGroupMapping -Identity "targetuser"

Network Share Hunting

share-hunting.sh
# Find interesting shares
Find-DomainShare -CheckShareAccess

# nxc spider shares
nxc smb target -u user -p password -M spider_plus

# Manual share hunting
smbclient -L //TARGET -U user%password
smbclient //TARGET/share -U user%password

Attack Path Planning

Attack-path planning: if you are admin on a system, check for a Domain Admin session; if not, find a credential opportunity and loop back

Strategy

user-hunting-workflow.ps1
# Step-by-step user hunting workflow

# 1. Find where you have admin access
Find-LocalAdminAccess > my_admin_access.txt

# 2. Identify high-value targets
Get-DomainGroupMember -Identity "Domain Admins" | Select-Object MemberName

# 3. Find where targets have sessions
Find-DomainUserLocation -UserGroupIdentity "Domain Admins"

# 4. Cross-reference with your access
# If DA is on system you have admin access to:
# - Dump credentials with Mimikatz
# - Token impersonation  
# - Hash extraction from LSASS

Quick Reference

Task Tool Command
Find DA sessions PowerView Find-DomainUserLocation -UserGroupIdentity "Domain Admins"
My admin access PowerView Find-LocalAdminAccess
Sessions on host nxc nxc smb TARGET -u user -p pass --sessions
Logged on users nxc nxc smb TARGET -u user -p pass --loggedon-users
Attack paths BloodHound Shortest Path to Domain Admin

Evidence Collection

The output of this phase is a relationship map — who is privileged, and which machine they touch — so evidence means the mapping plus the query that produced it.

Privileged principals: Members of Domain Admins, Enterprise Admins and Backup Operators, with the query used. Record nested groups separately, because the direct member list is usually shorter than the actual privilege.

Session map: Host → account pairs where a privileged account holds a session, with the collection time. Sessions expire; a map without a timestamp cannot be reproduced.

Your own access map: The Find-LocalAdminAccess or nxc smb result showing which hosts the test account is admin on. That is the set of hosts the exploitation phase may use.

Share access: Readable and writable shares per host, with the account the read was performed as. A writable share is a delivery path; a readable finance share is a confidentiality finding.

Breadcrumb trail: The command lines and their times for the touched hosts, so the client's SOC can separate your 4624s from an intrusion that happened the same week.

False Positive Identification

  • An old session in the table: Session enumeration reports sessions that the host has not cleaned up. Cross-check against the logon time and the host's uptime before reporting an admin as "logged on".
  • A privileged account with no interactive logon: Service accounts appear in privileged groups and never log on. Their session count is zero, not a gap in collection — the relevant finding is their memberOf.
  • A local admin who is not a domain admin: A helpdesk account in the local Administrators group of 200 workstations is a lateral-movement path, not domain compromise. Report the reach, not the label.
  • Access denied read as absence: NT_STATUS_ACCESS_DENIED from Get-NetSession means the query was refused, not that nobody is logged on. Do not report an empty result as a clean host.

Testing Checklist

The output of this phase is a claim about who is where. Each claim needs a timestamp and a host, or it expires before the report is written.

Confirm the hunt ran

  • ☐ Get-NetSession or nxc smb --sessions returns at least one host and account; an empty result on a busy host is a privilege problem, not a clean estate.
  • ☐ Invoke-UserHunter flags the hosts where a Domain Admin holds a session, and two of them are confirmed by hand.
  • ☐ Find-LocalAdminAccess lists the hosts your account is admin on - that list is the blast radius carried into exploitation.
  • ☐ Share access is proved by opening one file, not by reading a listing.

Confirm the claim holds

  • ☐ Every session row carries a collection time and is compared against the host's uptime before it is reported.
  • ☐ A privileged account with zero sessions is explained by its memberOf, not recorded as a collection gap.
  • ☐ A local-admin hit is graded by reach (how many hosts) rather than by the name of the group.
  • ☐ The hosts you touched are logged with timestamps, so the client's SOC can separate your 4624s from anyone else's.

Remediation & Defense

The controls that make this phase boring are the ones that stop a stolen account becoming domain admin.

Break the session path

  • • Tier admin accounts: Domain Admin credentials never log on to a workstation
  • • Use Protected Users for Tier 0 accounts, and deny delegation for them
  • • Enable Credential Guard and remove local admin rights from standard users (LAPS for the rest)

Reduce what enumeration returns

  • • Restrict Remote Registry and Server service session enumeration to admin groups
  • • Remove stale sessions and unused local admin entries, especially helpdesk accounts
  • • Audit share permissions so a standard user cannot read HR or Finance trees