Home/ATT&CK Technique/Boot or Logon Initialization Scripts
ATT&CK Technique

Boot or Logon Initialization Scripts

T1037 · persistence, privilege-escalation

Adversaries may use scripts automatically executed at boot or logon initialization to establish persistence. Initialization scripts can be used to perform administrative functions, which may often execute other programs or send information to an internal logging server. These scripts can vary based on operating system and whether applied locally or remotely.

Adversaries may use these scripts to maintain persistence on a single system. Depending on the access configuration of the logon scripts, either local credentials or an administrator account may be necessary. An adversary may also be able to escalate their privileges since some boot or logon initialization scripts run with higher privileges.

ESXiLinuxmacOSNetwork DevicesWindows

Actors Using This

14
latin_america_brazilian_organized_cybercrimeAmavaldo
russiaAPT28
russiaAPT29
chinaAPT41
china_state_sponsored_mandiant_canonical_microsoft_mulberry_typhoonAPT5 (UNC2630 / UNC2717 / Mulberry Typhoon)
russia_speaking_cybercrime8Base
iran_linked_dragos_tracked_ics_activity_group_cyberav3ngers_persona_2024_disclosedBAUXITE
russia_speaking_cybercrimeBianLian
chinaBillbug
russia_apt_sandwormBlackEnergy
ransomware_raas_independent_emergenceCactus
russia_apt_sandwormCaddyWiper
latin_america_brazilian_organized_cybercrimeCasbaneiro / Metamorfo

Likely Attack Path

Techniques the same actors pair with this one distinctively - those showing up among actors who use this technique noticeably more than across all actors (lift > 1.15), grouped by kill-chain phase. The × is that lift multiplier; the shared-actor count is in the tooltip. A near-universal technique pairs with everything at baseline, so its list is short by design.
privilege-escalation later

Mitigations

2
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.
M1024Restrict Registry Permissions

Restricting registry permissions involves configuring access control settings for sensitive registry keys and hives to ensure that only authorized users or processes can make modifications. By limiting access, organizations can prevent unauthorized changes that adversaries might use for persistence, privilege escalation, or defense evasion.

Review and Adjust Permissions on Critical Keys
  • Regularly review permissions on keys such as Run, RunOnce, and Services to ensure only authorized users have write access.
  • Use tools like icacls or PowerShell to automate permission adjustments. Enable Registry Auditing.
  • Enable auditing on sensitive keys to log access attempts.
  • Use Event Viewer or SIEM solutions to analyze logs and detect suspicious activity.
  • Example Audit Policy: auditpol /set /subcategory:"Registry" /success:enable /failure:enable Protect Credential-Related Hives.
  • Limit access to hives like SAM,SECURITY, and SYSTEM to prevent credential dumping or other unauthorized access.
  • Use LSA Protection to add an additional security layer for credential storage. Restrict Registry Editor Usage.
  • Use Group Policy to restrict access to regedit.exe for non-administrative users.
  • Block execution of registry editing tools on endpoints where they are unnecessary. Deploy Baseline Configuration Tools.
  • Use tools like Microsoft Security Compliance Toolkit or CIS Benchmarks to apply and maintain secure registry configurations.
Tools for Implementation Registry Permission Tools
  • Registry Editor (regedit): Built-in tool to manage registry permissions.
  • PowerShell: Automate permissions and manage keys. Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "KeyName" -Value "Value".
  • icacls: Command-line tool to modify ACLs.
Monitoring Tools
  • Sysmon: Monitor and log registry events.
  • Event Viewer: View registry access logs.
Policy Management Tools
  • Group Policy Management Console (GPMC): Enforce registry permissions via GPOs.
  • Microsoft Endpoint Manager: Deploy configuration baselines for registry permissions.

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) none
Analytics (MITRE CAR) 2
Runtime / container (Falco) none
File / malware (YARA) none
Network (Suricata/Snort) 2
Vuln scan (Nuclei) none

CAR Analytics

2
MITRE Cyber Analytics Repository - field-tested detection logic for this technique, written as pseudocode/queries you adapt to your own SIEM (Splunk, Sentinel, EQL). Each is a ready starting point for a detection rule, not just a description.
CAR-2013-01-002Moderate coverageAutorun Differences

The Sysinternals tool [Autoruns](../sensors/autoruns) checks the registry and file system for known identify persistence mechanisms. It will output any tools identified, including built-in or added-on Microsoft functionality and third party software. Many of these locations are known by adversaries and used to obtain Persistence.

Running Autoruns periodically in an environment makes it possible to collect and monitor its output for differences, which may include the removal or addition of persistent tools. Depending on the persistence mechanism and location, legitimate software may be more likely to make changes than an adversary tool. Thus, this analytic may result in significant noise in a highly dynamic environment.

While Autoruns is a convenient method to scan for programs using persistence mechanisms its scanning nature does not conform well to streaming based analytics. This analytic could be replaced with one that draws from sensors that collect registry and file information if streaming analytics are desired. Utilizes the Sysinternals autoruns tool (ignoring validated Microsoft entries).

Primarily not a detection analytic by itself but through analysis of results by an analyst can be used for such. Building another analytic on top of this one identifying unusual entries would likely be a beneficial alternative.

CAR-2020-11-001Moderate coverageBoot or Logon Initialization Scripts

Adversaries may schedule software to run whenever a user logs into the system.

this is done to establish persistence and sometimes for lateral movement. This trigger is established through the registry key HKEY_CURRENT_USER\EnvironmentUserInitMprLogonScript. This signature looks edits to existing keys or creation of new keys in that path. Users purposefully adding benign scripts to this path will result in false positives.

that case is rare, however. There are other ways of running a script at startup or login that are not covered in this signature. Note that this signature overlaps with the Windows Sysinternals Autoruns tool, which would also show changes to this registry path.

Pseudocode - Pseudocode - logon run script key added to registry using reg.exe on commandline, or new logon scipt keys in registry from any source.
processes = search Process:Create
logon_script_key_processes = filter processes where (
  command_line = "*reg*add*\Environment*UserInitMprLogonScript")
registry = search (Registry:Add OR Registry:Edit)
registry_logon_key_events = filter registry where (
  key = "*\Environment*UserInitMprLogonScript")
output (logon_script_key_processes, registry_logon_key_events)
Splunk - Splunk Search -- logon scripts
(index=__your_sysmon_index__ EventCode=1 Image="C:\\Windows\\System32\\reg.exe" CommandLine="*add*\\Environment*UserInitMprLogonScript") OR (index=__your_sysmon_index__ (EventCode=12 OR EventCode=14 OR EventCode=13) TargetObject="*\\Environment*UserInitMprLogonScript")
LogPoint - LogPoint Search -- logon scripts
norm_id=WindowsSysmon ((event_id=1 image="C:\Windows\System32\reg.exe" command="*add*\Environment*UserInitMprLogonScript") OR (event_id IN [12, 13, 14] target_object="*\Environment*UserInitMprLogonScript"))

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