HOME Resources Blog Living off WinRM: Abusing Complexity in Remote Management

|

Living off WinRM: Abusing Complexity in Remote Management

Key Context: What Is LOLBAS Anyway?

LOLBAS (Living Off The Land Binaries, Scripts, and Libraries) are legitimate Windows tools and binaries that attackers abuse to perform malicious actions without using custom malware. One of the criteria for a binary to be in the list is for it to have extra “unexpected” or undocumented functionality. These are often used to run malicious payloads on compromised systems, or simply discovered by researchers.

While it’s not officially included in the LOLBAS catalog (yet!), Windows Remote Management (WinRM) is a prime example of how built-in Windows functionality, trusted by administrators, can be quietly repurposed and abused by adversaries. Let’s take a deeper look.

Win R What?

Windows Remote Management (WinRM) is a Microsoft protocol that allows remote command execution and management of Windows machines. It enables administrators to run scripts, manage system settings, and access data remotely via tools like PowerShell. WinRM is commonly used for automation, remote administration, and integration with management platforms.

Its usage has also been observed across a range of adversary TTPs, particularly for defense evasion tactics. WinRM was previously used by multiple threat actors such as Chimera and FIN 13. It was also implemented into different tools such as Evil-WinRM and Cobalt Strike.

Winrs.exe is a binary used to execute commands on remote hosts using WinRM. According to the official documentation, you need to use the ‘/remote’ flag and the name of the remote host.

When winrs.exe executes the command, it’s not actually executed with winrs.exe as its parent process. Instead, it calls for winrshost.exe to execute the requested command. This gives us two different detections.

Given its stealthy execution flow and integration in attacker toolkits, understanding how winrs.exe works is critical for detecting its role in defense evasion tactics, especially in scenarios that deviate from documented usage.

Why Not Local?

Although not explicitly mentioned in the documentation, there is a way to run commands locally using winrs.exe. You simply need to use winrs.exe with the command you want to run, without the ‘/remote’ flag.

As surprising as it may seem, that’s all it takes for a red team or even an attacker to run a command or execute as the child process of a binary signed by Microsoft. This is a classic case of System Binary Proxy Execution (T1218), which is commonly used to evade defenses.

So How Do We Detect This?

Monitoring commands executed via WinRM – this might prove difficult and require exclusions if the organization uses WinRM legitimately. First, we can monitor for any usage of WinRM by searching for any process created by winrshost.exe. This will alert on any use of WinRM, including legitimate use, meaning it might need some tuning to account for legitimate administrative usage within the organization.

SecurityEvent
| where EventID == 4688
| where ParentProcessName =~ "C:\\Windows\\System32\\winrshost.exe"
| project-reorder Computer, Account, CommandLine, ParentProcessName

Additionally, we can monitor any attempt to execute any commands locally via winrs.exe:

SecurityEvent
| where EventID == 4688
| where NewProcessName == "C:\\Windows\\System32\\winrs.exe" and not (CommandLine has_any ("/remote","/r:","-remote","-r:"))
| project-reorder Computer, Account, CommandLine, ParentProcessName, TimeGenerated

It’s important to mention that there will be overlap, so any command given to winrs.exe is then executed by winrshost.exe. The main difference between the detections is the reliability – monitoring for WinRM commands using winrshost.exe will create false positives if WinRM is used in the environment however local command execution using winrs.exe will most likely be a true positive.

Conclusion

WinRM is a tool used by multiple threat actors and open source tools, so understanding how it works helps teams better interpret alerts and respond to incidents. Sadly, there are too many undocumented things within Windows, which is why projects like LOLBAS are important to security teams all around.

About the Author

Liran Ravich is a Security Architect at CardinalOps, specializing in detection engineering and security operations. Prior to this role, he worked at the Israeli National Cyber Directorate (INCD), where he worked within the national CERT and held various cybersecurity roles across government agencies. He is also an active contributor to the MITRE ATT&CK framework since version 12.