Potential Data Splitting Detected
This rule looks for the usage of common data splitting utilities with specific arguments that indicate data splitting for exfiltration on Linux systems. Data splitting is a technique used by adversaries to split data into smaller parts to avoid detection and exfiltrate data.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/11/04"
3integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
4maturity = "production"
5updated_date = "2025/03/20"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule looks for the usage of common data splitting utilities with specific arguments that indicate data splitting
11for exfiltration on Linux systems. Data splitting is a technique used by adversaries to split data into smaller parts to
12avoid detection and exfiltrate data.
13"""
14from = "now-9m"
15index = [
16 "endgame-*",
17 "logs-crowdstrike.fdr*",
18 "logs-endpoint.events.process*",
19 "logs-sentinel_one_cloud_funnel.*",
20]
21language = "eql"
22license = "Elastic License v2"
23name = "Potential Data Splitting Detected"
24note = """## Triage and analysis
25
26> **Disclaimer**:
27> 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.
28
29### Investigating Potential Data Splitting Detected
30
31Data splitting utilities on Linux, such as `dd` and `split`, are typically used for managing large files by dividing them into smaller, more manageable parts. Adversaries exploit these tools to covertly exfiltrate data by splitting it into inconspicuous segments. The detection rule identifies suspicious use of these utilities by monitoring specific command-line arguments and excluding benign processes, thereby flagging potential exfiltration activities.
32
33### Possible investigation steps
34
35- Review the process details to confirm the use of data splitting utilities like 'dd', 'split', or 'rsplit' with suspicious arguments such as 'bs=*', 'if=*', '-b', or '--bytes*'.
36- Examine the parent process name to ensure it is not a benign process like 'apport' or 'overlayroot', which are excluded in the rule.
37- Investigate the source and destination paths specified in the process arguments to determine if they involve sensitive or unusual locations, excluding paths like '/tmp/nvim*', '/boot/*', or '/dev/urandom'.
38- Check the user account associated with the process to assess if it has a history of legitimate use of these utilities or if it might be compromised.
39- Analyze recent network activity from the host to identify any potential data exfiltration attempts, especially if the process involves external connections.
40- Correlate this alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise.
41
42### False positive analysis
43
44- Processes related to system maintenance or updates, such as those initiated by the 'apport' or 'overlayroot' processes, may trigger false positives. Users can mitigate this by ensuring these parent processes are included in the exclusion list.
45- Backup operations that use 'dd' or 'split' for legitimate data management tasks can be mistaken for exfiltration attempts. Exclude specific backup scripts or processes by adding their unique identifiers or arguments to the exclusion criteria.
46- Development or testing environments where 'dd' or 'split' are used for creating test data or simulating data transfer can generate false alerts. Identify and exclude these environments by specifying their process names or argument patterns.
47- Automated scripts that use 'dd' or 'split' for routine data processing tasks should be reviewed and, if benign, added to the exclusion list to prevent unnecessary alerts.
48- Regular system operations involving '/dev/random', '/dev/urandom', or similar sources should be excluded, as these are common in non-malicious contexts and are already partially covered by the rule's exclusions.
49
50### Response and remediation
51
52- Immediately isolate the affected Linux system from the network to prevent further data exfiltration.
53- Terminate any suspicious processes identified by the detection rule, specifically those involving the `dd`, `split`, or `rsplit` utilities with the flagged arguments.
54- Conduct a thorough review of recent file access and modification logs to identify any unauthorized data handling or exfiltration attempts.
55- Restore any potentially compromised data from secure backups, ensuring that the restored data is free from any malicious alterations.
56- Implement stricter access controls and monitoring on sensitive data directories to prevent unauthorized access and manipulation.
57- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.
58- Enhance monitoring and alerting for similar suspicious activities by integrating additional threat intelligence sources and refining detection capabilities."""
59risk_score = 21
60rule_id = "e302e6c3-448c-4243-8d9b-d41da70db582"
61setup = """## Setup
62
63This rule requires data coming in from Elastic Defend.
64
65### Elastic Defend Integration Setup
66Elastic 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.
67
68#### Prerequisite Requirements:
69- Fleet is required for Elastic Defend.
70- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
71
72#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
73- Go to the Kibana home page and click "Add integrations".
74- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
75- Click "Add Elastic Defend".
76- Configure the integration name and optionally add a description.
77- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
78- 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).
79- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
80- 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.
81For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
82- Click "Save and Continue".
83- 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.
84For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
85"""
86severity = "low"
87tags = [
88 "Domain: Endpoint",
89 "OS: Linux",
90 "Use Case: Threat Detection",
91 "Tactic: Exfiltration",
92 "Data Source: Elastic Defend",
93 "Data Source: Crowdstrike",
94 "Data Source: SentinelOne",
95 "Data Source: Elastic Endgame",
96 "Resources: Investigation Guide",
97]
98timestamp_override = "event.ingested"
99type = "eql"
100
101query = '''
102process where host.os.type == "linux" and event.type == "start" and
103 event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
104 (
105 (process.name == "dd" and process.args like "bs=*" and process.args like "if=*") or
106 (
107 process.name in ("split", "rsplit") and
108 (
109 (process.args == "-b" or process.args like "--bytes*") or
110 (process.args == "-C" or process.args like "--line-bytes*")
111 )
112 )
113 ) and
114 not (
115 process.parent.name in ("apport", "overlayroot", "nessus-agent-module") or
116 process.args like (
117 "if=/tmp/nvim*", "if=/boot/*", "if=/dev/random", "if=/dev/urandom", "/dev/mapper/*",
118 "if=*.iso", "of=/dev/stdout", "if=/dev/zero", "if=/dev/sda", "/proc/sys/kernel/*"
119 )
120 )
121'''
122
123
124[[rule.threat]]
125framework = "MITRE ATT&CK"
126
127[rule.threat.tactic]
128id = "TA0010"
129name = "Exfiltration"
130reference = "https://attack.mitre.org/tactics/TA0010/"
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 Potential Data Splitting Detected
Data splitting utilities on Linux, such as dd
and split
, are typically used for managing large files by dividing them into smaller, more manageable parts. Adversaries exploit these tools to covertly exfiltrate data by splitting it into inconspicuous segments. The detection rule identifies suspicious use of these utilities by monitoring specific command-line arguments and excluding benign processes, thereby flagging potential exfiltration activities.
Possible investigation steps
- Review the process details to confirm the use of data splitting utilities like 'dd', 'split', or 'rsplit' with suspicious arguments such as 'bs=', 'if=', '-b', or '--bytes*'.
- Examine the parent process name to ensure it is not a benign process like 'apport' or 'overlayroot', which are excluded in the rule.
- Investigate the source and destination paths specified in the process arguments to determine if they involve sensitive or unusual locations, excluding paths like '/tmp/nvim*', '/boot/*', or '/dev/urandom'.
- Check the user account associated with the process to assess if it has a history of legitimate use of these utilities or if it might be compromised.
- Analyze recent network activity from the host to identify any potential data exfiltration attempts, especially if the process involves external connections.
- Correlate this alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise.
False positive analysis
- Processes related to system maintenance or updates, such as those initiated by the 'apport' or 'overlayroot' processes, may trigger false positives. Users can mitigate this by ensuring these parent processes are included in the exclusion list.
- Backup operations that use 'dd' or 'split' for legitimate data management tasks can be mistaken for exfiltration attempts. Exclude specific backup scripts or processes by adding their unique identifiers or arguments to the exclusion criteria.
- Development or testing environments where 'dd' or 'split' are used for creating test data or simulating data transfer can generate false alerts. Identify and exclude these environments by specifying their process names or argument patterns.
- Automated scripts that use 'dd' or 'split' for routine data processing tasks should be reviewed and, if benign, added to the exclusion list to prevent unnecessary alerts.
- Regular system operations involving '/dev/random', '/dev/urandom', or similar sources should be excluded, as these are common in non-malicious contexts and are already partially covered by the rule's exclusions.
Response and remediation
- Immediately isolate the affected Linux system from the network to prevent further data exfiltration.
- Terminate any suspicious processes identified by the detection rule, specifically those involving the
dd
,split
, orrsplit
utilities with the flagged arguments. - Conduct a thorough review of recent file access and modification logs to identify any unauthorized data handling or exfiltration attempts.
- Restore any potentially compromised data from secure backups, ensuring that the restored data is free from any malicious alterations.
- Implement stricter access controls and monitoring on sensitive data directories to prevent unauthorized access and manipulation.
- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.
- Enhance monitoring and alerting for similar suspicious activities by integrating additional threat intelligence sources and refining detection capabilities.
Related rules
- Access Control List Modification via setfacl
- Attempt to Clear Kernel Ring Buffer
- Attempt to Disable Auditd Service
- Attempt to Disable Syslog Service
- Base16 or Base32 Encoding/Decoding Activity