Pod or Container Creation with Suspicious Command-Line
This rule detects the creation of pods or containers that execute suspicious commands often associated with persistence or privilege escalation techniques. Attackers may use container orchestration tools like kubectl or container runtimes like docker to create pods or containers that run shell commands with arguments that indicate attempts to establish persistence (e.g., modifying startup scripts, creating backdoors).
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/12/01"
3integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
4maturity = "production"
5updated_date = "2025/12/08"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule detects the creation of pods or containers that execute suspicious commands often associated with persistence or
11privilege escalation techniques. Attackers may use container orchestration tools like kubectl or container runtimes like
12docker to create pods or containers that run shell commands with arguments that indicate attempts to establish persistence
13(e.g., modifying startup scripts, creating backdoors).
14"""
15from = "now-9m"
16index = [
17 "auditbeat-*",
18 "endgame-*",
19 "logs-auditd_manager.auditd-*",
20 "logs-crowdstrike.fdr*",
21 "logs-endpoint.events.process*",
22 "logs-sentinel_one_cloud_funnel.*",
23]
24language = "eql"
25license = "Elastic License v2"
26name = "Pod or Container Creation with Suspicious Command-Line"
27note = """## Triage and analysis
28
29> **Disclaimer**:
30> 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.
31
32### Investigating Pod or Container Creation with Suspicious Command-Line
33
34This rule flags pods or containers started via orchestration or runtime tools that immediately execute a shell with commands linked to persistence, privilege changes, or covert I/O (cron, rc.local, sudoers, .ssh, base64, netcat/socat, /tmp). This matters because attackers often spin short‑lived workloads to modify startup paths or drop backdoors. Example: kubectl run --restart=Never -- sh -c 'echo ssh-rsa AAAA... >> /root/.ssh/authorized_keys && nc -lvp 4444 -e /bin/sh'.
35
36### Possible investigation steps
37
38- Pivot to Kubernetes audit logs to identify the actor (user or service account), namespace, source IP/workstation, and RBAC context that launched the workload, and validate whether this aligns with approved admin activity.
39- Pull the pod/container spec and image metadata to quickly assess risk indicators like unapproved registry/image, privileged mode, hostNetwork/hostPID, and hostPath or sensitive volume mounts that could mutate the node.
40- Parse the executed command to determine whether it attempts persistence or backdoor setup (editing cron/rc.local, sudoers or authorized_keys, base64 file drops, starting netcat/socat listeners), and verify those changes on the container or node.
41- Correlate runtime and network telemetry for the workload to detect outbound connections or listening ports indicative of reverse shells, and identify destination endpoints and nodes involved.
42- Trace the launcher context by reviewing kubectl client host artifacts (shell history, kubeconfig, IAM/MFA tokens) or CI/CD logs, and check for recent anomalous commits or pipeline runs that could have triggered it.
43
44### False positive analysis
45
46- Administrators performing network troubleshooting or node diagnostics may start ephemeral pods via kubectl run --restart=Never or ad hoc containers with docker/nerdctl that launch sh and use nc/socat/telnet, read /proc, or write to /tmp.
47- Engineers may pass configs or test scripts into a shell using base64/xxd and touch cron, rc.local, /etc/ssh, ~/.ssh, or /etc/profile during validation or break-fix work, producing commands that resemble persistence behavior.
48
49### Response and remediation
50
51- Delete the offending pod/container, revoke the kubeconfig or runtime credentials used to launch it, and quarantine the image and namespace, cordoning the node if privileged, hostNetwork/hostPID, or hostPath were present.
52- Kill any spawned shells or listeners (e.g., sh -c 'nc -lvp ...', socat, telnet) on affected nodes, remove unauthorized firewall/iptables rules, and apply temporary deny-all egress NetworkPolicies to cut C2.
53- Eradicate persistence by restoring clean versions of /etc/cron*, /etc/rc.local, /etc/profile, /etc/sudoers, /etc/ssh/* and deleting unauthorized keys or scripts under /root/.ssh, ~/.ssh, /tmp, /dev/shm, /var/tmp, and hostPath-mounted directories.
54- Rebuild compromised nodes or redeploy workloads with known-good images, rotate cluster secrets and SSH keys, and validate baseline integrity with file hashes and admission scans before returning to service.
55- Escalate to incident response if the actor is unverified or commands touched /etc/shadow or /etc/sudoers, used privileged containers or hostPath to access the host, or opened external connections or listening ports on the node.
56- Harden by enforcing admission controls to deny pods that start /bin/sh or /bin/bash as PID 1, block privileged/hostNetwork/hostPID/hostPath, apply per-namespace egress policies, and restrict RBAC so only approved admins can run kubectl run --restart=Never or docker/nerdctl run.
57"""
58risk_score = 47
59rule_id = "c595363f-52a6-49e1-9257-0e08ae043dbd"
60severity = "medium"
61tags = [
62 "Domain: Endpoint",
63 "Domain: Container",
64 "OS: Linux",
65 "Use Case: Threat Detection",
66 "Tactic: Execution",
67 "Tactic: Privilege Escalation",
68 "Tactic: Persistence",
69 "Data Source: Elastic Defend",
70 "Data Source: Elastic Endgame",
71 "Data Source: Auditd Manager",
72 "Data Source: Crowdstrike",
73 "Data Source: SentinelOne",
74 "Resources: Investigation Guide",
75]
76timestamp_override = "event.ingested"
77type = "eql"
78query = '''
79process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and (
80 (process.name == "kubectl" and process.args == "run" and process.args == "--restart=Never" and process.args == "--") or
81 (process.name in ("docker", "nerdctl", "ctl") and process.args == "run")
82) and
83process.args in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
84process.command_line like~ (
85 "*atd*", "*cron*", "*/etc/rc.local*", "*/dev/tcp/*", "*/etc/init.d*", "*/etc/update-motd.d*", "*/etc/ld.so*", "*/etc/sudoers*", "*base64 *",
86 "*/etc/profile*", "*/etc/ssh*", "*/home/*/.ssh/*", "*/root/.ssh*" , "*~/.ssh/*", "*autostart*", "*xxd *", "*/etc/shadow*", "*./.*",
87 "*import*pty*spawn*", "*import*subprocess*call*", "*TCPSocket.new*", "*TCPSocket.open*", "*io.popen*", "*os.execute*", "*fsockopen*",
88 "*disown*", "* ncat *", "* nc *", "* netcat *", "* nc.traditional *", "*socat*", "*telnet*", "*/tmp/*", "*/dev/shm/*", "*/var/tmp/*",
89 "*/boot/*", "*/sys/*", "*/lost+found/*", "*/media/*", "*/proc/*", "*/var/backups/*", "*/var/log/*", "*/var/mail/*", "*/var/spool/*"
90)
91'''
92
93[[rule.threat]]
94framework = "MITRE ATT&CK"
95
96[[rule.threat.technique]]
97id = "T1059"
98name = "Command and Scripting Interpreter"
99reference = "https://attack.mitre.org/techniques/T1059/"
100
101[[rule.threat.technique.subtechnique]]
102id = "T1059.004"
103name = "Unix Shell"
104reference = "https://attack.mitre.org/techniques/T1059/004/"
105
106[[rule.threat.technique]]
107id = "T1609"
108name = "Container Administration Command"
109reference = "https://attack.mitre.org/techniques/T1609/"
110
111[rule.threat.tactic]
112id = "TA0002"
113name = "Execution"
114reference = "https://attack.mitre.org/tactics/TA0002/"
115
116[[rule.threat]]
117framework = "MITRE ATT&CK"
118
119[[rule.threat.technique]]
120id = "T1611"
121name = "Escape to Host"
122reference = "https://attack.mitre.org/techniques/T1611/"
123
124[rule.threat.tactic]
125id = "TA0004"
126name = "Privilege Escalation"
127reference = "https://attack.mitre.org/tactics/TA0004/"
128
129[[rule.threat]]
130framework = "MITRE ATT&CK"
131
132[[rule.threat.technique]]
133id = "T1053"
134name = "Scheduled Task/Job"
135reference = "https://attack.mitre.org/techniques/T1053/"
136
137[[rule.threat.technique.subtechnique]]
138id = "T1053.002"
139name = "At"
140reference = "https://attack.mitre.org/techniques/T1053/002/"
141
142[[rule.threat.technique.subtechnique]]
143id = "T1053.003"
144name = "Cron"
145reference = "https://attack.mitre.org/techniques/T1053/003/"
146
147[rule.threat.tactic]
148id = "TA0003"
149name = "Persistence"
150reference = "https://attack.mitre.org/tactics/TA0003/"
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 Pod or Container Creation with Suspicious Command-Line
This rule flags pods or containers started via orchestration or runtime tools that immediately execute a shell with commands linked to persistence, privilege changes, or covert I/O (cron, rc.local, sudoers, .ssh, base64, netcat/socat, /tmp). This matters because attackers often spin short‑lived workloads to modify startup paths or drop backdoors. Example: kubectl run --restart=Never -- sh -c 'echo ssh-rsa AAAA... >> /root/.ssh/authorized_keys && nc -lvp 4444 -e /bin/sh'.
Possible investigation steps
- Pivot to Kubernetes audit logs to identify the actor (user or service account), namespace, source IP/workstation, and RBAC context that launched the workload, and validate whether this aligns with approved admin activity.
- Pull the pod/container spec and image metadata to quickly assess risk indicators like unapproved registry/image, privileged mode, hostNetwork/hostPID, and hostPath or sensitive volume mounts that could mutate the node.
- Parse the executed command to determine whether it attempts persistence or backdoor setup (editing cron/rc.local, sudoers or authorized_keys, base64 file drops, starting netcat/socat listeners), and verify those changes on the container or node.
- Correlate runtime and network telemetry for the workload to detect outbound connections or listening ports indicative of reverse shells, and identify destination endpoints and nodes involved.
- Trace the launcher context by reviewing kubectl client host artifacts (shell history, kubeconfig, IAM/MFA tokens) or CI/CD logs, and check for recent anomalous commits or pipeline runs that could have triggered it.
False positive analysis
- Administrators performing network troubleshooting or node diagnostics may start ephemeral pods via kubectl run --restart=Never or ad hoc containers with docker/nerdctl that launch sh and use nc/socat/telnet, read /proc, or write to /tmp.
- Engineers may pass configs or test scripts into a shell using base64/xxd and touch cron, rc.local, /etc/ssh, ~/.ssh, or /etc/profile during validation or break-fix work, producing commands that resemble persistence behavior.
Response and remediation
- Delete the offending pod/container, revoke the kubeconfig or runtime credentials used to launch it, and quarantine the image and namespace, cordoning the node if privileged, hostNetwork/hostPID, or hostPath were present.
- Kill any spawned shells or listeners (e.g., sh -c 'nc -lvp ...', socat, telnet) on affected nodes, remove unauthorized firewall/iptables rules, and apply temporary deny-all egress NetworkPolicies to cut C2.
- Eradicate persistence by restoring clean versions of /etc/cron*, /etc/rc.local, /etc/profile, /etc/sudoers, /etc/ssh/* and deleting unauthorized keys or scripts under /root/.ssh, ~/.ssh, /tmp, /dev/shm, /var/tmp, and hostPath-mounted directories.
- Rebuild compromised nodes or redeploy workloads with known-good images, rotate cluster secrets and SSH keys, and validate baseline integrity with file hashes and admission scans before returning to service.
- Escalate to incident response if the actor is unverified or commands touched /etc/shadow or /etc/sudoers, used privileged containers or hostPath to access the host, or opened external connections or listening ports on the node.
- Harden by enforcing admission controls to deny pods that start /bin/sh or /bin/bash as PID 1, block privileged/hostNetwork/hostPID/hostPath, apply per-namespace egress policies, and restrict RBAC so only approved admins can run kubectl run --restart=Never or docker/nerdctl run.
Related rules
- Privileged Container Creation with Host Directory Mount
- Kernel Load or Unload via Kexec Detected
- Execution via GitHub Actions Runner
- Remote GitHub Actions Runner Registration
- File Transfer or Listener Established via Netcat