Home/ATT&CK Technique/Logon Script (Windows)
ATT&CK Technique

Logon Script (Windows)

T1037.001 · persistence, privilege-escalation

Adversaries may use Windows logon scripts automatically executed at logon initialization to establish persistence. Windows allows logon scripts to be run whenever a specific user or group of users log into a system. This is done via adding a path to a script to the HKCU\Environment\UserInitMprLogonScript Registry key.

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.

Windows

Actors Using This

5
russiaAPT28
russia_speaking_cybercrimeBianLian
latin_america_brazilian_organized_cybercrimeGrandoreiro
latin_america_brazilian_organized_cybercrimeGuildma / Astaroth
latin_america_brazilian_organized_cybercrimeJavali

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

Atomic Tests

1
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.
command_promptwindowsLogon Scripts
Adds a registry value to run batch script created in the %temp% directory. Upon execution, there will be a new environment variable in the HKCU\Environment key that can be viewed in the Registry Editor.
echo "#{script_command}" > #{script_path}
REG.exe ADD HKCU\Environment /v UserInitMprLogonScript /t REG_SZ /d "#{script_path}" /f

Mitigations

1
MITRE ATT&CK mitigations - vendor-agnostic guidance for reducing exposure to this technique.
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) 3
Analytics (MITRE CAR) 2
Runtime / container (Falco) none
File / malware (YARA) none
Network (Suricata/Snort) none
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

NIST 800-53AC-17, CM-07
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