Directory Creation in /bin directory
This rule identifies the creation of directories in the /bin directory. The /bin directory contains essential binary files that are required for the system to function properly. The creation of directories in this location could be an attempt to hide malicious files or executables, as these /bin directories usually just contain binaries.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/11/01"
3integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
4maturity = "production"
5min_stack_version = "8.13.0"
6min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
7updated_date = "2025/01/15"
8
9[rule]
10author = ["Elastic"]
11description = """
12This rule identifies the creation of directories in the /bin directory. The /bin directory contains essential binary
13files that are required for the system to function properly. The creation of directories in this location could be an
14attempt to hide malicious files or executables, as these /bin directories usually just contain binaries.
15"""
16from = "now-9m"
17index = ["logs-endpoint.events.*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
18language = "eql"
19license = "Elastic License v2"
20name = "Directory Creation in /bin directory"
21risk_score = 21
22rule_id = "3302835b-0049-4004-a325-660b1fba1f67"
23setup = """## Setup
24
25This rule requires data coming in from Elastic Defend.
26
27### Elastic Defend Integration Setup
28Elastic 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.
29
30#### Prerequisite Requirements:
31- Fleet is required for Elastic Defend.
32- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
33
34#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
35- Go to the Kibana home page and click "Add integrations".
36- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
37- Click "Add Elastic Defend".
38- Configure the integration name and optionally add a description.
39- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
40- 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).
41- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
42- 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.
43For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
44- Click "Save and Continue".
45- 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.
46For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
47"""
48severity = "low"
49tags = [
50 "Domain: Endpoint",
51 "OS: Linux",
52 "Use Case: Threat Detection",
53 "Tactic: Defense Evasion",
54 "Tactic: Persistence",
55 "Data Source: Elastic Defend",
56 "Data Source: Crowdstrike",
57 "Data Source: SentinelOne",
58 "Data Source: Elastic Endgame",
59 "Resources: Investigation Guide",
60]
61timestamp_override = "event.ingested"
62type = "eql"
63query = '''
64process where host.os.type == "linux" and event.type == "start" and
65 event.action in ("exec", "start", "ProcessRollup2", "exec_event") and process.name == "mkdir" and
66 process.args like ("/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*") and
67not process.args in ("/bin/mkdir", "/usr/bin/mkdir", "/usr/local/bin/mkdir")
68'''
69note = """## Triage and analysis
70
71> **Disclaimer**:
72> 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.
73
74### Investigating Directory Creation in /bin directory
75
76The /bin directory is crucial for Linux systems, housing essential binaries for system operations. Adversaries may exploit this by creating directories here to conceal malicious files, leveraging the directory's trusted status. The detection rule identifies suspicious directory creation by monitoring 'mkdir' executions in critical binary paths, excluding legitimate system operations, thus flagging potential threats for further investigation.
77
78### Possible investigation steps
79
80- Review the process details to confirm the execution of 'mkdir' in the specified critical binary paths such as /bin, /usr/bin, /usr/local/bin, /sbin, /usr/sbin, and /usr/local/sbin.
81- Check the parent process of the 'mkdir' command to determine if it was initiated by a legitimate system process or a potentially malicious one.
82- Investigate the user account associated with the 'mkdir' process to assess if it has the necessary permissions and if the activity aligns with the user's typical behavior.
83- Examine the system logs around the time of the directory creation for any other suspicious activities or anomalies that might indicate a broader attack.
84- Verify if any files or executables have been placed in the newly created directory and assess their legitimacy and potential threat level.
85- Cross-reference the event with threat intelligence sources to identify if the activity matches any known malicious patterns or indicators of compromise.
86
87### False positive analysis
88
89- System updates or package installations may trigger directory creation in the /bin directory as part of legitimate operations. Users can mitigate this by creating exceptions for known package management processes like apt, yum, or rpm.
90- Custom scripts or administrative tasks that require creating directories in the /bin directory for temporary storage or testing purposes can also lead to false positives. Users should document and exclude these specific scripts or tasks from the detection rule.
91- Automated deployment tools or configuration management systems such as Ansible, Puppet, or Chef might create directories in the /bin directory as part of their setup routines. Users should identify these tools and add them to the exclusion list to prevent unnecessary alerts.
92- Development or testing environments where developers have permissions to create directories in the /bin directory for application testing can result in false positives. Users should differentiate between production and non-production environments and apply the rule accordingly.
93
94### Response and remediation
95
96- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary.
97- Terminate any suspicious processes related to the directory creation in the /bin directory to halt any ongoing malicious activity.
98- Conduct a thorough review of the newly created directories and files within the /bin directory to identify and remove any malicious binaries or scripts.
99- Restore any altered or deleted legitimate binaries from a known good backup to ensure system integrity and functionality.
100- Implement file integrity monitoring on critical system directories, including /bin, to detect unauthorized changes in real-time.
101- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
102- Review and update access controls and permissions for the /bin directory to restrict unauthorized directory creation and enhance security posture."""
103
104[[rule.threat]]
105framework = "MITRE ATT&CK"
106
107[[rule.threat.technique]]
108id = "T1564"
109name = "Hide Artifacts"
110reference = "https://attack.mitre.org/techniques/T1564/"
111
112[[rule.threat.technique.subtechnique]]
113id = "T1564.001"
114name = "Hidden Files and Directories"
115reference = "https://attack.mitre.org/techniques/T1564/001/"
116
117[rule.threat.tactic]
118id = "TA0005"
119name = "Defense Evasion"
120reference = "https://attack.mitre.org/tactics/TA0005/"
121
122[[rule.threat]]
123framework = "MITRE ATT&CK"
124
125[rule.threat.tactic]
126id = "TA0003"
127name = "Persistence"
128reference = "https://attack.mitre.org/tactics/TA0003/"
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 Directory Creation in /bin directory
The /bin directory is crucial for Linux systems, housing essential binaries for system operations. Adversaries may exploit this by creating directories here to conceal malicious files, leveraging the directory's trusted status. The detection rule identifies suspicious directory creation by monitoring 'mkdir' executions in critical binary paths, excluding legitimate system operations, thus flagging potential threats for further investigation.
Possible investigation steps
- Review the process details to confirm the execution of 'mkdir' in the specified critical binary paths such as /bin, /usr/bin, /usr/local/bin, /sbin, /usr/sbin, and /usr/local/sbin.
- Check the parent process of the 'mkdir' command to determine if it was initiated by a legitimate system process or a potentially malicious one.
- Investigate the user account associated with the 'mkdir' process to assess if it has the necessary permissions and if the activity aligns with the user's typical behavior.
- Examine the system logs around the time of the directory creation for any other suspicious activities or anomalies that might indicate a broader attack.
- Verify if any files or executables have been placed in the newly created directory and assess their legitimacy and potential threat level.
- Cross-reference the event with threat intelligence sources to identify if the activity matches any known malicious patterns or indicators of compromise.
False positive analysis
- System updates or package installations may trigger directory creation in the /bin directory as part of legitimate operations. Users can mitigate this by creating exceptions for known package management processes like apt, yum, or rpm.
- Custom scripts or administrative tasks that require creating directories in the /bin directory for temporary storage or testing purposes can also lead to false positives. Users should document and exclude these specific scripts or tasks from the detection rule.
- Automated deployment tools or configuration management systems such as Ansible, Puppet, or Chef might create directories in the /bin directory as part of their setup routines. Users should identify these tools and add them to the exclusion list to prevent unnecessary alerts.
- Development or testing environments where developers have permissions to create directories in the /bin directory for application testing can result in false positives. Users should differentiate between production and non-production environments and apply the rule accordingly.
Response and remediation
- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary.
- Terminate any suspicious processes related to the directory creation in the /bin directory to halt any ongoing malicious activity.
- Conduct a thorough review of the newly created directories and files within the /bin directory to identify and remove any malicious binaries or scripts.
- Restore any altered or deleted legitimate binaries from a known good backup to ensure system integrity and functionality.
- Implement file integrity monitoring on critical system directories, including /bin, to detect unauthorized changes in real-time.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
- Review and update access controls and permissions for the /bin directory to restrict unauthorized directory creation and enhance security posture.
Related rules
- Git Hook Child Process
- Kernel Load or Unload via Kexec Detected
- Base16 or Base32 Encoding/Decoding Activity
- DNF Package Manager Plugin File Creation
- Dynamic Linker (ld.so) Creation