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: System
Computer: DC01.snapattack.labs
EventCode: 7040
EventID: 7040
EventSourceName: "Service Control Manager"
Guid: "{555908d1-a6d7-4695-8e1e-26931d2012f4}"
Keywords: 0x8080000000000000
Level: 4
Name: "Service Control Manager"
Opcode: 0
ProcessID: "628"
Qualifiers: "16384"
RecordNumber: 13445
ServiceName: Windows Remote Management (WS-Management)
SystemTime: '2024-12-06T16:01:15.986600Z'
Task: 0
ThreadID: "6124"
UserID: "S-1-5-21-1720375312-3826971191-370251595-1105"
Version: 0
param1: Windows Remote Management (WS-Management)
param2: disabled
param3: auto start
param4: WinRM
product: Windows
service: 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: 7036
EventRecordID: 13446
EventSourceName: "Service Control Manager"
Keywords: 0x8080000000000000
Level: 4
Name: "Service Control Manager"
Opcode: 0
ProcessID: "628"
ProcessId: 628
Qualifiers: "16384"
RecordNumber: 13446
ServiceName: Windows Remote Management (WS-Management)
SigmaEventCode: 7036
SystemTime: '2024-12-06T16:01:16.017845Z'
Task: 0
ThreadID: "6124"
Version: 0
param1: Windows Remote Management (WS-Management)
param2: running
product: Windows
service: Windows Remote Management (WS-Management)
service_name: Windows Remote Management (WS-Management)
status: started
vendor: Microsoft
vendor_product: Microsoft Windows
..
You will also see a svchost process creation event for the WinRM service with Event ID 4688.
...
EventID: 4688
CommandLine: C:\Windows\System32\svchost.exe -k NetworkService -p -s WinRM
ParentProcessName: C:\Windows\System32\services.exe
process_name: svchost.exe
process_path: C:\Windows\System32\svchost.exe
parent_process_path: C:\Windows\System32\services.exe
action: 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-WinRM
Provider Guid: A7975C8F-AC13-49F1-87DA-5A984A4AB417
EventID: 224
Version: 0
Level: 4
Task: 12
Opcode: 0
Keywords: 0x4000000000000004
TimeCreated SystemTime: 2024-12-06T16:01:16.581686Z
EventRecordID: 2483
Correlation ActivityID: F7FB9534-3AAA-0003-6FBF-FBF7AA3ADB01
Execution ProcessID: 9388
Execution ThreadID: 7796
Channel: Microsoft-Windows-WinRM/Operational
Computer: DC01.snapattack.labs
Security UserID: S-1-5-21-1720375312-3826971191-370251595-1105
message: Created a WinRM listener on HTTP://* 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-WinRM
Provider Guid: A7975C8F-AC13-49F1-87DA-5A984A4AB417
EventID: 224
Version: 0
Level: 4
Task: 12
Opcode: 0
Keywords: 0x4000000000000004
TimeCreated SystemTime: 2024-12-06T16:01:16.662767Z
EventRecordID: 2484
Correlation ActivityID: F7FB9534-3AAA-0003-6FBF-FBF7AA3ADB01
Execution ProcessID: 9388
Execution ThreadID: 7796
Channel: Microsoft-Windows-WinRM/Operational
Computer: DC01.snapattack.labs
Security UserID: S-1-5-21-1720375312-3826971191-370251595-1105
message: 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.exe
Company: Microsoft Corporation
CurrentDirectory: C:\Users\domainadmin\Documents\
Description: whoami - displays logged on user information
EventID: 1
Image: C:\Windows\System32\whoami.exe
IntegrityLevel: High
ParentCommandLine: C:\Windows\system32\wsmprovhost.exe -Embedding
ParentImage: C:\Windows\System32\wsmprovhost.exe
ParentProcessName: wsmprovhost.exe
ParentProcessPath: C:\Windows\System32\
ParentUser: snapattack\domainadmin
ProcessName: whoami.exe
ProcessPath: 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/Operational
CommandLine: C:\Windows\system32\wsmprovhost.exe -Embedding
Company: Microsoft Corporation
CurrentDirectory: C:\Windows\system32\
Description: Host process for WinRM plug-ins
EventDescription: Process creation
EventID: 1
EventRecordID: 13482
Image: C:\Windows\System32\wsmprovhost.exe
IntegrityLevel: High
Keywords: 0x8000000000000000
Level: 4
OriginalFileName: wsmprovhost.exe
ParentCommandLine: C:\Windows\system32\svchost.exe -k DcomLaunch -p
ParentImage: C:\Windows\System32\svchost.exe
ParentProcessGuid: A5CDDB11-CEFD-673C-0D00-000000000900
ParentProcessId: 860
ParentProcessName: svchost.exe
ParentProcessPath: C:\Windows\System32\
ParentUser: NT AUTHORITY\SYSTEM
ProcessGuid: A5CDDB11-201F-6753-D305-000000000900
ProcessID: "2176"
ProcessId: 9788
ProcessName: wsmprovhost.exe
ProcessPath: 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: System
Channel: Security
DestAddress: 10.3.10.6
DestPort: 5985
Direction: %%14592
Error_Code: -
EventID: 5156
EventRecordID: 4281794
FilterOrigin: Unknown
FilterRTID: 0
InterfaceIndex: 6
Keywords: 0x8020000000000000
LayerName: %%14610
LayerRTID: 44
SourceAddress: 10.3.10.8
SourcePort: 50863
action: success
dest: DC01.snapattack.labs
dest_port: 5985
event_id: 4281794
id: 4281794
name: The Windows Filtering Platform has allowed a connection
product: 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.6
dest_host: dc01
dest_ip: 10.3.10.6
dest_port: 5985
extracted_host: dc01
flow_id: CHciAg4GPDJ4PrzOng
http_method: POST
http_user_agent: Microsoft WinRM Client
http_user_agent_length: 22
id_orig_h: 10.3.10.8
id_orig_p: 50858
id_resp_h: 10.3.10.6
id_resp_p: 5985
is_broadcast: false
is_dest_internal_ip: true
is_src_internal_ip: true
method: POST
product: OS_Zeek
src: 10.3.10.8
src_ip: 10.3.10.8
src_port: 50858
status: 200
status_code: 200
uri: /wsman?PSVersion=5.1.19041.1237
uri_path: /wsman?PSVersion=5.1.19041.1237
uri_query: PSVersion=5.1.19041.1237
url: 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.
The post Detection Engineer’s Guide to Powershell Remoting appeared first on Security Boulevard.
Raven Tait
Source: Security Boulevard
Source Link: https://securityboulevard.com/2024/12/detection-engineers-guide-to-powershell-remoting/