XDG Autostart Entries are desktop startup configuration files used in Linux environments to launch applications automatically when a user signs in. Attackers abuse them for persistence by placing malicious entries in user autostart paths, so defenders should inspect autostart locations, file ownership and unexpected startup commands.
What XDG Autostart Entries Do
XDG Autostart Entries are desktop startup configuration files in Linux that tell the user session which applications to launch automatically at sign-in. In normal use, they support convenience and workflow continuity; in a security context, they also create a well-established persistence path.
How XDG Autostart Entries Are Structured
These entries are typically desktop launcher files placed in autostart locations that the desktop environment reads when a session begins. The file content usually points to a command, application, or script, so the security meaning of the entry depends on both the file path and the exact startup action it triggers.
Because the mechanism is session-driven, it can operate quietly after login rather than at boot. That makes it operationally simple for legitimate software, but also attractive when an attacker wants code to execute every time a user signs in.
For defenders, the practical question is not just whether an autostart file exists, but whether it belongs there, who owns it, and whether the command inside matches the software installed on the system. The same configuration surface that makes desktop startup predictable also makes it a useful place to hide unexpected execution.
Why XDG Autostart Entries Matter for Persistence
Autostart entries are one variant of logon persistence, a broader class of techniques used to regain execution after a reboot or new session. The core risk is that a malicious entry can blend into ordinary desktop behavior while silently restoring attacker code whenever the user returns.
That persistence is especially valuable to an intruder who already has write access to a user-writable startup path or can replace a trusted launcher. Once planted, the entry may survive routine use because it looks like part of the desktop session rather than an obvious system service.
NHIMG’s Persistence Techniques Guide places xdg autostart entries in the wider family of boot and logon persistence methods, which helps defenders compare this technique with other startup-based mechanisms.
How Defenders Inspect and Respond
Investigation starts with inventorying the autostart locations used by the desktop environment, then comparing each file against known software, expected ownership, and approved startup behavior. Unexpected command lines, unusual paths, or launcher files in user profiles that should not contain them deserve closer review.
If a malicious autostart entry is found, removal alone is not enough. Review adjacent startup locations, recent logon activity, and any files or scripts that the launcher references, because persistence often comes with related tampering. A post-removal check should also confirm that the same command was not planted elsewhere in the user session configuration.
For threat hunting, the most useful signals are changes to autostart files, new or modified launcher content, and execution that begins immediately after user sign-in. That is the point where a benign desktop convenience feature becomes a reliable attacker foothold.
Risk and Threat Considerations
XDG Autostart Entries are high-value persistence objects because they sit at the boundary between user convenience and unattended execution. If an attacker can plant or alter one, they can regain code execution at every sign-in without needing a kernel exploit or system service foothold.
Failure mechanism: Malicious launcher files are placed in a user-controlled autostart path, or a legitimate launcher is modified to invoke attacker-controlled commands during session startup.
Impact: The attacker gains recurring execution, which can support credential theft, surveillance, additional payload delivery, and continued access after the original compromise should have been removed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547.013 — XDG Autostart Entries | Defines XDG autostart as a logon persistence technique. |
| T1037 — Boot or Logon Autostart Execution | Covers startup-based execution that XDG autostart implements. | |
| Recommendation — Hunt for and remove unexpected XDG autostart persistence at sign-in. Correlate desktop startup execution with suspicious logon persistence. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Autostart files are configuration items that need baselining and review. |
| Recommendation — Baseline and audit desktop startup locations for unauthorized launcher files. | ||
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | Controls approved startup configuration and prevents unauthorized changes. |
| SI-4 — System Monitoring | Requires monitoring for suspicious changes and execution at logon. | |
| Recommendation — Define and enforce approved desktop startup settings and file locations. Monitor autostart path changes and sign-in execution for persistence indicators. | ||
Practitioner Guidance
What to watch for: Treat any new or changed autostart file as a persistence candidate, especially when the file owner, command target, or modification time does not match normal desktop software behavior. In practice, the most useful review is the one that asks whether the startup action is both expected and necessary for the user session.
Practitioner takeaway: Autostart review is a low-friction control with high value, because it catches a persistence path that is easy for attackers to hide inside everyday login behavior.
Related resources from NHI Mgmt Group
- How should security teams respond when a Node package uses autostart persistence and process masquerading on Windows endpoints?
- How should security teams handle credential entries that are valid across multiple URLs or subdomains?
- What do security teams get wrong about storing extra authentication data in vault entries?
- How should teams size an authorization system when relationship graphs grow from millions to 100 billion entries?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org