Detecting and Mitigating Boot or Logon Autostart (T1547)

Boot or Logon Autostart Execution (MITRE ATT&CK T1547) is a persistence and privilege escalation technique. It spans Linux, macOS, Windows and network devices. The idea is to configure the system so a program starts on its own at boot or when someone logs on.

Operating systems offer many ways to do this on purpose, and defenders rely on them too. That is exactly why the technique is common, and why it pays to know where each autostart mechanism lives.

How attackers use it

MITRE describes two families of mechanism. The first is special directories, or stores of configuration information such as the Windows registry, that the system reads to decide what to run. The second is modifying or extending kernel features, which can also cause code to run at startup.

Privilege matters here. Some autostart programs run with higher privileges than the user who set them up, so an adversary may use them to escalate as well as persist.

The parent technique is a family, and several members are covered in their own guides:

• Registry Run Keys and Startup Folder (T1547.001).
• Authentication Package (T1547.002).
• Time Providers (T1547.003).
• Other members, for example for Winlogon, kernel modules and extensions, login items on macOS, and more, which sit alongside these in the ATT&CK matrix.

How to detect it

MITRE's strategy for the parent has one analytic per operating system:

• Windows. Correlate registry modifications for Run and RunOnce keys with abnormal parent and child process relationships, and with outlier execution at user logon or system startup.
• Linux. Correlate creation or modification of systemd service files or /etc/init.d scripts with outlier process behavior during boot.
• macOS. Watch for creation or modification of LaunchAgent and LaunchDaemon plist files combined with anomalous execution of the plist payload after user logon.

The common approach is a baseline. List what starts at boot and logon on your standard builds, store the list, and compare. Anything new is a question worth asking. Pair the diff with the process view: new autostart entries that execute from temp folders, user profiles or other user writable paths deserve the quickest look.

How to reduce the risk

MITRE lists no mitigations for the parent technique, because the right controls depend on the mechanism. The sub-technique pages give specifics. Controls that apply broadly are:

1. Restrict write access. Limit who can write to Run keys, startup folders, unit directories and launch plist folders.
2. Use application control. Allow only known and signed software to execute, which turns a rogue autostart entry into a blocked launch.
3. Limit privileges. Autostarts that run as SYSTEM or root are the ones that escalate, so reduce who can create them.
4. Keep a baseline. Record the expected autostart entries and review drift.

Check your own environment

Read-only commands, by platform:

# Windows (command prompt): common run keys
reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run
reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run

# Linux: units set to start at boot
systemctl list-unit-files --state=enabled
ls -la /etc/init.d/

# macOS: launch plist folders
ls -la /Library/LaunchDaemons /Library/LaunchAgents ~/Library/LaunchAgents

For each result, check four things:

1. Is the owner or vendor known?
2. Does the path point at a protected folder?
3. Is the file signed, where signing is available?
4. Does the entry appear on other machines of the same build?

Quick check

Sources

• MITRE ATT&CK T1547, Boot or Logon Autostart Execution