T1547: Boot or Logon Autostart Execution
Adversaries may configure system settings to automatically execute a program during system boot or logon to maintain persistence or gain higher-level privileges on compromised systems. Operating systems may have mechanisms for automatically running a program on system boot or account logon.[1][2][3][4][5] These mechanisms may include automatically executing programs that are placed in specially designated directories or are referenced by repositories that store configuration information, such as the Windows Registry. An adversary may achieve the same goal by modifying or extending features of the kernel.
Since some boot or logon autostart programs run with higher privileges, an adversary may leverage these to elevate privileges.
Analyst context for executives and security teams
Boot or Logon Autostart Execution matters because it turns a one-time compromise into repeat access. If an adversary can place or reference code in operating-system autostart locations, that code can run whenever a system boots or a user logs on, sometimes with higher privileges. For leaders, the business issue is not just malware startup; it is whether the organization can prove which boot/logon programs are authorized across Windows, Linux, macOS, and network devices.
Executive priority
Prioritize this technique as a persistence and privilege-escalation control area. It affects endpoint resilience, incident containment, audit evidence, and recovery confidence: a system may appear cleaned but become re-compromised after reboot or user login if autostart locations are not validated. Executives should ask whether SOC and IR teams have baseline visibility into authorized autostart mechanisms, especially on high-value Windows systems, Linux/macOS workstations and servers, and network devices where supported by local tooling.
Technical view
ATT&CK lists this as an enterprise technique for persistence and privilege escalation across Linux, macOS, Windows, and Network Devices. The relationship context shows many concrete sub-techniques: Windows Run keys/startup folders, LSA authentication packages, time providers, Winlogon helper DLLs, SSPs, LSASS drivers, shortcut modification, port monitors, and print processors; Linux/macOS kernel modules/extensions; macOS re-opened applications and login items; and Linux XDG autostart entries. There is no official detection text supplied for T1547, but a related detection strategy, DET0274, exists. SOC and IR validation should focus on change monitoring and baselining of boot/logon execution points, file and configuration changes, and processes launched at boot or logon under unexpected user or service contexts.
Likely telemetry
- Windows Registry changes for Run/RunOnce, LSA, Winlogon, time provider, SSP, LSASS driver, port monitor, and print processor configuration locations referenced by the related sub-techniques
- Startup folder and shortcut creation or modification events on Windows
- DLL, executable, driver, kernel module, plist, .desktop, and login item file creation/modification metadata
- Process execution events tied to system boot, user logon, LSA, Winlogon, Windows Time service, print spooler, or desktop environment startup
- Service or boot-time load events for drivers, kernel modules, extensions, and autostart components
Detection direction
- Build or validate baselines of authorized boot/logon autostart entries by platform and role; alert on new, modified, unsigned, unusual, or user-writable entries where local policy supports that judgment.
- Correlate configuration changes with subsequent boot/logon process execution so alerts distinguish dormant persistence from executed persistence.
- Tune separately for user-context autostarts and privileged/system-context autostarts; the latter should usually receive higher triage priority because ATT&CK notes some mechanisms run with higher privileges.
- For Windows, ensure coverage extends beyond common Run keys to LSA-related packages, Winlogon, time providers, port monitors, print processors, LSASS drivers, startup folders, and shortcuts as reflected in the sub-technique relationships.
- For Linux and macOS, validate collection for kernel modules/extensions, login items, plist changes, re-opened application behavior, and XDG Autostart entries where those platforms are in scope.
Mitigation priorities
- Inventory and approve expected boot/logon autostart mechanisms for critical systems first, then expand to broader endpoint and server populations.
- Restrict write access to privileged autostart configuration stores, startup locations, kernel/module paths, and service-related directories according to least privilege.
- Include autostart locations in incident response containment and eradication checklists before declaring a host recovered or reboot-safe.
- Maintain compliance evidence showing authorized autostart entries, ownership, business justification, and recent change history for high-risk systems.
- Harden administrative workflows so software deployment, printer/security component installation, and OS configuration changes are attributable and reviewable.
Analyst notes and limits
The supplied relationship set is especially useful because it decomposes T1547 into concrete platform-specific autostart mechanisms. Several related software and one group are documented as using this technique, which supports its relevance for threat-informed defense, but the supplied data should not be interpreted as current exploitation or environment-specific exposure.
The official ATT&CK detection field for this object is not provided, and the related DET0274 content is not included here. This take therefore avoids claiming specific detection logic or coverage. Local operating-system versions, endpoint logging configuration, network device capabilities, software inventory, and change-control data are required to determine actual risk and detection quality.
Boot or Logon Autostart Execution
Adversaries may configure system settings to automatically execute a program during system boot or logon to maintain persistence or gain higher-level privileges on compromised systems. Operating systems may have mechanisms for automatically running a program on system boot or account logon.[1][2][3][4][5] These mechanisms may include automatically executing programs that are placed in specially designated directories or are referenced by repositories that store configuration information, such as the Windows Registry. An adversary may achieve the same goal by modifying or extending features of the kernel.
Since some boot or logon autostart programs run with higher privileges, an adversary may leverage these to elevate privileges.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1547.009 | Shortcut Modification Sub-technique | Shortcut Modification subtechnique of this object. |
| Enterprise | T1547.006 | Kernel Modules and Extensions Sub-technique | Kernel Modules and Extensions subtechnique of this object. |
| Enterprise | T1547.007 | Re-opened Applications Sub-technique | Re-opened Applications subtechnique of this object. |
| Enterprise | T1547.004 | Winlogon Helper DLL Sub-technique | Winlogon Helper DLL subtechnique of this object. |
| Enterprise | T1547.005 | Security Support Provider Sub-technique | Security Support Provider subtechnique of this object. |
| Enterprise | T1547.001 | Registry Run Keys / Startup Folder Sub-technique | Registry Run Keys / Startup Folder subtechnique of this object. |
| Enterprise | T1547.008 | LSASS Driver Sub-technique | LSASS Driver subtechnique of this object. |
| Enterprise | T1547.012 | Print Processors Sub-technique | Print Processors subtechnique of this object. |
| Enterprise | T1547.014 | Active Setup Sub-technique | Active Setup subtechnique of this object. |
| Enterprise | T1547.015 | Login Items Sub-technique | Login Items subtechnique of this object. |
| Enterprise | T1547.013 | XDG Autostart Entries Sub-technique | XDG Autostart Entries subtechnique of this object. |
| Enterprise | T1547.003 | Time Providers Sub-technique | Time Providers subtechnique of this object. |
| Enterprise | T1547.002 | Authentication Package Sub-technique | Authentication Package subtechnique of this object. |
| Enterprise | T1547.010 | Port Monitors Sub-technique | Port Monitors subtechnique of this object. |
Groups, software, and campaigns
G1044: APT42
APT42 is an Iranian-sponsored threat group that conducts cyber espionage and surveillance.[1] The group primarily focuses on targets in the Middle East region, but has targeted a variety of industries and countries since at least 2015.[1] APT42 starts cyber operations through spearphishing emails and/or the PINEFLOWER Android malware, then monitors and collects information from the compromised systems and devices.[1] Finally, APT42 exfiltrates data using native features and open-source tools.[2]
APT42 activities have been linked to Magic Hound by other commercial vendors. While there are behavior and software overlaps between Magic Hound and APT42, they appear to be distinct entities and are tracked as separate entities by their originating vendor.
S0653: xCaon
S0567: Dtrack
S0084: Mis-Type
Mis-Type is a backdoor hybrid that was used in Operation Dust Storm by 2012.[1]
S0651: BoxCaon
BoxCaon is a Windows backdoor that was used by IndigoZebra in a 2021 spearphishing campaign against Afghan government officials. BoxCaon's name stems from similarities shared with the malware family xCaon.[1]
S0083: Misdat
Misdat is a backdoor that was used in Operation Dust Storm from 2010 to 2011.[1]
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.3 | Current bundle | f4a194dc37af… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Microsoft Run Key
Microsoft. (n.d.). Run and RunOnce Registry Keys. Retrieved September 12, 2024.
Open source URL -
[2]
MSDN Authentication Packages
Microsoft. (n.d.). Authentication Packages. Retrieved March 1, 2017.
Open source URL -
[3]
Microsoft TimeProvider
Microsoft. (n.d.). Time Provider. Retrieved March 26, 2018.
Open source URL -
[4]
Cylance Reg Persistence Sept 2013
Langendorf, S. (2013, September 24). Windows Registry Persistence, Part 2: The Run Keys and Search-Order. Retrieved November 17, 2024.
Open source URL -
[5]
Linux Kernel Programming
Pomerantz, O., Salzman, P.. (2003, April 4). The Linux Kernel Module Programming Guide. Retrieved April 6, 2018.
Open source URL -
[6]
TechNet Autoruns
Russinovich, M. (2016, January 4). Autoruns for Windows v13.51. Retrieved June 6, 2016.
Open source URL -
[7]
mitre-attack T1547Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.