Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1547.013: XDG Autostart Entries

Adversaries may add or modify XDG Autostart Entries to execute malicious programs or commands when a user’s desktop environment is loaded at login. XDG Autostart entries are available for any XDG-compliant Linux system. XDG Autostart entries use Desktop Entry files (`.desktop`) to configure the user’s desktop environment upon user login. These configuration files determine what applications launch upon user login, define associated applications to open specific file types, and define applications used to open removable media.[1][2]

Adversaries may abuse this feature to establish persistence by adding a path to a malicious binary or command to the `Exec` directive in the `.desktop` configuration file. When the user’s desktop environment is loaded at user login, the `.desktop` files located in the XDG Autostart directories are automatically executed. System-wide Autostart entries are located in the `/etc/xdg/autostart` directory while the user entries are located in the `~/.config/autostart` directory.

Adversaries may combine this technique with Masquerading to blend malicious Autostart entries with legitimate programs.[3]

EnterpriseT1547.013Sub-techniqueObject v1.2 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

XDG Autostart Entries matter because they give Linux desktop applications a normal way to launch at user login, which also gives an intruder a low-friction persistence point. For organizations with Linux workstations, developer endpoints, cryptocurrency-related users, or privileged administrative desktops, unauthorized changes in user or system autostart locations can let malicious code return after reboot or re-login while looking like routine desktop behavior.

Executive priority

Treat this as a Linux endpoint resilience and identity-control issue, not only a malware artifact. Leaders should ask whether Linux desktops and workstations are in endpoint monitoring scope, whether user account privileges limit who can write to autostart locations, and whether incident response playbooks include login persistence checks. This is especially relevant where Linux endpoints support software development, sensitive administration, or other high-value user activity, because persistence at login can extend an intrusion even after initial malware removal.

Technical view

This sub-technique applies to Linux and supports persistence and privilege-escalation tactics under Boot or Logon Autostart Execution. Defenders should validate monitoring of `.desktop` file creation or modification in `/etc/xdg/autostart` and `~/.config/autostart`, with attention to the `Exec` directive and entries that invoke unusual binaries, scripts, interpreters, or commands. Because MITRE notes possible blending through Masquerading, triage should compare file names, locations, ownership, timestamps, and executed paths against expected desktop applications. The relationship to DET0390 indicates an ATT&CK detection strategy exists, but the supplied technique object does not include official detection text, so local detection logic must be verified against actual endpoint telemetry.

Likely telemetry

  • Linux file creation, modification, ownership, and permission changes for `/etc/xdg/autostart` and `~/.config/autostart`
  • Contents of `.desktop` files, especially `Exec` directives and referenced executable paths
  • User login/session start events for Linux desktop environments
  • Process execution events spawned during or shortly after user desktop login
  • Endpoint inventory or baseline data for approved autostart entries

Detection direction

  • Baseline legitimate system-wide and per-user XDG Autostart entries, then alert on new, modified, hidden, or misleading `.desktop` files.
  • Inspect `Exec` values for references to unexpected paths, renamed binaries, scripts, remote administration tools, or commands inconsistent with the entry name.
  • Correlate autostart file changes with subsequent login-time process execution to reduce noise and improve incident confidence.
  • Tune for legitimate software installers and desktop environment updates, which may create or modify valid autostart entries.
  • Prioritize high-value Linux users and shared systems where user-writable autostart persistence could materially affect response and containment.

Mitigation priorities

  • Apply least privilege and user account management so ordinary users and unnecessary service accounts cannot modify system-wide autostart locations.
  • Restrict file and directory permissions on sensitive autostart directories, especially `/etc/xdg/autostart`, while reviewing user-level autostart exposure.
  • Limit unauthorized software installation and execution so unapproved binaries or scripts referenced by autostart entries are less likely to run successfully.
  • Include XDG Autostart locations in Linux hardening standards, endpoint configuration reviews, and incident response persistence checklists.
  • Maintain an approved baseline of expected autostart entries for audit evidence and faster investigation.
Analyst notes and limits

Relationships show use by multiple cross-platform or Linux-capable malware/software entries, including Pupy, NETWIRE, CrossRAT, Fysbis, RotaJakiro, and InvisibleFerret, and by the Contagious Interview group. These relationships support defensive prioritization but should not be interpreted as proof of current activity in any environment. The most important local validation question is whether Linux desktop persistence paths are monitored with enough file and process context to distinguish legitimate desktop configuration from suspicious login execution.

The supplied ATT&CK object has no official detection text, and DET0390 details were not provided beyond the relationship. The assessment is limited to Linux XDG-compliant desktop behavior described in the object and does not establish active exploitation, customer exposure, or guaranteed detection coverage. Environment-specific baselines are required because legitimate autostart entries are common.

Official MITRE ATT&CK definition

XDG Autostart Entries

Adversaries may add or modify XDG Autostart Entries to execute malicious programs or commands when a user’s desktop environment is loaded at login. XDG Autostart entries are available for any XDG-compliant Linux system. XDG Autostart entries use Desktop Entry files (`.desktop`) to configure the user’s desktop environment upon user login. These configuration files determine what applications launch upon user login, define associated applications to open specific file types, and define applications used to open removable media.[1][2]

Adversaries may abuse this feature to establish persistence by adding a path to a malicious binary or command to the `Exec` directive in the `.desktop` configuration file. When the user’s desktop environment is loaded at user login, the `.desktop` files located in the XDG Autostart directories are automatically executed. System-wide Autostart entries are located in the `/etc/xdg/autostart` directory while the user entries are located in the `~/.config/autostart` directory.

Adversaries may combine this technique with Masquerading to blend malicious Autostart entries with legitimate programs.[3]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1547 Boot or Logon Autostart Execution This object subtechnique of Boot or Logon Autostart Execution.
Associated objects

Groups, software, and campaigns

Malware Enterprise

S0198: NETWIRE

NETWIRE is a publicly available, multiplatform remote administration tool (RAT) that has been used by criminal and APT groups since at least 2012.[1][2][3]

WindowsLinuxmacOS
Tool Enterprise

S0192: Pupy

Pupy is an open source, cross-platform (Windows, Linux, OSX, Android) remote administration and post-exploitation tool. [1] It is written in Python and can be generated as a payload in several different ways (Windows exe, Python file, PowerShell oneliner/file, Linux elf, APK, Rubber Ducky, etc.). [1] Pupy is publicly available on GitHub. [1]

LinuxWindowsmacOS
Malware Enterprise

S1245: InvisibleFerret

InvisibleFerret is a modular python malware that is leveraged for data exfiltration and remote access capabilities.[1][2][3] InvisibleFerret consists of four modules: main, payload, browser, and AnyDesk.[1] InvisibleFerret malware has been leveraged by North Korea-affiliated threat actors identified as DeceptiveDevelopment or Contagious Interview since 2023.[4][2][3][5] InvisibleFerret has historically been introduced to the victim environment through the use of the BeaverTail malware.[6][1][2][3][5]

LinuxmacOSWindows
Malware Enterprise

S1078: RotaJakiro

RotaJakiro is a 64-bit Linux backdoor used by APT32. First seen in 2018, it uses a plugin architecture to extend capabilities. RotaJakiro can determine it's permission level and execute according to access type (`root` or `user`).[1][2]

Linux
Relationship explorer

All related ATT&CK context

uses · Malware S0198: NETWIRE Enterprise mitigates · Mitigation M1022: Restrict File and Directory Permissions Enterprise uses · Group G1052: Contagious Interview Enterprise uses · Tool S0192: Pupy Enterprise mitigates · Mitigation M1018: User Account Management Enterprise mitigates · Mitigation M1033: Limit Software Installation Enterprise detects · Detection Strategy DET0390: Linux Detection Strategy for T1547.013 - XDG Autostart Entries Enterprise uses · Malware S1245: InvisibleFerret Enterprise subtechnique of · Technique T1547: Boot or Logon Autostart Execution Enterprise uses · Malware S0235: CrossRAT Enterprise uses · Malware S1078: RotaJakiro Enterprise uses · Malware S0410: Fysbis Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1022: Restrict 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`.

Mitigation Enterprise

M1018: User Account Management

User Account Management involves implementing and enforcing policies for the lifecycle of user accounts, including creation, modification, and deactivation. Proper account management reduces the attack surface by limiting unauthorized access, managing account privileges, and ensuring accounts are used according to organizational policies. This mitigation can be implemented through the following measures:

Enforcing the Principle of Least Privilege

- Implementation: Assign users only the minimum permissions required to perform their job functions. Regularly audit accounts to ensure no excess permissions are granted. - Use Case: Reduces the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions.

Implementing Strong Password Policies

- Implementation: Enforce password complexity requirements (e.g., length, character types). Require password expiration every 90 days and disallow password reuse. - Use Case: Prevents adversaries from gaining unauthorized access through password guessing or brute force attacks.

Managing Dormant and Orphaned Accounts

- Implementation: Implement automated workflows to disable accounts after a set period of inactivity (e.g., 30 days). Remove orphaned accounts (e.g., accounts without an assigned owner) during regular account audits. - Use Case: Eliminates dormant accounts that could be exploited by attackers.

Account Lockout Policies

- Implementation: Configure account lockout thresholds (e.g., lock accounts after five failed login attempts). Set lockout durations to a minimum of 15 minutes. - Use Case: Mitigates automated attack techniques that rely on repeated login attempts.

Multi-Factor Authentication (MFA) for High-Risk Accounts

- Implementation: Require MFA for all administrative accounts and high-risk users. Use MFA mechanisms like hardware tokens, authenticator apps, or biometrics. - Use Case: Prevents unauthorized access, even if credentials are stolen.

Restricting Interactive Logins

- Implementation: Restrict interactive logins for privileged accounts to specific secure systems or management consoles. Use group policies to enforce logon restrictions. - Use Case: Protects sensitive accounts from misuse or exploitation.

*Tools for Implementation*

Built-in Tools:

- Microsoft Active Directory (AD): Centralized account management and RBAC enforcement. - Group Policy Object (GPO): Enforce password policies, logon restrictions, and account lockout policies.

Identity and Access Management (IAM) Tools:

- Okta: Centralized user provisioning, MFA, and SSO integration. - Microsoft Azure Active Directory: Provides advanced account lifecycle management, role-based access, and conditional access policies.

Privileged Account Management (PAM): - CyberArk, BeyondTrust, Thycotic: Manage and monitor privileged account usage, enforce session recording, and JIT access.

Mitigation Enterprise

M1033: Limit Software Installation

Prevent users or groups from installing unauthorized or unapproved software to reduce the risk of introducing malicious or vulnerable applications. This can be achieved through allowlists, software restriction policies, endpoint management tools, and least privilege access principles. This mitigation can be implemented through the following measures:

Application Whitelisting

- Implement Microsoft AppLocker or Windows Defender Application Control (WDAC) to create and enforce allowlists for approved software. - Whitelist applications based on file hash, path, or digital signatures.

Restrict User Permissions

- Remove local administrator rights for all non-IT users. - Use Role-Based Access Control (RBAC) to restrict installation permissions to privileged accounts only.

Software Restriction Policies (SRP)

- Use GPO to configure SRP to deny execution of binaries from directories such as `%AppData%`, `%Temp%`, and external drives. - Restrict specific file types (`.exe`, `.bat`, `.msi`, `.js`, `.vbs`) to trusted directories only.

Endpoint Management Solutions

- Deploy tools like Microsoft Intune, SCCM, or Jamf for centralized software management. - Maintain a list of approved software, versions, and updates across the enterprise.

Monitor Software Installation Events

- Enable logging of software installation events and monitor Windows Event ID 4688 and Event ID 11707 for software installs. - Use SIEM or EDR tools to alert on attempts to install unapproved software.

Implement Software Inventory Management

- Use tools like OSQuery or Wazuh to scan for unauthorized software on endpoints and servers. - Conduct regular audits to detect and remove unapproved software.

*Tools for Implementation*

Application Whitelisting:

- Microsoft AppLocker - Windows Defender Application Control (WDAC)

Endpoint Management:

- Microsoft Intune - SCCM (System Center Configuration Manager) - Jamf Pro (macOS) - Puppet or Ansible for automation

Software Restriction Policies:

- Group Policy Object (GPO) - Microsoft Software Restriction Policies (SRP)

Monitoring and Logging:

- Splunk - OSQuery - Wazuh (open-source SIEM and XDR) - EDRs

Inventory Management and Auditing:

- OSQuery - Wazuh

Change history

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 .

ATT&CK release
19.1
Object version
1.2
Created
Modified
Raw hash
ea1540e318eb9a01...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.2 Current bundle ea1540e318eb…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Free Desktop Application Autostart Feb 2006

    Free Desktop. (2006, February 13). Desktop Application Autostart Specification. Retrieved September 12, 2019.

    Open source URL
  2. [2]
    Free Desktop Entry Keys

    Free Desktop. (2017, December 24). Recognized Desktop Entry Keys. Retrieved November 17, 2024.

    Open source URL
  3. [3]
    Red Canary Netwire Linux 2022

    TONY LAMBERT. (2022, June 7). Trapping the Netwire RAT on Linux. Retrieved September 28, 2023.

    Open source URL
  4. [4]
    mitre-attack T1547.013
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use