Shell Configuration Creation or Modification
This rule monitors the creation/alteration of a shell configuration file. Unix systems use shell configuration files to set environment variables, create aliases, and customize the user's environment. Adversaries may modify or add a shell configuration file to execute malicious code and gain persistence in the system. This behavior is consistent with the Kaiji malware family.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/04/30"
3integration = ["endpoint"]
4maturity = "production"
5updated_date = "2025/01/24"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule monitors the creation/alteration of a shell configuration file. Unix systems use shell configuration files to
11set environment variables, create aliases, and customize the user's environment. Adversaries may modify or add a shell
12configuration file to execute malicious code and gain persistence in the system. This behavior is consistent with the
13Kaiji malware family.
14"""
15false_positives = ["Legitimate user shell modification activity."]
16from = "now-9m"
17index = ["logs-endpoint.events.file*"]
18language = "eql"
19license = "Elastic License v2"
20name = "Shell Configuration Creation or Modification"
21references = [
22 "https://intezer.com/blog/research/kaiji-new-chinese-linux-malware-turning-to-golang/",
23 "https://www.elastic.co/security-labs/primer-on-persistence-mechanisms",
24]
25risk_score = 47
26rule_id = "28f6f34b-8e16-487a-b5fd-9d22eb903db8"
27setup = """## Setup
28
29This rule requires data coming in from Elastic Defend.
30
31### Elastic Defend Integration Setup
32Elastic 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.
33
34#### Prerequisite Requirements:
35- Fleet is required for Elastic Defend.
36- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
37
38#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
39- Go to the Kibana home page and click "Add integrations".
40- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
41- Click "Add Elastic Defend".
42- Configure the integration name and optionally add a description.
43- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
44- 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).
45- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
46- 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.
47For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
48- Click "Save and Continue".
49- 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.
50For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
51"""
52severity = "medium"
53tags = [
54 "Domain: Endpoint",
55 "OS: Linux",
56 "Use Case: Threat Detection",
57 "Tactic: Persistence",
58 "Data Source: Elastic Defend",
59 "Resources: Investigation Guide",
60]
61timestamp_override = "event.ingested"
62type = "eql"
63query = '''
64file where host.os.type == "linux" and event.action in ("rename", "creation") and file.path : (
65 // system-wide configurations
66 "/etc/profile", "/etc/profile.d/*", "/etc/bash.bashrc", "/etc/bash.bash_logout", "/etc/zsh/*",
67 "/etc/csh.cshrc", "/etc/csh.login", "/etc/fish/config.fish", "/etc/ksh.kshrc",
68 // root and user configurations
69 "/home/*/.profile", "/home/*/.bashrc", "/home/*/.bash_login", "/home/*/.bash_logout", "/home/*/.bash_profile",
70 "/root/.profile", "/root/.bashrc", "/root/.bash_login", "/root/.bash_logout", "/root/.bash_profile",
71 "/home/*/.zprofile", "/home/*/.zshrc", "/root/.zprofile", "/root/.zshrc",
72 "/home/*/.cshrc", "/home/*/.login", "/home/*/.logout", "/root/.cshrc", "/root/.login", "/root/.logout",
73 "/home/*/.config/fish/config.fish", "/root/.config/fish/config.fish",
74 "/home/*/.kshrc", "/root/.kshrc"
75) and not (
76 process.executable in (
77 "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf",
78 "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum",
79 "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic",
80 "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk",
81 "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet",
82 "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client",
83 "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/dev/fd/*", "/usr/bin/pamac-daemon",
84 "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/sbin/adduser", "/usr/sbin/useradd", "/usr/local/bin/dockerd",
85 "/usr/sbin/gdm", "/usr/bin/unzip", "/usr/bin/gnome-shell", "/sbin/mkhomedir_helper", "/usr/sbin/sshd",
86 "/opt/puppetlabs/puppet/bin/ruby", "/usr/bin/xfce4-session", "/usr/libexec/oddjob/mkhomedir", "/sbin/useradd",
87 "/usr/lib/systemd/systemd", "/usr/sbin/crond", "/usr/bin/pamac-daemon", "/usr/sbin/mkhomedir_helper",
88 "/opt/pbis/sbin/lwsmd", "/usr/sbin/oddjobd"
89 ) or
90 file.extension in ("swp", "swpx", "swx", "dpkg-remove") or
91 file.Ext.original.extension == "dpkg-new" or
92 process.executable : (
93 "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*",
94 "/usr/libexec/platform-python*"
95 ) or
96 process.executable == null or
97 process.name in ("adclient", "mkhomedir_helper", "teleport", "mkhomedir", "adduser", "desktopDaemon", "executor", "crio") or
98 (process.name == "sed" and file.name : "sed*") or
99 (process.name == "perl" and file.name : "e2scrub_all.tmp*")
100)
101'''
102note = """## Triage and analysis
103
104> **Disclaimer**:
105> 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.
106
107### Investigating Shell Configuration Creation or Modification
108
109Shell configuration files in Unix-like systems are crucial for setting up user environments by defining variables, aliases, and startup scripts. Adversaries exploit these files to execute malicious code persistently. The detection rule identifies suspicious creation or modification of these files, excluding benign processes, to flag potential threats, aligning with tactics like persistence and event-triggered execution.
110
111### Possible investigation steps
112
113- Review the specific file path involved in the alert to determine if it is a system-wide or user-specific shell configuration file, as listed in the query.
114- Identify the process executable that triggered the alert and verify if it is part of the excluded benign processes. If not, investigate the process's origin and purpose.
115- Check the modification or creation timestamp of the file to correlate with any known user activities or scheduled tasks that might explain the change.
116- Examine the contents of the modified or newly created shell configuration file for any suspicious or unauthorized entries, such as unexpected scripts or commands.
117- Investigate the user account associated with the file modification to determine if the activity aligns with their typical behavior or if the account may have been compromised.
118- Cross-reference the alert with other security logs or alerts to identify any related suspicious activities or patterns that could indicate a broader attack campaign.
119
120### False positive analysis
121
122- System package managers like dpkg, rpm, and yum often modify shell configuration files during software installations or updates. To handle these, exclude processes with executables such as /bin/dpkg or /usr/bin/rpm from triggering alerts.
123- Automated system management tools like Puppet and Chef may alter shell configuration files as part of their routine operations. Exclude these processes by adding exceptions for executables like /opt/puppetlabs/puppet/bin/puppet or /usr/bin/chef-client.
124- User account management activities, such as adding new users, can lead to shell configuration file modifications. Exclude processes like /usr/sbin/adduser or /sbin/useradd to prevent false positives in these scenarios.
125- Temporary files created by text editors (e.g., .swp files) during editing sessions can trigger alerts. Exclude file extensions such as swp, swpx, and swx to avoid these false positives.
126- Virtualization and containerization tools like Docker and Podman may modify shell configuration files as part of their operations. Exclude executables like /usr/bin/dockerd or /usr/bin/podman to manage these cases.
127
128### Response and remediation
129
130- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
131- Review the modified or newly created shell configuration files to identify and remove any unauthorized or malicious code.
132- Restore the affected shell configuration files from a known good backup to ensure the system's environment is clean and secure.
133- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.
134- Monitor the system and network for any signs of re-infection or related suspicious activity, focusing on the indicators of compromise (IOCs) associated with the Kaiji malware family.
135- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
136- Implement additional monitoring and alerting for changes to shell configuration files to enhance detection of similar threats in the future."""
137
138[[rule.threat]]
139framework = "MITRE ATT&CK"
140
141[[rule.threat.technique]]
142id = "T1546"
143name = "Event Triggered Execution"
144reference = "https://attack.mitre.org/techniques/T1546/"
145
146[[rule.threat.technique.subtechnique]]
147id = "T1546.004"
148name = "Unix Shell Configuration Modification"
149reference = "https://attack.mitre.org/techniques/T1546/004/"
150
151[rule.threat.tactic]
152id = "TA0003"
153name = "Persistence"
154reference = "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 Shell Configuration Creation or Modification
Shell configuration files in Unix-like systems are crucial for setting up user environments by defining variables, aliases, and startup scripts. Adversaries exploit these files to execute malicious code persistently. The detection rule identifies suspicious creation or modification of these files, excluding benign processes, to flag potential threats, aligning with tactics like persistence and event-triggered execution.
Possible investigation steps
- Review the specific file path involved in the alert to determine if it is a system-wide or user-specific shell configuration file, as listed in the query.
- Identify the process executable that triggered the alert and verify if it is part of the excluded benign processes. If not, investigate the process's origin and purpose.
- Check the modification or creation timestamp of the file to correlate with any known user activities or scheduled tasks that might explain the change.
- Examine the contents of the modified or newly created shell configuration file for any suspicious or unauthorized entries, such as unexpected scripts or commands.
- Investigate the user account associated with the file modification to determine if the activity aligns with their typical behavior or if the account may have been compromised.
- Cross-reference the alert with other security logs or alerts to identify any related suspicious activities or patterns that could indicate a broader attack campaign.
False positive analysis
- System package managers like dpkg, rpm, and yum often modify shell configuration files during software installations or updates. To handle these, exclude processes with executables such as /bin/dpkg or /usr/bin/rpm from triggering alerts.
- Automated system management tools like Puppet and Chef may alter shell configuration files as part of their routine operations. Exclude these processes by adding exceptions for executables like /opt/puppetlabs/puppet/bin/puppet or /usr/bin/chef-client.
- User account management activities, such as adding new users, can lead to shell configuration file modifications. Exclude processes like /usr/sbin/adduser or /sbin/useradd to prevent false positives in these scenarios.
- Temporary files created by text editors (e.g., .swp files) during editing sessions can trigger alerts. Exclude file extensions such as swp, swpx, and swx to avoid these false positives.
- Virtualization and containerization tools like Docker and Podman may modify shell configuration files as part of their operations. Exclude executables like /usr/bin/dockerd or /usr/bin/podman to manage these cases.
Response and remediation
- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
- Review the modified or newly created shell configuration files to identify and remove any unauthorized or malicious code.
- Restore the affected shell configuration files from a known good backup to ensure the system's environment is clean and secure.
- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.
- Monitor the system and network for any signs of re-infection or related suspicious activity, focusing on the indicators of compromise (IOCs) associated with the Kaiji malware family.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
- Implement additional monitoring and alerting for changes to shell configuration files to enhance detection of similar threats in the future.
References
Related rules
- Shadow File Modification by Unusual Process
- Systemd Generator Created
- Systemd-udevd Rule File Creation
- Unusual SSHD Child Process
- Yum Package Manager Plugin File Creation