Process Killing Detected via Defend for Containers
ELASTIC detection rule by Elastic · Elastic License v2
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.
[metadata]
creation_date = "2026/03/05"
integration = ["cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/03/05"
[rule]
author = ["Elastic"]
description = """
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.
"""
false_positives = [
"""
There is a potential for false positives if the processes are killed for legitimate purposes,
such as debugging or troubleshooting. It is important to investigate any alerts generated by
this rule to determine if they are indicative of malicious activity or part of legitimate
container activity.
""",
]
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Process Killing Detected via Defend for Containers"
note = """## 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 Process Killing Detected via Defend for Containers
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.
### Possible investigation steps
- 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.
### False positive analysis
- 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.
### Response and remediation
- 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.
"""
references = [
"https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware",
]
risk_score = 21
rule_id = "85d9c573-ad77-461b-8315-9a02a280b20b"
severity = "low"
tags = [
"Data Source: Elastic Defend for Containers",
"Domain: Container",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Impact",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
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"
)
)
)
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1489"
name = "Service Stop"
reference = "https://attack.mitre.org/techniques/T1489/"
[rule.threat.tactic]
id = "TA0040"
name = "Impact"
reference = "https://attack.mitre.org/tactics/TA0040/"