Potential Command Shell via NetCat

Identifies potential attempt to execute via a reverse shell using the netcat utility to execute Windows commands using the default interpreters like Cmd.exe and Powershell.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/10/14"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2026/05/03"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies potential attempt to execute via a reverse shell using the netcat utility to execute Windows commands using
 11the default interpreters like Cmd.exe and Powershell.
 12"""
 13from = "now-9m"
 14index = ["logs-endpoint.events.process-*"]
 15language = "eql"
 16license = "Elastic License v2"
 17name = "Potential Command Shell via NetCat"
 18risk_score = 73
 19rule_id = "9c0f61fa-abf4-4b11-8d9d-5978c09182dd"
 20severity = "high"
 21tags = [
 22    "Domain: Endpoint",
 23    "OS: Windows",
 24    "Use Case: Threat Detection",
 25    "Tactic: Execution",
 26    "Resources: Investigation Guide",
 27    "Data Source: Elastic Defend"
 28]
 29timestamp_override = "event.ingested"
 30type = "eql"
 31
 32query = '''
 33process where host.os.type == "windows" and event.type == "start" and
 34process.name : ("cmd.exe", "powershell.exe") and process.parent.args : "-e" and
 35 (
 36  (process.parent.args_count == 5 and process.parent.command_line regex~ """.*[0-9]{1,3}(\.[0-9]{1,3}){3}.*""") or
 37  (process.parent.args : "-*l*" and process.parent.args : "-*p*" and process.parent.args : ("cmd.exe", "powershell.exe"))
 38  )
 39'''
 40
 41note = """## Triage and analysis
 42
 43### Investigating Potential Command Shell via NetCat
 44
 45#### Possible investigation steps
 46
 47- Which remote-shell mode does the alert-local process evidence show?
 48  - Focus: `process.parent.command_line`, `process.parent.args_count`, and `process.name`.
 49  - Implication: escalate when "-e" wires "cmd.exe" or "powershell.exe" to an explicit IP, unusual port, or "-l"/"-p" listener; lower concern only when shell mode, port or destination, and child shell match a known lab, red-team, or break-glass workflow.
 50
 51- Does the parent binary identity fit a recognized NetCat-family tool instead of a renamed payload?
 52  - Focus: `process.parent.executable`, `process.parent.name`, and code signature.
 53  - Implication: escalate when the parent is unsigned, renamed, or runs from temp, downloads, archives, shares, or another user-writable path; identity lowers concern only when path and signer fit the same controlled tool, and never clears the `-e` shell behavior by itself.
 54
 55- Do recovered parent network events confirm a connect-back destination or exposed listener?
 56  - Focus: network events on `host.id` for `process.parent.entity_id`; separate DNS `dns.question.name` from `destination.ip`, `destination.port`, and `network.direction`. $investigate_0
 57  - Hint: network fields come from endpoint network events, not the process alert; compare any command-line IP or port with recovered connections.
 58  - Implication: escalate when recovered connections confirm a public or unexpected destination, or a listener is exposed on an unexpected asset; missing network telemetry is unresolved, not benign.
 59
 60- Did the spawned shell launch operator commands after start?
 61  - Focus: child process starts where `process.parent.entity_id` matches the spawned shell `process.entity_id`; review `process.name`, `process.executable`, and `process.command_line`. $investigate_1
 62  - Implication: escalate when descendants show reconnaissance, credential, download, persistence, staging, lateral movement, or cleanup; no descendants weakens operator-control evidence but does not make the remote-shell pattern benign.
 63
 64- Does the user and host context support the shell exposure?
 65  - Focus: `user.id`, `user.name`, `host.id`, `host.name`, and `process.parent.command_line`.
 66  - Implication: escalate when user-host pairing or account identity conflicts with expected testing or emergency use; lower concern only when the same user, host, and parent command fit one bounded authorized activity.
 67
 68- If local evidence is suspicious or unresolved, do surrounding alerts expand the scope?
 69  - Focus: alerts for the same `user.id`, especially execution, defense-evasion, persistence, credential-access, lateral-movement, or command-and-control tied to the same parent command or recovered destination. $investigate_2
 70  - Hint: also check the same `host.id` to decide whether this remains one process on one asset or part of a broader compromise. $investigate_3
 71  - Implication: expand response scope when surrounding alerts share the user, host, parent command, or recovered destination pattern; keep triage local when no corroborating alerts appear after the parent, network, and descendant checks.
 72
 73- What disposition is supported by shell mode, parent identity, descendant commands, network recovery, user-host context, and alert scope?
 74  - Focus: synthesize shell mode, parent identity, descendants, network recovery, user-host context, and alert scope.
 75  - Implication: escalate on alert-local "-e" behavior plus any corroborator: unrecognized parent, external or exposed network evidence, operator descendants, user-host conflict, or related alerts. Close only when all categories bind to one authorized security-testing or break-glass activity with no contradictions; if telemetry cannot prove legitimacy, require outside confirmation. Preserve artifacts and escalate when evidence is mixed or visibility is incomplete.
 76
 77### False positive analysis
 78
 79- NetCat "-e" shells are an operational anti-pattern outside confirmed security testing or break-glass support. Confirm benign use only when parent path and signer, exact parent command, shell mode, child shell, recovered destination or listen-port evidence, `user.id`, and `host.id` all align to the same bounded workflow. Use schedules, tickets, or owner confirmation only to corroborate that telemetry-matched activity; without them, require telemetry-only confirmation that the same user, host, parent command, and destination or port pattern recur for this rule. Any mismatch keeps the alert suspicious.
 80- Before creating an exception, validate stability across prior alerts for the same `user.id` and `host.id`. Anchor the exception on `process.parent.executable`, `process.parent.command_line`, child `process.command_line`, user/host scope, and recovered destination or listen-port pattern. Avoid exceptions on `process.name`, parent basename, or shell name alone.
 81
 82### Response and remediation
 83
 84- If confirmed benign, reverse any temporary containment and document the parent identity, exact command, shell mode, child shell, user/host scope, and recovered destination or listen-port evidence that proved the workflow. Create an exception only if that same workflow is stable across prior alerts from this rule.
 85- If suspicious but unconfirmed, preserve volatile state and case exports first: parent and child process entity IDs, command lines, descendant commands, parent binary path and signer, and recovered network indicators. Apply reversible containment tied to the findings, such as temporary destination blocks, firewall control of the exposed listener, or host isolation when interactive control or broader scope is likely and the host can tolerate it. Avoid process termination or deletion until evidence capture is complete.
 86- If confirmed malicious, first record `process.parent.entity_id`, `process.entity_id`, parent and child command lines, descendant commands, and recovered network indicators. Then isolate the host as appropriate, block recovered destination, domain, IP, or port indicators, and terminate the NetCat parent, spawned shell, and malicious descendants after evidence capture. Reset credentials only when descendant commands, user-host context, or related alerts show credential or administrator-command exposure.
 87- Eradicate only artifacts found during the investigation: the NetCat binary or script wrapper, staged payloads, persistence, service or listener configuration, tunnels, and cleanup scripts. Then remediate the delivery path that placed the tool on the host.
 88- Post-incident hardening: restrict unauthorized NetCat-family binaries and "-e" shell usage, retain process and network telemetry, and document adjacent variants such as renamed utilities, relay mode without "-e", or delayed shell handoff in the case record for future response.
 89"""
 90
 91setup = """## Setup
 92
 93This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
 94
 95Setup instructions: https://ela.st/install-elastic-defend
 96"""
 97
 98[rule.investigation_fields]
 99field_names = [
100    "@timestamp",
101    "host.id",
102    "user.id",
103    "process.entity_id",
104    "process.executable",
105    "process.command_line",
106    "process.parent.entity_id",
107    "process.parent.executable",
108    "process.parent.command_line",
109    "process.parent.args",
110    "process.parent.args_count",
111    "process.parent.code_signature.subject_name",
112    "process.parent.code_signature.trusted",
113]
114
115[transform]
116
117[[transform.investigate]]
118label = "Network events for the netcat parent process"
119description = ""
120providers = [
121  [
122    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
123    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" },
124    { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" }
125  ]
126]
127relativeFrom = "now-1h"
128relativeTo = "now"
129
130[[transform.investigate]]
131label = "Descendant processes from the spawned shell"
132description = ""
133providers = [
134  [
135    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
136    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
137    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
138  ]
139]
140relativeFrom = "now-1h"
141relativeTo = "now"
142
143[[transform.investigate]]
144label = "Alerts associated with the user"
145description = ""
146providers = [
147  [
148    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
149    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
150  ]
151]
152relativeFrom = "now-48h/h"
153relativeTo = "now"
154
155[[transform.investigate]]
156label = "Alerts associated with the host"
157description = ""
158providers = [
159  [
160    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
161    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
162  ]
163]
164relativeFrom = "now-48h/h"
165relativeTo = "now"
166
167[[rule.threat]]
168framework = "MITRE ATT&CK"
169
170[[rule.threat.technique]]
171id = "T1059"
172name = "Command and Scripting Interpreter"
173reference = "https://attack.mitre.org/techniques/T1059/"
174
175[[rule.threat.technique.subtechnique]]
176id = "T1059.001"
177name = "PowerShell"
178reference = "https://attack.mitre.org/techniques/T1059/001/"
179
180[[rule.threat.technique.subtechnique]]
181id = "T1059.003"
182name = "Windows Command Shell"
183reference = "https://attack.mitre.org/techniques/T1059/003/"
184
185[rule.threat.tactic]
186id = "TA0002"
187name = "Execution"
188reference = "https://attack.mitre.org/tactics/TA0002/"
189
190[[rule.threat]]
191framework = "MITRE ATT&CK"
192
193[[rule.threat.technique]]
194id = "T1095"
195name = "Non-Application Layer Protocol"
196reference = "https://attack.mitre.org/techniques/T1095/"
197
198[rule.threat.tactic]
199id = "TA0011"
200name = "Command and Control"
201reference = "https://attack.mitre.org/tactics/TA0011/"

Triage and analysis

Investigating Potential Command Shell via NetCat

Possible investigation steps

  • Which remote-shell mode does the alert-local process evidence show?

    • Focus: process.parent.command_line, process.parent.args_count, and process.name.
    • Implication: escalate when "-e" wires "cmd.exe" or "powershell.exe" to an explicit IP, unusual port, or "-l"/"-p" listener; lower concern only when shell mode, port or destination, and child shell match a known lab, red-team, or break-glass workflow.
  • Does the parent binary identity fit a recognized NetCat-family tool instead of a renamed payload?

    • Focus: process.parent.executable, process.parent.name, and code signature.
    • Implication: escalate when the parent is unsigned, renamed, or runs from temp, downloads, archives, shares, or another user-writable path; identity lowers concern only when path and signer fit the same controlled tool, and never clears the -e shell behavior by itself.
  • Do recovered parent network events confirm a connect-back destination or exposed listener?

    • Focus: network events on host.id for process.parent.entity_id; separate DNS dns.question.name from destination.ip, destination.port, and network.direction. $investigate_0
    • Hint: network fields come from endpoint network events, not the process alert; compare any command-line IP or port with recovered connections.
    • Implication: escalate when recovered connections confirm a public or unexpected destination, or a listener is exposed on an unexpected asset; missing network telemetry is unresolved, not benign.
  • Did the spawned shell launch operator commands after start?

    • Focus: child process starts where process.parent.entity_id matches the spawned shell process.entity_id; review process.name, process.executable, and process.command_line. $investigate_1
    • Implication: escalate when descendants show reconnaissance, credential, download, persistence, staging, lateral movement, or cleanup; no descendants weakens operator-control evidence but does not make the remote-shell pattern benign.
  • Does the user and host context support the shell exposure?

    • Focus: user.id, user.name, host.id, host.name, and process.parent.command_line.
    • Implication: escalate when user-host pairing or account identity conflicts with expected testing or emergency use; lower concern only when the same user, host, and parent command fit one bounded authorized activity.
  • If local evidence is suspicious or unresolved, do surrounding alerts expand the scope?

    • Focus: alerts for the same user.id, especially execution, defense-evasion, persistence, credential-access, lateral-movement, or command-and-control tied to the same parent command or recovered destination. $investigate_2
    • Hint: also check the same host.id to decide whether this remains one process on one asset or part of a broader compromise. $investigate_3
    • Implication: expand response scope when surrounding alerts share the user, host, parent command, or recovered destination pattern; keep triage local when no corroborating alerts appear after the parent, network, and descendant checks.
  • What disposition is supported by shell mode, parent identity, descendant commands, network recovery, user-host context, and alert scope?

    • Focus: synthesize shell mode, parent identity, descendants, network recovery, user-host context, and alert scope.
    • Implication: escalate on alert-local "-e" behavior plus any corroborator: unrecognized parent, external or exposed network evidence, operator descendants, user-host conflict, or related alerts. Close only when all categories bind to one authorized security-testing or break-glass activity with no contradictions; if telemetry cannot prove legitimacy, require outside confirmation. Preserve artifacts and escalate when evidence is mixed or visibility is incomplete.

False positive analysis

  • NetCat "-e" shells are an operational anti-pattern outside confirmed security testing or break-glass support. Confirm benign use only when parent path and signer, exact parent command, shell mode, child shell, recovered destination or listen-port evidence, user.id, and host.id all align to the same bounded workflow. Use schedules, tickets, or owner confirmation only to corroborate that telemetry-matched activity; without them, require telemetry-only confirmation that the same user, host, parent command, and destination or port pattern recur for this rule. Any mismatch keeps the alert suspicious.
  • Before creating an exception, validate stability across prior alerts for the same user.id and host.id. Anchor the exception on process.parent.executable, process.parent.command_line, child process.command_line, user/host scope, and recovered destination or listen-port pattern. Avoid exceptions on process.name, parent basename, or shell name alone.

Response and remediation

  • If confirmed benign, reverse any temporary containment and document the parent identity, exact command, shell mode, child shell, user/host scope, and recovered destination or listen-port evidence that proved the workflow. Create an exception only if that same workflow is stable across prior alerts from this rule.
  • If suspicious but unconfirmed, preserve volatile state and case exports first: parent and child process entity IDs, command lines, descendant commands, parent binary path and signer, and recovered network indicators. Apply reversible containment tied to the findings, such as temporary destination blocks, firewall control of the exposed listener, or host isolation when interactive control or broader scope is likely and the host can tolerate it. Avoid process termination or deletion until evidence capture is complete.
  • If confirmed malicious, first record process.parent.entity_id, process.entity_id, parent and child command lines, descendant commands, and recovered network indicators. Then isolate the host as appropriate, block recovered destination, domain, IP, or port indicators, and terminate the NetCat parent, spawned shell, and malicious descendants after evidence capture. Reset credentials only when descendant commands, user-host context, or related alerts show credential or administrator-command exposure.
  • Eradicate only artifacts found during the investigation: the NetCat binary or script wrapper, staged payloads, persistence, service or listener configuration, tunnels, and cleanup scripts. Then remediate the delivery path that placed the tool on the host.
  • Post-incident hardening: restrict unauthorized NetCat-family binaries and "-e" shell usage, retain process and network telemetry, and document adjacent variants such as renamed utilities, relay mode without "-e", or delayed shell handoff in the case record for future response.

Related rules

to-top