Home/ATT&CK Technique/Unix Shell Configuration Modification
ATT&CK Technique

Unix Shell Configuration Modification

T1546.004 · privilege-escalation, persistence

Adversaries may establish persistence through executing malicious commands triggered by a user’s shell. User Unix Shells execute several configuration scripts at different points throughout the session based on events. For example, when a user opens a command-line interface or remotely logs in (such as via SSH) a login shell is initiated.

The login shell executes scripts from the system (/etc) and the user’s home directory (~/) to configure the environment. All login shells on a system use /etc/profile when initiated. These configuration scripts run at the permission level of their directory and are often used to set environment variables, create aliases, and customize the user’s environment.

When the shell exits or terminates, additional shell scripts are executed to ensure the shell exits appropriately. Adversaries may attempt to establish persistence by inserting commands into scripts automatically executed by shells. Using bash as an example, the default shell for most GNU/Linux systems, adversaries may add commands that launch malicious binaries into the /etc/profile and /etc/profile.d files.

These files typically require root permissions to modify and are executed each time any shell on a system launches. For user level permissions, adversaries can insert malicious commands into ~/.bash_profile, ~/.bash_login, or ~/.profile which are sourced when a user opens a command-line interface or connects remotely. Since the system only executes the first existing file in the listed order, adversaries have used ~/.bash_profile to ensure execution.

Adversaries have also leveraged the ~/.bashrc file which is additionally executed if the connection is established remotely or an additional interactive shell is opened, such as a new tab in the command-line interface. Some malware targets the termination of a program to trigger execution, adversaries can use the ~/.bash_logout file to execute malicious commands at the end of a session. For macOS, the functionality of this technique is similar but may leverage zsh, the default shell for macOS 10.15+.

When the Terminal.app is opened, the application launches a zsh login shell and a zsh interactive shell. The login shell configures the system environment using /etc/profile, /etc/zshenv, /etc/zprofile, and /etc/zlogin. The login shell then configures the user environment with ~/.zprofile and ~/.zlogin.

The interactive shell uses the ~/.zshrc to configure the user environment. Upon exiting, /etc/zlogout and ~/.zlogout are executed. For legacy programs, macOS executes /etc/bashrc on startup.

LinuxmacOS

Actors Using This

1

Atomic Tests

7
Executable Atomic Red Team test cases for exercising this technique in a lab. Copy a command, run it on the listed platform, confirm your detections fire.
shmacos, linuxAdd command to .bash_profile
Adds a command to the .bash_profile file of the current user
echo '#{command_to_add}' >> ~/.bash_profile
shmacos, linuxAdd command to .bashrc
Adds a command to the .bashrc file of the current user
echo '#{command_to_add}' >> ~/.bashrc
shlinuxAdd command to .shrc
Adds a command to the .shrc file of the current user
echo '#{command_to_add}' >> ~/.shrc
shelevatedlinuxAppend to the system shell profile
An adversary may wish to establish persistence by executing malicious commands from the systems /etc/profile every time "any" user logs in.
echo '#{text_to_append}' >> /etc/profile
shlinuxAppend commands user shell profile
An adversary may wish to establish persistence by executing malicious commands from the users ~/.profile every time the "user" logs in.
echo '#{text_to_append}' >> ~/.profile
shelevatedlinuxSystem shell profile scripts
An adversary may wish to establish persistence by adding commands into any of the script files in the /etc/profile.d/ directory, which are executed every time "any" user logs in.
echo '#{text_to_append}' >> /etc/profile.d/bash_completion.sh
bashelevatedlinuxCreate/Append to .bash_logout
The Bash shell runs ~/.bash_logout "if it exists" to run commands on user logout. An adversary may create or append to a .bash_logout to clear history, start processes etc. Note the ~/.bash_logout is only run if you explicitly exit or log out of an "interactive login shell session" i.e. via the console, SSH, /bin/bash -l or su -l <username>. This test creates the art user, logs in, creates a .bash_logout which will echo some text into the art.txt file on logout and logs out and the /home/art/art.txt is created.
useradd --create-home --shell /bin/bash art
su -l art -c "echo 'echo \"Atomic Red Team was here... T1546.004\" >> /home/art/art.txt' >> /home/art/.bash_logout; exit"

Mitigations

1
MITRE ATT&CK mitigations - vendor-agnostic guidance for reducing exposure to this technique.
M1022Restrict File and Directory Permissions

Restricting file and directory permissions involves setting access controls at the file system level to limit which users, groups, or processes can read, write, or execute files. By configuring permissions appropriately, organizations can reduce the attack surface for adversaries seeking to access sensitive data, plant malicious code, or tamper with system files.

Enforce Least Privilege Permissions
  • Remove unnecessary write permissions on sensitive files and directories.
  • Use file ownership and groups to control access for specific roles. Example (Windows): Right-click the shared folder.
  • Properties.
  • Security tab.
  • Adjust permissions for NTFS ACLs.
Harden File Shares
  • Disable anonymous access to shared folders.
  • Enforce NTFS permissions for shared folders on Windows. Example: Set permissions to restrict write access to critical files, such as system executables (e.g., /bin or /sbin on Linux). Use tools like chown and chmod to assign file ownership and limit access. On Linux, apply: chmod 750 /etc/sensitive.conf `chown root:admin /etc/sensitive.
conf` File Integrity Monitoring (FIM)
  • Use tools like Tripwire, Wazuh, or OSSEC to monitor changes to critical file permissions.
Audit File System Access
  • Enable auditing to track permission changes or unauthorized access attempts.
  • Use auditd (Linux) or Event Viewer (Windows) to log activities.
Restrict Startup Directories
  • Configure permissions to prevent unauthorized writes to directories like C:\ProgramData\Microsoft\Windows\Start Menu. Example: Restrict write access to critical directories like /etc/, /usr/local/, and Windows directories such as C:\Windows\System32.
  • On Windows, use icacls to modify permissions: icacls "C:\Windows\System32" /inheritance:r /grant:r SYSTEM:(OI)(CI)F.
  • On Linux, monitor permissions using tools like lsattr or auditd.

Detection Coverage

2/6 layers
Coverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).
Behavioral / log (Sigma) 1
Analytics (MITRE CAR) none
Runtime / container (Falco) 2
File / malware (YARA) none
Network (Suricata/Snort) none
Vuln scan (Nuclei) none

Falco Runtime Rules

2
Container / Linux runtime detections that fire on this technique.
WARNINGRead Shell Configuration File
This rule detects attempts made by non-shell programs to read shell configuration files. It offers additional generic auditing. It serves as a baseline detection alert for unusual shell configuration file accesses. The rule "Modify Shell Configuration File" might be more relevant and adequate for your specific cases.
view condition
open_read and (fd.filename in (shell_config_filenames) or
     fd.name in (shell_config_files) or
     fd.directory in (shell_config_directories))
and not proc.name in (shell_binaries)
WARNINGModify Shell Configuration File
Detect attempts to modify shell configuration files, primarily aimed at establishing persistence by automatically inserting commands into scripts executed by shells. The upstream rule excludes shell processes because they often create unnecessary noise. However, this might lead to missed detections. To customize the rule for your situation, you can fine-tune it using enhanced profiling. For example, you might want to only consider interactive shell processes (where proc.tty != 0).
view condition
open_write and (fd.filename in (shell_config_filenames) or
     fd.name in (shell_config_files) or
     fd.directory in (shell_config_directories))
and not proc.name in (shell_binaries) and not exe_running_docker_save and not user_known_shell_config_modifiers

Comply & Defend

Intelligence Graph · click any node to traverse
CVETechnique ActorTool Family
drag to reposition · click any node to traverse · button top-right enlarges
External lookups - second-class, for what we don’t hold ourselves
Vulnerabilities
CISA KEV catalog
CWE weaknesses
CAPEC attack patterns
Package vulnerabilities
Threat intelligence
Threat actors
Tools & malware
ATT&CK techniques
IOCs
Detection & defense
Sigma rules
YARA rules
Atomic Red Team tests
D3FEND countermeasures
Compliance
NIST 800-53
ISO 27001:2022
SOC 2 TSC
PCI-DSS v4.0
CIS Controls v8.1
About
All capabilities
Live statistics
Data sources
Privacy policy
Terms of service
threatengine.sh  ·  Open-source threat intelligence platform  ·  100+ authoritative sources  ·  Every fact traces to its origin