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

to-top