Unusual Base64 Encoding/Decoding Activity

This rule leverages ESQL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/02/21"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/12/17"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule leverages ESQL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64
 11encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or
 12network-based security controls. ESQL rules have limited fields available in its alert documents. Make sure to review
 13the original documents to aid in the investigation of this alert.
 14"""
 15from = "now-61m"
 16interval = "1h"
 17language = "esql"
 18license = "Elastic License v2"
 19name = "Unusual Base64 Encoding/Decoding Activity"
 20note = """## Triage and analysis
 21
 22> **Disclaimer**:
 23> 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.
 24
 25### Investigating Unusual Base64 Encoding/Decoding Activity
 26Base64 encoding is a method to convert binary data into ASCII text, often used for data transmission. Adversaries exploit this to obfuscate malicious payloads or commands, bypassing security controls. The detection rule identifies suspicious Base64 activity on Linux by monitoring specific processes and command patterns, flagging anomalies for further investigation.
 27
 28### Possible investigation steps
 29
 30- Review the process name and command line arguments to understand the context of the Base64 activity. Check if the process name matches known legitimate applications or scripts.
 31- Examine the timestamp of the event to determine if the activity occurred during normal operational hours or if it coincides with other suspicious activities.
 32- Investigate the host operating system type and agent ID to identify the specific Linux system involved and assess if it has a history of similar alerts or other security incidents.
 33- Analyze the process command line for any unusual patterns or parameters that might indicate obfuscation or malicious intent, such as the presence of decode flags or unexpected Base64 operations.
 34- Correlate the event with other logs or alerts from the same host or network to identify potential lateral movement or coordinated attacks.
 35- Check for any recent changes or deployments on the affected system that might explain the Base64 activity, such as new software installations or updates.
 36- Consult threat intelligence sources to determine if the observed Base64 patterns or command line arguments are associated with known malware or attack techniques.
 37
 38### False positive analysis
 39
 40- Routine administrative scripts may use base64 encoding for legitimate data processing tasks. Review the process.command_line and process.args fields to identify known scripts and consider excluding them from the rule.
 41- Backup or data transfer operations might employ base64 encoding to handle binary data. Verify the process.name and process.command_line to ensure these operations are recognized and add exceptions for these specific processes.
 42- Development environments often use base64 encoding for testing purposes. Identify development-related processes by examining the process.name and process.command_line and exclude them if they are part of regular development activities.
 43- Automated system monitoring tools might trigger this rule if they use base64 encoding for log or data analysis. Check the agent.id and process.command_line to confirm these tools and exclude them from the rule if they are verified as non-threatening.
 44- Security tools that perform data encoding for analysis or reporting could be flagged. Validate these tools by reviewing the process.name and process.command_line and create exceptions for them if they are part of the security infrastructure.
 45
 46### Response and remediation
 47
 48- Isolate the affected Linux system from the network to prevent further data exfiltration or lateral movement by the adversary.
 49- Terminate any suspicious processes identified by the alert, particularly those involving base64 encoding/decoding, to halt potential malicious activity.
 50- Conduct a thorough review of the process command lines and arguments flagged by the alert to identify any malicious scripts or payloads. Remove or quarantine these files as necessary.
 51- Check for any unauthorized user accounts or privilege escalations that may have been established during the attack and revoke access immediately.
 52- Restore any affected systems or files from a known good backup to ensure the integrity of the system and data.
 53- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the suspicious base64 activity.
 54- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts exist.
 55"""
 56risk_score = 21
 57rule_id = "c5637438-e32d-4bb3-bc13-bd7932b3289f"
 58setup = """## Setup
 59
 60This rule requires data coming in from one of the following integrations:
 61- Elastic Defend
 62
 63### Elastic Defend Integration Setup
 64Elastic 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.
 65
 66#### Prerequisite Requirements:
 67- Fleet is required for Elastic Defend.
 68- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 69
 70#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 71- Go to the Kibana home page and click "Add integrations".
 72- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 73- Click "Add Elastic Defend".
 74- Configure the integration name and optionally add a description.
 75- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 76- 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).
 77- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 78- 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.
 79For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 80- Click "Save and Continue".
 81- 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.
 82For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 83"""
 84severity = "low"
 85tags = [
 86    "Domain: Endpoint",
 87    "OS: Linux",
 88    "Use Case: Threat Detection",
 89    "Tactic: Defense Evasion",
 90    "Data Source: Elastic Defend",
 91    "Resources: Investigation Guide",
 92]
 93timestamp_override = "event.ingested"
 94type = "esql"
 95query = '''
 96from logs-endpoint.events.process-* metadata _id, _index, _version
 97| mv_expand event.action 
 98| where
 99    host.os.type == "linux" and
100    event.type == "start" and
101    event.action == "exec" and (
102        (
103            process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and
104            process.command_line like "*-*d*"
105        ) or
106        (
107            process.name == "openssl" and
108            process.args == "enc" and
109            process.args in ("-d", "-base64", "-a")
110        ) or
111        (
112            process.name like "python*" and (
113                (
114                    process.args == "base64" and
115                    process.args in ("-d", "-u", "-t")
116                ) or
117                (
118                    process.args == "-c" and
119                    process.command_line like "*base64*" and
120                    process.command_line like "*b64decode*"
121                )
122            )
123        ) or
124        (
125            process.name like "perl*" and
126            process.command_line like "*decode_base64*"
127        ) or
128        (
129            process.name like "ruby*" and
130            process.args == "-e" and
131            process.command_line like "*Base64.decode64*"
132        )
133    )
134| keep
135    @timestamp,
136    _id,
137    _index,
138    _version,
139    host.os.type,
140    event.type,
141    event.action,
142    process.name,
143    process.args,
144    process.command_line,
145    process.parent.name,
146    process.parent.command_line,
147    agent.id,
148    host.name,
149    event.dataset,
150    data_stream.namespace
151| stats
152    Esql.event_count = count(),
153    Esql.process_parent_name_values = values(process.parent.name),
154    Esql.process_parent_command_line_values = values(process.parent.command_line),
155    Esql.agent_id_count_distinct = count_distinct(agent.id),
156    Esql.host_name_values = values(host.name),
157    Esql.agent_id_values = values(agent.id),
158    Esql.event_dataset_values = values(event.dataset),
159    Esql.data_stream_namespace_values = values(data_stream.namespace)
160    by process.name, process.command_line
161| where
162    Esql.agent_id_count_distinct == 1 and
163    Esql.event_count < 15
164| sort Esql.event_count asc
165'''
166
167[[rule.threat]]
168framework = "MITRE ATT&CK"
169
170[[rule.threat.technique]]
171id = "T1027"
172name = "Obfuscated Files or Information"
173reference = "https://attack.mitre.org/techniques/T1027/"
174
175[[rule.threat.technique]]
176id = "T1140"
177name = "Deobfuscate/Decode Files or Information"
178reference = "https://attack.mitre.org/techniques/T1140/"
179
180[rule.threat.tactic]
181id = "TA0005"
182name = "Defense Evasion"
183reference = "https://attack.mitre.org/tactics/TA0005/"
184
185[[rule.threat]]
186framework = "MITRE ATT&CK"
187
188[[rule.threat.technique]]
189id = "T1059"
190name = "Command and Scripting Interpreter"
191reference = "https://attack.mitre.org/techniques/T1059/"
192
193[[rule.threat.technique.subtechnique]]
194id = "T1059.004"
195name = "Unix Shell"
196reference = "https://attack.mitre.org/techniques/T1059/004/"
197
198[[rule.threat.technique]]
199id = "T1204"
200name = "User Execution"
201reference = "https://attack.mitre.org/techniques/T1204/"
202
203[[rule.threat.technique.subtechnique]]
204id = "T1204.002"
205name = "Malicious File"
206reference = "https://attack.mitre.org/techniques/T1204/002/"
207
208[rule.threat.tactic]
209id = "TA0002"
210name = "Execution"
211reference = "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 Unusual Base64 Encoding/Decoding Activity

Base64 encoding is a method to convert binary data into ASCII text, often used for data transmission. Adversaries exploit this to obfuscate malicious payloads or commands, bypassing security controls. The detection rule identifies suspicious Base64 activity on Linux by monitoring specific processes and command patterns, flagging anomalies for further investigation.

Possible investigation steps

  • Review the process name and command line arguments to understand the context of the Base64 activity. Check if the process name matches known legitimate applications or scripts.
  • Examine the timestamp of the event to determine if the activity occurred during normal operational hours or if it coincides with other suspicious activities.
  • Investigate the host operating system type and agent ID to identify the specific Linux system involved and assess if it has a history of similar alerts or other security incidents.
  • Analyze the process command line for any unusual patterns or parameters that might indicate obfuscation or malicious intent, such as the presence of decode flags or unexpected Base64 operations.
  • Correlate the event with other logs or alerts from the same host or network to identify potential lateral movement or coordinated attacks.
  • Check for any recent changes or deployments on the affected system that might explain the Base64 activity, such as new software installations or updates.
  • Consult threat intelligence sources to determine if the observed Base64 patterns or command line arguments are associated with known malware or attack techniques.

False positive analysis

  • Routine administrative scripts may use base64 encoding for legitimate data processing tasks. Review the process.command_line and process.args fields to identify known scripts and consider excluding them from the rule.
  • Backup or data transfer operations might employ base64 encoding to handle binary data. Verify the process.name and process.command_line to ensure these operations are recognized and add exceptions for these specific processes.
  • Development environments often use base64 encoding for testing purposes. Identify development-related processes by examining the process.name and process.command_line and exclude them if they are part of regular development activities.
  • Automated system monitoring tools might trigger this rule if they use base64 encoding for log or data analysis. Check the agent.id and process.command_line to confirm these tools and exclude them from the rule if they are verified as non-threatening.
  • Security tools that perform data encoding for analysis or reporting could be flagged. Validate these tools by reviewing the process.name and process.command_line and create exceptions for them if they are part of the security infrastructure.

Response and remediation

  • Isolate the affected Linux system from the network to prevent further data exfiltration or lateral movement by the adversary.
  • Terminate any suspicious processes identified by the alert, particularly those involving base64 encoding/decoding, to halt potential malicious activity.
  • Conduct a thorough review of the process command lines and arguments flagged by the alert to identify any malicious scripts or payloads. Remove or quarantine these files as necessary.
  • Check for any unauthorized user accounts or privilege escalations that may have been established during the attack and revoke access immediately.
  • Restore any affected systems or files from a known good backup to ensure the integrity of the system and data.
  • Implement additional monitoring on the affected system and similar environments to detect any recurrence of the suspicious base64 activity.
  • Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts exist.

Related rules

to-top