AN0326: Analytic 0326
Creation of LaunchAgents or LaunchDaemons with names resembling known system services but executing non-Apple signed code or scripts.
Analyst context for executives and security teams
This analytic is about spotting macOS persistence-like configuration where LaunchAgents or LaunchDaemons are created with names that look like legitimate system services but point to non-Apple-signed code or scripts. For leaders, the value is not the file name alone; it is whether the organization can prove that macOS service-startup locations are monitored, code-signing trust is visible, and suspicious masquerading can be investigated quickly.
Executive priority
Treat this as a macOS resilience and audit-readiness control check. If Macs are material to executives, developers, administrators, or regulated workflows, security leaders should ask whether endpoint logging can show who created or changed LaunchAgent/LaunchDaemon items, whether the executed payload is Apple-signed, and whether SOC playbooks distinguish approved enterprise agents from suspicious system-like names. This supports incident scoping, managed detection validation, and evidence for endpoint control effectiveness.
Technical view
For macOS only, validate detection around creation or modification of LaunchAgents and LaunchDaemons whose names resemble known system services while executing non-Apple-signed binaries or scripts. Because no official detection logic is supplied, teams should build or test analytics using local endpoint telemetry: plist path and label, executable or script target, code-signing status, creator process/user, file ownership and permissions, and subsequent launchd-driven execution. Tuning should account for legitimate enterprise management tools that install launch items but should still verify signing, naming, path consistency, and approved ownership.
Likely telemetry
- macOS file creation and modification events for LaunchAgents and LaunchDaemons locations
- Property list metadata including label, program, program arguments, and target path
- Code-signing or trust metadata showing whether the executed file is Apple-signed
- Process execution telemetry involving launchd and the configured executable or script interpreter
- User, parent process, timestamp, ownership, and permission metadata for created launch items
Detection direction
- Validate visibility into creation and modification of LaunchAgent and LaunchDaemon plist files on macOS systems.
- Correlate system-like service names with non-Apple-signed executables or scripts rather than alerting on naming alone.
- Tune allowlists for known enterprise management, security, and software update agents using signing, path, and ownership evidence.
- Review blind spots where file telemetry exists but code-signing status, plist contents, or launchd execution context is not collected.
- Prioritize investigation when a newly created launch item uses a trusted-looking name but points to a script, unusual path, or unsigned/non-Apple-signed payload.
Mitigation priorities
- Establish an approved inventory of macOS LaunchAgents and LaunchDaemons for managed devices.
- Require endpoint controls and logging that capture plist changes, executable targets, and code-signing status.
- Limit administrative rights and unauthorized software installation where operationally feasible.
- Use change-control or device management policy to validate legitimate launch items deployed by IT and security tools.
- Create an incident response checklist for suspicious launch items, including collection of plist contents, target files, signing data, owner, timestamps, and related process activity.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, AN0326, for enterprise ATT&CK on macOS. It has no supplied tactics, relationships, or official detection logic. The practical interpretation is therefore limited to the official description: creation of LaunchAgents or LaunchDaemons with system-service-like names that execute non-Apple-signed code or scripts.
No relationship context, tactic mapping, procedure examples, or official detection query was supplied. This take does not assert active exploitation, attribution, impact, or guaranteed detection coverage. Local macOS management practices and approved enterprise agents are required to separate suspicious masquerading from legitimate software.
Analytic 0326
Creation of LaunchAgents or LaunchDaemons with names resembling known system services but executing non-Apple signed code or scripts.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.0 | Current bundle | a2f4fc5fc918… |
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]
mitre-attack AN0326Open 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.