Use WinRM, WinRS or PowerShell remoting

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.

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. More detail ↓

If → then

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

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Use WinRM, WinRS or PowerShell remoting

USE WHEN: A WinRM listener and a candidate endpoint-authorized account
STARTING ACCESS: Identified authentication material, destination service reachability and a candidate authorized identity
RESULT: A verified remote command session under the endpoint-authorized identity

Recognize the clue

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

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

SYNTHETIC EXAMPLE OUTPUT

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

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

Confirm: Verify accepted authentication, correct name/TLS context, endpoint rights and any second-hop requirements.

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.
Still inconclusive: Second-hop resource failure does not disprove the first WinRM authentication.

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

Evil-WinRM

Current Evil-WinRM ticket-file support:

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

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

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

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.

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.

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.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗