Emond
Where this stands
A reviewer read the telemetry and concluded there is nothing here to detect that a sibling technique does not already cover.
All four log sources in AN1534 resolve to the same Sigma logsource, {product: macos, service: unifiedlog}, and that logsource has no field vocabulary anywhere — not in this corpus (zero rules use it; grep 'service: unifiedlog' across data/detections/*/rule.yml returns nothing), not in the Sigma taxonomy, and not in the brief, which supplies no eventIds and no field names for any of the four entries. AUTHORING.md rule 1 forbids substituting a different logsource, so the categories that would carry this behaviour with real fields — {category: file_event, product: macos} with TargetFilename for the rule-plist write, {category: process_creation, product: macos} with Image/CommandLine for the emond-spawned shell — are not available; writing TargetFilename or Image under service: unifiedlog would invent a vocabulary and produce exactly the parses-everywhere-matches-nothing failure rule 1 exist […]
What the technique is
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. 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. 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.
Read it on attack.mitre.orgWhat MITRE says you would watch
- AN1534
Detection focuses on identifying unauthorized file creation or modification within /etc/emond.d/rules/ or /private/var/db/emondClients, which indicate attempts to register a malicious emond rule. Correlate with process execution of /sbin/emond and any launched commands it invokes, especially during boot or login events. Anomalies may include rules created by non-root users or unexpected shell commands executed by emond.
Technique names and descriptions © MITRE ATT&CK®, CC BY 4.0. Not endorsed by MITRE.