T1546.014: Emond
Adversaries may gain persistence and elevate privileges by executing malicious content triggered by the Event Monitor Daemon (emond). Emond is a Launch Daemon that accepts events from various services, runs them through a simple rules engine, and takes action. The emond binary at /sbin/emond will load any rules from the /etc/emond.d/rules/ directory and take action once an explicitly defined event takes place.
The rule files are in the plist format and define the name, event type, and action to take. Some examples of event types include system startup and user authentication. Examples of actions are to run a system command or send an email. The emond service will not launch if there is no file present in the QueueDirectories path /private/var/db/emondClients, specified in the Launch Daemon configuration file at/System/Library/LaunchDaemons/com.apple.emond.plist.[1][2][3]
Adversaries may abuse this service by writing a rule to execute commands when a defined event occurs, such as system start up or user authentication.[1][2][3] Adversaries may also be able to escalate privileges from administrator to root as the emond service is executed with root privileges by the Launch Daemon service.
Analyst context for executives and security teams
Emond is a macOS event mechanism that can run actions when events such as startup or user authentication occur. The business significance is that a small, OS-native configuration change can create persistence and potentially run with root privileges, making it easy to miss if macOS endpoint monitoring focuses only on obvious login items or user-level agents.
Executive priority
Treat this as a macOS persistence and privilege-escalation validation item. Leaders should ask whether managed detection, incident response playbooks, and endpoint hardening standards include native macOS launch and event-triggered mechanisms, not just malware signatures. For audit and resilience purposes, teams should be able to show whether emond is needed, whether its rule locations are monitored, and how unauthorized changes would be investigated.
Technical view
This is a macOS sub-technique under Event Triggered Execution. Defenders should validate visibility into /sbin/emond behavior, /etc/emond.d/rules/ plist rule files, the QueueDirectories path /private/var/db/emondClients, and the Launch Daemon configuration at /System/Library/LaunchDaemons/com.apple.emond.plist. Because ATT&CK provides no official detection text for this object, detection engineering should be based on the related DET0555 strategy and local baselining of legitimate emond use. IR teams should examine rule names, event types, actions, file creation or modification times, and any commands launched by emond, especially around startup and user authentication events.
Likely telemetry
- macOS file creation, modification, and permission metadata for /etc/emond.d/rules/
- plist content collection or endpoint configuration inventory for emond rule files
- process execution telemetry showing commands launched by emond or related launchd activity
- Launch Daemon configuration state for /System/Library/LaunchDaemons/com.apple.emond.plist
- presence or changes in /private/var/db/emondClients
Detection direction
- Confirm whether DET0555 or equivalent local analytics cover event-triggered execution via emond on macOS.
- Baseline whether emond is used at all in the environment; unexpected rule files or newly introduced QueueDirectories content should be reviewed.
- Alert on creation or modification of plist rules under /etc/emond.d/rules/ and correlate with process execution from emond.
- Tune carefully for legitimate administrative or OS-related use where present; false positives are most likely where teams intentionally use emond rules.
- Check for blind spots in macOS endpoint logging, especially if file integrity monitoring does not include system rule directories or if process telemetry does not retain parent-child execution context.
Mitigation priorities
- Determine whether emond is required on managed macOS systems; if unnecessary, consider disabling or removing the feature consistent with mitigation M1042.
- Restrict and monitor administrative write access to emond-related directories and configuration paths.
- Include emond rule locations in configuration compliance checks and endpoint file monitoring.
- Ensure macOS incident response procedures include review of Launch Daemons and event-triggered persistence mechanisms, not only common login or startup items.
Analyst notes and limits
The object is specific to macOS and maps to persistence and privilege escalation. The key defensive value is validating control coverage around native event-triggered execution and root-context daemon behavior. The revoked T1519 object points to this sub-technique, so current content should reference T1546.014 rather than the revoked technique ID.
ATT&CK does not provide official detection logic for this object in the supplied fields. The take is limited to the official description, external references, and relationships provided; local evidence is required to determine whether emond is present, legitimate, disabled, or abused in any specific environment.
Emond
Adversaries may gain persistence and elevate privileges by executing malicious content triggered by the Event Monitor Daemon (emond). Emond is a Launch Daemon that accepts events from various services, runs them through a simple rules engine, and takes action. The emond binary at /sbin/emond will load any rules from the /etc/emond.d/rules/ directory and take action once an explicitly defined event takes place.
The rule files are in the plist format and define the name, event type, and action to take. Some examples of event types include system startup and user authentication. Examples of actions are to run a system command or send an email. The emond service will not launch if there is no file present in the QueueDirectories path /private/var/db/emondClients, specified in the Launch Daemon configuration file at/System/Library/LaunchDaemons/com.apple.emond.plist.[1][2][3]
Adversaries may abuse this service by writing a rule to execute commands when a defined event occurs, such as system start up or user authentication.[1][2][3] Adversaries may also be able to escalate privileges from administrator to root as the emond service is executed with root privileges by the Launch Daemon service.
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 | T1519 | Emond | Emond revoked by this object. |
| Enterprise | T1546 | Event Triggered Execution | This object subtechnique of Event Triggered Execution. |
All related ATT&CK context
Mitigation direction
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.1 | Current bundle | 558399cb6798… |
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]
xorrior emond Jan 2018
Ross, Chris. (2018, January 17). Leveraging Emond on macOS For Persistence. Retrieved September 10, 2019.
Open source URL -
[2]
magnusviri emond Apr 2016
Reynolds, James. (2016, April 7). What is emond?. Retrieved September 10, 2019.
Open source URL -
[3]
sentinelone macos persist Jun 2019
Stokes, Phil. (2019, June 17). HOW MALWARE PERSISTS ON MACOS. Retrieved September 10, 2019.
Open source URL -
[4]
mitre-attack T1546.014Open 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.