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

T1037.005: Startup Items

Adversaries may use startup items automatically executed at boot initialization to establish persistence. Startup items execute during the final phase of the boot process and contain shell scripts or other executable files along with configuration information used by the system to determine the execution order for all startup items.[1]

This is technically a deprecated technology (superseded by Launch Daemon), and thus the appropriate folder, /Library/StartupItems isn’t guaranteed to exist on the system by default, but does appear to exist by default on macOS Sierra. A startup item is a directory whose executable and configuration property list (plist), StartupParameters.plist, reside in the top-level directory.

An adversary can create the appropriate folders/files in the StartupItems directory to register their own persistence mechanism.[2] Additionally, since StartupItems run during the bootup phase of macOS, they will run as the elevated root user.

EnterpriseT1037.005Sub-techniqueObject v1.1 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Startup Items is a macOS persistence and privilege-escalation technique where files placed under the legacy /Library/StartupItems mechanism can run during boot, potentially as root. Its business significance is not that it is common on every Mac, but that it represents a high-value persistence location on systems where this deprecated technology still exists or is tolerated. For leaders, this is a validation question: do managed Mac endpoints monitor legacy boot-time execution paths, or only modern mechanisms such as Launch Daemons?

Executive priority

Prioritize this as a macOS endpoint resilience and audit-evidence issue, especially for fleets that include older macOS versions or long-lived systems. Because Startup Items can execute at boot with elevated privileges, unauthorized changes can affect incident containment, rebuild decisions, and confidence in endpoint trust. Security leaders should ask whether file permissions, change monitoring, and incident response collection cover /Library/StartupItems and related plist/executable content, while recognizing that the directory may not exist by default on all macOS systems.

Technical view

For SOC, detection engineering, and IR teams, validate visibility for creation or modification of directories, shell scripts, executables, and StartupParameters.plist files in /Library/StartupItems. ATT&CK does not provide official detection text for this object, but the related detection strategy DET0429 indicates detection should focus on modification of macOS Startup Items. Treat this as part of the broader Boot or Logon Initialization Scripts family, with macOS-specific scoping and attention to privilege escalation because Startup Items run during boot as root. The software relationship to jRAT provides only a usage example from ATT&CK, not evidence of current activity in any environment.

Likely telemetry

  • macOS file creation, modification, deletion, and permission changes under /Library/StartupItems
  • File metadata and ownership for Startup Item directories, executable files, shell scripts, and StartupParameters.plist
  • Endpoint detection or host audit logs showing privileged writes to legacy startup paths
  • Configuration or asset inventory indicating whether /Library/StartupItems exists on managed macOS hosts
  • Boot-time execution evidence where available, correlated with recently changed Startup Item files

Detection direction

  • Baseline whether /Library/StartupItems exists across the macOS fleet; absence on many systems is expected because the technology is deprecated.
  • Alert on new or modified Startup Item directories, StartupParameters.plist files, shell scripts, or executables in the top-level StartupItems structure.
  • Prioritize events where non-administrative users, unexpected processes, or software deployment paths modify Startup Items.
  • Tune for legitimate administrative or legacy software installers that may still use Startup Items, while requiring change-control evidence for persistence-capable modifications.
  • Use the DET0429 relationship as the ATT&CK-supported detection direction: detect modification of macOS Startup Items.

Mitigation priorities

  • Apply M1022: restrict file and directory permissions so only authorized administrators or managed processes can write to sensitive startup locations.
  • Remove unnecessary write permissions on /Library/StartupItems where the directory exists, and verify ownership and permissions of any Startup Item content.
  • Use asset and configuration management to identify systems where this deprecated mechanism is present and determine whether it is still required.
  • Require change control for any legitimate Startup Item usage and investigate unmanaged or unexplained entries.
  • Include this path in macOS hardening, compliance evidence collection, and incident response triage checklists.
Analyst notes and limits

This technique is macOS-specific and is a sub-technique of Boot or Logon Initialization Scripts. The ATT&CK object emphasizes that Startup Items are deprecated and superseded by Launch Daemons, but the folder may still exist on some macOS versions such as macOS Sierra. The key defensive value is coverage validation for legacy persistence paths, not assuming every macOS endpoint is exposed.

Official ATT&CK detection text is not provided for this technique. The assessment is limited to the supplied ATT&CK fields, external references, and relationships; local endpoint configuration, macOS version distribution, EDR/audit policy, and administrative software behavior are required to determine actual exposure and detection coverage.

Official MITRE ATT&CK definition

Startup Items

Adversaries may use startup items automatically executed at boot initialization to establish persistence. Startup items execute during the final phase of the boot process and contain shell scripts or other executable files along with configuration information used by the system to determine the execution order for all startup items.[1]

This is technically a deprecated technology (superseded by Launch Daemon), and thus the appropriate folder, /Library/StartupItems isn’t guaranteed to exist on the system by default, but does appear to exist by default on macOS Sierra. A startup item is a directory whose executable and configuration property list (plist), StartupParameters.plist, reside in the top-level directory.

An adversary can create the appropriate folders/files in the StartupItems directory to register their own persistence mechanism.[2] Additionally, since StartupItems run during the bootup phase of macOS, they will run as the elevated root user.

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.

2 rows
Domain ID Name Relationship / procedure
Enterprise T1037 Boot or Logon Initialization Scripts This object subtechnique of Boot or Logon Initialization Scripts.
Enterprise T1165 Startup Items Startup Items revoked by this object.
Associated objects

Groups, software, and campaigns

Malware Enterprise

S0283: jRAT

jRAT is a cross-platform, Java-based backdoor originally available for purchase in 2012. Variants of jRAT have been distributed via a software-as-a-service platform, similar to an online subscription model.[1] [2]

LinuxWindowsmacOS
Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1022: Restrict File and Directory Permissions Enterprise uses · Malware S0283: jRAT Enterprise subtechnique of · Technique T1037: Boot or Logon Initialization Scripts Enterprise revoked by · Technique T1165: Startup Items Enterprise detects · Detection Strategy DET0429: Detect Modification of macOS Startup Items 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`.

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.1
Created
Modified
Raw hash
d529d771a67592d8...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle d529d771a675…
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]
    Startup Items

    Apple. (2016, September 13). Startup Items. Retrieved July 11, 2017.

    Open source URL
  2. [2]
    Methods of Mac Malware Persistence

    Patrick Wardle. (2014, September). Methods of Malware Persistence on Mac OS X. Retrieved July 5, 2017.

    Open source URL
  3. [3]
    mitre-attack T1037.005
    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