Tool Installation Detected via Defend for Containers

This rule detects the installation of tools inside a container. An adversary may need to install additional software to enumerate the container, its environment, and move laterally within the environment.

Elastic rule (View on GitHub)

 1[metadata]
 2creation_date = "2026/01/21"
 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/02/06"
 8
 9[rule]
10author = ["Elastic"]
11description = """
12This rule detects the installation of tools inside a container. An adversary may need to install additional software
13to enumerate the container, its environment, and move laterally within the environment.
14"""
15false_positives = [
16    """
17    There is a potential for false positives if the tools are installed for legitimate purposes,
18    such as debugging or troubleshooting. It is important to investigate any alerts generated by this rule to determine
19    if they are indicative of malicious activity or part of legitimate container activity.
20    """,
21]
22from = "now-6m"
23index = ["logs-cloud_defend.process*"]
24interval = "5m"
25language = "eql"
26license = "Elastic License v2"
27name = "Tool Installation Detected via Defend for Containers"
28note = """ ## Triage and analysis
29
30> **Disclaimer**:
31> 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.
32
33### Investigating Tool Installation Detected via Defend for Containers
34
35This rule flags interactive package installs inside Linux containers for network utilities or interpreters, a strong signal of hands-on activity to enumerate, fetch payloads, and pivot. Example attacker pattern: after gaining a shell in a pod, they run apt/apk/pacman to add curl, netcat, or socat, pull a second stage from an external host, and open a reverse shell to move from the container into adjacent services.
36
37### Possible investigation steps
38
39- Attribute the interactive install by correlating Kubernetes audit events (exec/attach) and runtime logs to the pod/namespace, a specific user or service account, source IP, and client, and verify alignment with approved break-glass procedures.
40- Diff the running container filesystem against the image baseline or SBOM to enumerate newly added binaries and libraries, review package manager logs/cache, and capture hashes and paths for forensics.
41- Examine pod-level network telemetry and DNS logs around the event for outbound connections, downloads, or reverse shell patterns, and isolate the workload if beaconing or exfiltration is observed.
42- Verify the pod’s security context and mounts for privilege escalation vectors (privileged, hostPID/IPC, hostPaths, docker.sock) and inventory exposed credentials (service account tokens, cloud metadata, env vars, ~/.ssh, .aws), rotating any secrets at risk.
43- Hunt across the cluster for similar interactive installs or exec sessions using audit and Defend for Containers telemetry, and review recent image builds and deployments to detect in-cluster modifications before quarantining or restarting affected workloads.
44
45### False positive analysis
46
47- A developer attaches an interactive shell to a running container to debug connectivity, using apt or apk to install curl or netcat for quick tests, which matches the rule’s interactive install of network utilities.
48- During an approved break-glass fix, an operator interactively installs python or openssl with yum or dnf in a minimal container to run a temporary diagnostic script, triggering the same package-install signature.
49
50### Response and remediation
51
52- Immediately isolate the pod/container that performed interactive installs (e.g., apt-get install curl, apk add netcat) by applying a deny-all NetworkPolicy, terminating active kubectl exec/attach sessions, and cordoning the node if the pod is privileged or has hostPath/docker.sock mounts.
53- Stop and delete the compromised workload, snapshot the container filesystem, then redeploy the deployment/statefulset from a trusted image and purge added tools by removing packages and caches (/var/lib/apt, /var/cache/apk, /var/cache/yum) from any retained volumes.
54- Rotate the pod’s service account token and any exposed credentials found in env vars, ~/.ssh, or cloud provider metadata, and invalidate outbound connections established by newly installed binaries like curl, wget, socat, or netcat via egress firewall rules.
55- Restore normal connectivity only after confirming no unauthorized binaries remain by diffing against the image SBOM and checking package history files like /var/log/dpkg.log, /var/log/yum.log, or /etc/apk/world, then validating app readiness/liveness probes.
56- Escalate to incident response if the install included tor/torsocks, openssl used to generate new keys, reverse-shell behavior (e.g., netcat -e or socat TCP:external_ip), or if activity occurred in production without a change request.
57- Enforce immutability and least privilege by rebuilding images without package managers or shells (distroless), enabling read-only root filesystems, disallowing kubectl exec via RBAC, using admission controls to block privileged pods and hostPath/docker.sock mounts, and tightening egress to only approved destinations.
58"""
59risk_score = 21
60rule_id = "527d23e6-8b67-4a8e-a6bd-5169b90ab2a8"
61severity = "low"
62tags = [
63    "Data Source: Elastic Defend for Containers",
64    "Domain: Container",
65    "OS: Linux",
66    "Use Case: Threat Detection",
67    "Tactic: Execution",
68    "Resources: Investigation Guide",
69]
70timestamp_override = "event.ingested"
71type = "eql"
72query = '''
73process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.interactive == true and (
74  (process.name in ("apt", "apt-get", "dnf", "microdnf", "yum", "zypper", "tdnf") and process.args == "install") or
75  (process.name == "apk" and process.args == "add") or
76  (process.name == "pacman" and process.args like "-*S*") or
77  (process.name in ("rpm", "dpkg") and process.args in ("-i", "--install"))
78) and process.args like (
79  "curl", "wget", "socat", "busybox", "openssl", "torsocks",
80  "netcat", "netcat-openbsd", "netcat-traditional", "ncat", "tor",
81  "python*", "perl", "node", "nodejs", "ruby", "lua", "bash", "sh",
82  "dash", "zsh", "fish", "tcsh", "csh", "ksh"
83) and container.id like "?*"
84'''
85
86[[rule.threat]]
87framework = "MITRE ATT&CK"
88
89[[rule.threat.technique]]
90id = "T1072"
91name = "Software Deployment Tools"
92reference = "https://attack.mitre.org/techniques/T1072/"
93
94[rule.threat.tactic]
95id = "TA0002"
96name = "Execution"
97reference = "https://attack.mitre.org/tactics/TA0002/"

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 Tool Installation Detected via Defend for Containers

This rule flags interactive package installs inside Linux containers for network utilities or interpreters, a strong signal of hands-on activity to enumerate, fetch payloads, and pivot. Example attacker pattern: after gaining a shell in a pod, they run apt/apk/pacman to add curl, netcat, or socat, pull a second stage from an external host, and open a reverse shell to move from the container into adjacent services.

Possible investigation steps

  • Attribute the interactive install by correlating Kubernetes audit events (exec/attach) and runtime logs to the pod/namespace, a specific user or service account, source IP, and client, and verify alignment with approved break-glass procedures.
  • Diff the running container filesystem against the image baseline or SBOM to enumerate newly added binaries and libraries, review package manager logs/cache, and capture hashes and paths for forensics.
  • Examine pod-level network telemetry and DNS logs around the event for outbound connections, downloads, or reverse shell patterns, and isolate the workload if beaconing or exfiltration is observed.
  • Verify the pod’s security context and mounts for privilege escalation vectors (privileged, hostPID/IPC, hostPaths, docker.sock) and inventory exposed credentials (service account tokens, cloud metadata, env vars, ~/.ssh, .aws), rotating any secrets at risk.
  • Hunt across the cluster for similar interactive installs or exec sessions using audit and Defend for Containers telemetry, and review recent image builds and deployments to detect in-cluster modifications before quarantining or restarting affected workloads.

False positive analysis

  • A developer attaches an interactive shell to a running container to debug connectivity, using apt or apk to install curl or netcat for quick tests, which matches the rule’s interactive install of network utilities.
  • During an approved break-glass fix, an operator interactively installs python or openssl with yum or dnf in a minimal container to run a temporary diagnostic script, triggering the same package-install signature.

Response and remediation

  • Immediately isolate the pod/container that performed interactive installs (e.g., apt-get install curl, apk add netcat) by applying a deny-all NetworkPolicy, terminating active kubectl exec/attach sessions, and cordoning the node if the pod is privileged or has hostPath/docker.sock mounts.
  • Stop and delete the compromised workload, snapshot the container filesystem, then redeploy the deployment/statefulset from a trusted image and purge added tools by removing packages and caches (/var/lib/apt, /var/cache/apk, /var/cache/yum) from any retained volumes.
  • Rotate the pod’s service account token and any exposed credentials found in env vars, ~/.ssh, or cloud provider metadata, and invalidate outbound connections established by newly installed binaries like curl, wget, socat, or netcat via egress firewall rules.
  • Restore normal connectivity only after confirming no unauthorized binaries remain by diffing against the image SBOM and checking package history files like /var/log/dpkg.log, /var/log/yum.log, or /etc/apk/world, then validating app readiness/liveness probes.
  • Escalate to incident response if the install included tor/torsocks, openssl used to generate new keys, reverse-shell behavior (e.g., netcat -e or socat TCP:external_ip), or if activity occurred in production without a change request.
  • Enforce immutability and least privilege by rebuilding images without package managers or shells (distroless), enabling read-only root filesystems, disallowing kubectl exec via RBAC, using admission controls to block privileged pods and hostPath/docker.sock mounts, and tightening egress to only approved destinations.

Related rules

to-top