Tunneling and/or Port Forwarding Detected via Defend for Containers

  1[metadata]
  2creation_date = "2026/02/10"
  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/10"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects the use of tunneling and/or port forwarding tools inside a container. This
 13could indicate a threat actor is using these tools to communicate with a C2 server, is attempting
 14to exfiltrate data from the container, or is attempting to pivot within the container network.
 15"""
 16from = "now-6m"
 17index = ["logs-cloud_defend.process*"]
 18interval = "5m"
 19language = "eql"
 20license = "Elastic License v2"
 21name = "Tunneling and/or Port Forwarding 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 Tunneling and/or Port Forwarding Detected via Defend for Containers
 28
 29This detects tunneling or port-forwarding tools launched inside Linux containers, which attackers use to create hidden pathways for command-and-control, data theft, or lateral movement across the container network. A common pattern is running SSH with local/remote/dynamic forwarding or tools like chisel/socat to expose an internal service (e.g., database or kube API) through an external relay, bypassing normal network controls and segmentation.
 30
 31### Possible investigation steps
 32
 33- Identify the owning workload (pod/deployment/cronjob), image tag, and recent rollout or configuration changes to determine whether the tunnel/forwarding behavior is expected for that service.  
 34- Review the full executed command line, environment variables, and process ancestry to confirm what local/remote addresses and ports are being bridged and whether execution originated from an interactive session or startup script.  
 35- Enumerate active listeners and established connections from the container/node at the time of the alert to find externally reachable forwards, unexpected egress destinations, and any traffic to known C2 or relay infrastructure.  
 36- Correlate container network telemetry with DNS queries and outbound proxy usage to detect protocol tunneling patterns (e.g., long-lived sessions, high-entropy subdomains, unusual ports) and identify the initial ingress path.  
 37- Check for follow-on actions in the container and cluster (new binaries dropped, modified entrypoints, created secrets/serviceaccounts, or lateral access attempts) that would indicate persistence or pivoting beyond simple debugging.
 38
 39### False positive analysis
 40
 41- A developer or SRE launches `ssh` with `-L`/`-R`/`-D` options from inside a container during troubleshooting to temporarily reach an internal service (e.g., database or API) from their workstation through the container network.  
 42- A containerized service legitimately embeds proxying/forwarding behavior (e.g., `socat`, `3proxy`, `frps`, or `proxychains`) to expose or bridge ports as part of its normal runtime configuration, causing expected long-lived listeners and relayed connections that match tunnel/forwarding patterns.
 43
 44### Response and remediation
 45
 46- Isolate the affected pod/container by scaling the workload to zero or cordoning/quarantining the node and applying a deny-all egress policy to stop the active tunnel/forward while preserving artifacts for collection.  
 47- Terminate the tunneling process (e.g., ssh with -L/-R/-D, socat TCP4-LISTEN, chisel client/server, ngrok) and remove any dropped binaries or modified entrypoints/startup scripts that re-launch the forwarder.  
 48- Capture and review the running command line, parent process chain, active listeners, and established connections to identify exposed internal services and block the destination IPs/domains/ports used by the tunnel at the network edge and cluster egress controls.  
 49- Rotate potentially exposed credentials (Kubernetes service account tokens, cloud/API keys, database passwords) and validate RBAC/service account usage for unauthorized access originating from the affected workload.  
 50- Rebuild and redeploy from a known-good image, pin image digests, and add admission controls to block images containing tunneling utilities or starting processes with port-forwarding arguments unless explicitly approved.  
 51- Escalate to incident response immediately if the tunnel connects to external infrastructure, forwards access to sensitive services (e.g., kube-apiserver, etcd, databases), or similar tunneling behavior appears in multiple pods/namespaces."""
 52references = [
 53    "https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware",
 54]
 55risk_score = 47
 56rule_id = "9d94d61b-9476-41ff-a8d3-3d24b4bb8158"
 57severity = "medium"
 58tags = [
 59    "Data Source: Elastic Defend for Containers",
 60    "Domain: Container",
 61    "OS: Linux",
 62    "Use Case: Threat Detection",
 63    "Tactic: Command and Control",
 64    "Resources: Investigation Guide",
 65]
 66timestamp_override = "event.ingested"
 67type = "eql"
 68query = '''
 69process where event.type == "start" and event.action == "exec" and (
 70  (
 71    // Tunneling and/or Port Forwarding via process args
 72    (process.args regex """.*[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{1,5}:[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{1,5}.*""") or
 73    // gost
 74    (process.name == "gost" and process.args : ("-L*", "-C*", "-R*")) or
 75    // ssh
 76    (process.name == "ssh" and (process.args like ("-*R*", "-*L*", "-*D*", "-*w*") and 
 77     not (process.args == "chmod" or process.args like "*rungencmd*"))) or
 78    // ssh Tunneling and/or Port Forwarding via SSH option
 79    (process.name == "ssh" and process.args == "-o" and process.args like~(
 80      "*ProxyCommand*", "*LocalForward*", "*RemoteForward*", "*DynamicForward*", "*Tunnel*", "*GatewayPorts*", "*ExitOnForwardFailure*", "*ProxyCommand*", "*ProxyJump*"
 81    )) or
 82    // sshuttle
 83    (process.name == "sshuttle" and process.args in ("-r", "--remote", "-l", "--listen")) or
 84    // earthworm
 85    (process.args == "-s" and process.args == "-d" and process.args == "rssocks") or
 86    // socat
 87    (process.name == "socat" and process.args : ("TCP4-LISTEN:*", "SOCKS*")) or
 88    // chisel
 89    (process.name : "chisel*" and process.args in ("client", "server")) or
 90    // iodine(d), dnscat, hans, ptunnel-ng, ssf, 3proxy & ngrok 
 91    (process.name in ("iodine", "iodined", "dnscat", "hans", "hans-ubuntu", "ptunnel-ng", "ssf", "3proxy", "ngrok", "wstunnel", "pivotnacci", "frps", "proxychains"))
 92  )
 93) and container.id like "?*"
 94'''
 95
 96[[rule.threat]]
 97framework = "MITRE ATT&CK"
 98
 99[[rule.threat.technique]]
100id = "T1572"
101name = "Protocol Tunneling"
102reference = "https://attack.mitre.org/techniques/T1572/"
103
104[rule.threat.tactic]
105id = "TA0011"
106name = "Command and Control"
107reference = "https://attack.mitre.org/tactics/TA0011/"