Login Hook macOS: Persistenza via com.apple.loginwindow.plist (T1037.002)

In un ingaggio red team su endpoint macOS, l'installazione di un login hook è un'operazione a bassa complessità che richiede però privilegi amministrativi. Il comando canonico documentato da Apple sfrutta l'utility defaults:

sudo defaults write com.apple.loginwindow LoginHook /path/to/script.sh

Lo script deve essere eseguibile (chmod +x) e di proprietà root per essere invocato correttamente da loginwindow. In modo speculare si imposta un logout hook con la chiave LogoutHook. La rimozione avviene con sudo defaults delete com.apple.loginwindow LoginHook.

Per un payload realistico in laboratorio, lo script bash può contenere una reverse shell verso un listener controllato, oppure invocare un binario Mach-O droppato in una directory scrivibile. Un pattern osservato consiste nel wrappare il payload malevolo in uno script che esegue anche un comando legittimo, riducendo il sospetto in caso di ispezione manuale. Ricorda che il payload gira come root indipendentemente dall'utente che effettua il login, un aspetto sfruttabile per lateral movement locale verso account amministrativi.

Per la fase di enumeration precedente, verifica la presenza di hook già configurati con:

sudo defaults read com.apple.loginwindow

Se una chiave LoginHook è già presente, sovrascriverla comprometterebbe un servizio legittimo (raro ma possibile in ambienti MDM legacy); considera invece di aggiungere comandi allo script esistente per mantenere la funzionalità originale ed evitare detection basate su comportamento anomalo dell'utente.

Sul piano tooling, il framework offensivo di riferimento per macOS è Mythic (open source), che nei payload Apfell/Poseidon include moduli di persistenza. Per validare la catena end-to-end in un lab isolato sono utili anche Empire (open source, fork attivo BC-Security) e i moduli macOS di Atomic Red Team (open source), che pubblica test T1037.002 riproducibili con il runner Invoke-AtomicTest.

Come consideration OPSEC: la tecnica lascia un artefatto binario molto evidente (il plist modificato) e la deprecazione ufficiale rende un login hook di per sé un IOC ad alta confidenza per un blue team preparato. In ingaggi contro target maturi, meccanismi Launch Agent con nomi camuffati offrono maggiore stealth. Il login hook resta però utile in scenari smash-and-grab, contro workstation aziendali con MDM datati o in retest per verificare che remediation precedenti abbiano coperto anche i vettori legacy.

Il monitoraggio di T1037.002 si fonda su due segnali complementari: modifiche al file plist /Library/Preferences/com.apple.loginwindow.plist e esecuzioni figlie anomale del processo loginwindow al momento del login utente. La detection strategy MITRE DET0244 con analytic AN0682 raccomanda esattamente questa correlazione tra modifica del plist e successiva esecuzione entro una finestra temporale ristretta.

Le log source principali sono la Unified Log di macOS (macos:unifiedlog) e la telemetria di file system events sui plist (fs:plist). Con lo Endpoint Security Framework di Apple, un agent EDR può intercettare gli eventi ES_EVENT_TYPE_NOTIFY_WRITE e ES_EVENT_TYPE_NOTIFY_RENAME sul path del plist. Sul fronte prodotti, Jamf Protect (a pagamento), CrowdStrike Falcon per macOS (a pagamento) e l'open source Santa di Google (open source, focalizzato su binary allowlisting ma utile per contesto processi) coprono questo scenario. Per stack SIEM personalizzati, osquery (open source) espone la tabella plist che permette query schedulate su /Library/Preferences/com.apple.loginwindow.plist con estrazione delle chiavi LoginHook e LogoutHook.

Un query osquery efficace estrae valore e path dello script:

SELECT key, value FROM plist WHERE path = '/Library/Preferences/com.apple.loginwindow.plist' AND key IN ('LoginHook','LogoutHook');

Qualsiasi risultato non vuoto merita triage manuale, data la deprecazione della funzionalità dal 2015.

Sul piano comportamentale, l'analytic AN0682 suggerisce di rompere la lineage attesa dei processi: il processo loginwindow dovrebbe generare figli noti (Dock, Finder, SystemUIServer). L'esecuzione di uno script bash, di un interprete Python o di un binario in path utente da parte di loginwindow è fortemente anomala. Il tuning previsto dalla strategy include quattro dimensioni: path dello script (che varia per ambiente), user context (con attenzione ad account privilegiati), finestra temporale tra modifica plist ed esecuzione, e nome del parent process per identificare masquerading.

I falsi positivi sono statisticamente rari data la deprecazione, ma possibili in ambienti con MDM legacy o script di onboarding aziendali storici. La strategia consigliata è baseline iniziale su tutta la flotta, whitelisting dei pochi hook legittimi documentati, e alerting ad alta severità su qualsiasi nuova modifica. Come controllo preventivo si applica la mitigazione M1022 (Restrict File and Directory Permissions): il plist deve essere writable solo da root e monitorato via File Integrity Monitoring con strumenti come Wazuh (open source) o osquery in modalità scheduled con diffing dei risultati.

L'analisi forense di un incidente che coinvolge un login hook macOS parte da un artefatto centrale e ben definito: /Library/Preferences/com.apple.loginwindow.plist. Su un disco acquisito (immagine E01 o DMG), questo file va estratto e parsato con plutil -p oppure convertito in XML con plutil -convert xml1. La presenza delle chiavi LoginHook o LogoutHook con un path arbitrario è di per sé un forte indicatore di compromissione, considerata la deprecazione ufficiale della funzionalità dal 2015.

La timeline di compromissione si ricostruisce correlando i timestamp MACB del plist (accessibili con stat o con Autopsy, open source, che parsa nativamente HFS+ e APFS) con gli eventi della Unified Log. La Unified Log macOS conserva tipicamente 7-30 giorni di eventi ed è interrogabile live con log show --predicate 'process == "loginwindow"' --last 7d oppure su immagine forense estraendo i file .tracev3 da /var/db/diagnostics/ e processandoli con UnifiedLogReader (open source) di Yogesh Khatri o con macos-UnifiedLogs in Rust (open source) di Mandiant.

Gli artefatti collaterali da raccogliere includono lo script referenziato dal login hook (spesso in /tmp, /Users/Shared/ o directory con nomi camuffati come /Library/Application Support/), il file stesso con le sue extended attributes (xattr -l) che rivelano se è stato scaricato via browser (attributo com.apple.quarantine), e la history bash/zsh dell'utente amministrativo che ha eseguito sudo defaults write. Su macOS moderni anche /var/db/sudo e la Unified Log registrano eventi sudo, permettendo di identificare l'account e il timestamp esatti della modifica.

Per un'analisi strutturata è utile il framework AutoMacTC (open source, sviluppato da CrowdStrike) che raccoglie in modo standardizzato plist di persistenza, launch items, browser history e quarantine events. In alternativa mac_apt (open source) di Yogesh Khatri estrae plist di persistenza da immagini offline. Entrambi producono output CSV/SQLite integrabili in Timesketch (open source) o Plaso/log2timeline (open source) per la costruzione della super timeline.

Un dettaglio investigativo rilevante: se lo script del login hook è stato eliminato dopo l'esecuzione, tecnica anti-forense comune, il plist può ancora referenziare un path inesistente. L'assenza del file target combinata con la presenza della chiave costituisce essa stessa un IOC significativo. Verifica sempre anche i backup Time Machine, che potrebbero conservare la versione originale dello script per analisi malware statica (con tool come Hopper Disassembler, a pagamento con demo gratuita, o Ghidra, open source).

I dati MITRE ATT&CK non riportano gruppi APT, software o campagne attualmente associati a T1037.002 Login Hook. Questa assenza documentale è di per sé un elemento di intelligence rilevante e va interpretata con attenzione da un Threat Intelligence Officer.

La deprecazione della funzionalità da parte di Apple nel 2015 (macOS 10.11 El Capitan) ha spinto la maggior parte degli attori sofisticati verso vettori di persistenza più moderni e stealthier sul mondo Apple: Launch Agent e Launch Daemon (T1543.001 e T1543.004), plist di LoginItems (T1547.015), abuso di Emond (deprecato anch'esso), e più recentemente XPC services. Le famiglie di macOS malware documentate pubblicamente negli ultimi anni — inclusi ecosistemi noti come XCSSET, Silver Sparrow, MacStealer, JokerSpy e i loader collegati a operazioni nord-coreane — favoriscono in modo netto Launch Agent con nomi che imitano software Apple legittimi.

Questo pattern suggerisce che il login hook rimanga un vettore residuale, potenzialmente utilizzato in tre scenari operativi: primo, attacchi opportunistici contro target con macOS legacy (10.10 e precedenti, dove la funzionalità non era ancora deprecata); secondo, red team engagement che testano copertura difensiva su vettori dimenticati; terzo, catene di persistenza multi-vettore dove il login hook affianca meccanismi più moderni come fallback ridondante, sfruttando proprio la scarsa attenzione difensiva dedicata a tecniche deprecate.

Dal punto di vista del threat landscape geografico, i gruppi con capacità offensive mature su macOS restano concentrati in poche aree: cluster nord-coreani (Lazarus e sub-cluster), operatori cinesi con focus su tecnologia e journalism, e commercial spyware vendor con base in EMEA. Nessuno di questi ha, nella documentazione MITRE, mapping esplicito verso Login Hook, ma il framework MITRE aggiorna i mapping in modo incrementale e assenza di attribuzione non equivale ad assenza di uso.

Per un programma di threat intelligence orientato alla difesa, la raccomandazione è di monitorare attivamente T1037.002 come indicatore ad alta confidenza: qualsiasi rilevamento in ambiente enterprise moderno merita triage prioritario, sia perché la funzionalità è deprecata (quindi baseline attesa vicina a zero), sia perché la sua presenza suggerisce un attaccante che conosce il sistema in profondità o al contrario che ricicla strumenti datati. Nel primo caso, indica sofisticazione e conoscenza di nicchia; nel secondo, opportunismo con toolkit obsoleti — due profili molto diversi che richiedono response calibrate. In entrambi gli scenari, la caccia dovrebbe estendersi immediatamente ad altri meccanismi di persistenza per identificare l'intera catena, dato che raramente il login hook è l'unico ancoraggio.

MITRE ATT&CK T1037.002 (Login Hook), tattiche TA0003 e TA0004. Mitigazione M1022 (Restrict File and Directory Permissions). Detection Strategy DET0244 con analytic AN0682. MITRE D3FEND per artefatti e controlli difensivi correlati. Le sezioni tecniche integrano conoscenza professionale su tool macOS (osquery, Santa, AutoMacTC, mac_apt, UnifiedLogReader, Mythic, Atomic Red Team, Jamf Protect, Wazuh) e comandi nativi macOS (defaults, plutil, log, xattr, stat) verificati contro documentazione ufficiale Apple e repository open source dei rispettivi progetti.