Powershell Remoting is a powerful feature in Windows that enables IT administrators to remotely execute commands, manage configurations, and automate tasks across multiple systems in a network. Utilizing Windows Remote Management (WinRM), it facilitates efficient management by allowing centralized control over endpoints, making it an essential tool for system administrators to streamline operations and maintain system compliance. With robust integration into Powershell scripting, it supports complex automation workflows and helps enhance the overall productivity and reliability of IT infrastructures. However, Powershell Remoting can be exploited by attackers to move laterally within a network, execute malicious scripts, and establish persistent access. By leveraging its legitimate functionalities, attackers can execute arbitrary commands, extract sensitive data, and disable security mechanisms while blending into standard administrative operations to evade detection. This dual-use nature makes it a potent vector for cyberattacks if improperly secured. Powershell and Windows Event Logs provide significant insight into detecting suspicious activity associated with remoting. However, if these logs are not actively monitored or ingested into a SIEM solution, attackers may go unnoticed. In this blog, we’ll explore how to detect and respond to potential abuse of Powershell Remoting using Sysmon and native Windows logging tools to safeguard your environment.
Enabling PS Remoting
Powershell Remoting is disabled by default on most Windows machines. This does limit the attack surface somewhat but not entirely. To enable remoting, an attacker must open Powershell and execute the command Enable-PSRemoting -Force. This will turn on the Powershell Remoting feature and ensure the WinRM is configured correctly. That initial access vector can vary from actor to actor but a common method is using WMIC to remotely execute the Powershell command using their current credentials. This is specially dangerous if they have access to an account with higher permissions.
This WMIC activity alone offers a host of detection opportunities, but since that isn’t the focus of this blog, we will instead take a look at the Powershell command itself. If you’d like to see more details of the WMIC command take a look at our captured threat session of this activity. This activity looks like the following in the process graph:
The first thing we will look at is Windows Event 7040 which is logged by the Service Control Manager and indicates that the start type of a service has been changed.
...Channel: SystemComputer: DC01.snapattack.labsEventCode: 7040EventID: 7040EventSourceName: "Service Control Manager"Guid: "{555908d1-a6d7-4695-8e1e-26931d2012f4}"Keywords: 0x8080000000000000Level: 4Name: "Service Control Manager"Opcode: 0ProcessID: "628"Qualifiers: "16384"RecordNumber: 13445ServiceName: Windows Remote Management (WS-Management)SystemTime: '2024-12-06T16:01:15.986600Z'Task: 0ThreadID: "6124"UserID: "S-1-5-21-1720375312-3826971191-370251595-1105"Version: 0param1: Windows Remote Management (WS-Management)param2: disabledparam3: auto startparam4: WinRMproduct: Windowsservice: Windows Remote Management (WS-Management)service_name: Windows Remote Management (WS-Management)start_mode: auto...
Here we can see the Windows Remote Management (WS-Management) service has its start_mode set to auto start. This allows it to start on boot and offers persistent access to the WinRM service. The next thing the Enable-PSRemoting command does is actually turn on the WinRM Service.
...EventID: 7036EventRecordID: 13446EventSourceName: "Service Control Manager"Keywords: 0x8080000000000000Level: 4Name: "Service Control Manager"Opcode: 0ProcessID: "628"ProcessId: 628Qualifiers: "16384"RecordNumber: 13446ServiceName: Windows Remote Management (WS-Management)SigmaEventCode: 7036SystemTime: '2024-12-06T16:01:16.017845Z'Task: 0ThreadID: "6124"Version: 0param1: Windows Remote Management (WS-Management)param2: runningproduct: Windowsservice: Windows Remote Management (WS-Management)service_name: Windows Remote Management (WS-Management)status: startedvendor: Microsoftvendor_product: Microsoft Windows..
You will also see a svchost process creation event for the WinRM service with Event ID 4688.
...EventID: 4688CommandLine: C:\Windows\System32\svchost.exe -k NetworkService -p -s WinRMParentProcessName: C:\Windows\System32\services.exeprocess_name: svchost.exeprocess_path: C:\Windows\System32\svchost.exeparent_process_path: C:\Windows\System32\services.exeaction: allowed...
Enabling Powershell remoting modifies some objects to allow the WinRM traffic to flow correctly. First it will update some firewall rules and then it will create a HTTP listener. Both of these actions are logged thankfully. For the http listener it is contained outside of the normal Windows Security logs and is instead in Microsoft-Windows-WinRM/Operational under Event ID 224. These logs also contain other informational logs about WinRM including the service type changing and service starting. Here is the http listener being created in Event ID 224.
Provider Name: Microsoft-Windows-WinRMProvider Guid: A7975C8F-AC13-49F1-87DA-5A984A4AB417EventID: 224Version: 0Level: 4Task: 12Opcode: 0Keywords: 0x4000000000000004TimeCreated SystemTime: 2024-12-06T16:01:16.581686ZEventRecordID: 2483Correlation ActivityID: F7FB9534-3AAA-0003-6FBF-FBF7AA3ADB01Execution ProcessID: 9388Execution ThreadID: 7796Channel: Microsoft-Windows-WinRM/OperationalComputer: DC01.snapattack.labsSecurity UserID: S-1-5-21-1720375312-3826971191-370251595-1105message: Created a WinRM listener on * to accept WS-Man requests to any IP on this machine.
The related firewall rule being enabled in Event 224 looks like the following.
Provider Name: Microsoft-Windows-WinRMProvider Guid: A7975C8F-AC13-49F1-87DA-5A984A4AB417EventID: 224Version: 0Level: 4Task: 12Opcode: 0Keywords: 0x4000000000000004TimeCreated SystemTime: 2024-12-06T16:01:16.662767ZEventRecordID: 2484Correlation ActivityID: F7FB9534-3AAA-0003-6FBF-FBF7AA3ADB01Execution ProcessID: 9388Execution ThreadID: 7796Channel: Microsoft-Windows-WinRM/OperationalComputer: DC01.snapattack.labsSecurity UserID: S-1-5-21-1720375312-3826971191-370251595-1105message: WinRM firewall exception enabled.
The firewall exception can also be found in a few other logs. Specifically Windows Event 4947 and Microsoft-Windows-Windows Firewall With Advanced Security/Firewall Event 2005. Detections on any of these that you are collecting will help identify Enable-PSRemoting.
Trusted Hosts
Enable-PSRemoting is all that is needed if an attacker is pivoting using domain-joined computers to perform Powershell Remoting. However, if they execute remote Powershell commands from a computer not connected to the same domain as the target machine, the machine is considered an “untrusted host.” To ensure Powershell Remoting works from any machine, they must either add that single machine to the Trusted Hosts list for the machine they’re Powershell Remoting into or set all hosts as trusted hosts using a wildcard. They will either add a single machine via Set-Item wsman:\localhost\Client\TrustedHosts -Value “<_YourComputerName_>” or add all hosts with the command Set-Item wsman: localhostClientTrustedHosts -Value *.
Invoke-Command
There are two major ways to interact with Powershell Remoting: Invoke-Command and Enter-PSSession. First we are going to look as is Invoke-Command. This will execute the script-block or Powershell script on the target host.
This spawns a new process under the wsmprovhost.exe parent. This is Windows Remote Management Provider Host. It is a key component of the Windows Remote Management (WinRM) service.
Looking at the Sysmon (EventCode 1) or Windows process creation logs (Event ID 4688) we can see more details.
CommandLine: C:\Windows\system32\whoami.exeCompany: Microsoft CorporationCurrentDirectory: C:\Users\domainadmin\Documents\Description: whoami - displays logged on user informationEventID: 1Image: C:\Windows\System32\whoami.exeIntegrityLevel: HighParentCommandLine: C:\Windows\system32\wsmprovhost.exe -EmbeddingParentImage: C:\Windows\System32\wsmprovhost.exeParentProcessName: wsmprovhost.exeParentProcessPath: C:\Windows\System32\ParentUser: snapattack\domainadminProcessName: whoami.exeProcessPath: C:\Windows\System32\Product: Microsoft® Windows® Operating System...
This is a high integrity process so it has elevated permissions and is executing the whoami from the script-block specified in the attack. Monitoring for child processes of wsmprovhost.exe, especially other windows utilities, can help isolate this activity. For more logs and details, we have captured this activity in our platform: Lateral Movement with Powershell Remoting
Enter-PSSession
This alternative technique gives the attacker a full powershell terminal session on the target host using WinRM.
This will generate another interesting log based around wsmprovhost.exe.
Channel: Microsoft-Windows-Sysmon/OperationalCommandLine: C:\Windows\system32\wsmprovhost.exe -EmbeddingCompany: Microsoft CorporationCurrentDirectory: C:\Windows\system32\Description: Host process for WinRM plug-insEventDescription: Process creationEventID: 1EventRecordID: 13482Image: C:\Windows\System32\wsmprovhost.exeIntegrityLevel: HighKeywords: 0x8000000000000000Level: 4OriginalFileName: wsmprovhost.exeParentCommandLine: C:\Windows\system32\svchost.exe -k DcomLaunch -pParentImage: C:\Windows\System32\svchost.exeParentProcessGuid: A5CDDB11-CEFD-673C-0D00-000000000900ParentProcessId: 860ParentProcessName: svchost.exeParentProcessPath: C:\Windows\System32\ParentUser: NT AUTHORITY\SYSTEMProcessGuid: A5CDDB11-201F-6753-D305-000000000900ProcessID: "2176"ProcessId: 9788ProcessName: wsmprovhost.exeProcessPath: C:\Windows\System32\Product: Microsoft® Windows® Operating System...
The important considerations with this log is the combination of CommandLine and ParentCommandLine. This activity occurs whenever someone connects via Enter-Session. The process graph for this activity looks fairly similar to the Invoke-Command. Both have the activity spawn under the wsmprovhost.exe process.
For more logs and details, we have captured this activity in our platform: Lateral Movement with Powershell Remoting
Network Detections
Windows Event 5156 also captures the network connection being allowed by Windows Filtering Platform to the WinRM ports 5985 and 5986. You can use this to identify Powershell Remoting connections.
Application: SystemChannel: SecurityDestAddress: 10.3.10.6DestPort: 5985Direction: %%14592Error_Code: -EventID: 5156EventRecordID: 4281794FilterOrigin: UnknownFilterRTID: 0InterfaceIndex: 6Keywords: 0x8020000000000000LayerName: %%14610LayerRTID: 44SourceAddress: 10.3.10.8SourcePort: 50863action: successdest: DC01.snapattack.labsdest_port: 5985event_id: 4281794id: 4281794name: The Windows Filtering Platform has allowed a connectionproduct: Windows...
If you have a network intrustion detection tool like Zeek available you can see interesting HTTP requests associated with this activity as well.
dest: 10.3.10.6dest_host: dc01dest_ip: 10.3.10.6dest_port: 5985extracted_host: dc01flow_id: CHciAg4GPDJ4PrzOnghttp_method: POSThttp_user_agent: Microsoft WinRM Clienthttp_user_agent_length: 22id_orig_h: 10.3.10.8id_orig_p: 50858id_resp_h: 10.3.10.6id_resp_p: 5985is_broadcast: falseis_dest_internal_ip: trueis_src_internal_ip: truemethod: POSTproduct: OS_Zeeksrc: 10.3.10.8src_ip: 10.3.10.8src_port: 50858status: 200status_code: 200uri: /wsman?PSVersion=5.1.19041.1237uri_path: /wsman?PSVersion=5.1.19041.1237uri_query: PSVersion=5.1.19041.1237url: dc01:5985/wsman?PSVersion=5.1.19041.1237...
The key things to notice here are the Microsoft WinRM Client user agent which indicates this is a WinRM connection and the /wsman?PSVersion=5.1.19041.1237 WinRM uri with PowerShell version specified. These will also be http requests on the WinRM port of 5985 which is unusual itself. For more logs and details, we have captured this activity in our platform: Lateral Movement with Powershell Remoting
MITRE
T1078.001: Valid Accounts”Š”, “ŠDomain Accounts
Adversaries may obtain and abuse credentials of a default account as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. T1059.001: Command and Scripting Interpreter”Š”, “ŠPowerShell
Adversaries may abuse PowerShell commands and scripts for execution. T1543.003: Create or Modify System Process”Š”, “ŠWindows Service
Adversaries may create or modify Windows services to repeatedly execute malicious payloads as part of persistence. T1021.006: Remote Services”Š”, “ŠWindows Remote Management
Adversaries may use Valid Accounts to interact with remote systems using Windows Remote Management (WinRM). T1571: Non-Standard Port
Adversaries may communicate using a protocol and port pairing that are typically not associated.
Log Summary
To detect on the information in this blog you will need to be logging the following:
– Windows Event ID 7040 to detect the WinRM service being set to start automatically.
– Windows Event ID 7036 to detect the WINRM service being started.
– Windows Event ID 4688 to detect the creation of svchost.exe processes for WinRM.
– Windows Event ID 224 to detect the creation of HTTP listeners and firewall rules for WinRM.
– Windows Event ID 5156 to detect allowed connections to ports 5985 and 5986 for WinRM.
– Zeek http logs to identify the HTTP POST traffic with Microsoft WinRM Client as the user agent.
– Sysmon Event ID 1 to detect high-integrity processes spawned from wsmprovhost.exe.
Conclusion
PowerShell Remoting is a powerful tool for system administrators, but its misuse can pose significant risks to enterprise security. The ability to enable and utilize WinRM for remote command execution provides attackers with a stealthy method to move laterally, establish persistence, and execute malicious actions under the guise of legitimate processes. However, defenders can detect and mitigate these threats by closely monitoring critical events, such as process creations, service changes, and network connections. By understanding and identifying the behaviors described in this blog, organizations can better safeguard their environments against potential abuse of PowerShell Remoting. SnapAttack is the threat hunting, detection engineering, and detection validation platform for proactive threat-informed defense. Register for a FREE community account to access the tons of content included in this blog post, as well as thousands of other detections. Subscribers also get advanced features like a no-code detection builder, one-click deployments to leading SIEMs and EDRs like Chronicle, Sentinel, Splunk, CrowdStrike and SentinelOne, advanced threat profiles to prioritize relevant threats, and customized reports that track MITRE ATT&CK coverage and more!
Resources
PowerShell remoting – PowerShell PowerShell Remoting for Hackers: Domain Takeover in 2025 Month of PowerShell – PowerShell Remoting, Part 1 5985,5986 – Pentesting WinRM – HackTricks
Detection Engineer’s Guide to Powershell Remoting was originally published in SnapAttack on Medium, where people are continuing the conversation by highlighting and responding to this story.
First seen on securityboulevard.com
Jump to article: securityboulevard.com/2024/12/detection-engineers-guide-to-powershell-remoting/
