Emond abuse (MITRE ATT&CK T1546.014) is a macOS technique for persistence and privilege escalation. Emond is the Event Monitor Daemon. It accepts events from various services, runs them through a simple rules engine and takes action.
How attackers use it
The emond binary at /sbin/emond loads rules from /etc/emond.d/rules/. Rule files are plists that define a name, an event type and an action. Event types include system startup and user authentication. Actions include running a system command or sending an email.
MITRE notes emond will not launch unless a file exists in the QueueDirectories path /private/var/db/emondClients, set in the launch daemon file /System/Library/LaunchDaemons/com.apple.emond.plist.
An adversary writes a rule that executes commands when an event occurs. Since emond runs with root privileges, this can move an attacker from administrator to root.
How to detect it
- Unauthorized file creation or changes in
/etc/emond.d/rules/or/private/var/db/emondClients. - Execution of
/sbin/emondand the commands it launches, especially at boot or login. - Rules created by non-root users, or unexpected shell commands run by emond.
A read-only check on macOS is to list the rules directory: ls -la /etc/emond.d/rules/. On most fleets it should be empty or contain only what you put there.
How to reduce the risk
MITRE's mitigation is to disable the feature. Consider disabling emond by removing the launch daemon plist file for it, if you do not use it.
Quick check
Why does emond abuse raise privileges?
Emond runs as root through a launch daemon, so a rule created by an administrator executes its action with root permissions.
