File Creation in /var/log via Suspicious Process

This rule detects the creation of files in the /var/log/ directory via process executables located in world-writeable locations or via hidden processes. Attackers may attempt to hide their activities by creating files in the /var/log/ directory, which is commonly used for logging system events.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/03/11"
  3integration = ["endpoint", "sentinel_one_cloud_funnel"]
  4maturity = "production"
  5min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
  6min_stack_version = "8.13.0"
  7updated_date = "2025/04/07"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects the creation of files in the /var/log/ directory via process executables located in
 13world-writeable locations or via hidden processes. Attackers may attempt to hide their activities by
 14creating files in the /var/log/ directory, which is commonly used for logging system events. 
 15"""
 16from = "now-9m"
 17index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 18language = "kuery"
 19license = "Elastic License v2"
 20name = "File Creation in /var/log via Suspicious Process"
 21note = """ ## Triage and analysis
 22
 23> **Disclaimer**:
 24> 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.
 25
 26### Investigating File Creation in /var/log via Suspicious Process
 27
 28In Linux environments, the `/var/log` directory is crucial for storing system logs, which are essential for monitoring and troubleshooting. Adversaries may exploit this by creating files in this directory using executables from insecure locations, aiming to conceal their activities. The detection rule identifies such suspicious file creations by monitoring processes from world-writable or hidden paths, flagging potential evasion tactics.
 29
 30### Possible investigation steps
 31
 32- Review the process executable path to determine if it originates from a world-writable or hidden location such as /tmp, /var/tmp, /dev/shm, or similar directories. This can indicate potential malicious activity.
 33- Examine the process name and its parent process to understand the context of the file creation and identify if it is associated with known legitimate or suspicious activities.
 34- Check the file path in /var/log to see if the created file has any unusual naming conventions or lacks a file extension, which might suggest an attempt to hide or disguise the file.
 35- Investigate the user account under which the process was executed to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior.
 36- Correlate the event with other logs or alerts from the same host to identify any related suspicious activities or patterns that could indicate a broader compromise.
 37- Assess the risk and impact of the file creation by considering the severity and risk score provided, and prioritize further actions based on this assessment.
 38
 39### False positive analysis
 40
 41- System maintenance scripts or legitimate applications may create temporary log files in /var/log using executables from directories like /tmp or /var/tmp. To handle this, identify and whitelist these known processes by their executable paths.
 42- Automated backup or monitoring tools might generate files in /var/log as part of their routine operations. Review these tools and exclude their processes from the rule to prevent unnecessary alerts.
 43- Development or testing environments often involve scripts that create log files in /var/log for debugging purposes. Consider excluding these environments from the rule or creating specific exceptions for known development processes.
 44- Some system updates or package installations might temporarily use world-writable directories for executable scripts that interact with /var/log. Monitor these activities and create exceptions for trusted update processes to reduce false positives.
 45
 46### Response and remediation
 47
 48- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
 49- Terminate any suspicious processes identified as originating from world-writable or hidden paths, especially those involved in file creation within /var/log.
 50- Conduct a thorough review of the files created in /var/log to determine if they contain malicious content or scripts, and remove any unauthorized files.
 51- Restore any affected system files or logs from a known good backup to ensure system integrity and continuity of logging.
 52- Implement stricter permissions on directories like /tmp, /var/tmp, and /dev/shm to prevent unauthorized execution of processes from these locations.
 53- Escalate the incident to the security operations team for further analysis and to determine if additional systems are compromised.
 54- Update and enhance monitoring rules to detect similar suspicious activities in the future, focusing on process execution from insecure locations and unauthorized file creation in critical directories.
 55"""
 56risk_score = 21
 57rule_id = "ddf26e25-3e30-42b2-92db-bde8eb82ad67"
 58setup = """## Setup
 59
 60This rule requires data coming in from Elastic Defend.
 61
 62### Elastic Defend Integration Setup
 63Elastic 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.
 64
 65#### Prerequisite Requirements:
 66- Fleet is required for Elastic Defend.
 67- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 68
 69#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 70- Go to the Kibana home page and click "Add integrations".
 71- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 72- Click "Add Elastic Defend".
 73- Configure the integration name and optionally add a description.
 74- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 75- 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).
 76- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 77- 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.
 78For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 79- Click "Save and Continue".
 80- 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.
 81For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 82"""
 83severity = "low"
 84tags = [
 85    "Domain: Endpoint",
 86    "OS: Linux",
 87    "Use Case: Threat Detection",
 88    "Tactic: Defense Evasion",
 89    "Tactic: Execution",
 90    "Tactic: Persistence",
 91    "Data Source: Elastic Defend",
 92    "Data Source: SentinelOne",
 93    "Data Source: Elastic Endgame",
 94    "Resources: Investigation Guide",
 95]
 96timestamp_override = "event.ingested"
 97type = "new_terms"
 98query = '''
 99event.category:file and host.os.type:linux and event.action:(creation or file_create_event or file_rename_event or rename) and
100(process.executable:(/tmp/* or /var/tmp/* or /dev/shm/* or ./* or /boot/*) or process.name:.*) and
101file.path:/var/log/* and not file.extension:*
102'''
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]
126name = "Execution"
127id = "TA0002"
128reference = "https://attack.mitre.org/tactics/TA0002/"
129
130[[rule.threat.technique]]
131id = "T1059"
132name = "Command and Scripting Interpreter"
133reference = "https://attack.mitre.org/techniques/T1059/"
134
135[[rule.threat.technique.subtechnique]]
136name = "Unix Shell"
137id = "T1059.004"
138reference = "https://attack.mitre.org/techniques/T1059/004/"
139
140[[rule.threat]]
141framework = "MITRE ATT&CK"
142
143[rule.threat.tactic]
144id = "TA0003"
145name = "Persistence"
146reference = "https://attack.mitre.org/tactics/TA0003/"
147
148[rule.new_terms]
149field = "new_terms_fields"
150value = ["file.path", "process.executable"]
151
152[[rule.new_terms.history_window_start]]
153field = "history_window_start"
154value = "now-10d"
...
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.

In Linux environments, the /var/log directory is crucial for storing system logs, which are essential for monitoring and troubleshooting. Adversaries may exploit this by creating files in this directory using executables from insecure locations, aiming to conceal their activities. The detection rule identifies such suspicious file creations by monitoring processes from world-writable or hidden paths, flagging potential evasion tactics.

  • Review the process executable path to determine if it originates from a world-writable or hidden location such as /tmp, /var/tmp, /dev/shm, or similar directories. This can indicate potential malicious activity.
  • Examine the process name and its parent process to understand the context of the file creation and identify if it is associated with known legitimate or suspicious activities.
  • Check the file path in /var/log to see if the created file has any unusual naming conventions or lacks a file extension, which might suggest an attempt to hide or disguise the file.
  • Investigate the user account under which the process was executed to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior.
  • Correlate the event with other logs or alerts from the same host to identify any related suspicious activities or patterns that could indicate a broader compromise.
  • Assess the risk and impact of the file creation by considering the severity and risk score provided, and prioritize further actions based on this assessment.
  • System maintenance scripts or legitimate applications may create temporary log files in /var/log using executables from directories like /tmp or /var/tmp. To handle this, identify and whitelist these known processes by their executable paths.
  • Automated backup or monitoring tools might generate files in /var/log as part of their routine operations. Review these tools and exclude their processes from the rule to prevent unnecessary alerts.
  • Development or testing environments often involve scripts that create log files in /var/log for debugging purposes. Consider excluding these environments from the rule or creating specific exceptions for known development processes.
  • Some system updates or package installations might temporarily use world-writable directories for executable scripts that interact with /var/log. Monitor these activities and create exceptions for trusted update processes to reduce false positives.
  • Isolate the affected system from the network to prevent further malicious activity and lateral movement.
  • Terminate any suspicious processes identified as originating from world-writable or hidden paths, especially those involved in file creation within /var/log.
  • Conduct a thorough review of the files created in /var/log to determine if they contain malicious content or scripts, and remove any unauthorized files.
  • Restore any affected system files or logs from a known good backup to ensure system integrity and continuity of logging.
  • Implement stricter permissions on directories like /tmp, /var/tmp, and /dev/shm to prevent unauthorized execution of processes from these locations.
  • Escalate the incident to the security operations team for further analysis and to determine if additional systems are compromised.
  • Update and enhance monitoring rules to detect similar suspicious activities in the future, focusing on process execution from insecure locations and unauthorized file creation in critical directories.

Related rules

to-top