DNS Enumeration Detected via Defend for Containers

  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/01/27"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects the execution of DNS enumeration tools inside a container. DNS enumeration tools are used to
 13enumerate the DNS servers and domains of the container, which can be used by an adversary to gain information about
 14the network configuration of the container and the services running inside it.
 15"""
 16false_positives = [
 17    """
 18    There is a potential for false positives if the DNS enumeration tools are used for legitimate purposes,
 19    such as debugging or troubleshooting. It is important to investigate any alerts generated by this rule to determine
 20    if they are indicative of malicious activity or part of legitimate container activity.
 21    """,
 22]
 23from = "now-6m"
 24index = ["logs-cloud_defend.process*"]
 25interval = "5m"
 26language = "eql"
 27license = "Elastic License v2"
 28name = "DNS Enumeration Detected via Defend for Containers"
 29note = """ ## Triage and analysis
 30
 31> **Disclaimer**:
 32> 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.
 33
 34### Investigating DNS Enumeration Detected via Defend for Containers
 35
 36This rule flags interactive use of DNS utilities (nslookup, dig, host, or getent hosts) inside a Linux container that query internal Kubernetes names such as kubernetes.default or *.svc.cluster.local, signaling in-cluster service discovery. After compromising a pod, an attacker opens an interactive shell and runs nslookup kubernetes.default or dig *.svc.cluster.local to enumerate services and namespaces, map reachable endpoints, and stage lateral movement toward the API server, internal dashboards, or other pods.
 37
 38### Possible investigation steps
 39
 40- Correlate with Kubernetes audit logs to see if a kubectl exec/attach or ephemeral container was launched into this pod at the same time and identify the requesting user, source IP, and service account identity.
 41- Pull pod metadata (namespace, owner workload, node, image digest, service account) and verify whether this is a sanctioned troubleshooting/debug context by checking image baseline and change tickets.
 42- Examine command history and process lineage within the container around the alert to spot follow‑on actions such as reading /var/run/secrets/kubernetes.io/serviceaccount, querying the API server, installing tools, or scanning internal ranges.
 43- Review DNS and network telemetry from the pod (CoreDNS logs, CNI flow logs) to map the queried hostnames and any subsequent connections to internal services or the API server.
 44- If unauthorized activity is suspected, isolate the pod via network policy or eviction, rotate the pod’s service account token and related secrets, and redeploy from a trusted image while investigating node and registry access paths.
 45
 46### False positive analysis
 47
 48- An authorized operator attaches an interactive shell to a pod for in-cluster troubleshooting and runs nslookup/dig/host or getent hosts against kubernetes.default or *.svc.cluster.local, matching the rule but expected.
 49- A pod or initContainer configured with tty: true or stdin enabled executes startup/readiness logic that calls getent hosts or nslookup on internal service FQDNs (*.svc.cluster.local), which is benign but appears as interactive enumeration.
 50
 51### Response and remediation
 52
 53- Immediately isolate the affected pod by applying a deny‑egress NetworkPolicy to the CoreDNS service and cluster service CIDRs, terminate the interactive shell that ran nslookup/dig/host or getent hosts, and temporarily block kubectl exec/attach to the workload.
 54- Evict the pod and redeploy from a trusted image digest, removing any ephemeral containers added for debugging and uninstalling ad‑hoc packages (e.g., dnsutils, busybox) that were introduced into the container.
 55- Rotate credentials by deleting and reissuing the workload’s service account token and any mounted secrets or registry credentials, then verify the new pod does not perform interactive lookups of kubernetes.default or *.svc.cluster.local.
 56- Escalate to incident response if enumeration originates from a production namespace, a privileged service account, or is followed by reading /var/run/secrets/kubernetes.io/serviceaccount or curl/wget to https://kubernetes.default, or if similar activity is observed across multiple pods.
 57- Harden going forward by restricting exec/attach via RBAC, enforcing Admission Controls/Pod Security to disallow tty/stdin and unauthorized ephemeral containers, limiting egress to CoreDNS and internal services with NetworkPolicies, and using distroless/stripped images that omit nslookup/dig/host.
 58"""
 59risk_score = 21
 60rule_id = "74ee9a2d-5ed3-40c8-9e6c-523d2e6a17ef"
 61severity = "low"
 62tags = [
 63    "Data Source: Elastic Defend for Containers",
 64    "Domain: Container",
 65    "OS: Linux",
 66    "Use Case: Threat Detection",
 67    "Tactic: Discovery",
 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
 74process.interactive == true and container.id like "*" and 
 75(
 76  /* getent hosts is often used without a target arg */
 77  (process.name == "getent" and process.args == "hosts") or
 78
 79  /* explicit DNS query tools */
 80  (
 81    process.name in ("nslookup", "dig", "host") or
 82    (
 83      /* Account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg */
 84      process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
 85      process.args in (
 86        "nslookup", "/bin/nslookup", "/usr/bin/nslookup", "/usr/local/bin/nslookup",
 87        "dig", "/bin/dig", "/usr/bin/dig", "/usr/local/bin/dig",
 88        "host", "/bin/host", "/usr/bin/host", "/usr/local/bin/host"
 89      ) and
 90      /* default exclusion list to not FP on default multi-process commands */
 91      not process.args in (
 92        "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
 93        "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
 94        "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
 95        "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
 96      )
 97    )
 98  ) and
 99  process.args like~ (
100    "kubernetes.default",
101    "kubernetes",
102    "*.svc",
103    "*.svc.cluster.local",
104    "*.cluster.local"
105  )
106)
107'''
108
109[[rule.threat]]
110framework = "MITRE ATT&CK"
111
112[[rule.threat.technique]]
113id = "T1018"
114name = "Remote System Discovery"
115reference = "https://attack.mitre.org/techniques/T1018/"
116
117[[rule.threat.technique]]
118id = "T1613"
119name = "Container and Resource Discovery"
120reference = "https://attack.mitre.org/techniques/T1613/"
121
122[[rule.threat.technique]]
123id = "T1016"
124name = "System Network Configuration Discovery"
125reference = "https://attack.mitre.org/techniques/T1016/"
126
127[[rule.threat.technique]]
128id = "T1049"
129name = "System Network Connections Discovery"
130reference = "https://attack.mitre.org/techniques/T1049/"
131
132[rule.threat.tactic]
133id = "TA0007"
134name = "Discovery"
135reference = "https://attack.mitre.org/tactics/TA0007/"