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"
  5updated_date = "2025/03/20"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule identifies the creation of directories in the /bin directory. The /bin directory contains essential binary
 11files that are required for the system to function properly. The creation of directories in this location could be an
 12attempt to hide malicious files or executables, as these /bin directories usually just contain binaries.
 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 = "Directory Creation in /bin directory"
 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 Directory Creation in /bin directory
 30
 31The /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.
 32
 33### Possible investigation steps
 34
 35- 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.
 36- Check the parent process of the 'mkdir' command to determine if it was initiated by a legitimate system process or a potentially malicious one.
 37- 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.
 38- Examine the system logs around the time of the directory creation for any other suspicious activities or anomalies that might indicate a broader attack.
 39- Verify if any files or executables have been placed in the newly created directory and assess their legitimacy and potential threat level.
 40- Cross-reference the event with threat intelligence sources to identify if the activity matches any known malicious patterns or indicators of compromise.
 41
 42### False positive analysis
 43
 44- 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.
 45- 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.
 46- 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.
 47- 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.
 48
 49### Response and remediation
 50
 51- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary.
 52- Terminate any suspicious processes related to the directory creation in the /bin directory to halt any ongoing malicious activity.
 53- Conduct a thorough review of the newly created directories and files within the /bin directory to identify and remove any malicious binaries or scripts.
 54- Restore any altered or deleted legitimate binaries from a known good backup to ensure system integrity and functionality.
 55- Implement file integrity monitoring on critical system directories, including /bin, to detect unauthorized changes in real-time.
 56- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
 57- Review and update access controls and permissions for the /bin directory to restrict unauthorized directory creation and enhance security posture."""
 58risk_score = 21
 59rule_id = "3302835b-0049-4004-a325-660b1fba1f67"
 60setup = """## Setup
 61
 62This rule requires data coming in from Elastic Defend.
 63
 64### Elastic Defend Integration Setup
 65Elastic 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.
 66
 67#### Prerequisite Requirements:
 68- Fleet is required for Elastic Defend.
 69- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 70
 71#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 72- Go to the Kibana home page and click "Add integrations".
 73- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 74- Click "Add Elastic Defend".
 75- Configure the integration name and optionally add a description.
 76- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 77- 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).
 78- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 79- 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.
 80For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 81- Click "Save and Continue".
 82- 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.
 83For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 84"""
 85severity = "low"
 86tags = [
 87    "Domain: Endpoint",
 88    "OS: Linux",
 89    "Use Case: Threat Detection",
 90    "Tactic: Defense Evasion",
 91    "Tactic: Persistence",
 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", "start", "ProcessRollup2", "exec_event") and process.name == "mkdir" and
104  process.args like ("/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*") and
105not process.args in ("/bin/mkdir", "/usr/bin/mkdir", "/usr/local/bin/mkdir")
106'''
107
108
109[[rule.threat]]
110framework = "MITRE ATT&CK"
111[[rule.threat.technique]]
112id = "T1564"
113name = "Hide Artifacts"
114reference = "https://attack.mitre.org/techniques/T1564/"
115[[rule.threat.technique.subtechnique]]
116id = "T1564.001"
117name = "Hidden Files and Directories"
118reference = "https://attack.mitre.org/techniques/T1564/001/"
119
120
121
122[rule.threat.tactic]
123id = "TA0005"
124name = "Defense Evasion"
125reference = "https://attack.mitre.org/tactics/TA0005/"
126[[rule.threat]]
127framework = "MITRE ATT&CK"
128
129[rule.threat.tactic]
130id = "TA0003"
131name = "Persistence"
132reference = "https://attack.mitre.org/tactics/TA0003/"
...
toml

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.

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.

  • 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.
  • 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.
  • 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

to-top