Esecuzione Serverless: Serverless Execution (T1648)

Per un red team, la simulazione di T1648 richiede un tenant cloud dedicato e un'attenta gestione dei permessi, perché una funzione mal configurata può generare costi imprevisti o toccare risorse produttive. L'approccio corretto è partire da un account di test con MFA disabilitato solo internamente e credenziali generate ad-hoc.

Il tool di riferimento pubblicamente documentato è Pacu (open source), il framework di exploitation AWS mantenuto da Rhino Security Labs. Una volta caricate le credenziali della vittima simulata con set_keys, il modulo lambda__backdoor_new_users consente di creare una Lambda persistente che si attiva alla creazione di ogni nuovo utente IAM, aggiungendo access key controllate dall'attaccante. Il modulo iam__privesc_scan mappa in anticipo i vettori di privilege escalation disponibili, incluso lo sfruttamento di PassRole su funzioni Lambda.

Su AWS lo scenario classico si costruisce così: partendo da credenziali con permessi lambda:CreateFunction e iam:PassRole su un ruolo privilegiato, si crea una funzione che, all'esecuzione, invoca l'API IAM per creare nuovi utenti o access key. La CLI ufficiale è sufficiente: aws lambda create-function per il deploy, aws events put-rule e aws events put-targets per collegare un trigger CloudWatch Events (oggi EventBridge) all'evento CreateUser. Il payload zippato può contenere poche righe di boto3 che manipolano IAM.

Su Azure l'equivalente è la creazione di una Function App con identità gestita associata; il comando az functionapp create seguito da az functionapp identity assign permette di collegare una managed identity con ruoli RBAC eccessivi. Su GCP si usa gcloud functions deploy specificando --service-account per far ereditare i privilegi del service account bersaglio.

Per la componente SaaS, in Microsoft 365 un tester con licenza Power Automate può creare un flusso When a new email arrives con azione Forward the message, dimostrando l'esfiltrazione silenziosa della posta. In Google Workspace, un Apps Script legato a un trigger onOpen su un file Drive può inviare il contenuto a un endpoint esterno tramite UrlFetchApp.fetch.

Strumenti complementari utili in laboratorio: ScoutSuite (open source) per la ricognizione post-deploy dei permessi effettivi, CloudGoat (open source) di Rhino Security Labs per scenari AWS pre-costruiti che includono percorsi Lambda-based, e Stratus Red Team (open source) di DataDog, che espone tecniche mappate direttamente su ATT&CK inclusa aws.execution.lambda-backdoor.

La detection di T1648 si gioca interamente sulla control plane del cloud e sui log delle piattaforme SaaS, perché nulla di questa tecnica tocca gli endpoint tradizionali. Il framework MITRE identifica tre analitiche complementari — IaaS, Office Suite e SaaS — che vanno implementate insieme per coprire l'intera superficie.

Sul fronte IaaS la fonte primaria è AWS CloudTrail (a pagamento, incluso nel costo dell'account con retention limitata), con equivalenti Azure Activity Log e Google Cloud Audit Logs. Gli eventi da correlare sono CreateFunction, UpdateFunctionCode, UpdateFunctionConfiguration, PutRolePolicy e AttachRolePolicy emessi in sequenza temporale ravvicinata, specialmente quando l'attore non è uno degli identity abitualmente autorizzati a deployare codice. Un pattern ad alto valore è la creazione di una Lambda seguita entro pochi minuti dall'invocazione della stessa con generazione di traffico egress verso IP mai osservati, oppure dalla creazione di nuove access key IAM. Il parametro di tuning [AllowedFunctions] — una baseline di funzioni approvate — è essenziale per ridurre i falsi positivi generati dalle pipeline CI/CD legittime.

Per la componente Office Suite i log da abilitare sono m365:unified e m365:exchange nel Microsoft Purview Audit (freemium, con retention estesa nei tier E5). Gli eventi FlowCreated e FlowUpdated nel workload MicrosoftFlow vanno correlati con azioni sensibili tipiche del post-compromise: creazione di regole di inoltro esterno (New-InboxRule con ForwardTo verso domini esterni), generazione di link di condivisione anonimi su SharePoint (AnonymousLinkCreated), o invocazioni API verso endpoint sconosciuti. Il parametro [UserContext] consente di whitelisting delle business unit di sviluppo che legittimamente creano automazioni.

Per i SaaS l'analitica AN1055 punta su log Google Workspace saas:appsscript e saas:googledrive. Uno script Apps Script associato a trigger onOpen o onEdit che effettua chiamate UrlFetchApp verso domini esterni è un segnale forte, così come script che accedono a scope OAuth ad alto rischio come drive.readonly o gmail.readonly.

Le mitigazioni M1018 (User Account Management) e M1036 (Account Use Policies) si traducono in controlli preventivi complementari alla detection: rimuovere i permessi di creazione funzioni serverless dagli utenti che non ne hanno necessità, applicare Conditional Access ai creator di flussi Power Automate, restringere gli scope OAuth ad alto rischio in Google Workspace. I falsi positivi principali derivano da pipeline DevOps automatizzate: mantenere una baseline aggiornata di service principal e ruoli CI/CD è indispensabile.

L'analisi forense di T1648 richiede un cambio di paradigma rispetto alla DFIR endpoint-centric: gli artefatti non risiedono su disco locale ma nei log immutabili delle control plane cloud e nei metadata delle risorse serverless. La ricostruzione della timeline parte quasi sempre dagli audit log del provider.

In ambiente AWS l'artefatto cardine è CloudTrail, che registra ogni chiamata API con userIdentity, sourceIPAddress, userAgent e requestParameters. Gli eventi da estrarre in ordine cronologico sono CreateFunction (con il codice sorgente indirettamente ricostruibile via GetFunction), CreateEventSourceMapping o PutRule/PutTargets per identificare i trigger, e le successive Invoke con relativi responseElements. La console di CloudWatch Logs conserva l'output della funzione stessa: se l'attaccante non ha disabilitato il logging (operazione tracciata a sua volta), è possibile recuperare stdout/stderr con i risultati dell'esecuzione. Il tool ufficiale aws logs filter-log-events permette query mirate. Per il codice deployato, la chiamata aws lambda get-function restituisce un URL pre-signed valido 10 minuti da cui scaricare il pacchetto zip originale.

In Azure l'equivalente è il Activity Log più i Diagnostic Settings delle Function App, che vanno esportati verso Log Analytics o uno storage account per retention estesa. Le operazioni chiave sono Microsoft.Web/sites/write (creazione), Microsoft.Web/sites/functions/write e le assegnazioni di identità gestite. In GCP i Cloud Audit Logs (Admin Activity e Data Access) tracciano google.cloud.functions.v1.CloudFunctionsService.CreateFunction e le successive esecuzioni.

Per la componente Microsoft 365, il Unified Audit Log (interrogabile via Search-UnifiedAuditLog in PowerShell o dal portale Purview) espone il workload MicrosoftFlow con eventi CreateFlow, EditFlow, DeleteFlow comprensivi del payload JSON del flusso stesso, che rivela trigger e azioni. Le regole di inoltro Exchange create dai flussi lasciano tracce parallele in New-InboxRule. In Google Workspace il rapporto Admin SDK Reports API permette di enumerare tutti gli Apps Script attivi e i loro trigger installati.

La timeline tipica di un incidente T1648 si compone di: momento di compromissione delle credenziali iniziali (spesso via phishing o access key esposte), enumerazione dei permessi (chiamate iam:List*), creazione della funzione malevola, configurazione del trigger event-driven, prima esecuzione test, e infine attivazione operativa. Correlare gli IP sorgente delle chiamate API con la threat intelligence su range noti (VPN commerciali, esci Tor, IP di provider anomali per l'organizzazione) permette di distinguere l'attività legittima da quella malevola. Strumenti come CloudTrail Lake (a pagamento) o Athena (a pagamento, pay-per-query) su bucket S3 di CloudTrail facilitano query SQL su grandi volumi di eventi.

Il panorama di threat intelligence relativo a T1648 presenta una peculiarità importante: MITRE ATT&CK non associa attualmente alcun gruppo APT formalmente tracciato a questa tecnica, e censisce una sola campagna software rilevante — il framework offensivo Pacu (S1091) sviluppato da Rhino Security Labs, capace di creare funzioni Lambda malevole in modo automatizzato. Questa scarsità di attribuzioni riflette due dinamiche del threat landscape cloud.

La prima è che l'abuso di servizi serverless è tipicamente un enabler tattico piuttosto che una firma distintiva di un attore specifico: chi compromette un tenant cloud tende a utilizzare Lambda, Functions o Power Automate come strumenti opportunistici a valle dell'accesso iniziale, senza lasciare TTP sufficientemente uniche da consentire attribuzione. La seconda è che la detection e reporting su incidenti cloud rimangono meno mature rispetto agli attacchi endpoint tradizionali, e molti compromessi vengono classificati sotto tecniche più generiche di Valid Accounts o Cloud Service Discovery senza tracciare la componente serverless.

Dal punto di vista dei pattern osservabili nel wild — al di fuori delle attribuzioni formali MITRE — l'abuso di serverless è documentato ricorrentemente in due macro-categorie di intrusione. La prima è il cryptomining opportunistico, dove attaccanti finanziariamente motivati sfruttano credenziali AWS esposte pubblicamente (tipicamente access key committate su repository Git) per deployare Lambda o Fargate task che minano criptovalute a spese della vittima, generando bollette che possono raggiungere decine di migliaia di dollari in poche ore. La seconda è la persistenza in ambienti M365 tramite Power Automate, tipica di operazioni di Business Email Compromise dove l'attaccante, dopo aver compromesso una casella tramite phishing, installa flussi di inoltro silenzioso per mantenere accesso alla corrispondenza anche dopo la rotazione delle credenziali o l'attivazione di MFA.

Il tool Pacu merita un approfondimento specifico: essendo open source e ampiamente documentato, è diventato de facto lo standard sia per red team legittimi sia per attaccanti reali che vogliono automatizzare l'exploitation post-compromise in AWS. I moduli lambda__backdoor_new_users e lambda__backdoor_new_roles implementano esattamente lo scenario descritto da MITRE nella tecnica, e la loro presenza in un ambiente compromesso — rilevabile via User-Agent anomali nelle chiamate CloudTrail — costituisce un indicatore di alto valore.

La tendenza strategica per i prossimi cicli è un aumento dell'attenzione degli attaccanti verso le piattaforme di low-code/no-code automation (Power Automate, Zapier, Make), percepite come blind spot dai SOC tradizionali. I threat intelligence team dovrebbero includere nelle proprie collezioni le API di audit di queste piattaforme e monitorare i marketplace di connettori per identificare integrazioni malevole o abusabili.

MITRE ATT&CK: tecnica T1648 (Serverless Execution), tattica TA0002. Software S1091 (Pacu). Mitigazioni M1018, M1036. Detection Strategy DET0374 con analitiche AN1053, AN1054, AN1055. MITRE D3FEND per mapping difensivo. Le sezioni operative su comandi CLI (AWS, Azure, gcloud), tool complementari (ScoutSuite, CloudGoat, Stratus Red Team) e artefatti di audit cloud si basano su conoscenza professionale di cybersecurity e documentazione ufficiale dei rispettivi vendor e progetti open source.