Base64 Decoded Payload Piped to Interpreter

  1[metadata]
  2creation_date = "2025/02/21"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/04/07"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects when a base64 decoded payload is piped to an interpreter on Linux systems. Adversaries may use
 11base64 encoding to obfuscate data and pipe it to an interpreter to execute malicious code. This technique may
 12be used to evade detection by host- or network-based security controls.
 13"""
 14from = "now-9m"
 15index = ["logs-endpoint.events.process*"]
 16language = "eql"
 17license = "Elastic License v2"
 18name = "Base64 Decoded Payload Piped to Interpreter"
 19note = """ ## Triage and analysis
 20
 21> **Disclaimer**:
 22> 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.
 23
 24### Investigating Base64 Decoded Payload Piped to Interpreter
 25
 26Base64 encoding is a method to encode binary data into ASCII text, often used for data obfuscation. Adversaries exploit this by encoding malicious payloads and decoding them on a target system, piping the output to interpreters like bash or python for execution. The detection rule identifies such activities by monitoring for processes that decode Base64 and subsequently execute scripts, indicating potential malicious behavior.
 27
 28### Possible investigation steps
 29
 30- Review the process command line arguments to identify the specific Base64 decoding activity, focusing on the presence of flags like `-d` or `-a` in conjunction with tools such as `base64`, `openssl`, or scripting languages like `python`, `perl`, or `ruby`.
 31- Examine the parent process entity ID and command line to understand the context in which the Base64 decoding was initiated, identifying any potentially suspicious parent processes.
 32- Investigate the subsequent interpreter process that was executed, such as `bash`, `python`, or `ruby`, to determine the nature of the script or command being run, looking for any signs of malicious activity.
 33- Check the timing and sequence of the processes involved to confirm if the Base64 decoding and interpreter execution occurred within the specified maxspan of 3 seconds, indicating a likely automated or scripted action.
 34- Analyze the host ID and any associated user accounts to determine if the activity aligns with expected behavior for that system or user, or if it suggests unauthorized access or compromise.
 35- Correlate the alert with other security events or logs from the same host or user to identify any additional indicators of compromise or related suspicious activities.
 36
 37### False positive analysis
 38
 39- Legitimate administrative scripts may use Base64 encoding to handle data securely. Review the context of the script execution and consider excluding specific scripts or directories from monitoring if they are verified as safe.
 40- Automated backup or data transfer processes might use Base64 encoding for data integrity. Identify these processes and create exceptions for known, trusted applications or scripts.
 41- Development environments often use Base64 encoding for testing purposes. If a development tool or script is frequently triggering alerts, consider excluding the specific development environment or user accounts from this rule.
 42- Security tools or monitoring solutions may use Base64 encoding as part of their normal operations. Verify the source of the alert and exclude known security tools from triggering this rule.
 43- System updates or package installations might involve Base64 operations. Monitor the timing and context of these alerts and exclude specific update processes if they are consistently identified as false positives.
 44
 45### Response and remediation
 46
 47- Isolate the affected system from the network to prevent further execution of potentially malicious code and lateral movement.
 48- Terminate any suspicious processes identified by the detection rule, particularly those involving base64 decoding and piping to interpreters.
 49- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized file modifications or network connections.
 50- Restore the system from a known good backup if malicious activity is confirmed and the integrity of the system is compromised.
 51- Update and patch all software and systems to mitigate vulnerabilities that could be exploited by similar techniques.
 52- Implement enhanced monitoring and logging for base64 decoding activities and interpreter executions to detect similar threats in the future.
 53- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist.
 54"""
 55risk_score = 47
 56rule_id = "5bdad1d5-5001-4a13-ae99-fa8619500f1a"
 57setup = """## Setup
 58
 59This rule requires data coming in from Elastic Defend.
 60
 61### Elastic Defend Integration Setup
 62Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
 63
 64#### Prerequisite Requirements:
 65- Fleet is required for Elastic Defend.
 66- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 67
 68#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 69- Go to the Kibana home page and click "Add integrations".
 70- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 71- Click "Add Elastic Defend".
 72- Configure the integration name and optionally add a description.
 73- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 74- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
 75- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 76- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
 77For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 78- Click "Save and Continue".
 79- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
 80For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 81"""
 82severity = "medium"
 83tags = [
 84    "Domain: Endpoint",
 85    "OS: Linux",
 86    "Use Case: Threat Detection",
 87    "Tactic: Defense Evasion",
 88    "Tactic: Execution",
 89    "Data Source: Elastic Defend",
 90    "Resources: Investigation Guide",
 91]
 92timestamp_override = "event.ingested"
 93type = "eql"
 94query = '''
 95sequence by host.id, process.parent.entity_id with maxspan=3s
 96  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
 97    (process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and process.command_line like~ "*-*d*") or
 98    (process.name == "openssl" and process.args == "enc" and process.args in ("-d", "-base64", "-a")) or
 99    (process.name like "python*" and
100    (process.args == "base64" and process.args in ("-d", "-u", "-t")) or
101    (process.args == "-c" and process.args like "*base64*" and process.command_line like~ "*b64decode*")
102    ) or
103    (process.name like "perl*" and process.command_line like~ "*decode_base64*") or
104    (process.name like "ruby*" and process.args == "-e" and process.command_line like~ "*Base64.decode64*")
105  )]
106 [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name like~ (
107    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "perl*", "ruby*", "lua*", "php*"
108 )]
109'''
110
111[[rule.threat]]
112framework = "MITRE ATT&CK"
113
114  [rule.threat.tactic]
115  name = "Defense Evasion"
116  id = "TA0005"
117  reference = "https://attack.mitre.org/tactics/TA0005/"
118
119    [[rule.threat.technique]]
120    name = "Obfuscated Files or Information"
121    id = "T1027"
122    reference = "https://attack.mitre.org/techniques/T1027/"
123
124    [[rule.threat.technique]]
125    name = "Deobfuscate/Decode Files or Information"
126    id = "T1140"
127    reference = "https://attack.mitre.org/techniques/T1140/"
128
129[[rule.threat]]
130framework = "MITRE ATT&CK"
131
132  [rule.threat.tactic]
133  name = "Execution"
134  id = "TA0002"
135  reference = "https://attack.mitre.org/tactics/TA0002/"
136
137    [[rule.threat.technique]]
138    id = "T1059"
139    name = "Command and Scripting Interpreter"
140    reference = "https://attack.mitre.org/techniques/T1059/"
141
142      [[rule.threat.technique.subtechnique]]
143      name = "Unix Shell"
144      id = "T1059.004"
145      reference = "https://attack.mitre.org/techniques/T1059/004/"
146
147    [[rule.threat.technique]]
148    name = "User Execution"
149    id = "T1204"
150    reference = "https://attack.mitre.org/techniques/T1204/"
151
152      [[rule.threat.technique.subtechnique]]
153      name = "Malicious File"
154      id = "T1204.002"
155      reference = "https://attack.mitre.org/techniques/T1204/002/"