This chapter covers Evil-WinRM, a powerful penetration testing tool used to gain interactive Windows remote shells via the WinRM protocol. For the PT0-002 exam, understanding Evil-WinRM is critical for Objective 5.1 (Tools and Scripts), as it is a key tool for post-exploitation and lateral movement in Windows environments. Approximately 5-8% of exam questions touch on remote management tools and their use in penetration testing, with Evil-WinRM being a frequent focus due to its integration with Metasploit and its ability to bypass modern defenses.
Jump to a section
Imagine a high-security office building where employees use secure keycards to access different floors. The building has a master key system: a special key that can open any door in the building, but only works when used from a specific entrance that logs all access. Evil-WinRM is like a master key for Windows Remote Management (WinRM) — it uses the same protocol as legitimate remote administration but automates the process of gaining a full interactive shell, like a burglar who has stolen the master key and knows exactly which door to use. The protocol itself (WinRM) is like the building's electronic lock system: it allows authorized personnel to open doors remotely. Evil-WinRM, however, is a specialized tool that not only uses the master key (valid credentials) but also bypasses many standard restrictions — like entering through a service entrance that has less surveillance. It leverages the same SOAP-based web service messages as legitimate WinRM but sends commands in a way that gives the attacker a persistent, interactive command prompt, similar to having a walkie-talkie inside the building. The tool also handles encryption (HTTPS) and authentication (NTLM/Kerberos) transparently, just as the master key works with any lock mechanism. In penetration testing, Evil-WinRM is the preferred tool when you have valid credentials and need a reliable, stealthy remote shell on a Windows target, especially in post-exploitation scenarios where you want to avoid noisy payloads like reverse shells.
What is Evil-WinRM and Why It Exists
Evil-WinRM is an open-source penetration testing tool written in Ruby that provides a fully interactive shell to Windows systems via the WinRM (Windows Remote Management) protocol. It was created by Hackplayers and is maintained as a community project. The tool's primary purpose is to give penetration testers a reliable, encrypted, and authenticated remote shell on Windows machines without needing to deploy traditional payloads like reverse shells or bind shells. This is especially valuable in post-exploitation phases where stealth and persistence are paramount.
The WinRM protocol (Microsoft's implementation of WS-Management) is natively enabled on most modern Windows systems (Windows Server 2012 and later, Windows 8 and later) and is used for remote administration. Evil-WinRM exploits this legitimate functionality to provide an attacker with a shell that looks and feels like a native Windows command prompt (cmd.exe) or PowerShell console. Because WinRM traffic is encrypted (HTTPS by default, HTTP also supported) and uses standard ports (5985 for HTTP, 5986 for HTTPS), it often blends in with normal administrative traffic, making it harder for network defenders to detect.
How Evil-WinRM Works Internally
Evil-WinRM operates by establishing a WinRM session over HTTP or HTTPS. The process involves several steps:
Authentication: Evil-WinRM supports multiple authentication methods: Basic, NTLM, Kerberos, and Certificate-based. The most common in penetration testing is NTLM, which uses the user's password hash or plaintext password. The tool sends a WS-Management Identify request to the target's WinRM listener, which triggers a challenge-response exchange. If successful, the server returns a session token.
Session Establishment: Once authenticated, Evil-WinRM opens a WinRM shell resource using the CreateShell operation. This creates a new command shell (cmd.exe or PowerShell) on the target, associated with the authenticated user's privileges. The shell ID is returned and used for subsequent commands.
Command Execution: Commands are sent using the Command operation, which includes the shell ID and the command string. The output is retrieved via the Receive operation, which polls for results. Evil-WinRM supports both synchronous and asynchronous command execution. For interactive use, it sends each command as a separate Command operation, mimicking a terminal.
Interactive Features: Evil-WinRM provides features like tab completion, history, and file upload/download. Upload/download uses the WinRM Put and Get operations, which transfer files as base64-encoded payloads within SOAP messages. This allows transferring files up to 2GB in size (limited by WinRM's default max envelope size, which can be increased).
Persistence: The shell remains active until the user exits or the session times out. Evil-WinRM also supports a "Bypass" mode that disables PowerShell's execution policy and logging (using the -Bypass flag), making it stealthier.
Key Components, Values, Defaults, and Timers
- Default Ports: WinRM listens on port 5985 (HTTP) and 5986 (HTTPS). Evil-WinRM defaults to port 5985 unless -S (SSL) is specified.
- Authentication Methods:
- -u and -p for Basic or NTLM (plaintext password)
- -H for NTLM hash (pass-the-hash)
- -k for Kerberos (requires domain context)
- -c for certificate authentication (client certificate file)
- SSL: Use -S to force HTTPS; --no-ssl to disable (not recommended).
- Timeout: Default command timeout is 60 seconds (configurable with -t).
- Execution Policy Bypass: -b flag bypasses PowerShell execution policy.
- Output Format: -o to specify output format (e.g., -o xml for XML output).
- Proxy Support: -P for HTTP proxy.
- Logging: -l logs all traffic to a file.
- Max Envelope Size: Default is 150KB; file transfers may fail for larger files unless increased on the server (via winrm set winrm/config @{MaxEnvelopeSizekb="2048"}).
Configuration and Verification Commands
To use Evil-WinRM, you must first have valid credentials for the target Windows system. The target must have WinRM enabled and configured to allow remote connections. On the target, you can verify WinRM status with:
winrm get winrm/configOr via PowerShell:
Get-Service -Name WinRMTo enable WinRM (if not already enabled):
Enable-PSRemoting -ForceThis sets the service to start automatically and configures the firewall rules for ports 5985/5986.
How Evil-WinRM Interacts with Related Technologies
Evil-WinRM is often used in conjunction with Metasploit. You can load Evil-WinRM as a Metasploit module (auxiliary/scanner/winrm/winrm_login for brute-forcing, exploit/windows/winrm/winrm_script_exec for execution). However, the standalone Evil-WinRM tool (Ruby gem) is more flexible for interactive use. It also integrates with Impacket's wmiexec and psexec for lateral movement, but Evil-WinRM provides a more seamless shell experience.
Evil-WinRM can be used to pivot through a compromised host to reach internal networks. By establishing a WinRM session to a jump box, you can then use that session to access other systems. This is particularly useful in Active Directory environments where WinRM is commonly enabled for administrative tasks.
Common Use Cases in Penetration Testing
Post-Exploitation: After gaining initial access (e.g., via a web shell or phishing), you can use Evil-WinRM to get a more stable shell.
Lateral Movement: With compromised credentials, you can move from one Windows host to another using WinRM.
Pass-the-Hash: Evil-WinRM's -H option allows you to authenticate using only the NTLM hash, bypassing the need for the plaintext password.
File Transfer: Upload tools like Mimikatz or download exfiltrated data.
Persistence: Create scheduled tasks or services via the shell.
Limitations and Considerations
WinRM Must Be Enabled: If the target has WinRM disabled or blocked by firewall, Evil-WinRM will not work.
Logging: WinRM events are logged in the Windows Event Log (Microsoft-Windows-WinRM/Operational). Defenders may detect anomalous usage.
Antivirus: While Evil-WinRM itself is not malicious, the commands you run (e.g., Mimikatz) may trigger AV. Use obfuscation or AMSI bypasses.
User Privileges: The shell runs with the privileges of the authenticated user. For administrative tasks, you need an admin account.
Network Segmentation: WinRM may be restricted to certain subnets or require Kerberos authentication in domain environments.
Step-by-Step: Using Evil-WinRM to Gain a Shell
Install Evil-WinRM (if not already installed): gem install evil-winrm
Identify Target: Ensure WinRM is open on port 5985 or 5986. Use Nmap: nmap -p 5985,5986 <target>
Authenticate: Run evil-winrm -i <target> -u <username> -p <password> (or use -H for hash)
Explore: Use commands like whoami, ipconfig, systeminfo to gather information.
Upload Tools: upload /path/to/tool.exe
Execute Commands: Run tools or PowerShell scripts.
Download Results: download /path/on/target/file.txt
Exit: Type exit to close the session.
Example Command Line
evil-winrm -i 192.168.1.100 -u Administrator -p 'P@ssw0rd' -SThis connects to 192.168.1.100 using SSL, authenticating as Administrator with the given password.
Enable WinRM on Target
Before Evil-WinRM can connect, the target Windows system must have WinRM enabled and configured. By default, WinRM is disabled on client editions (Windows 10/11) but enabled on server editions. Use `Enable-PSRemoting -Force` in an elevated PowerShell to enable WinRM. This command starts the WinRM service, sets it to auto-start, creates an HTTP listener on port 5985, and adds firewall rules. For HTTPS, you must configure a certificate and use `winrm create winrm/config/Listener?Address=*+Transport=HTTPS`. Verify with `Test-WSMan <target>`.
Install Evil-WinRM
Evil-WinRM is distributed as a Ruby gem. Install it using `gem install evil-winrm` on a Linux system with Ruby (commonly Kali Linux). Alternatively, it is pre-installed on Kali. Ensure you have the required dependencies: `ruby-dev`, `build-essential`. After installation, verify with `evil-winrm --version`. The tool can also be run from source by cloning the GitHub repository.
Gather Credentials
You need valid credentials for the target. These can be obtained through phishing, password spraying, or pass-the-hash from a previous compromise. For domain accounts, you need the username in UPN format (e.g., `user@domain.com`) or DOMAIN\user. For local accounts, use the local username. If you have an NTLM hash (e.g., from Mimikatz), you can use `-H` to pass the hash without knowing the plaintext password.
Connect to Target
Execute `evil-winrm -i <target IP> -u <username> -p <password>`. If using SSL, add `-S`. If using a hash, replace `-p` with `-H <hash>`. The tool will attempt to authenticate and open a shell. If successful, you'll see a prompt like `Evil-WinRM shell>`. If authentication fails, check credentials and that WinRM is listening. Use verbose mode (`-V`) for debugging.
Execute Commands and Transfer Files
Once the shell is open, you can run any command as the authenticated user. Use `upload` and `download` to transfer files. Commands are executed via WinRM's `Command` operation, which sends the command as a string. Output is retrieved asynchronously. For interactive commands like `cmd.exe /c`, the session behaves like a terminal. Use `Bypass-4MSI` to bypass AMSI if needed.
In a typical enterprise penetration test, Evil-WinRM is used extensively during the post-exploitation phase. One common scenario is after gaining initial access via a phishing email that drops a Beacon or a web shell. The tester then uses Mimikatz to extract credentials from memory. With those credentials, they use Evil-WinRM to connect to other Windows servers in the environment, such as domain controllers or file servers, to escalate privileges or exfiltrate data.
Another scenario is in a red team engagement where the goal is to simulate an advanced persistent threat. The team might use Evil-WinRM to maintain persistence by creating scheduled tasks that call back to the WinRM shell. Because WinRM traffic is encrypted and uses standard ports, it often evades detection by network monitoring tools that look for anomalous outbound connections. However, defenders can detect Evil-WinRM by monitoring event ID 4104 (PowerShell script block logging) if the tester uses PowerShell, or by correlating WinRM logins from unusual IPs.
A common misconfiguration that leads to success is when WinRM is left enabled but with weak authentication settings, such as allowing Basic authentication over HTTP. In such cases, an attacker can brute-force credentials using tools like crackmapexec and then use Evil-WinRM to gain access. Production environments often have WinRM enabled for administrative convenience but forget to restrict access via firewall rules or to enforce HTTPS and Kerberos authentication. Performance-wise, Evil-WinRM is lightweight; the main bottleneck is the WinRM service's MaxEnvelopeSize, which defaults to 150KB. For file transfers larger than that, the tester must either increase the limit on the target or split the file. In high-latency networks, commands may time out, so adjusting the timeout with -t is advisable.
The PT0-002 exam tests Evil-WinRM under Objective 5.1 (Given a scenario, use tools to conduct a penetration test). Specifically, you need to know:
- Tool Name: Evil-WinRM (sometimes written as evil-winrm).
- Purpose: Gain an interactive shell over WinRM.
- Ports: Default ports 5985 (HTTP) and 5986 (HTTPS).
- Authentication: Supports passwords, NTLM hashes, Kerberos, and certificates.
- Common Switches: -i (IP), -u (user), -p (password), -H (hash), -S (SSL), -b (bypass execution policy).
- File Transfer: upload and download commands.
Common wrong answers on exam questions include:
1. Confusing Evil-WinRM with PsExec: Both provide remote execution, but PsExec uses SMB and creates a service, while Evil-WinRM uses WinRM. The exam may present a scenario where WinRM is the only open port; Evil-WinRM is the correct tool.
2. Thinking Evil-WinRM only works with PowerShell: While it can spawn PowerShell, it can also spawn cmd.exe. The default is PowerShell, but you can specify -c for cmd.
3. Assuming it requires administrative privileges: Evil-WinRM runs with the privileges of the authenticated user. If the user is a standard user, the shell is limited.
4. Believing it only works over HTTPS: It works over both HTTP and HTTPS, though HTTPS is more secure and less likely to trigger alarms.
Edge cases the exam loves:
- Pass-the-Hash: The -H option allows authentication with just the NTLM hash, which is a key differentiator from tools that require plaintext.
- Bypass Execution Policy: The -b flag bypasses PowerShell's execution policy, which is important when the target has restricted PowerShell.
- SSL vs. Non-SSL: If the question mentions WinRM on port 5986, you must use -S. If port 5985, no -S.
To eliminate wrong answers, focus on the protocol: if the target has WinRM open, Evil-WinRM is the tool. If the question mentions SMB or port 445, PsExec or WMI might be more appropriate. Also note that Evil-WinRM is a Ruby gem, so it runs on Linux, not natively on Windows (though you can use it on Windows via Ruby).
Evil-WinRM is a Ruby-based tool for interactive shells over WinRM on ports 5985 (HTTP) and 5986 (HTTPS).
Supports authentication with password (`-p`), NTLM hash (`-H`), Kerberos (`-k`), and certificates (`-c`).
Use `-S` for SSL; default is HTTP. Always prefer HTTPS in real engagements.
File transfer via `upload` and `download` commands; files are base64-encoded in SOAP messages.
Default command timeout is 60 seconds; adjust with `-t`.
The tool is commonly used in post-exploitation for lateral movement and privilege escalation.
WinRM must be enabled on the target (`Enable-PSRemoting -Force`).
Evil-WinRM can bypass PowerShell execution policy with `-b` flag.
Event ID 4104 (PowerShell script block logging) may log commands if PowerShell is used.
The `-V` flag enables verbose output for debugging authentication issues.
These come up on the exam all the time. Here's how to tell them apart.
Evil-WinRM
Uses WinRM protocol (ports 5985/5986)
Provides interactive shell via WinRM
Supports pass-the-hash (NTLM hash)
Encrypted by default (HTTPS)
Lightweight, no service creation
PsExec
Uses SMB protocol (port 445)
Creates a Windows service to execute commands
Requires admin privileges to create service
Traffic may be unencrypted (SMB signing optional)
Can be detected by service creation logs
Mistake
Evil-WinRM requires the target to have PowerShell enabled.
Correct
Evil-WinRM can spawn either cmd.exe or PowerShell. By default, it uses cmd.exe if available, but you can specify PowerShell with the `-P` flag. The tool does not require PowerShell; it only requires WinRM to be running.
Mistake
Evil-WinRM works only over HTTPS (port 5986).
Correct
Evil-WinRM supports both HTTP (port 5985) and HTTPS (port 5986). Use the `-S` flag for SSL. The default is HTTP.
Mistake
You must have administrative privileges to use Evil-WinRM.
Correct
Evil-WinRM runs with the privileges of the authenticated user. If the user is a standard user, you will have a limited shell. However, many post-exploitation tasks require admin rights.
Mistake
Evil-WinRM is a Metasploit module.
Correct
Evil-WinRM is a standalone Ruby tool. There is a Metasploit module for WinRM exploitation (auxiliary/scanner/winrm/winrm_login), but the standalone tool is more feature-rich for interactive shells.
Mistake
Evil-WinRM can only be used on domain-joined machines.
Correct
Evil-WinRM works on both domain-joined and workgroup machines. For workgroup machines, use local credentials. For domain machines, use domain credentials or pass-the-hash.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Evil-WinRM is a penetration testing tool that uses the WinRM protocol to provide an interactive shell. WinRM is the legitimate Windows Remote Management service. Evil-WinRM automates the authentication and session management to give the tester a command prompt. Unlike standard WinRM clients (like `winrs`), Evil-WinRM offers features like pass-the-hash, file upload/download, and bypass of execution policies.
Evil-WinRM uses port 5985 for HTTP and port 5986 for HTTPS. These are the default WinRM ports. When using the `-S` flag, it connects to port 5986. Without `-S`, it uses port 5985. You can specify a custom port with `-p` (but that is not typical).
Yes. Use the `-H` option followed by the NTLM hash (in hex format, e.g., `-H aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0`). This allows authentication without the plaintext password. The hash can be obtained from tools like Mimikatz.
Evil-WinRM is pre-installed on Kali. If not, install it via `sudo gem install evil-winrm`. Ensure Ruby is installed (`sudo apt install ruby`). For the latest version, you can clone the GitHub repository and run `ruby evil-winrm.rb`.
CrackMapExec (CME) has a `winrm` module that can execute commands but does not provide an interactive shell. Evil-WinRM provides a full interactive shell with history, tab completion, and file transfer. CME is better for bulk command execution across many hosts; Evil-WinRM is for interactive exploration.
Evil-WinRM is primarily designed for Linux. However, it can run on Windows if Ruby is installed. Most pentesters use it on Kali Linux. There is also a PowerShell version called `evil-winrm.ps1` but it is less common.
Defenders can monitor WinRM event logs (Microsoft-Windows-WinRM/Operational) for unusual authentication events. PowerShell script block logging (Event ID 4104) may capture commands if PowerShell is used. Network monitoring can detect WinRM traffic on ports 5985/5986 from unusual IPs.
You've just covered Evil-WinRM and Remote Management — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?