Loading

Process Killing Detected via Defend for Containers

This rule detects the killing of processes inside a container. An adversary may attempt to find and kill competing processes to gain control of the container.

Rule type: eql
Rule indices:

  • logs-cloud_defend.process*

Rule Severity: low
Risk Score: 21
Runs every: 5m
Searches indices from: now-6m
Maximum alerts per execution: 100
References:

Tags:

  • Data Source: Elastic Defend for Containers
  • Domain: Container
  • OS: Linux
  • Use Case: Threat Detection
  • Tactic: Impact
  • Resources: Investigation Guide

Version: 1
Rule authors:

  • Elastic

Rule license: Elastic License v2

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.

This 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.

  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
process where event.type == "start" and event.action == "exec" and container.id like "*?" and
(
  process.name in ("kill", "pkill", "killall") or
  (
    /* Account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg */
    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
    process.args in (
      "kill", "/bin/kill", "/usr/bin/kill", "/usr/local/bin/kill",
      "pkill", "/bin/pkill", "/usr/bin/pkill", "/usr/local/bin/pkill",
      "killall", "/bin/killall", "/usr/bin/killall", "/usr/local/bin/killall"
    ) and
    /* default exclusion list to not FP on default multi-process commands */
    not process.args in (
      "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
      "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
      "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
    )
  )
)

Framework: MITRE ATT&CK