Persistenza via Emond: Event Monitor Daemon (T1546.014)

Per riprodurre T1546.014 in un contesto di red team autorizzato su macOS, la sequenza operativa parte dalla verifica dello stato del daemon e dalla creazione degli artefatti richiesti. Su versioni recenti di macOS emond è stato deprecato, quindi la tecnica è realistica soprattutto su sistemi legacy (macOS 10.15 e precedenti) o in ambienti dove il daemon è stato preservato.

Il primo passo consiste nel verificare che il Launch Daemon sia caricato:

sudo launchctl list | grep emond

Successivamente si crea il file segnaposto nella QueueDirectory, indispensabile per attivare il servizio:

sudo touch /private/var/db/emondClients/redteam

A questo punto si prepara una regola plist in /etc/emond.d/rules/redteam.plist che dichiara un evento di tipo startup o periodic e associa un'azione RunCommand. La struttura tipica prevede le chiavi name, enabled, eventTypes e actions, con quest'ultima che punta al percorso del binario da eseguire e agli argomenti. Il payload può essere una reverse shell scritta in bash o Python, oppure il caricamento di un LaunchAgent secondario per ridurre la superficie di detection sulla regola stessa.

Una volta piazzata la regola, si forza il ricaricamento:

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.emond.plist sudo launchctl load /System/Library/LaunchDaemons/com.apple.emond.plist

Per la validazione dell'esecuzione con privilegi root, un semplice comando id > /tmp/emond_test.txt nella regola permette di confermare il contesto di esecuzione senza generare traffico di rete.

Sul fronte tooling, il framework Mythic (open source) offre agent macOS come Apfell e Poseidon che possono essere utilizzati per orchestrare il deployment del payload post-esecuzione della regola. Empire nella sua fork mantenuta da BC Security (open source) include moduli di persistenza macOS utili come riferimento architetturale. Per la generazione dei plist in modo programmatico, PlistBuddy è nativo del sistema:

/usr/libexec/PlistBuddy -c "Add :name string RedTeamRule" /etc/emond.d/rules/redteam.plist

In laboratorio è utile confrontare il comportamento con altre tecniche di persistenza macOS come i LaunchAgent e i LoginItem per costruire scenari di detection engineering realistici. Documentare l'orario esatto di creazione dei file e il comando di esecuzione consente al blue team di calibrare le regole di correlazione durante il debrief.

La detection di T1546.014 si costruisce attorno a tre pilastri: monitoraggio file system dei percorsi noti, correlazione con l'esecuzione del binario emond e analisi comportamentale dei processi figli generati con contesto root.

La strategia DET0555 definita da MITRE si concentra su creazioni o modifiche non autorizzate all'interno di /etc/emond.d/rules/ e /private/var/db/emondClients. Su macOS moderni la fonte primaria è macos:unifiedlog, il sistema di logging unificato accessibile via log show e log stream. Una query di baseline utile è:

log stream --predicate 'eventMessage CONTAINS "emond"' --info

Per la correlazione operativa, gli alert dovrebbero attivarsi quando un file plist viene creato in /etc/emond.d/rules/ da un processo padre diverso dai tool di provisioning aziendale (MDM come Jamf, Kandji, Mosyle). Un secondo indicatore ad alta confidenza è la creazione del file segnaposto in /private/var/db/emondClients seguita entro pochi minuti dal caricamento del Launch Daemon. Il TimeWindow di correlazione può essere calibrato in base al comportamento della flotta, tipicamente tra 60 e 300 secondi.

Gli EDR commerciali che coprono macOS come CrowdStrike Falcon, SentinelOne Singularity e Jamf Protect (tutti a pagamento) offrono telemetria nativa sui file event e sui process tree. Sul fronte open source, osquery (open source) permette query dirette sui Launch Daemons e sui file di regole:

SELECT * FROM file WHERE path LIKE '/etc/emond.d/rules/%'; SELECT * FROM launchd WHERE label LIKE '%emond%';

Integrando osquery con Fleet (open source) o Kolide (a pagamento) si ottiene visibilità continua sulla flotta.

I falsi positivi sono relativamente contenuti perché emond è pochissimo utilizzato legittimamente. Le eccezioni riguardano immagini golden datate o software di monitoraggio legacy che possono creare regole. Il tuning ParentProcessFilter suggerito da MITRE consiste nell'escludere processi firmati Apple e strumenti MDM aziendali dalla lista di allerta.

Dal punto di vista dei controlli preventivi, la mitigazione M1042 raccomanda la disabilitazione completa del Launch Daemon rimuovendo o rinominando il file plist di sistema, operazione fattibile in ambienti dove emond non è utilizzato (la quasi totalità dei casi). Il comando di disabilitazione è:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.emond.plist

Una policy MDM può distribuire questa configurazione su tutta la flotta e generare un evento di conformità in caso di riattivazione, trasformando la persistenza in un segnale forte piuttosto che debole.

L'analisi forense di un incidente che coinvolge T1546.014 parte dalla raccolta di quattro categorie di artefatti: i file di regola in /etc/emond.d/rules/, il file segnaposto in /private/var/db/emondClients, i log unificati di sistema e gli eventuali payload droppati dal comando eseguito dalla regola.

Su un'immagine macOS, l'esame del filesystem inizia dall'estrazione dei plist di regola con verifica di firma, autore e timestamp. Il comando plutil -p /etc/emond.d/rules/.plist* permette di visualizzare in forma leggibile il contenuto delle regole, inclusi i campi eventTypes e actions. La chiave RunCommand rivela il payload eseguito, mentre SendEmail può indicare esfiltrazione o segnalazione all'attaccante dell'avvenuta esecuzione.

I metadati temporali sono critici per costruire la timeline. Su HFS+ e APFS si estraggono creation time, modification time e last access con:

stat -f "%N %SB %Sm %Sa" /etc/emond.d/rules/.plist*

Correlando questi timestamp con il file in /private/var/db/emondClients si identifica il momento esatto della configurazione della persistenza. La divergenza tra creation time del file segnaposto e del plist di regola può indicare che l'attaccante ha piazzato la regola in un secondo momento, suggerendo accessi multipli.

I log unificati conservano evidenze dell'esecuzione di emond. L'estrazione avviene con:

log show --predicate 'process == "emond"' --last 30d

Su sistemi con storage limitato la ritenzione può essere inferiore a 30 giorni, quindi la raccolta va effettuata il prima possibile durante l'incident response. Il database dei log è accessibile anche offline dal percorso /var/db/diagnostics/ per analisi post-mortem su immagini disco.

Per la ricostruzione della catena di esecuzione, i payload lanciati da emond ereditano contesto root e sono visibili come processi figli del PID di emond. Se il payload è uno script shell, il file può risiedere in /tmp, /var/tmp o in directory nascoste sotto /Users/Shared/. L'analisi dei bash history o dei zsh history dell'utente compromesso completa il quadro sulle azioni preparatorie.

Sul fronte network forensics, se la regola includeva reverse shell o beaconing, i log DNS del resolver di sistema (/var/log/) e le catture PCAP dal perimetro consentono di ricostruire l'infrastruttura C2. La correlazione con database di passive DNS e Certificate Transparency (crt.sh è gratuito) aiuta a identificare domini registrati contestualmente all'intrusione. Il report forense dovrebbe documentare hash SHA-256 di tutti i file recuperati, catena di custodia e ricostruzione temporale minuto per minuto della finestra di compromissione.

Dal punto di vista della threat intelligence, T1546.014 rappresenta una tecnica di nicchia all'interno dell'arsenale offensivo macOS. I dati MITRE ATT&CK forniti non associano gruppi APT, software o campagne specifiche a questa sotto-tecnica, il che riflette due dinamiche complementari nel panorama delle minacce.

La prima dinamica riguarda la superficie d'attacco effettiva. Emond è stato progressivamente deprecato da Apple e la sua utilità come vettore di persistenza si è ridotta significativamente sulle versioni recenti di macOS. Gli attori sofisticati tendono a preferire meccanismi più affidabili e meno documentati come i LaunchAgent utente, i LaunchDaemon di terze parti, gli abusi di Login Items e le tecniche basate su cron o AppleScript. Questo spiega l'assenza di attribuzioni pubbliche consolidate su emond specificamente.

La seconda dinamica riguarda la visibilità. Molte compromissioni macOS mirate a target di alto valore rimangono non pubblicate o parzialmente documentate, e le tecniche di persistenza specifiche possono essere omesse dai report per proteggere metodi di detection. È plausibile che emond sia stato utilizzato in campagne mirate contro giornalisti, dissidenti o executive senza che l'attribuzione sia stata resa pubblica.

Dal punto di vista dei pattern osservabili, la tecnica si inserisce nel contesto più ampio della persistenza macOS che ha visto crescente interesse da parte di gruppi come quelli tradizionalmente associati alla Corea del Nord (con toolkit per macOS documentati in altre sotto-tecniche di ATT&CK) e a operazioni di sorveglianza commerciale. La convergenza tra spyware commerciale e capacità offensive statali sul target macOS ha ampliato l'interesse verso tutti i meccanismi di Event Triggered Execution del sistema Apple.

Per un programma di threat intelligence, il monitoraggio di T1546.014 dovrebbe integrarsi con feed specifici macOS come Objective-See (gratuito) mantenuto da Patrick Wardle, che pubblica regolarmente analisi di malware macOS e mantiene tool come KnockKnock e BlockBlock per il rilevamento di meccanismi di persistenza. Il progetto The DFIR Report e SentinelLabs pubblicano occasionalmente analisi tecniche su intrusioni macOS che possono contenere IOC utili.

La raccomandazione operativa per un CTI team è di trattare emond come indicatore di rischio più che come tecnica ad alta prevalenza: la presenza di modifiche a /etc/emond.d/rules/ su un endpoint aziendale è quasi certamente anomala e merita triage immediato. Integrare questa telemetria nel modello di priorità degli alert e nei playbook di threat hunting proattivo consente di trasformare una tecnica rara in un segnale ad altissima fedeltà, coerente con la strategia di detection DET0555 e con la mitigazione M1042 raccomandata da MITRE.

MITRE ATT&CK: tecnica T1546.014, tattiche TA0003 e TA0004, mitigazione M1042, strategia di detection DET0555 (AN1534 macOS). Log source: macos:unifiedlog. Per comandi operativi, tool (Mythic, Empire, osquery, Fleet, PlistBuddy, KnockKnock, BlockBlock) e procedure di forensics macOS è stata integrata conoscenza professionale di cybersecurity verificabile tramite documentazione ufficiale dei rispettivi progetti e repository pubblici.