Unix Socket Connection

This rule monitors for inter-process communication via Unix sockets. Adversaries may attempt to communicate with local Unix sockets to enumerate application details, find vulnerabilities/configuration mistakes and potentially escalate privileges or set up malicious communication channels via Unix sockets for inter-process communication to attempt to evade detection.

Elastic rule (View on GitHub)

 1[metadata]
 2creation_date = "2023/09/04"
 3integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 4maturity = "production"
 5min_stack_version = "8.13.0"
 6min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 7updated_date = "2025/01/15"
 8
 9[rule]
10author = ["Elastic"]
11description = """
12This rule monitors for inter-process communication via Unix sockets. Adversaries may attempt to communicate with local
13Unix sockets to enumerate application details, find vulnerabilities/configuration mistakes and potentially escalate
14privileges or set up malicious communication channels via Unix sockets for inter-process communication to attempt to
15evade detection.
16"""
17from = "now-9m"
18index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
19language = "eql"
20license = "Elastic License v2"
21name = "Unix Socket Connection"
22risk_score = 21
23rule_id = "41284ba3-ed1a-4598-bfba-a97f75d9aba2"
24severity = "low"
25tags = [
26    "Domain: Endpoint",
27    "OS: Linux",
28    "Use Case: Threat Detection",
29    "Tactic: Execution",
30    "Data Source: Elastic Defend",
31    "Data Source: Elastic Endgame",
32    "Data Source: Auditd Manager",
33    "Data Source: Crowdstrike",
34    "Data Source: SentinelOne",
35    "Resources: Investigation Guide",
36]
37timestamp_override = "event.ingested"
38type = "eql"
39query = '''
40process where host.os.type == "linux" and event.type == "start" and
41 event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
42 (
43  (process.name in ("nc", "ncat", "netcat", "nc.openbsd") and
44   process.args == "-U" and process.args : ("/usr/local/*", "/run/*", "/var/run/*")) or
45  (process.name == "socat" and
46   process.args == "-" and process.args : ("UNIX-CLIENT:/usr/local/*", "UNIX-CLIENT:/run/*", "UNIX-CLIENT:/var/run/*"))
47) and
48not process.args == "/var/run/libvirt/libvirt-sock"
49'''
50note = """## Triage and analysis
51
52> **Disclaimer**:
53> 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.
54
55### Investigating Unix Socket Connection
56
57Unix sockets facilitate efficient inter-process communication (IPC) on the same host, crucial for system operations. However, adversaries can exploit them to probe applications, identify weaknesses, or establish covert channels. The detection rule identifies suspicious use of tools like netcat and socat with specific arguments, signaling potential misuse of Unix sockets for unauthorized communication or privilege escalation attempts.
58
59### Possible investigation steps
60
61- Review the process details to confirm the execution of netcat or socat with the specified arguments, focusing on the process name and arguments fields to verify the suspicious activity.
62- Investigate the source and destination of the Unix socket connection by examining the process.args field to determine if the connection is legitimate or potentially malicious.
63- Check the user context under which the process was executed to assess if there is any indication of privilege escalation attempts.
64- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities that might indicate a broader attack.
65- Examine the process lineage to understand the parent process and any child processes spawned, which might provide insights into how the suspicious process was initiated.
66- Verify if the process is part of any known legitimate application or service by cross-referencing with system documentation or application inventories.
67
68### False positive analysis
69
70- Legitimate administrative tasks using netcat or socat for system maintenance or monitoring can trigger alerts. To manage this, identify and whitelist specific scripts or commands used regularly by system administrators.
71- Automated backup or monitoring tools that use Unix sockets for communication may be flagged. Review these tools and add them to an exception list if they are verified as safe and necessary for operations.
72- Certain applications may use Unix sockets for legitimate inter-process communication, such as database services or web servers. Monitor these applications and exclude their typical behavior from the rule to prevent unnecessary alerts.
73- Development environments where developers frequently use netcat or socat for testing purposes can generate false positives. Establish a policy to differentiate between development and production environments and apply exceptions accordingly.
74- System services like libvirt, which are known to use Unix sockets, should be excluded from the rule as indicated by the exception for /var/run/libvirt/libvirt-sock. Regularly update this list to include other known benign services.
75
76### Response and remediation
77
78- Immediately isolate the affected host from the network to prevent potential lateral movement or data exfiltration.
79- Terminate any suspicious processes identified by the detection rule, specifically those involving netcat or socat with the flagged arguments.
80- Conduct a thorough review of the affected system's logs to identify any unauthorized access or data manipulation that may have occurred.
81- Reset credentials and review permissions for any accounts that may have been compromised or used in the attack.
82- Apply patches or configuration changes to address any vulnerabilities or misconfigurations identified during the investigation.
83- Monitor the affected system and network for any signs of recurring suspicious activity, focusing on Unix socket connections.
84- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected."""
85
86[[rule.threat]]
87framework = "MITRE ATT&CK"
88
89[[rule.threat.technique]]
90id = "T1559"
91name = "Inter-Process Communication"
92reference = "https://attack.mitre.org/techniques/T1559/"
93
94[rule.threat.tactic]
95id = "TA0002"
96name = "Execution"
97reference = "https://attack.mitre.org/tactics/TA0002/"

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 Unix Socket Connection

Unix sockets facilitate efficient inter-process communication (IPC) on the same host, crucial for system operations. However, adversaries can exploit them to probe applications, identify weaknesses, or establish covert channels. The detection rule identifies suspicious use of tools like netcat and socat with specific arguments, signaling potential misuse of Unix sockets for unauthorized communication or privilege escalation attempts.

Possible investigation steps

  • Review the process details to confirm the execution of netcat or socat with the specified arguments, focusing on the process name and arguments fields to verify the suspicious activity.
  • Investigate the source and destination of the Unix socket connection by examining the process.args field to determine if the connection is legitimate or potentially malicious.
  • Check the user context under which the process was executed to assess if there is any indication of privilege escalation attempts.
  • Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities that might indicate a broader attack.
  • Examine the process lineage to understand the parent process and any child processes spawned, which might provide insights into how the suspicious process was initiated.
  • Verify if the process is part of any known legitimate application or service by cross-referencing with system documentation or application inventories.

False positive analysis

  • Legitimate administrative tasks using netcat or socat for system maintenance or monitoring can trigger alerts. To manage this, identify and whitelist specific scripts or commands used regularly by system administrators.
  • Automated backup or monitoring tools that use Unix sockets for communication may be flagged. Review these tools and add them to an exception list if they are verified as safe and necessary for operations.
  • Certain applications may use Unix sockets for legitimate inter-process communication, such as database services or web servers. Monitor these applications and exclude their typical behavior from the rule to prevent unnecessary alerts.
  • Development environments where developers frequently use netcat or socat for testing purposes can generate false positives. Establish a policy to differentiate between development and production environments and apply exceptions accordingly.
  • System services like libvirt, which are known to use Unix sockets, should be excluded from the rule as indicated by the exception for /var/run/libvirt/libvirt-sock. Regularly update this list to include other known benign services.

Response and remediation

  • Immediately isolate the affected host from the network to prevent potential lateral movement or data exfiltration.
  • Terminate any suspicious processes identified by the detection rule, specifically those involving netcat or socat with the flagged arguments.
  • Conduct a thorough review of the affected system's logs to identify any unauthorized access or data manipulation that may have occurred.
  • Reset credentials and review permissions for any accounts that may have been compromised or used in the attack.
  • Apply patches or configuration changes to address any vulnerabilities or misconfigurations identified during the investigation.
  • Monitor the affected system and network for any signs of recurring suspicious activity, focusing on Unix socket connections.
  • Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.

Related rules

to-top