Serverless Compromesso: Serverless (T1584.007)

Trattandosi di una tecnica di Resource Development pre-compromissione, l'obiettivo in un esercizio red team non è "bucare" un provider ma simulare in laboratorio un canale C2 che sfrutti infrastruttura serverless, in modo lab-safe e su account di proprietà del team.

Uno scenario tipico prevede il deploy di una funzione che faccia da relay verso un listener controllato. Con AWS SAM CLI (open source) si può inizializzare e distribuire una Lambda minimale tramite sam init e sam deploy --guided, esponendola dietro un API Gateway. Su Cloudflare l'equivalente è Wrangler (open source), la CLI ufficiale dei Workers, con cui si crea e pubblica un Worker via wrangler init e wrangler deploy. Per Google, clasp (open source) permette di gestire Apps Script da riga di comando con clasp create e clasp push.

La logica del redirector è banale: la funzione riceve una richiesta HTTPS, la inoltra all'endpoint del team operator e restituisce la risposta. Questo pattern di domain/serverless fronting fa apparire il traffico come diretto a un sottodominio del provider.

Sul lato framework C2, molti team usano Cobalt Strike (a pagamento) con i suoi Malleable C2 profile per modellare i beacon, oppure alternative open source come Sliver (open source), Mythic (open source) e Havoc (open source), tutte in grado di lavorare dietro redirector HTTP/S. La catena tipica in lab è: implant sull'endpoint → funzione serverless come proxy → team server.

Una sequenza operativa realistica per la simulazione:

• Registrare un account cloud dedicato all'esercizio, mai riutilizzare produzione.
• Distribuire la funzione proxy con la CLI del provider (SAM, Wrangler o clasp).
• Configurare il listener del framework C2 dietro l'endpoint serverless.
• Generare un implant che punti al sottodominio del provider.
• Documentare gli IOC prodotti per il successivo hand-off al blue team.

Su Windows l'implant può essere testato con un semplice Invoke-WebRequest PowerShell verso l'endpoint per validare il canale; su Linux/macOS l'equivalente è curl -s . Il valore dell'esercizio sta nel far emergere quanto sia difficile, per chi difende, separare queste chiamate dal normale traffico verso i domini del provider — esattamente l'effetto che la tecnica ricerca. Mantieni scope, autorizzazioni scritte e teardown delle risorse al termine.

La sfida per il SOC è netta: come indica l'analitica AN1996 della detection DET0864, gran parte dell'attività si svolge fuori dalla visibilità dell'organizzazione bersaglio. L'infrastruttura serverless viene compromessa altrove; ciò che si osserva è solo il suo utilizzo nelle fasi successive (Initial Access, Command and Control). La detection è quindi prevalentemente indiretta e comportamentale.

Gli artefatti digitali rilevanti sono le connessioni di rete e i record DNS. Il traffico verso funzioni serverless si presenta come richieste HTTPS verso sottodomini dei grandi provider — i domini associati a Lambda dietro API Gateway, ai Workers di Cloudflare, agli Apps Script di Google. Le fonti di log utili sono:

• Proxy/web gateway e log TLS/SNI per il campo server name.
• DNS resolver logs per risoluzioni verso i domini del provider.
• Netflow/Zeek per volumetria, periodicità e durata delle sessioni.
• EDR per correlare il processo che origina la connessione.

L'approccio efficace non è bloccare il dominio del provider — è traffico legittimo diffuso — ma profilare il comportamento. Un beacon serverless tende a mostrare pattern di beaconing: intervalli regolari, jitter contenuto, payload di dimensione simile. Strumenti come RITA (open source) analizzano i log Zeek proprio per individuare periodicità sospette. In un ambiente Elastic o Splunk si costruiscono alert su frequenza e regolarità delle chiamate a un singolo sottodominio serverless da parte di un host che non ha ragioni applicative per contattarlo.

Sul piano dei controlli preventivi (Harden/Isolate), è utile applicare l'ispezione TLS ove consentito, il filtraggio delle categorie con allow-list applicative, e la segmentazione che impedisca a workstation d'ufficio di parlare direttamente con endpoint di sviluppo cloud. La Network Traffic Analysis e il DNS Traffic Analysis sono le leve difensive centrali: correlare chi genera la richiesta, verso quale sottodominio e con quale cadenza.

I falsi positivi sono la difficoltà maggiore. Applicazioni SaaS legittime, integrazioni, telemetria e servizi di sviluppo usano massicciamente Lambda, Workers e Apps Script. Un allarme basato sul solo dominio produrrebbe rumore ingestibile. La strada praticabile è arricchire con contesto: processo di origine anomalo (es. un binario non browser che parla HTTPS con un Worker), assenza di user-agent coerente, host che non appartiene a team di sviluppo, o correlazione temporale con altri indicatori di compromissione. Solo la combinazione di segnali comportamentali eleva questi eventi da rumore a lead investigabile.

Per l'analista forense la tecnica pone un vincolo strutturale: l'atto di compromissione dell'infrastruttura serverless avviene al di fuori dell'endpoint aziendale. Gli artefatti disponibili si dividono quindi in due famiglie — le fonti esterne che documentano l'infrastruttura e gli artefatti host che emergono solo dopo il contatto con l'endpoint malevolo.

Sul fronte esterno, l'indagine ricostruisce la natura del sottodominio serverless contattato. Il passive DNS consente di storicizzare le risoluzioni e capire per quanto tempo un endpoint è stato attivo. I log Certificate Transparency, consultabili tramite servizi come crt.sh (gratuito) o il motore Censys (freemium), aiutano a datare l'emissione di certificati e a correlare sottodomini. Il WHOIS storico ha valore limitato per i domini condivisi del provider, ma resta utile quando l'attaccante mappa un dominio custom sulla funzione.

Sull'host, gli artefatti compaiono nella fase di C2 e vanno inseriti in timeline. Su Windows le tracce utili includono:

• Le voci di DNS cache (ipconfig /displaydns) e i record in %SystemRoot%\System32\dns.
• Gli eventi di rete di Sysmon EventCode 3 (connessione) e EventCode 22 (DNS query), che legano processo, destinazione e timestamp.
• La cronologia di Prefetch e le ShimCache/Amcache per datare l'esecuzione dell'implant che ha originato le connessioni.

Su Linux la correlazione si fa con gli audit di rete via auditd o con Sysmon for Linux (open source), che registra le connessioni in modo analogo a Windows; utili anche i log di journald e le connessioni residue rilevabili con ss -tanp durante il triage a caldo. Su macOS le connessioni e i processi si ricostruiscono dallo Unified Logging interrogato con log show --predicate.

Il filo conduttore della ricostruzione è temporale: si parte dal primo EventCode 22 verso il sottodominio del provider, si aggancia il processo responsabile tramite EventCode 3, si datano esecuzione e persistenza con Prefetch e Amcache, e si confronta il tutto con la finestra di attività dell'endpoint desunta da passive DNS e Certificate Transparency.

Non esistono, nei dati MITRE forniti, campagne o software documentati associati a questa tecnica: l'analista deve quindi evitare di forzare attribuzioni e concentrarsi sulla correlazione tra artefatti host e telemetria esterna, tenendo presente che l'assenza di tracce sull'endpoint durante la fase di setup è connaturata alla tecnica, non indice di indagine incompleta.

I dati MITRE forniti per T1584.007 non associano alcun gruppo APT, software o campagna documentata alla tecnica: le statistiche riportano zero attori, zero tool e zero operazioni tracciate, a fronte di una singola mitigazione. Per un Threat Intelligence Officer questo profilo va letto correttamente, senza colmare il vuoto con attribuzioni non supportate dai dati.

L'assenza di attori mappati non significa assenza di rilevanza. Al contrario, riflette la natura stessa della tecnica: compromettere infrastruttura serverless serve proprio a rendere difficile l'attribuzione. Traffico che origina da sottodomini di AWS, Cloudflare o Google si confonde con l'enorme volume di comunicazioni legittime verso quegli stessi provider, riducendo i segnali che permetterebbero di collegare un'operazione a uno specifico attore. È una tecnica progettata per erodere proprio il lavoro di clustering e attribuzione su cui si fonda la threat intelligence.

Dal punto di vista dei pattern, la collocazione in TA0042 (Resource Development) la posiziona a monte della kill chain, come abilitatore per fasi successive. La descrizione tecnica evidenzia due modalità d'uso ricorrenti che meritano tracciamento nei propri modelli analitici: la funzione serverless che risponde direttamente alle macchine infette e quella che agisce da proxy verso un C2 di proprietà dell'avversario. Entrambe convergono sull'obiettivo di occultare l'infrastruttura (Hide Infrastructure), tecnica correlata nella stessa tattica.

Sul piano del tracciamento infrastrutturale, la mitigazione M1056 (Pre-compromise) indirizza verso piattaforme che un team di intelligence usa comunemente per monitorare e correlare infrastruttura avversaria. Tra quelle citate nei dati figurano MISP (open source), utile per condividere e correlare indicatori all'interno di communities, e servizi commerciali come Recorded Future e Anomali (a pagamento) per l'arricchimento contestuale. Per la sorveglianza della superficie esterna la stessa mitigazione richiama Shodan e Censys (freemium), mentre per il monitoraggio di domini e DNS indica servizi come DomainTools (a pagamento).

Il trend da comunicare al management è chiaro: la maturazione dell'ecosistema cloud rende il serverless una scelta infrastrutturale sempre più attraente per chi vuole minimizzare la propria impronta. La priorità difensiva non è attendere un'attribuzione formale — che i dati mostrano ancora assente — ma costruire baseline comportamentali del proprio traffico verso i provider cloud, così da rendere osservabile l'abuso quando si manifesterà nelle fasi di Initial Access e C2.

MITRE ATT&CK: tecnica T1584.007 (Serverless), tattica TA0042 (Resource Development), mitigazione M1056 (Pre-compromise), detection DET0864 e analitica AN1996. Tool di detection e simulazione citati da documentazione ufficiale e repository pubblici (AWS SAM CLI, Wrangler, clasp, Sliver, Mythic, Havoc, RITA, MISP, Sysmon). Parte dei comandi, artefatti forensi e procedure operative derivano da conoscenza professionale di cybersecurity, nel rispetto delle regole su tool reali e verificabili.