Multi-Base64 Decoding Attempt from Suspicious Location

This rule detects the execution of multiple base64 decoding commands to decode data. multi-decoded data is suspicious, and may be used by attackers to obfuscate malicious payloads or commands.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/07/24"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/09/01"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects the execution of multiple base64 decoding commands to decode data. multi-decoded
 11data is suspicious, and may be used by attackers to obfuscate malicious payloads or commands.
 12"""
 13from = "now-9m"
 14index = ["logs-endpoint.events.process*"]
 15language = "eql"
 16license = "Elastic License v2"
 17name = "Multi-Base64 Decoding Attempt from Suspicious Location"
 18note = """## Triage and analysis
 19
 20> **Disclaimer**:
 21> 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.
 22
 23### Investigating Multi-Base64 Decoding Attempt from Suspicious Location
 24
 25Base64 encoding is a common method to encode binary data into ASCII text, often used for data transmission. Adversaries exploit this by encoding malicious payloads to evade detection. The detection rule identifies suspicious decoding activities, especially from unusual directories, by monitoring rapid sequences of decoding commands. It excludes benign processes to reduce false positives, focusing on potential threats in Linux environments.
 26
 27### Possible investigation steps
 28
 29- Review the process details, including the parent entity ID and executable path, to understand the context of the decoding activity and identify the parent process responsible for initiating the base64 commands.
 30- Examine the working directory where the decoding occurred, focusing on suspicious locations such as "/tmp/*", "/var/tmp*", "/dev/shm/*", "/var/www/*", "/home/*", and "/root/*" to determine if the activity aligns with typical usage patterns or if it indicates potential malicious behavior.
 31- Analyze the command-line arguments used in the decoding process, specifically looking for "-d*" or "--d*" flags, to assess whether the decoding was intended to obfuscate data or execute hidden payloads.
 32- Investigate the sequence of events within the 3-second maxspan to identify any rapid or automated decoding attempts that could suggest scripted or malicious activity.
 33- Check for any exclusions in the rule, such as known benign processes or directories, to ensure the alert is not a false positive and the activity is genuinely suspicious.
 34- Correlate the alert with other security events or logs from the same host or network segment to gather additional context and determine if this is part of a larger attack or isolated incident.
 35
 36### False positive analysis
 37
 38- Scheduled tasks or cron jobs may trigger base64 decoding in benign processes. Exclude known executables like "/etc/cron.daily/vivaldi" and "/etc/cron.daily/opera-browser" to reduce false positives.
 39- System management tools or agents, such as those located in "/opt/microsoft/omsagent/plugin" or "/opt/rapid7/ir_agent/*", might use base64 decoding for legitimate purposes. Add these directories to the exclusion list to prevent unnecessary alerts.
 40- Temporary directories like "/tmp/newroot/*" may be used by legitimate applications for transient data processing. Consider excluding these paths if they are frequently involved in non-malicious activities.
 41- User scripts or applications in home directories may use base64 for encoding or decoding data. Monitor and whitelist specific user processes that are known to be safe to avoid false positives.
 42- Regularly review and update the exclusion list based on observed benign activities to ensure the rule remains effective without generating excessive false alerts.
 43
 44### Response and remediation
 45
 46- Immediately isolate the affected system to prevent further execution of potentially malicious payloads. Disconnect the system from the network to contain the threat.
 47
 48- Review and terminate any suspicious processes identified by the detection rule, particularly those involving base64 decoding from unusual directories. Use process management tools to kill these processes.
 49
 50- Conduct a thorough examination of the directories flagged by the alert (e.g., /tmp, /var/tmp, /dev/shm) to identify and remove any malicious files or scripts. Ensure these directories are cleaned of unauthorized or suspicious content.
 51
 52- Restore the system from a known good backup if any malicious activity is confirmed, ensuring that the backup is free from compromise.
 53
 54- Escalate the incident to the security operations team for further investigation and analysis. Provide them with logs and details of the processes and directories involved for deeper threat assessment.
 55
 56- Implement additional monitoring and alerting for similar suspicious activities, focusing on rapid sequences of base64 decoding commands and unusual directory usage to enhance detection capabilities.
 57
 58- Review and update access controls and permissions for the directories involved to prevent unauthorized access and execution of potentially harmful scripts or binaries.
 59"""
 60risk_score = 21
 61rule_id = "03d856c2-7f74-4540-a530-e20af5e39789"
 62setup = """## Setup
 63
 64This rule requires data coming in from Elastic Defend.
 65
 66### Elastic Defend Integration Setup
 67Elastic 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.
 68
 69#### Prerequisite Requirements:
 70- Fleet is required for Elastic Defend.
 71- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 72
 73#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 74- Go to the Kibana home page and click "Add integrations".
 75- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 76- Click "Add Elastic Defend".
 77- Configure the integration name and optionally add a description.
 78- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 79- 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).
 80- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 81- 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.
 82For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 83- Click "Save and Continue".
 84- 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.
 85For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 86"""
 87severity = "low"
 88tags = [
 89    "Domain: Endpoint",
 90    "OS: Linux",
 91    "Use Case: Threat Detection",
 92    "Tactic: Defense Evasion",
 93    "Tactic: Execution",
 94    "Data Source: Elastic Defend",
 95    "Resources: Investigation Guide"
 96]
 97type = "eql"
 98query = '''
 99sequence by process.parent.entity_id with maxspan=3s
100  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.executable != null and
101   process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and
102   // Only including potentially suspicious locations
103   process.args like~ ("-d*", "--d*") and process.working_directory like (
104     "/tmp/*", "/var/tmp*", "/dev/shm/*", "/var/www/*", "/home/*", "/root/*"
105   ) and not (
106     process.parent.executable in (
107       "/usr/share/ec2-instance-connect/eic_curl_authorized_keys", "/etc/cron.daily/vivaldi",
108       "/etc/cron.daily/opera-browser"
109     ) or
110     process.working_directory like (
111       "/opt/microsoft/omsagent/plugin", "/opt/rapid7/ir_agent/*", "/tmp/newroot/*"
112      )
113   )]
114  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.executable != null and
115   process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and
116   process.args like~ ("-d*", "--d*")]
117'''
118
119[[rule.threat]]
120framework = "MITRE ATT&CK"
121
122  [rule.threat.tactic]
123  name = "Defense Evasion"
124  id = "TA0005"
125  reference = "https://attack.mitre.org/tactics/TA0005/"
126
127    [[rule.threat.technique]]
128    name = "Obfuscated Files or Information"
129    id = "T1027"
130    reference = "https://attack.mitre.org/techniques/T1027/"
131
132    [[rule.threat.technique]]
133    name = "Deobfuscate/Decode Files or Information"
134    id = "T1140"
135    reference = "https://attack.mitre.org/techniques/T1140/"
136
137[[rule.threat]]
138framework = "MITRE ATT&CK"
139
140  [rule.threat.tactic]
141  name = "Execution"
142  id = "TA0002"
143  reference = "https://attack.mitre.org/tactics/TA0002/"
144
145    [[rule.threat.technique]]
146    id = "T1059"
147    name = "Command and Scripting Interpreter"
148    reference = "https://attack.mitre.org/techniques/T1059/"
149
150      [[rule.threat.technique.subtechnique]]
151      name = "Unix Shell"
152      id = "T1059.004"
153      reference = "https://attack.mitre.org/techniques/T1059/004/"
154
155    [[rule.threat.technique]]
156    name = "User Execution"
157    id = "T1204"
158    reference = "https://attack.mitre.org/techniques/T1204/"
159
160      [[rule.threat.technique.subtechnique]]
161      name = "Malicious File"
162      id = "T1204.002"
163      reference = "https://attack.mitre.org/techniques/T1204/002/"```

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 Multi-Base64 Decoding Attempt from Suspicious Location

Base64 encoding is a common method to encode binary data into ASCII text, often used for data transmission. Adversaries exploit this by encoding malicious payloads to evade detection. The detection rule identifies suspicious decoding activities, especially from unusual directories, by monitoring rapid sequences of decoding commands. It excludes benign processes to reduce false positives, focusing on potential threats in Linux environments.

Possible investigation steps

  • Review the process details, including the parent entity ID and executable path, to understand the context of the decoding activity and identify the parent process responsible for initiating the base64 commands.
  • Examine the working directory where the decoding occurred, focusing on suspicious locations such as "/tmp/", "/var/tmp", "/dev/shm/", "/var/www/", "/home/", and "/root/" to determine if the activity aligns with typical usage patterns or if it indicates potential malicious behavior.
  • Analyze the command-line arguments used in the decoding process, specifically looking for "-d*" or "--d*" flags, to assess whether the decoding was intended to obfuscate data or execute hidden payloads.
  • Investigate the sequence of events within the 3-second maxspan to identify any rapid or automated decoding attempts that could suggest scripted or malicious activity.
  • Check for any exclusions in the rule, such as known benign processes or directories, to ensure the alert is not a false positive and the activity is genuinely suspicious.
  • Correlate the alert with other security events or logs from the same host or network segment to gather additional context and determine if this is part of a larger attack or isolated incident.

False positive analysis

  • Scheduled tasks or cron jobs may trigger base64 decoding in benign processes. Exclude known executables like "/etc/cron.daily/vivaldi" and "/etc/cron.daily/opera-browser" to reduce false positives.
  • System management tools or agents, such as those located in "/opt/microsoft/omsagent/plugin" or "/opt/rapid7/ir_agent/*", might use base64 decoding for legitimate purposes. Add these directories to the exclusion list to prevent unnecessary alerts.
  • Temporary directories like "/tmp/newroot/*" may be used by legitimate applications for transient data processing. Consider excluding these paths if they are frequently involved in non-malicious activities.
  • User scripts or applications in home directories may use base64 for encoding or decoding data. Monitor and whitelist specific user processes that are known to be safe to avoid false positives.
  • Regularly review and update the exclusion list based on observed benign activities to ensure the rule remains effective without generating excessive false alerts.

Response and remediation

  • Immediately isolate the affected system to prevent further execution of potentially malicious payloads. Disconnect the system from the network to contain the threat.

  • Review and terminate any suspicious processes identified by the detection rule, particularly those involving base64 decoding from unusual directories. Use process management tools to kill these processes.

  • Conduct a thorough examination of the directories flagged by the alert (e.g., /tmp, /var/tmp, /dev/shm) to identify and remove any malicious files or scripts. Ensure these directories are cleaned of unauthorized or suspicious content.

  • Restore the system from a known good backup if any malicious activity is confirmed, ensuring that the backup is free from compromise.

  • Escalate the incident to the security operations team for further investigation and analysis. Provide them with logs and details of the processes and directories involved for deeper threat assessment.

  • Implement additional monitoring and alerting for similar suspicious activities, focusing on rapid sequences of base64 decoding commands and unusual directory usage to enhance detection capabilities.

  • Review and update access controls and permissions for the directories involved to prevent unauthorized access and execution of potentially harmful scripts or binaries.

Related rules

to-top