File Creation and Execution Detected via Defend for Containers

This rule detects when an interactive process creates a file inside of a running container, followed by its execution. This could indicate a potential container breakout attempt, an attacker's attempt to gain unauthorized access to the underlying host, or to evade detection by security controls.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/02/06"
  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 when an interactive process creates a file inside of a running container, followed by its execution.
 13This could indicate a potential container breakout attempt, an attacker's attempt to gain unauthorized access to the
 14underlying host, or to evade detection by security controls.
 15"""
 16from = "now-6m"
 17index = ["logs-cloud_defend.process*", "logs-cloud_defend.file*"]
 18interval = "5m"
 19language = "eql"
 20license = "Elastic License v2"
 21name = "File Creation and Execution Detected via Defend for Containers"
 22note = """## Triage and analysis
 23
 24> **Disclaimer**:
 25> 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.
 26
 27### Investigating File Creation and Execution Detected via Defend for Containers
 28
 29This detects an interactive session inside a running Linux container creating a new file and then executing it moments later, a pattern that often signals hands-on intrusion rather than routine automation. Attackers commonly use an `exec` shell into a pod/container to drop a small script or ELF payload (for reverse shell, credential theft, or host discovery) and run it immediately to establish control or stage a breakout attempt.
 30
 31### Possible investigation steps
 32
 33- Correlate the alert time with container runtime and Kubernetes audit logs to identify who started the interactive session (user/service account), from where (source IP), and via what mechanism (kubectl exec/attach, docker exec).  
 34- Acquire the newly created file from the container filesystem, record hash/size/permissions, and analyze its contents to determine whether it is a script, ELF payload, or staged dropper.  
 35- Reconstruct the execution chain by reviewing the process tree and interactive shell artifacts (TTY, environment, shell history) to understand the operator’s commands before and after running the file.  
 36- Inspect the container’s network activity immediately following execution (DNS lookups, new outbound connections, unusual ports/destinations) to confirm or rule out command-and-control or payload download behavior.  
 37- Validate whether the activity indicates privilege escalation or breakout by checking the node and container for access to sensitive host interfaces (e.g., docker.sock, hostPath mounts, /proc probing) and contain the workload if present.
 38
 39### False positive analysis
 40
 41- A developer or SRE uses an interactive shell in the container to create or modify a script/binary for debugging (e.g., `cat`/heredoc/vim writing to `/tmp` or the app directory) and then immediately runs it to reproduce an issue or validate a fix.  
 42- An operator performs interactive break-glass maintenance by manually writing a short helper script (log collection, configuration validation, one-off remediation) inside the container and executing it right after creation to restore service during an incident.
 43
 44### Response and remediation
 45
 46- Immediately isolate the affected workload by cordoning and draining the node or applying a deny-all network policy to the pod/namespace, then terminate the interactive session and stop the container to prevent further execution.  
 47- Preserve evidence by snapshotting the container filesystem and collecting the created file and any adjacent artifacts (shell history, temp directories, downloaded tools), then compute hashes and submit the file for malware analysis.  
 48- Eradicate by deleting the compromised pod/container and redeploying from a known-good image, rotating any credentials that may have been exposed in the container environment, and blocking the observed outbound destinations if C2 behavior is present.  
 49- Escalate to incident response immediately if the executed file attempts host interaction (e.g., accesses docker.sock, /proc, hostPath mounts) or if you observe new privileged containers, node-level processes, or lateral movement to other pods/namespaces.  
 50- Harden by restricting interactive exec/attach to a small admin group with MFA, enforcing Pod Security/Admission policies to disallow privileged/host mounts, and enabling runtime controls to block execution from writable paths like /tmp and /dev/shm."""
 51risk_score = 47
 52rule_id = "b799720e-40d0-4dd6-9c9c-4f193a6ed643"
 53severity = "medium"
 54tags = [
 55    "Data Source: Elastic Defend for Containers",
 56    "Domain: Container",
 57    "OS: Linux",
 58    "Use Case: Threat Detection",
 59    "Tactic: Execution",
 60    "Tactic: Command and Control",
 61    "Resources: Investigation Guide",
 62]
 63timestamp_override = "event.ingested"
 64type = "eql"
 65query = '''
 66sequence by container.id, user.id with maxspan=3s
 67  [file where host.os.type == "linux" and event.type == "creation" and process.interactive == true and container.id like "?*" and
 68   file.path like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", "/home/*") and
 69   not process.name in ("apt", "apt-get", "dnf", "microdnf", "yum", "zypper", "tdnf", "apk", "pacman", "rpm", "dpkg")] by file.path
 70  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
 71   process.interactive == true and container.id like "?*"] by process.executable
 72'''
 73
 74[[rule.threat]]
 75framework = "MITRE ATT&CK"
 76
 77[rule.threat.tactic]
 78name = "Execution"
 79id = "TA0002"
 80reference = "https://attack.mitre.org/tactics/TA0002/"
 81
 82[[rule.threat.technique]]
 83id = "T1059"
 84name = "Command and Scripting Interpreter"
 85reference = "https://attack.mitre.org/techniques/T1059/"
 86
 87[[rule.threat.technique.subtechnique]]
 88id = "T1059.004"
 89name = "Unix Shell"
 90reference = "https://attack.mitre.org/techniques/T1059/004/"
 91
 92[[rule.threat]]
 93framework = "MITRE ATT&CK"
 94
 95[rule.threat.tactic]
 96name = "Command and Control"
 97id = "TA0011"
 98reference = "https://attack.mitre.org/tactics/TA0011/"
 99
100[[rule.threat.technique]]
101name = "Application Layer Protocol"
102id = "T1071"
103reference = "https://attack.mitre.org/techniques/T1071/"

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 File Creation and Execution Detected via Defend for Containers

This detects an interactive session inside a running Linux container creating a new file and then executing it moments later, a pattern that often signals hands-on intrusion rather than routine automation. Attackers commonly use an exec shell into a pod/container to drop a small script or ELF payload (for reverse shell, credential theft, or host discovery) and run it immediately to establish control or stage a breakout attempt.

Possible investigation steps

  • Correlate the alert time with container runtime and Kubernetes audit logs to identify who started the interactive session (user/service account), from where (source IP), and via what mechanism (kubectl exec/attach, docker exec).
  • Acquire the newly created file from the container filesystem, record hash/size/permissions, and analyze its contents to determine whether it is a script, ELF payload, or staged dropper.
  • Reconstruct the execution chain by reviewing the process tree and interactive shell artifacts (TTY, environment, shell history) to understand the operator’s commands before and after running the file.
  • Inspect the container’s network activity immediately following execution (DNS lookups, new outbound connections, unusual ports/destinations) to confirm or rule out command-and-control or payload download behavior.
  • Validate whether the activity indicates privilege escalation or breakout by checking the node and container for access to sensitive host interfaces (e.g., docker.sock, hostPath mounts, /proc probing) and contain the workload if present.

False positive analysis

  • A developer or SRE uses an interactive shell in the container to create or modify a script/binary for debugging (e.g., cat/heredoc/vim writing to /tmp or the app directory) and then immediately runs it to reproduce an issue or validate a fix.
  • An operator performs interactive break-glass maintenance by manually writing a short helper script (log collection, configuration validation, one-off remediation) inside the container and executing it right after creation to restore service during an incident.

Response and remediation

  • Immediately isolate the affected workload by cordoning and draining the node or applying a deny-all network policy to the pod/namespace, then terminate the interactive session and stop the container to prevent further execution.
  • Preserve evidence by snapshotting the container filesystem and collecting the created file and any adjacent artifacts (shell history, temp directories, downloaded tools), then compute hashes and submit the file for malware analysis.
  • Eradicate by deleting the compromised pod/container and redeploying from a known-good image, rotating any credentials that may have been exposed in the container environment, and blocking the observed outbound destinations if C2 behavior is present.
  • Escalate to incident response immediately if the executed file attempts host interaction (e.g., accesses docker.sock, /proc, hostPath mounts) or if you observe new privileged containers, node-level processes, or lateral movement to other pods/namespaces.
  • Harden by restricting interactive exec/attach to a small admin group with MFA, enforcing Pod Security/Admission policies to disallow privileged/host mounts, and enabling runtime controls to block execution from writable paths like /tmp and /dev/shm.

Related rules

to-top