Serverless Malevolo: Serverless (T1583.007)

Trattandosi di una tecnica di Resource Development, l'obiettivo in un ingaggio red team non è "bucare" nulla ma simulare la costruzione di un canale C2 serverless in modo lab-safe, per validare la capacità di detection del blue team.

La catena tipica prevede tre passaggi: registrazione di un account presso un provider serverless, deploy di una funzione che funge da reverse proxy o redirector verso il vero listener C2, e configurazione dell'impianto perché il beacon parli con un sottodominio del provider anziché con un IP grezzo.

Su Cloudflare Workers si opera con la CLI ufficiale wrangler (open source). L'inizializzazione di un progetto avviene con wrangler init e la pubblicazione con:

wrangler deploy

La funzione Worker viene scritta per inoltrare le richieste HTTP in ingresso verso il team server, agendo da domain fronting/redirector. Il risultato è un endpoint su tuo-worker.workers.dev che maschera l'origine.

Su AWS Lambda la simulazione usa la CLI ufficiale aws (freemium, costi a consumo). Si crea una funzione e la si espone tramite un endpoint HTTP:

aws lambda create-function --function-name redirector --runtime python3.12 --handler app.handler --role --zip-file fileb://pkg.zip

abbinata a un Function URL o a un API Gateway per ottenere l'endpoint pubblico. Su Google Apps Script si può pubblicare uno script come web app che ritorna contenuti dinamici, sfruttando i domini Google come facciata.

Per il framework offensivo lato listener, in laboratorio si usano tipicamente:

• Cobalt Strike (a pagamento) con profili Malleable C2 che imitano traffico legittimo
• Mythic (open source), agnostico rispetto al redirector serverless
• Sliver (open source), con supporto a listener HTTP/HTTPS dietro proxy

Il redirector serverless si limita a inoltrare verso questi team server, così che il beacon dell'endpoint compromesso veda solo il dominio del provider cloud.

Regole d'ingaggio: usa esclusivamente account, domini e infrastruttura di tua proprietà, con esplicita autorizzazione scritta; non instradare mai traffico di produzione; e distruggi le funzioni al termine del test. La campagna APT41 DUST ha impiegato proprio Cloudflare Workers per il C2, quindi replicarne la topologia (beacon → Worker → team server) offre uno scenario realistico per allenare i controlli di rete e di threat hunting sul traffico verso sottodomini cloud.

La rilevazione preventiva è intrinsecamente difficile: l'avversario allestisce la funzione serverless al di fuori del perimetro aziendale, quindi la fase di acquisizione è invisibile. Come indicato dall'analitica AN1961 (DET0829), gli sforzi vanno concentrati sulle fasi correlate del ciclo di vita — cioè quando l'infrastruttura viene usata per il command and control — e sulla ricerca di caratteristiche uniche del software avversario, quando note.

Gli artefatti digitali più utili sono di natura di rete: Domain Name, DNS Record, Network Traffic e certificati TLS. Il traffico serverless si presenta verso sottodomini di provider comuni (workers.dev, endpoint Lambda su amazonaws.com, script.google.com), quindi il segnale non è il dominio in sé ma il comportamento della connessione.

Sul piano comportamentale conviene profilare il traffico in uscita cercando indicatori tipici di beaconing dietro redirector: intervalli regolari (jitter costante), rapporto anomalo tra byte inviati e ricevuti, connessioni persistenti verso un singolo sottodominio serverless da host che normalmente non usano quel servizio, e user-agent o pattern JA3/JA3S ricorrenti. Le fonti di log chiave sono i proxy web e i firewall di nuova generazione con ispezione TLS, i log DNS (query verso sottodomini workers.dev o Function URL), i Zeek/Suricata logs per la telemetria di rete e i flussi NetFlow.

Sul lato controlli di rafforzamento (Harden/Isolate), la mitigazione M1056 (Pre-compromise) riconosce che non esistono controlli preventivi efficaci perché il comportamento avviene fuori scopo. Restano però utili misure indirette: threat intelligence per popolare blocklist di endpoint noti come malevoli tramite piattaforme come MISP (open source), e monitoraggio della superficie esterna con Shodan e Censys (entrambi freemium).

Il principale falso positivo è dato dall'uso legittimo e crescente di servizi serverless: molte applicazioni SaaS, CDN e integrazioni aziendali passano proprio per Workers, Lambda e Apps Script. Bloccare l'intero provider è impraticabile, quindi la detection deve essere di precisione, correlando l'anomalia di rete con eventi sull'endpoint (processo che genera la connessione, parentela di processo sospetta, assenza di firma). Un buon approccio è il baselining: stabilire quali host e applicazioni parlano legittimamente con quei domini, e trattare come segnale ogni deviazione. Data la visibilità limitata, il valore maggiore arriva dall'hunting retrospettivo alimentato da IOC di campagne note come APT41 DUST.

Nell'analisi forense di T1583.007 l'investigatore parte svantaggiato: l'infrastruttura serverless vive sui sistemi del provider, non sull'endpoint, e le sue caratteristiche di occultamento rendono l'attribuzione complessa. La ricostruzione si appoggia perciò a fonti esterne e agli artefatti che emergono dopo il contatto tra la vittima e l'endpoint malevolo.

Le fonti esterne più preziose sono il passive DNS, che consente di storicizzare quali IP hanno risolto un sottodominio serverless nel tempo, i log di Certificate Transparency (consultabili tramite servizi come crt.sh, gratuito) per individuare certificati emessi per domini di facciata, e il WHOIS storico per gli eventuali domini custom mappati sulla funzione. Poiché i Worker vivono spesso su workers.dev e le Lambda dietro domini AWS, l'elemento di attribuzione si sposta sull'analisi dei pattern di deploy e dei certificati piuttosto che sulla proprietà del dominio.

Sull'endpoint compromesso, la timeline si costruisce dagli artefatti di rete e di esecuzione legati all'uso dell'infrastruttura. Su Windows sono rilevanti gli eventi di connessione di rete di Sysmon (Event ID 3) che legano un processo a un sottodominio serverless, gli eventi di query DNS (Event ID 22), la cache DNS interrogabile con ipconfig /displaydns, e i log del proxy o del firewall locale. La correlazione processo→connessione permette di isolare il binario del beacon che ha instaurato il canale. Utili anche gli artefatti di persistenza e i prefetch per datare la prima esecuzione dell'impianto.

Su Linux si esaminano i log di rete disponibili, la telemetria di auditd e, se presente, Sysmon for Linux per correlare processi e connessioni in uscita; i log del resolver e le connessioni attive tramite ss -tnp aiutano a fotografare le sessioni verso endpoint cloud durante l'acquisizione live.

Gli artefatti digitali di riferimento restano quindi Network Traffic, DNS Record, Domain Name e i certificati associati. Un caso concreto è la campagna APT41 DUST (C0040, gennaio 2023 – giugno/luglio 2024): APT41 ha ospitato infrastruttura dietro Cloudflare e utilizzato Cloudflare Workers per il command and control, colpendo shipping, logistica e media in Europa, Asia e Medio Oriente. In un'indagine su vittime analoghe, l'analista incrocerebbe gli IOC di rete di quella campagna con la telemetria endpoint per confermare l'uso del redirector serverless e ricostruire la finestra temporale di compromissione.

Il dato di intelligence più rilevante per T1583.007 ruota attorno a un unico attore documentato nei dati disponibili: APT41, tramite la campagna APT41 DUST (C0040).

La campagna si è svolta da gennaio 2023 fino a luglio 2024 e ha preso di mira entità in Europa, Asia e Medio Oriente. I settori colpiti — shipping, logistica e media — indicano una finalità di raccolta informativa, coerente con il profilo storico di APT41 come attore dalle motivazioni miste. Sul piano del tooling, la campagna ha combinato malware già osservato come DUSTPAN con strumenti di nuova osservazione come DUSTTRAP, segno di un arsenale in evoluzione attivo.

L'elemento centrale per questa tecnica è la scelta infrastrutturale: APT41 ha ospitato la propria infrastruttura dietro Cloudflare e ha utilizzato i Cloudflare Workers per il command and control. È un pattern che sfrutta esattamente il vantaggio descritto dalla tecnica — mimetizzare il traffico C2 tra le normali comunicazioni verso un provider cloud ubiquo, complicando sia il blocco selettivo sia l'attribuzione. Per un difensore, ciò significa che il traffico verso sottodomini workers.dev non può essere trattato come intrinsecamente benigno né bloccato in blocco.

Il trend che emerge è l'adozione di infrastruttura serverless come livello di offuscamento e resilienza: invece di esporre IP o domini propri facilmente inseribili in blocklist, l'attore inserisce un redirector effimero e a basso costo tra vittima e team server. Questo pattern abbassa la barriera d'ingresso e riduce i costi operativi, rendendo plausibile la sua diffusione anche presso attori meno sofisticati oltre ad APT statuali.

Sul fronte delle contromisure di intelligence, la mitigazione M1056 (Pre-compromise) riconosce apertamente che la tecnica non è facilmente contrastabile con controlli preventivi, poiché opera fuori dal perimetro aziendale. Il valore si sposta quindi sul tracciamento continuo dell'infrastruttura avversaria tramite piattaforme di threat intelligence come MISP (open source), Recorded Future e Anomali (entrambe a pagamento), per correlare IOC, sovrapposizioni di tool e riuso di endpoint tra campagne. Data la scarsità di gruppi mappati su questa specifica tecnica, la priorità per un Threat Intelligence Officer è alimentare l'hunting con gli IOC di APT41 DUST e monitorare l'emergere di altri attori che convergano sullo stesso modello serverless, aggiornando di conseguenza le regole di correlazione del SOC.

MITRE ATT&CK: tecnica T1583.007 (Serverless), tattica TA0042. Campagna C0040 (APT41 DUST). Mitigazione M1056 (Pre-compromise). Detection DET0829 e analitica AN1961. Riferimenti a MITRE D3FEND per artefatti di rete e DNS. Tool citati verificabili: wrangler, AWS CLI, Sysmon, MISP, Shodan, Censys, crt.sh, Cobalt Strike, Mythic, Sliver. Parte dei dettagli operativi su comandi e artefatti deriva da conoscenza professionale di cybersecurity, non dai dati MITRE forniti.