Boot or Logon Initialization Scripts is ATT&CK T1037. It is mapped to two tactics, Persistence and Privilege Escalation, and it applies to ESXi, Linux, macOS, Network Devices and Windows.
Operating systems and devices run scripts automatically when a machine starts or a user logs in. Administrators use them for legitimate setup. Attackers use the same hook to make sure their code runs again after a reboot or a new session.
How attackers use it
MITRE explains that initialization scripts can perform administrative functions, often by running other programs or sending information to an internal logging server. They differ by operating system and by whether they apply locally or remotely.
An adversary can use these scripts to keep a foothold on a single system. Depending on how access to the scripts is configured, local credentials or an administrator account may be needed. There is also a privilege angle: some boot or logon initialization scripts run with higher privileges than the user, so modifying one can be a route to escalation.
The procedure examples on the page show the range. One group hijacked legitimate application-specific startup scripts so malware ran at startup. Another used a hidden shell script under /etc/rc.d/init.d to run a backdoor and rootkit. A campaign against network edge devices used malicious boot scripts to install a backdoor. Others installed an init.d startup script or a .conf file under /etc/init to keep persistence, and one modified boot process files under a temporary init path.
MITRE splits the technique into five sub-techniques: Windows logon scripts, macOS login hooks, network logon scripts, RC scripts and startup items. Each has its own post in this series.
Click through it at your own pace, or open it full screen.
How to detect it
The MITRE detection strategy is to monitor the modification and execution of these scripts, with one analytic per platform:
- Windows: changes to and execution of user or system logon scripts, for example in Registry Run keys or startup folders.
- Linux: changes to shell initialization scripts such as .bashrc, .profile and /etc/profile.
- macOS: modification and execution of login hook scripts, and LaunchAgents or LaunchDaemons used for persistence.
- ESXi: changes to rc.local.d or other rc scripts that run on boot.
- Network devices: changes to startup-config files that include boot scripts or scheduled execution routines.
Two data sources carry most of the weight. File integrity monitoring on the script locations tells you something changed. Process creation events tied to logon or boot time tell you something ran. Neither is enough alone, since both administrators and attackers touch these files.
A good habit is to keep a known-good copy or hash of every initialization script in your environment. Then a change is a diff you can review, not a question you cannot answer.
How to reduce the risk
MITRE lists two mitigations for the parent technique:
- Restrict registry permissions. Set proper permissions on registry hives so users cannot modify the keys that point to logon scripts.
- Restrict file and directory permissions. Limit write access to logon scripts to specific administrators.
Beyond MITRE's list, it helps to centralize who can change these scripts, to put them under change control, and to alert on any change outside a change window.
Check your own environment
A checklist to start with:
- Where do your logon scripts live (Group Policy, the NETLOGON share, local registry keys)?
- Who has write access to each of those locations?
- Are your Linux shell profiles and rc files under file integrity monitoring?
- Do your ESXi hosts and network devices have a known-good startup configuration to compare against?
Read-only commands to look around. Linux, list system startup script locations and their modification times:
ls -l /etc/rc.local /etc/init.d /etc/profile /etc/profile.d 2>/dev/null
Windows, check the per-user logon script registry value (the value may not exist, which is the normal state):
reg query HKCU\Environment /v UserInitMprLogonScript
macOS, list launch agents and daemons:
ls -l ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons
Quick check
Why is this technique listed under both Persistence and Privilege Escalation?
The scripts run automatically at boot or logon, which keeps code running after a restart. Some of them run with higher privileges than the account that planted the change, which can give the attacker more access.
Name one control that limits who can plant a malicious logon script.
Restricting write access to logon scripts to specific administrators, or setting permissions on the registry hives that hold script paths.
