Process Killing Detected via Defend for Containers

  1[metadata]
  2creation_date = "2026/03/05"
  3integration = ["cloud_defend"]
  4maturity = "production"
  5min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
  6min_stack_version = "9.3.0"
  7updated_date = "2026/03/05"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects the killing of processes inside a container. An adversary may attempt to find and
 13kill competing processes to gain control of the container.
 14"""
 15false_positives = [
 16    """
 17    There is a potential for false positives if the processes are killed for legitimate purposes,
 18    such as debugging or troubleshooting. It is important to investigate any alerts generated by
 19    this rule to determine if they are indicative of malicious activity or part of legitimate
 20    container activity.
 21    """,
 22]
 23from = "now-6m"
 24index = ["logs-cloud_defend.process*"]
 25interval = "5m"
 26language = "eql"
 27license = "Elastic License v2"
 28name = "Process Killing Detected via Defend for Containers"
 29note = """## Triage and analysis
 30
 31> **Disclaimer**:
 32> 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.
 33
 34### Investigating Process Killing Detected via Defend for Containers
 35
 36This rule detects execution of Linux process-termination utilities inside a container, indicating attempts to stop services or disable security tooling to seize control of the workload. Attackers commonly enumerate running processes and then use `kill`, `pkill`, or `killall` (often launched via a shell or busybox) to terminate agents, web servers, or competing miner processes and maintain persistence or resource dominance.
 37
 38### Possible investigation steps
 39
 40- Identify the target processes and signals by pivoting to container process telemetry immediately before and after the kill event to confirm which service or agent stopped and whether it restarted.  
 41- Determine whether the kill was user-initiated administration or malicious impact by correlating the container execution event to the invoking session/command chain and any recent interactive access (exec/attach), CI job, or startup script activity.  
 42- Assess impact and intent by checking for concurrent disruption indicators such as sudden healthcheck failures, pod restarts, service errors, or termination of security/monitoring agents within the same container or namespace.  
 43- Investigate precursor behavior by reviewing recent process and file activity in the container for enumeration, credential access, or tooling drops (e.g., curl/wget downloads, new binaries in writable paths, modified entrypoints).  
 44- Scope and contain by searching for similar kill activity across the cluster and, if suspicious, isolate the workload, capture runtime artifacts (process list, network connections, filesystem diff), and preserve relevant logs for incident response.
 45
 46### False positive analysis
 47
 48- Legitimate operational workflows can exec into a container and use `kill`/`pkill`/`killall` to restart a hung application process or free resources after troubleshooting, especially during deployments or incident mitigation.  
 49- Container entrypoint scripts or maintenance jobs may invoke shell or busybox wrappers that call `kill` to gracefully stop child processes during shutdown/rotation, leading to detections during normal lifecycle events like restarts and log/process supervision.
 50
 51### Response and remediation
 52
 53- Quarantine the affected pod/container by removing it from service (scale to zero or cordon/drain the node) and temporarily block further `exec/attach` access while preserving evidence.  
 54- Capture volatile artifacts before termination, including the current process tree, the killed process PID/name and signal used, open network connections, and a filesystem diff for newly dropped binaries or modified entrypoint scripts.  
 55- Eradicate by redeploying the workload from a trusted image, rotating any credentials or tokens accessible to the container (service account, registry, application secrets), and removing any unauthorized binaries or cron/sidecar persistence found.  
 56- Recover service by restoring expected processes and health checks, validating logs/metrics resume normally, and monitoring for repeated `kill`/`pkill`/`killall` executions or unexpected restarts in the same namespace.  
 57- Escalate to incident response if the terminated process was a security/monitoring agent, if multiple containers show coordinated kill activity, or if follow-on behaviors appear such as tool downloads, privilege escalation attempts, or outbound connections to unknown endpoints.  
 58- Harden by enforcing least-privilege (drop `SYS_PTRACE`/debug capabilities, read-only root filesystem), restricting interactive access with RBAC and just-in-time approvals, and adding runtime policies to deny process-termination utilities in production images where not required.
 59"""
 60references = [
 61    "https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware",
 62]
 63risk_score = 21
 64rule_id = "85d9c573-ad77-461b-8315-9a02a280b20b"
 65severity = "low"
 66tags = [
 67    "Data Source: Elastic Defend for Containers",
 68    "Domain: Container",
 69    "OS: Linux",
 70    "Use Case: Threat Detection",
 71    "Tactic: Impact",
 72    "Resources: Investigation Guide",
 73]
 74timestamp_override = "event.ingested"
 75type = "eql"
 76query = '''
 77process where event.type == "start" and event.action == "exec" and container.id like "*?" and 
 78(
 79  process.name in ("kill", "pkill", "killall") or
 80  (
 81    /* Account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg */
 82    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
 83    process.args in (
 84      "kill", "/bin/kill", "/usr/bin/kill", "/usr/local/bin/kill",
 85      "pkill", "/bin/pkill", "/usr/bin/pkill", "/usr/local/bin/pkill",
 86      "killall", "/bin/killall", "/usr/bin/killall", "/usr/local/bin/killall"
 87    ) and
 88    /* default exclusion list to not FP on default multi-process commands */
 89    not process.args in (
 90      "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
 91      "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
 92      "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
 93    )
 94  )
 95)
 96'''
 97
 98[[rule.threat]]
 99framework = "MITRE ATT&CK"
100
101[[rule.threat.technique]]
102id = "T1489"
103name = "Service Stop"
104reference = "https://attack.mitre.org/techniques/T1489/"
105
106[rule.threat.tactic]
107id = "TA0040"
108name = "Impact"
109reference = "https://attack.mitre.org/tactics/TA0040/"