Abuso di Piattaforme di Distribuzione Software: Software Deployment Tools (T1072)

L'obiettivo di un red team engagement su T1072 è dimostrare che chi controlla la piattaforma di deployment controlla l'intera rete. La simulazione parte dall'enumerazione degli strumenti presenti nell'ambiente e arriva all'esecuzione remota su target multipli.

Fase 1 — Discovery dell'infrastruttura di deployment. Su un host Windows domain-joined, verifica la presenza del client SCCM interrogando il namespace WMI relativo:

Get-WmiObject -Namespace "root\ccm" -Class SMS_Client

Se il risultato mostra una versione attiva, l'ambiente utilizza SCCM e l'host è gestito. Per Intune, controlla la registrazione dell'endpoint tramite:

dsregcmd /status

Il campo MdmUrl popolato indica enrollment attivo in un MDM. Su ambienti Linux, verifica la presenza di Ansible cercando connessioni SSH ricorrenti da un orchestratore con last o ispezionando i log di configurazione sotto /var/log/ansible/ se configurati centralizzati. Per Puppet, controlla il servizio con systemctl status puppet e il certificato sotto /etc/puppetlabs/puppet/ssl/.

Fase 2 — Abuso di SCCM. Lo strumento SharpSCCM (open source) consente di interagire con l'infrastruttura SCCM da un host compromesso. Il comando per eseguire codice su un target specifico attraverso il meccanismo di Application Deployment:

SharpSCCM.exe exec -d <target_device_name> -p "cmd.exe /c whoami > C:\temp\proof.txt"

Per un approccio di ricognizione, SCCMHunter (open source) permette di enumerare site server, distribution point e account di servizio dall'interno del dominio. Questi tool richiedono che l'operatore disponga di credenziali con permessi sulla console SCCM — tipicamente ottenuti tramite compromissione di un account IT.

Fase 3 — Abuso di piattaforme cloud. Su AWS, se l'operatore ha compromesso credenziali con permesso ssm:SendCommand, può eseguire comandi su istanze EC2 gestite:

aws ssm send-command --document-name "AWS-RunPowerShellScript" --targets "Key=instanceids,Values=i-0123456789abcdef0" --parameters commands="whoami"

Su Intune, un Global Administrator può pubblicare uno script PowerShell tramite il portale di gestione che verrà eseguito come SYSTEM su tutti i dispositivi enrolled. Per PDQ Deploy — lo stesso tool usato nella campagna C0018 per distribuire AvosLocker — la simulazione è immediata se si accede alla console: basta creare un pacchetto con il payload e assegnarlo a una collection di target.

Fase 4 — Validazione. Al termine dell'esecuzione, raccogli evidenze (screenshot, output dei comandi, timestamp) e dimostra che il perimetro di blast radius corrisponde all'intera population gestita dalla piattaforma. Il deliverable per il cliente deve evidenziare quanti endpoint sono raggiungibili con un singolo task di deployment.

Il punto critico della detection su T1072 è che le piattaforme di deployment eseguono codice in modo legittimo ogni giorno. L'analisi AN0623 individua il pattern fondamentale lato Windows: processi come CCMExec.exe o CcmExec.exe che generano figli inusuali — PowerShell, cmd.exe, mshta.exe — in contesto SYSTEM fuori dalle finestre di manutenzione. I log necessari sono WinEventLog:Security e WinEventLog:Application. L'EventCode 4688 (Process Creation) con command line auditing abilitato è la sorgente primaria: filtra per ParentImage contenente i binari del deployment agent e User uguale a SYSTEM, correlando con l'orario.

Il tuning è essenziale per sopravvivere ai falsi positivi. Costruisci una allowlist dei binari SCCM legittimi (CCMExec.exe, TSManager.exe, ServiceHost.exe) e degli account di servizio schedulati. Ogni alert che non corrisponde a queste baseline merita indagine. Imposta una TimeWindow che rifletta le finestre di manutenzione documentate: un deployment alle 3 di notte di martedì è atteso, lo stesso deployment alle 14 di un venerdì fuori ciclo è anomalo.

Su Linux (AN0624), monitora tramite auditd le syscall execve originate da processi figli di Ansible, Puppet o Chef. La chiave è incrociare l'IP sorgente della connessione SSH con la lista degli orchestratori autorizzati (DeployingHostAllowList). Un nodo non gestito che riceve improvvisamente un playbook Ansible è un indicatore forte.

Per ambienti macOS (AN0625), il focus è sui processi generati da JAMF o Munki: Terminal, osascript o bash lanciati dal JAMF agent con autorità di firma non riconosciuta sono immediatamente sospetti. Verifica la signing authority dello script contro la baseline.

In ambienti cloud (AN0626), i log AWS CloudTrail registrano ogni invocazione di SendCommand su Systems Manager. Crea un alert quando il comando è eseguito da un IAM role non presente nella allowlist degli amministratori di deployment, oppure quando il target include istanze fuori dalla lista degli endpoint attesi. Per Intune, monitora l'audit log di Microsoft Entra per la creazione di script PowerShell da parte di account Global Administrator appena compromessi.

Per i network device (AN0627), i syslog di apparati gestiti da FortiManager o Cisco Prime devono essere correlati con IP sorgente e account CLI atteso: un config push da un IP non autorizzato o un reboot non schedulato è un segnale ad alta priorità.

Una strategia efficace prevede un dashboard dedicato nel SIEM che aggreghi tutti gli eventi di deployment cross-platform, con drill-down per orario, account, target e processo figlio. L'obiettivo non è bloccare il deployment — che interromperebbe le operazioni IT — ma garantire che ogni esecuzione sia riconducibile a un change ticket approvato.

Quando un avversario sfrutta una piattaforma di deployment, gli artefatti forensi si distribuiscono tra il server di gestione e gli endpoint target. La ricostruzione della timeline deve coprire entrambi i lati.

Sul server SCCM, i log principali risiedono sotto C:\Program Files\Microsoft Configuration Manager\Logs\. Il file distmgr.log registra la distribuzione dei pacchetti ai distribution point, mentre execmgr.log sugli endpoint client traccia l'esecuzione locale dei task ricevuti. Ogni entry include timestamp, package ID, e program name — dati sufficienti per identificare quale pacchetto è stato usato come vettore. Il database SQL di SCCM (tipicamente su un'istanza dedicata) contiene la tabella vSMS_TaskSequencePackage che preserva la cronologia delle modifiche ai task, incluse le date di creazione e l'account che ha effettuato la modifica.

Sugli endpoint Windows target, l'analisi parte dal registro eventi. L'EventCode 4688 con command line auditing mostra il processo figlio lanciato dal client SCCM. Verifica anche il registro WinEventLog:Application per eventi legati all'installazione software (EventCode 11707, 11724). Il file system offre ulteriori indizi: i pacchetti SCCM vengono scaricati nella cache locale sotto C:\Windows\ccmcache\ — ogni sottocartella numerata corrisponde a un pacchetto, e i timestamp NTFS (creazione, modifica, accesso) aiutano a posizionare l'evento nella timeline. Usa MFTECmd (open source, parte di Eric Zimmerman's tools) per parsare la $MFT e ottenere timestamp ad alta risoluzione:

MFTECmd.exe -f "C:$MFT" --csv "C:\forensics\output" --csvf mft_output.csv

Per PDQ Deploy — impiegato nella campagna C0018 per distribuire AvosLocker — il database SQLite del server PDQ contiene lo storico completo dei deployment con target, timestamp ed exit code. Il database si trova nella directory di installazione di PDQ Deploy e può essere analizzato con qualsiasi client SQLite. Sugli endpoint, PDQ utilizza una directory temporanea per lo staging dei pacchetti e l'esecuzione avviene tramite un servizio dedicato i cui log sono nel registro eventi Windows.

Su ambienti Linux, se l'attaccante ha sfruttato Ansible, i log di esecuzione (se configurati) si trovano sul control node sotto il percorso definito in ansible.cfg (parametro log_path). Sugli endpoint target, i comandi eseguiti lasciano traccia nel log di auditd sotto /var/log/audit/audit.log: filtra per type=EXECVE e correla con connessioni SSH dal control node visibili in /var/log/auth.log.

Per ambienti cloud, AWS CloudTrail conserva ogni invocazione di SendCommand con parametri completi, incluso il contenuto dello script eseguito. L'artefatto è immutabile se CloudTrail è configurato con log file validation. Per Intune, i log di audit in Microsoft Entra registrano la creazione e l'assegnazione di script, mentre sull'endpoint il client Intune Management Extension scrive log sotto C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\.

Quando costruisci la timeline complessiva, allinea gli eventi del server di deployment (creazione pacchetto → distribuzione) con quelli degli endpoint (ricezione → esecuzione → attività post-exploitation). La finestra tra la prima distribuzione malevola e l'ultima è il blast window dell'attacco, e determina l'ambito del contenimento.

L'abuso di piattaforme di deployment è trasversale a gruppi con motivazioni, regioni e livelli di sofisticazione molto diversi. Questo lo rende un pattern comportamentale da monitorare indipendentemente dall'attore specifico.

APT32 (G0050), gruppo di matrice vietnamita noto per operazioni di spionaggio nel Sud-est asiatico, ha compromesso una console McAfee ePO per distribuire malware come task di deployment legittimo. La scelta di ePO è significativa: un prodotto di sicurezza endpoint usato come vettore di compromissione crea un cortocircuito di fiducia particolarmente efficace, perché gli alert generati dal deployment di un agent antivirus vengono tipicamente ignorati. Questo approccio indica un'elevata conoscenza dell'infrastruttura target e un probabile accesso prolungato prima dell'esecuzione.

Sandworm Team (G0034), gruppo attribuito all'intelligence militare russa e tra i più distruttivi in circolazione, ha utilizzato RemoteExec, un tool commerciale per l'esecuzione remota agentless. La preferenza per strumenti commerciali legittimi piuttosto che per malware custom è una costante di Sandworm nelle fasi di lateral movement: riduce l'esposizione a detection signature-based e si confonde con l'attività di amministrazione ordinaria.

Mustang Panda (G0129), attore cinese focalizzato su spionaggio geopolitico, ha sfruttato tool legittimi — agenti antivirus, servizi di sicurezza e strumenti di sviluppo applicativo — per eseguire script e caricare DLL tramite side-loading. L'approccio di Mustang Panda evidenzia un pattern ricorrente: l'attaccante non compromette la piattaforma di deployment in sé, ma sfrutta la fiducia che l'organizzazione ripone nei binari firmati di questi tool.

Silence (G0091), gruppo specializzato in attacchi al settore finanziario (in particolare ATM e sistemi bancari), ha impiegato RAdmin, software commerciale di controllo remoto comunemente usato per la gestione di workstation e sportelli ATM. L'utilizzo di RAdmin in ambienti bancari si confonde perfettamente con le operazioni di manutenzione ordinaria dei terminali.

Threat Group-1314 (G0028) ha utilizzato direttamente la piattaforma Altiris della vittima per il lateral movement, un caso emblematico di "living off the land" applicato ai tool di deployment aziendali. Medusa Group (G1051) ha impiegato BigFix e PDQ Deploy per distribuire il proprio payload di cifratura ransomware, lo stesso pattern osservato nella campagna C0018 dove attori non identificati hanno usato PDQ Deploy per propagare AvosLocker attraverso la rete compromessa.

Il pattern emergente è chiaro: la piattaforma di deployment è un moltiplicatore di forza. Che l'obiettivo sia spionaggio (APT32, Mustang Panda), sabotaggio (Sandworm), furto finanziario (Silence) o ransomware (Medusa Group, C0018), il deployment tool consente di scalare l'operazione dall'accesso singolo all'intera infrastruttura. L'indicatore predittivo più rilevante per un TI analyst è l'accesso anomalo alla console di gestione: se un gruppo ottiene credenziali di un amministratore SCCM, Intune o BigFix, la distribuzione del payload è questione di ore. Il monitoraggio degli account privilegiati su queste piattaforme è la prima linea di early warning.

Framework MITRE ATT&CK v16 — Tecnica T1072 (Software Deployment Tools), tattiche TA0002, TA0008. Campagna C0018 (AvosLocker deployment via PDQ Deploy). Gruppi: G0050, G0034, G0129, G0091, G0028, G1051. Software: S0041. Mitigazioni: M1015, M1017, M1018, M1026, M1027, M1029, M1030, M1032, M1033, M1051. Detection: DET0223 (AN0623–AN0627). Tool di detection e forensics: MFTECmd, auditd, CloudTrail, Sysmon. Integrato con conoscenza professionale per tool e procedure operative.