Pacchetti di Installazione Malevoli: Installer Packages (T1546.016)

In un contesto di red team autorizzato, la simulazione di T1546.016 richiede la costruzione di installer funzionanti che incorporino payload negli hook di installazione. Su macOS il tool nativo è pkgbuild (open source, incluso nei Command Line Tools di Xcode), che permette di specificare una directory --scripts contenente file preinstall e postinstall. Un flusso tipico prevede la creazione della struttura di root con pkgbuild --root ./payload --scripts ./scripts --identifier com.test.demo --version 1.0 output.pkg, dove lo script postinstall è un semplice shell script eseguibile che scrive un plist in /Library/LaunchDaemons/ e lo carica con launchctl load.

Per ottenere maggior realismo si può usare productbuild (open source) per firmare il pacchetto con un Developer ID valido, aggirando parzialmente Gatekeeper. Il framework Mythic C2 (open source) include payload macOS come Poseidon che si prestano a essere impacchettati in questo modo, ed è utile per esercizi di detection engineering.

Su Linux il vettore equivalente si costruisce con dpkg-deb (open source, incluso in Debian/Ubuntu). La directory DEBIAN/ del pacchetto contiene i maintainer script: basta creare un file postinst eseguibile con shebang #!/bin/bash che aggiunga un cron job, un systemd unit o una backdoor SSH, poi impacchettare con dpkg-deb --build ./mypackage. Per RPM il flusso equivalente usa rpmbuild (open source) con la sezione %post dello spec file.

Su Windows la costruzione di MSI malevoli passa da WiX Toolset (open source) o dalla più rapida alternativa Advanced Installer (freemium). WiX permette di definire Custom Actions di tipo Type 34 (esecuzione di file installati) o Type 3072 (esecuzione di script embedded). Un pattern classico è dichiarare una CustomAction che invoca cmd.exe /c verso uno script droppato in %TEMP%. Per test rapidi è possibile abusare del tool msiexec.exe con la sintassi /i package.msi /quiet per validare il comportamento silente.

Per scenari di supply chain simulata, tool come Sigstore cosign (open source) e la manipolazione di ambienti CI/CD (GitLab Runner, Jenkins) permettono di riprodurre la catena osservata in C0057, dove l'attaccante compromise l'ambiente di build prima della firma del pacchetto legittimo. Fondamentale documentare hash prima/dopo e mantenere l'attività confinata in VM isolate senza connettività a repository di produzione.

La detection di T1546.016 si basa sulla correlazione tra eventi di installazione e successive attività anomale dei processi figli. Il pattern chiave è: un processo installer legittimo genera un child process che non appartiene al normale ciclo di installazione. Il framework D3FEND suggerisce di concentrarsi su Process Spawn Analysis e Script Execution Analysis come contromisure principali.

Su macOS la fonte primaria è macos:unifiedlog consultabile con log show --predicate 'process == "installer"' --last 1h oppure via streaming con log stream. L'alert deve triggerare quando /usr/sbin/installer genera figli diversi dai binari attesi (shove, installd, package_script_service). Particolarmente sospetto è l'avvio di bash, sh, python, osascript o curl come discendenti diretti di package_script_service, soprattutto se lo script postinstall scrive in /Library/LaunchDaemons/, /Library/LaunchAgents/ o /private/var/. Attenzione ai falsi positivi generati da MDM legittimi come Jamf e Munki, che orchestrano installer come parte della normale gestione di flotta e vanno inseriti in una allowlist di parent process.

Su Linux la telemetria arriva da auditd:SYSCALL con regole mirate. Una regola auditctl -w /var/lib/dpkg/info/ -p wa -k pkg_scripts traccia le modifiche ai maintainer script installati, mentre -a always,exit -F arch=b64 -S execve -F ppid=$(pidof dpkg) cattura le esecuzioni figlie di dpkg. Il sospetto cresce quando un postinst esegue wget, curl, nc o modifica /etc/systemd/system/, /etc/cron.d/, /root/.ssh/authorized_keys. I falsi positivi tipici vengono da pacchetti che legittimamente creano utenti di servizio o abilitano unit systemd.

Su Windows la piattaforma di riferimento è WinEventLog:Sysmon con configurazione derivata dal template di SwiftOnSecurity (open source). Gli eventi chiave sono EventID 1 (Process Create) filtrando su ParentImage: msiexec.exe con child image path in %TEMP%\MSI*.tmp, C:\Users\Public\ o cartelle fuori da Program Files. L'EventID 11 (File Create) di Sysmon rileva DLL o EXE droppati da msiexec.exe in percorsi anomali. Anche il canale nativo Microsoft-Windows-Application-Experience/Program-Inventory e i log MSI in %WINDIR%\Installer\ forniscono contesto. Utile costruire una baseline dei publisher MSI firmati abituali dell'ambiente e allertare su deviazioni.

La correlazione più efficace unisce tre segnali in una finestra di 60 secondi: esecuzione installer, scrittura in path di persistenza, avvio di processo di rete verso IP esterno non presente in threat intel allowlist.

L'analisi forense post-incidente di T1546.016 parte dagli artefatti dell'installer stesso, che tipicamente sopravvivono al deployment. Su macOS la directory /var/db/receipts/ contiene i file .bom (Bill of Materials) e .plist di ogni pacchetto installato: il comando pkgutil --pkgs elenca tutti i pacchetti registrati, mentre pkgutil --files enumera i file installati e pkgutil --info fornisce timestamp e identificativo. L'analisi del .bom con lsbom /var/db/receipts/.bom rivela la struttura originale del pacchetto.

Gli script preinstall e postinstall non vengono conservati sul sistema dopo l'installazione, quindi la ricostruzione richiede il recupero del .pkg originale, spesso reperibile in ~/Downloads/, ~/Library/Caches/ o nei log del browser. La unified log di macOS mantiene traccia dell'esecuzione: log show --predicate 'subsystem == "com.apple.install"' --start "2024-01-01" permette query temporali. Fondamentali gli artefatti di persistenza risultanti: /Library/LaunchDaemons/, /Library/LaunchAgents/, ~/Library/LaunchAgents/, ciascuno con timestamp stat che deve essere correlato al timestamp di installazione. Nel caso C0057, l'analisi rivelò che AppleJeus aveva aggiunto una .dylib malevola dentro il pacchetto .dmg dell'applicazione 3CX per macOS, con la libreria che veniva caricata al primo avvio dell'applicazione principale.

Su Linux il database di dpkg in /var/lib/dpkg/status e i log in /var/log/dpkg.log e /var/log/apt/history.log forniscono la cronologia completa delle installazioni con timestamp precisi. I maintainer script rimangono estratti in /var/lib/dpkg/info/<package>.postinst e possono essere confrontati con l'originale ottenuto ri-scaricando il .deb dal mirror ufficiale e usando dpkg-deb -e package.deb ./extracted. Per RPM l'equivalente è rpm -qp --scripts package.rpm che estrae gli script embedded, mentre rpm -qa --last fornisce la timeline di installazione. I log auditd in /var/log/audit/audit.log, se attivi al momento del compromise, contengono le syscall execve generate dagli script.

Su Windows la cache MSI in C:\Windows\Installer\ conserva copie dei pacchetti installati con nomi randomizzati recuperabili tramite il registro in HKLM\SOFTWARE\Classes\Installer\Products\. Il tool Orca (gratuito, Microsoft Windows SDK) permette di aprire file .msi ed esaminare la tabella CustomAction, evidenziando eventuali payload embedded. Il registro *HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall* fornisce la lista completa dei prodotti con GUID, publisher e InstallDate. Le tracce Prefetch di msiexec.exe e dei processi figli in C:\Windows\Prefetch\ completano la timeline con dati di prima e ultima esecuzione.

Dai dati disponibili emerge un caso di studio dominante per T1546.016: la campagna C0057 (3CX Supply Chain Attack), attiva tra novembre 2022 e marzo 2023, condotta dal cluster UNC4736 associato all'operatore AppleJeus. Questa attribuzione posiziona la tecnica all'interno dell'ecosistema noto per essere collegato a operatori nordcoreani con interesse primario nel settore finanziario e delle criptovalute, storicamente motivati da obiettivi di generazione di ricavi per lo stato sponsor.

La peculiarità strategica di C0057 è l'aver rappresentato il primo caso pubblicamente documentato di una supply chain compromise che ne innesca un'altra: l'accesso iniziale avvenne quando un dipendente 3CX scaricò ed eseguì una versione trojanizzata ed end-of-life del software di trading X_Trader di Trading Technologies. Da questo pivot, gli operatori compromise gli ambienti di build sia Windows sia macOS utilizzati per distribuire l'applicazione 3CX Desktop, dimostrando una capacità matura di manipolare pipeline CI/CD in ambienti eterogenei.

AppleJeus (S0584) è il software di riferimento per questa tecnica nei dati MITRE. La sua implementazione sfrutta due varianti operative: nella modalità standalone utilizza gli script postinstall per estrarre un plist nascosto dalla cartella /Resources dell'applicazione ed eseguirlo come Launch Daemon con privilegi elevati; nella variante osservata durante C0057, il malware iniettò una .dylib malevola dentro il pacchetto .dmg dell'installer macOS di 3CX, sfruttando quindi il meccanismo di caricamento librerie oltre agli script di post-installazione. Questa dualità mostra padronanza tecnica sia degli hook di installazione sia dei meccanismi di dynamic linking di macOS.

Il target scope della campagna è indicativo: pur avendo 3CX una base installata di 600.000 clienti e 12 milioni di utenti, il targeting secondario si concentrò selettivamente su vittime nei settori difesa e criptovalute, dove vennero deployati payload aggiuntivi come Gopuram per credential theft e persistenza estesa. Questo pattern di supply chain di massa con exploitation selettiva è diventato un modello di riferimento per successive operazioni analoghe.

Il trend rilevabile è chiaro: gli installer packages rappresentano un vettore privilegiato per attori state-sponsored che pianificano compromise di lunga durata su target ad alto valore. La combinazione di firma valida del vendor legittimo (che aggira Gatekeeper, SmartScreen e la maggior parte dei controlli EDR baseline) con privilegi ereditati root/SYSTEM rende la tecnica particolarmente adatta a scenari dove l'obiettivo è ottenere foothold persistente prima della detection. Per le organizzazioni nei settori target, il monitoring delle build pipeline e la verifica di integrità dei pacchetti installati diventano controlli critici, non opzionali.

MITRE ATT&CK: T1546.016 (Installer Packages), tattiche TA0003 e TA0004. Software S0584 (AppleJeus). Campagna C0057 (3CX Supply Chain Attack, 2022-2023). Detection strategies DET0330 con analytic AN0938 (macOS unified log), AN0939 (Linux auditd), AN0940 (Windows Sysmon). Framework MITRE D3FEND per contromisure Process Spawn Analysis e Script Execution Analysis. Integrata conoscenza professionale su tool open source (pkgbuild, dpkg-deb, WiX Toolset, Orca, Sysmon) e sintassi di comandi nativi per costruzione lab e analisi forense.