Incoming Execution via WinRM Remote Shell
Identifies remote execution via Windows Remote Management (WinRM) remote shell on a target host. This could be an indication of lateral movement.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/11/24"
3integration = ["endpoint", "windows"]
4maturity = "production"
5updated_date = "2025/01/15"
6min_stack_version = "8.14.0"
7min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
8
9[rule]
10author = ["Elastic"]
11description = """
12Identifies remote execution via Windows Remote Management (WinRM) remote shell on a target host. This could be an
13indication of lateral movement.
14"""
15false_positives = [
16 """
17 WinRM is a dual-use protocol that can be used for benign or malicious activity. It's important to baseline your
18 environment to determine the amount of noise to expect from this tool.
19 """,
20]
21from = "now-9m"
22index = [
23 "winlogbeat-*",
24 "logs-endpoint.events.process-*",
25 "logs-endpoint.events.network-*",
26 "logs-windows.sysmon_operational-*",
27]
28language = "eql"
29license = "Elastic License v2"
30name = "Incoming Execution via WinRM Remote Shell"
31risk_score = 47
32rule_id = "1cd01db9-be24-4bef-8e7c-e923f0ff78ab"
33severity = "medium"
34tags = [
35 "Domain: Endpoint",
36 "OS: Windows",
37 "Use Case: Threat Detection",
38 "Tactic: Lateral Movement",
39 "Data Source: Elastic Defend",
40 "Data Source: Sysmon",
41 "Resources: Investigation Guide",
42]
43type = "eql"
44
45query = '''
46sequence by host.id with maxspan=30s
47 [network where host.os.type == "windows" and process.pid == 4 and network.direction : ("incoming", "ingress") and
48 destination.port in (5985, 5986) and network.protocol == "http" and source.ip != "127.0.0.1" and source.ip != "::1"]
49 [process where host.os.type == "windows" and
50 event.type == "start" and process.parent.name : "winrshost.exe" and not process.executable : "?:\\Windows\\System32\\conhost.exe"]
51'''
52note = """## Triage and analysis
53
54> **Disclaimer**:
55> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
56
57### Investigating Incoming Execution via WinRM Remote Shell
58
59Windows Remote Management (WinRM) is a protocol that allows for remote management and execution of commands on Windows machines. While beneficial for legitimate administrative tasks, adversaries can exploit WinRM for lateral movement by executing commands remotely. The detection rule identifies suspicious activity by monitoring network traffic on specific ports and processes initiated by WinRM, flagging potential unauthorized remote executions.
60
61### Possible investigation steps
62
63- Review the network traffic logs to confirm the presence of incoming connections on ports 5985 or 5986, which are used by WinRM, and verify if these connections are expected or authorized.
64- Identify the source IP address of the incoming connection and determine if it belongs to a known and trusted network or device. Investigate any unfamiliar or suspicious IP addresses.
65- Examine the process tree for the process initiated by winrshost.exe to identify any unusual or unauthorized processes that were started as a result of the remote execution.
66- Check the user account associated with the WinRM session to ensure it is legitimate and has not been compromised. Look for any signs of unauthorized access or privilege escalation.
67- Correlate the event with other security logs, such as authentication logs, to identify any related suspicious activities or patterns that might indicate lateral movement or a broader attack campaign.
68- Investigate the timeline of events to determine if there are any other related alerts or activities occurring around the same time that could provide additional context or evidence of malicious intent.
69
70### False positive analysis
71
72- Legitimate administrative tasks using WinRM can trigger alerts. Regularly review and whitelist known administrative IP addresses or users to reduce false positives.
73- Automated scripts or management tools that use WinRM for routine tasks may be flagged. Identify these scripts and create exceptions for their specific process names or execution paths.
74- Monitoring tools that check system health via WinRM might be misidentified as threats. Exclude these tools by specifying their source IPs or process names in the detection rule.
75- Scheduled tasks that utilize WinRM for updates or maintenance can cause alerts. Document these tasks and adjust the rule to ignore their specific execution patterns.
76- Internal security scans or compliance checks using WinRM should be accounted for. Coordinate with security teams to recognize these activities and exclude them from triggering alerts.
77
78### Response and remediation
79
80- Isolate the affected host immediately from the network to prevent further lateral movement and potential data exfiltration.
81- Terminate any suspicious processes associated with WinRM, particularly those not originating from legitimate administrative tools or known good sources.
82- Review and revoke any unauthorized access credentials or accounts that may have been used to initiate the WinRM session.
83- Conduct a thorough examination of the affected host for any additional signs of compromise, such as unauthorized software installations or changes to system configurations.
84- Restore the affected system from a known good backup if any malicious activity or unauthorized changes are confirmed.
85- Implement network segmentation to limit the ability of threats to move laterally across the network, focusing on restricting access to critical systems.
86- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
87
88
89[[rule.threat]]
90framework = "MITRE ATT&CK"
91[[rule.threat.technique]]
92id = "T1021"
93name = "Remote Services"
94reference = "https://attack.mitre.org/techniques/T1021/"
95[[rule.threat.technique.subtechnique]]
96id = "T1021.006"
97name = "Windows Remote Management"
98reference = "https://attack.mitre.org/techniques/T1021/006/"
99
100
101
102[rule.threat.tactic]
103id = "TA0008"
104name = "Lateral Movement"
105reference = "https://attack.mitre.org/tactics/TA0008/"
Triage and analysis
Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
Investigating Incoming Execution via WinRM Remote Shell
Windows Remote Management (WinRM) is a protocol that allows for remote management and execution of commands on Windows machines. While beneficial for legitimate administrative tasks, adversaries can exploit WinRM for lateral movement by executing commands remotely. The detection rule identifies suspicious activity by monitoring network traffic on specific ports and processes initiated by WinRM, flagging potential unauthorized remote executions.
Possible investigation steps
- Review the network traffic logs to confirm the presence of incoming connections on ports 5985 or 5986, which are used by WinRM, and verify if these connections are expected or authorized.
- Identify the source IP address of the incoming connection and determine if it belongs to a known and trusted network or device. Investigate any unfamiliar or suspicious IP addresses.
- Examine the process tree for the process initiated by winrshost.exe to identify any unusual or unauthorized processes that were started as a result of the remote execution.
- Check the user account associated with the WinRM session to ensure it is legitimate and has not been compromised. Look for any signs of unauthorized access or privilege escalation.
- Correlate the event with other security logs, such as authentication logs, to identify any related suspicious activities or patterns that might indicate lateral movement or a broader attack campaign.
- Investigate the timeline of events to determine if there are any other related alerts or activities occurring around the same time that could provide additional context or evidence of malicious intent.
False positive analysis
- Legitimate administrative tasks using WinRM can trigger alerts. Regularly review and whitelist known administrative IP addresses or users to reduce false positives.
- Automated scripts or management tools that use WinRM for routine tasks may be flagged. Identify these scripts and create exceptions for their specific process names or execution paths.
- Monitoring tools that check system health via WinRM might be misidentified as threats. Exclude these tools by specifying their source IPs or process names in the detection rule.
- Scheduled tasks that utilize WinRM for updates or maintenance can cause alerts. Document these tasks and adjust the rule to ignore their specific execution patterns.
- Internal security scans or compliance checks using WinRM should be accounted for. Coordinate with security teams to recognize these activities and exclude them from triggering alerts.
Response and remediation
- Isolate the affected host immediately from the network to prevent further lateral movement and potential data exfiltration.
- Terminate any suspicious processes associated with WinRM, particularly those not originating from legitimate administrative tools or known good sources.
- Review and revoke any unauthorized access credentials or accounts that may have been used to initiate the WinRM session.
- Conduct a thorough examination of the affected host for any additional signs of compromise, such as unauthorized software installations or changes to system configurations.
- Restore the affected system from a known good backup if any malicious activity or unauthorized changes are confirmed.
- Implement network segmentation to limit the ability of threats to move laterally across the network, focusing on restricting access to critical systems.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
Related rules
- Execution via TSClient Mountpoint
- Incoming DCOM Lateral Movement via MSHTA
- Incoming DCOM Lateral Movement with MMC
- Incoming DCOM Lateral Movement with ShellBrowserWindow or ShellWindows
- Incoming Execution via PowerShell Remoting