Potential Reverse Shell via UDP

  1[metadata]
  2creation_date = "2023/07/04"
  3integration = ["auditd_manager"]
  4maturity = "production"
  5updated_date = "2025/01/15"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This detection rule identifies suspicious network traffic patterns associated with UDP reverse shell activity. This
 11activity consists of a sample of an execve, socket and connect syscall executed by the same process, where the
 12auditd.data.a0-1 indicate a UDP connection, ending with an egress connection event. An attacker may establish a Linux
 13UDP reverse shell to bypass traditional firewall restrictions and gain remote access to a target system covertly.
 14"""
 15from = "now-9m"
 16index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
 17language = "eql"
 18license = "Elastic License v2"
 19name = "Potential Reverse Shell via UDP"
 20references = [
 21    "https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md",
 22    "https://www.elastic.co/security-labs/primer-on-persistence-mechanisms",
 23    "https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd",
 24]
 25risk_score = 47
 26rule_id = "a5eb21b7-13cc-4b94-9fe2-29bb2914e037"
 27setup = """## Setup
 28
 29This rule requires data coming in from one of the following integrations:
 30- Auditbeat
 31- Auditd Manager
 32
 33### Auditbeat Setup
 34Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.
 35
 36#### The following steps should be executed in order to add the Auditbeat on a Linux System:
 37- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
 38- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
 39- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
 40- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
 41- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
 42
 43### Auditd Manager Integration Setup
 44The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.
 45Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system.
 46
 47#### The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux System:
 48- Go to the Kibana home page and click “Add integrations”.
 49- In the query bar, search for “Auditd Manager” and select the integration to see more details about it.
 50- Click “Add Auditd Manager”.
 51- Configure the integration name and optionally add a description.
 52- Review optional and advanced settings accordingly.
 53- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
 54- Click “Save and Continue”.
 55- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).
 56
 57#### Rule Specific Setup Note
 58Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.
 59However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
 60- For this detection rule no additional audit rules are required to be added to the integration.
 61"""
 62severity = "medium"
 63tags = [
 64    "Data Source: Auditd Manager",
 65    "Domain: Endpoint",
 66    "OS: Linux",
 67    "Use Case: Threat Detection",
 68    "Tactic: Execution",
 69    "Resources: Investigation Guide",
 70]
 71timestamp_override = "event.ingested"
 72type = "eql"
 73
 74query = '''
 75sample by host.id, process.pid, process.parent.pid
 76  [process where host.os.type == "linux" and event.type == "start" and event.action == "executed" and process.name : (
 77    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*",
 78    "ruby", "openssl", "awk", "telnet", "lua*", "socat"
 79    )]
 80  [process where host.os.type == "linux" and auditd.data.syscall == "socket" and process.name : (
 81    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*",
 82    "ruby", "openssl", "awk", "telnet", "lua*", "socat"
 83    ) and auditd.data.a1 == "2"]
 84  [network where host.os.type == "linux" and event.type == "start" and event.action == "connected-to" and
 85   process.name : (
 86    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*",
 87    "ruby", "openssl", "awk", "telnet", "lua*", "socat"
 88    ) and network.direction == "egress" and destination.ip != null and
 89   not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")]
 90'''
 91note = """## Triage and analysis
 92
 93> **Disclaimer**:
 94> 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.
 95
 96### Investigating Potential Reverse Shell via UDP
 97
 98Reverse shells over UDP can be exploited by attackers to bypass firewalls and gain unauthorized access to systems. This technique leverages UDP's connectionless nature, making it harder to detect. Adversaries may use scripting languages or network tools to initiate these connections. The detection rule identifies suspicious processes executing network-related syscalls and egress connections, flagging potential reverse shell activity.
 99
100### Possible investigation steps
101
102- Review the process details such as process.pid, process.parent.pid, and process.name to identify the specific process that triggered the alert and its parent process.
103- Examine the command line arguments and environment variables associated with the suspicious process to understand its intended function and origin.
104- Check the network connection details, including destination.ip and network.direction, to determine the external entity the process attempted to connect to and assess if it is a known malicious IP or domain.
105- Investigate the user account associated with the process to determine if it has been compromised or if there are any signs of unauthorized access.
106- Analyze historical logs for any previous instances of similar process executions or network connections to identify patterns or repeated attempts.
107- Correlate the alert with other security events or alerts from the same host.id to gather additional context and assess the scope of potential compromise.
108
109### False positive analysis
110
111- Legitimate administrative scripts or tools may trigger the rule if they use UDP for valid network operations. Users can create exceptions for specific scripts or processes that are known to perform routine administrative tasks.
112- Automated monitoring or network management tools that use UDP for health checks or status updates might be flagged. Identify these tools and exclude their process names or network patterns from the rule.
113- Development or testing environments where developers frequently use scripting languages or network tools for legitimate purposes can cause false positives. Consider excluding specific host IDs or process names associated with these environments.
114- Custom applications that use UDP for communication, especially if they are developed in-house, may be mistakenly identified. Review these applications and whitelist their process names or network behaviors if they are verified as safe.
115- Network scanning or diagnostic tools that use UDP for troubleshooting can be misinterpreted as malicious. Ensure these tools are recognized and excluded from the detection rule if they are part of regular network maintenance activities.
116
117### Response and remediation
118
119- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
120- Terminate any suspicious processes identified by the detection rule, particularly those associated with known reverse shell tools or scripting languages.
121- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified system files.
122- Review and update firewall rules to block outbound UDP traffic from unauthorized applications or processes, ensuring legitimate traffic is not disrupted.
123- Reset credentials for any accounts accessed from the affected host, especially if they have administrative privileges.
124- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected.
125- Implement enhanced monitoring and logging for similar suspicious activities, focusing on the execution of network-related syscalls and egress connections from scripting languages or network tools."""
126
127
128[[rule.threat]]
129framework = "MITRE ATT&CK"
130[[rule.threat.technique]]
131id = "T1059"
132name = "Command and Scripting Interpreter"
133reference = "https://attack.mitre.org/techniques/T1059/"
134[[rule.threat.technique.subtechnique]]
135id = "T1059.004"
136name = "Unix Shell"
137reference = "https://attack.mitre.org/techniques/T1059/004/"
138
139
140
141[rule.threat.tactic]
142id = "TA0002"
143name = "Execution"
144reference = "https://attack.mitre.org/tactics/TA0002/"
145[[rule.threat]]
146framework = "MITRE ATT&CK"
147[[rule.threat.technique]]
148id = "T1071"
149name = "Application Layer Protocol"
150reference = "https://attack.mitre.org/techniques/T1071/"
151
152
153[rule.threat.tactic]
154id = "TA0011"
155name = "Command and Control"
156reference = "https://attack.mitre.org/tactics/TA0011/"