Curl or Wget Execution from Container Context

  1[metadata]
  2creation_date = "2026/04/22"
  3integration = ["auditd_manager"]
  4maturity = "production"
  5updated_date = "2026/04/22"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects execution of curl or wget from processes whose title aligns with **`runc init`**, a common fingerprint 
 11for workloads running inside **OCI/runc-backed containers** on Linux hosts instrumented with Auditd Manager. 
 12After breaking out of an application container or abusing a privileged workload, attackers often pull ingress tooling
 13(stagers, scripts, implants) or stage exfiltration with minimal HTTP clients. Those utilities are also used
 14benignly in images, so context matters; the `runc init` anchor narrows the signal to the container runtime boundary
 15where unexpected download clients are more worthy of review than the same binaries on a bare-metal admin shell.
 16"""
 17false_positives = [
 18    """
 19    Base images, entrypoints, or init wrappers may legitimately invoke curl or wget during container startup (package
 20    installs, health checks); baseline trusted images and exclude stable image digests or namespaces when noisy.
 21    """,
 22    """
 23    Developer-oriented containers and CI build pods can run curl/wget from PID 1 descendants under runc; correlate with
 24    build pipelines and approved registries.
 25    """,
 26]
 27from = "now-9m"
 28index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
 29language = "kuery"
 30license = "Elastic License v2"
 31name = "Curl or Wget Execution from Container Context"
 32note = """## Triage and analysis
 33
 34### Investigating Curl or Wget Execution from Container Context
 35
 36The rule matches Auditd-backed process events where `process.title` is `runc init` and the executed program is
 37curl/wget (by `process.name`) or the argument vector suggests curl or wget paths. Use it to spot ingress tool 
 38transfer or scripted downloads from inside a container as seen at the host audit layer.
 39
 40### Possible investigation steps
 41
 42- Reconstruct the full command line from `process.args` / `process.command_line` and identify URLs, output paths, and
 43  flags such as `-O`, `--post-file`, or TLS bypass (`-k`).
 44- Map the event to the container: cgroup, `container.id`, `kubernetes.pod.*`, or runtime metadata if present on the
 45  document; identify the image, namespace, and workload owner.
 46- Review egress from the host or pod network policy logs for destinations contacted shortly after the execution.
 47- Compare against recent image or manifest changes for the workload to rule out intentional startup scripts.
 48
 49### False positive analysis
 50
 51- Package managers and bootstrap scripts in official images may run curl/wget once at start; document and exclude when
 52  verified.
 53- Security scanners or health checks running in sidecars could match; validate agent type and schedule.
 54
 55### Response and remediation
 56
 57- If unauthorized, isolate the node or workload, revoke credentials available to the container, inspect for dropped
 58  binaries or cron/systemd additions, and rotate any secrets the container could reach.
 59"""
 60references = [
 61    "https://attack.mitre.org/techniques/T1105/",
 62    "https://gtfobins.github.io/gtfobins/curl/",
 63    "https://gtfobins.github.io/gtfobins/wget/",
 64]
 65risk_score = 47
 66rule_id = "e7b2c3d4-5a6b-4e8f-9c0d-1a2b3e4f5a6b"
 67setup = """## Setup
 68
 69This rule requires data from **Auditd Manager** (or legacy Auditbeat shipping comparable ECS fields).
 70
 71### Auditd Manager Integration Setup
 72The Auditd Manager integration receives audit events from the Linux Audit Framework. With `auditd_manager`,
 73administrators can define audit rules, track system events, and generate reports.
 74
 75#### Steps to deploy Auditd Manager
 76- In Kibana, open **Add integrations**, search for **Auditd Manager**, and add it to an agent policy deployed on Linux
 77  hosts that should emit syscall audit data.
 78- For integration details, see the [Auditd Manager documentation](https://docs.elastic.co/integrations/auditd_manager).
 79
 80#### Rule-specific notes
 81- Ensure syscall coverage includes **execve** (or equivalent) for processes inside containers so `curl`, `wget`, and
 82  argument lists are captured on the host.
 83- Confirm that **`process.title`** (or the mapped proctitle field) reflects **`runc init`** for your runtime; other
 84  runtimes may use different titles—tune the predicate if you standardize on `crun`, `containerd-shim`, etc.
 85"""
 86severity = "medium"
 87tags = [
 88    "Domain: Endpoint",
 89    "OS: Linux",
 90    "Use Case: Threat Detection",
 91    "Tactic: Command and Control",
 92    "Tactic: Execution",
 93    "Domain: Containers",
 94    "Data Source: Auditd Manager",
 95    "Resources: Investigation Guide",
 96]
 97timestamp_override = "event.ingested"
 98type = "query"
 99query = '''
100host.os.type:linux and 
101data_stream.dataset:"auditd_manager.auditd" and
102event.action:("executed" or "exec") and
103process.title:"runc init" and
104(
105  process.name:(curl or wget) or
106  process.args:(* curl* or */bin/curl* or *wget*)
107)
108'''
109
110[[rule.threat]]
111framework = "MITRE ATT&CK"
112
113[[rule.threat.technique]]
114id = "T1105"
115name = "Ingress Tool Transfer"
116reference = "https://attack.mitre.org/techniques/T1105/"
117
118[rule.threat.tactic]
119id = "TA0011"
120name = "Command and Control"
121reference = "https://attack.mitre.org/tactics/TA0011/"