Curl SOCKS Proxy Detected via Defend for Containers
This rule detects the use of the "curl" command-line tool with SOCKS proxy options. Attackers may use "curl" to establish a SOCKS proxy connection to bypass network restrictions and exfiltrate data or communicate with C2 servers.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/01/22"
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 use of the "curl" command-line tool with SOCKS proxy options. Attackers may use "curl" to establish a
13SOCKS proxy connection to bypass network restrictions and exfiltrate data or communicate with C2 servers.
14"""
15false_positives = [
16 """
17 There is a potential for false positives if SOCKS proxies are used for legitimate purposes, such as debugging or
18 troubleshooting, or if the "curl" command-line tool is used to download files from a known benign source. It is
19 important to investigate any alerts generated by this rule to determine if they are indicative of malicious
20 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 = "Curl SOCKS Proxy 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 Curl SOCKS Proxy Detected via Defend for Containers
35
36This detection flags interactive curl invocations inside Linux containers that use SOCKS proxy options, indicating traffic tunneling to evade egress controls and enable data exfiltration or C2 communications. A common pattern is an operator with shell access launching curl -x socks5h://localhost:1080 or --socks5-hostname via a dynamically created SSH -D port, then fetching payloads, beaconing to external endpoints, or posting stolen data through the proxy.
37
38### Possible investigation steps
39
40- Retrieve the full curl command line to extract the SOCKS proxy host:port, target URLs, and signs of uploads or auth (e.g., -d/--data, -T/--upload-file, -H Authorization), then pivot those IOCs across container and cluster telemetry.
41- If the proxy points to localhost or an internal address, confirm a SOCKS listener in the container or node network namespace and identify the owning process to reveal the tunneling mechanism.
42- Examine the process ancestry and same TTY/session context to attribute the action and spot precursor activity such as ssh -D, chisel, cloudflared, tor, or 3proxy establishing the proxy.
43- Correlate Kubernetes metadata (pod, namespace, service account, node, image) and kube-apiserver audit logs for exec/attach to identify the actor, verify legitimacy, and find similar events in sibling pods or earlier revisions.
44- Review network flows and DNS from this container through the proxy to external destinations to quantify data volume and destination reputation, and check for access to sensitive internal services.
45
46### False positive analysis
47
48- A developer troubleshooting from an interactive shell inside a container runs curl with -x/--proxy socks5 options to validate egress or reach internal endpoints through an approved proxy (e.g., localhost or an internal host), generating a benign match.
49- Shell profiles or container environment configuration automatically route curl through --preproxy/--socks5-hostname to access internal APIs or artifact mirrors during interactive checks, causing expected activity to be flagged.
50"""
51references = ["https://www.trendmicro.com/en_us/research/25/f/tor-enabled-docker-exploit.html"]
52risk_score = 47
53rule_id = "eb958cb3-dead-42b6-94ff-b9de6721fab2"
54severity = "medium"
55tags = [
56 "Data Source: Elastic Defend for Containers",
57 "Domain: Container",
58 "OS: Linux",
59 "Use Case: Threat Detection",
60 "Tactic: Command and Control",
61 "Resources: Investigation Guide",
62]
63timestamp_override = "event.ingested"
64type = "eql"
65query = '''
66process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
67process.name == "curl" and process.args like ("--socks5-hostname", "--proxy", "--preproxy", "socks5*", "-x") and
68process.interactive == true and container.id like "?*"
69'''
70
71[[rule.threat]]
72framework = "MITRE ATT&CK"
73
74[[rule.threat.technique]]
75id = "T1572"
76name = "Protocol Tunneling"
77reference = "https://attack.mitre.org/techniques/T1572/"
78
79[rule.threat.tactic]
80id = "TA0011"
81name = "Command and Control"
82reference = "https://attack.mitre.org/tactics/TA0011/"
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 Curl SOCKS Proxy Detected via Defend for Containers
This detection flags interactive curl invocations inside Linux containers that use SOCKS proxy options, indicating traffic tunneling to evade egress controls and enable data exfiltration or C2 communications. A common pattern is an operator with shell access launching curl -x socks5h://localhost:1080 or --socks5-hostname via a dynamically created SSH -D port, then fetching payloads, beaconing to external endpoints, or posting stolen data through the proxy.
Possible investigation steps
- Retrieve the full curl command line to extract the SOCKS proxy host:port, target URLs, and signs of uploads or auth (e.g., -d/--data, -T/--upload-file, -H Authorization), then pivot those IOCs across container and cluster telemetry.
- If the proxy points to localhost or an internal address, confirm a SOCKS listener in the container or node network namespace and identify the owning process to reveal the tunneling mechanism.
- Examine the process ancestry and same TTY/session context to attribute the action and spot precursor activity such as ssh -D, chisel, cloudflared, tor, or 3proxy establishing the proxy.
- Correlate Kubernetes metadata (pod, namespace, service account, node, image) and kube-apiserver audit logs for exec/attach to identify the actor, verify legitimacy, and find similar events in sibling pods or earlier revisions.
- Review network flows and DNS from this container through the proxy to external destinations to quantify data volume and destination reputation, and check for access to sensitive internal services.
False positive analysis
- A developer troubleshooting from an interactive shell inside a container runs curl with -x/--proxy socks5 options to validate egress or reach internal endpoints through an approved proxy (e.g., localhost or an internal host), generating a benign match.
- Shell profiles or container environment configuration automatically route curl through --preproxy/--socks5-hostname to access internal APIs or artifact mirrors during interactive checks, causing expected activity to be flagged.
References
Related rules
- Suspicious Network Tool Launch Detected via Defend for Containers
- DNS Enumeration Detected via Defend for Containers
- Direct Interactive Kubernetes API Request Detected via Defend for Containers
- Direct Interactive Kubernetes API Request by Common Utilities
- Direct Interactive Kubernetes API Request by Unusual Utilities