Dashboard Cloud: Cloud Service Dashboard (T1538)

In un ingaggio red team autorizzato su ambiente cloud, l'accesso alla dashboard è tipicamente il passo successivo al furto o compromissione di credenziali IAM. La simulazione realistica di T1538 richiede di riprodurre il comportamento di un utente che apre semplicemente il browser e naviga i menu, evitando pattern automatizzati che tradirebbero l'operazione.

Su AWS, dopo aver ottenuto credenziali valide (via phishing, secrets leak in repository, o session hijacking), l'operatore può caricare la sessione nel browser tramite l'endpoint di federation. Il flusso legittimo prevede la chiamata a sts:GetFederationToken seguita dallo scambio della sessione contro un signin token. Strumenti come aws-vault (open source) o Leapp (open source) permettono di gestire profili multipli e aprire console federate direttamente dal browser senza esporre le chiavi.

Una volta dentro la console, la ricognizione si concentra su servizi ad alto valore informativo. La sezione IAM rivela ruoli, policy inline e trust relationship sfruttabili per privilege escalation. EC2 Dashboard mostra istanze, security group e volumi EBS. S3 elenca bucket con relativa configurazione di accesso pubblico. Systems Manager Inventory — abusato dal gruppo Scattered Spider (G1015) — permette di enumerare l'inventario software delle istanze gestite senza toccarle direttamente, riducendo l'esposizione.

Su Azure, il portale offre viste equivalenti tramite Resource Graph Explorer, che consente query KQL sull'intero tenant. Per simulare l'attività senza automazione, l'operatore naviga manualmente Subscriptions → Resource Groups → Resources. Tool come ROADrecon (open source) e AzureHound (open source, parte di BloodHound) replicano la stessa enumerazione via API, utili per confrontare cosa un difensore vedrebbe nei log rispetto alla navigazione GUI.

Su GCP, il Security Command Center e Asset Inventory aggregano findings e risorse. ScoutSuite (open source) e Prowler (open source) sono equivalenti automatizzati validi per il baseline assessment, ma per emulare fedelmente T1538 conviene affidarsi al browser reale.

Accorgimenti operativi importanti per il red team: utilizzare un browser dedicato con user agent tipico dell'utente compromesso, connettersi da un exit node geograficamente coerente (VPN residenziale o proxy nella stessa regione della vittima), rispettare l'orario lavorativo della target organization e limitare la durata della sessione. Ogni click viene tracciato nei log di identity provider e in CloudTrail/Azure Activity Log, quindi la stealth deriva dalla plausibilità del contesto, non dall'assenza di tracce.

La detection di T1538 si basa quasi interamente sulla correlazione tra evento di autenticazione e navigazione successiva, perché la GUI in sé non genera azioni distinguibili da un utente legittimo. Il framework MITRE identifica quattro analitiche chiave (AN0808-AN0811) che coprono IaaS, Identity Provider, Office Suite e SaaS.

Su AWS, il log source primario è CloudTrail. L'evento ConsoleLogin segna l'ingresso nella dashboard e va arricchito con il campo userAgent, sourceIPAddress e additionalEventData.MFAUsed. Una regola efficace correla ConsoleLogin con successiva serie di chiamate Describe*, List* e Get* entro una finestra di 5-15 minuti, filtrando gli user agent riconducibili a browser (Mozilla, Chrome, Safari) rispetto a quelli SDK (aws-cli, Boto3, aws-sdk-go). L'anomalia scatta quando la stessa identità normalmente opera solo via CLI e improvvisamente compare in console.

Su Azure AD/Entra ID, i log SignInLogs forniscono geolocalizzazione, device compliance state, risk score calcolato da Identity Protection. La query KQL tipica in Sentinel filtra AppDisplayName == "Azure Portal" correlato a RiskLevelAggregated in ("medium","high") oppure a viaggio impossibile. La navigazione successiva verso pagine sensibili come Users, Enterprise Applications o Conditional Access viene tracciata in AuditLogs con Category == "DirectoryManagement".

Per Microsoft 365, il log UnifiedAuditLog registra accessi al Security & Compliance Center, Exchange Admin Center e Teams Admin. L'operazione UserLoggedIn con ApplicationId corrispondente a Admin Center, seguita da ViewedDashboard o operazioni di lettura configurazione, indica esplorazione GUI. Sui portali SaaS (Okta, Salesforce, Box, Zoom) le API di audit espongono eventi analoghi: user.session.start di Okta seguito da navigazione admin è un pattern da baseline per utente.

Gli indicatori di valore includono: login da ASN residenziale o VPN commerciale (Mullvad, NordVPN, ProtonVPN, IPVanish) verso account privilegiati, user agent inconsistente con il device history dell'utente, prima navigazione mai osservata verso pagine di billing o service quotas (spesso preludio a resource hijacking), sequenze di pageview troppo rapide o troppo sistematiche per essere umane.

I falsi positivi principali derivano da amministratori legittimi in trasferta, adozione di nuovi dispositivi corporate, sessioni MDM automatizzate e strumenti CASB che navigano i portali per policy enforcement. Il tuning richiede allowlist per user agent noti, baseline per pattern di navigazione per ruolo IAM e soglie differenziate per account privilegiati rispetto a utenti standard.

L'indagine forense su un caso di T1538 vive quasi esclusivamente sui log lato cloud, perché l'attività genera pochissimi artefatti endpoint — l'attaccante interagisce con un browser che dialoga con servizi web. La priorità dell'analista è ricostruire la timeline di sessione a partire dai log di identity e activity del tenant compromesso.

Su AWS, i CloudTrail Management Events sono la fonte primaria. L'evento ConsoleLogin contiene userIdentity.arn, sourceIPAddress, userAgent e responseElements.ConsoleLogin con valore Success o Failure. Da lì si ricostruisce la sessione correlando eventTime, sessionCredentialFromConsole e le chiamate successive che condividono lo stesso accessKeyId temporaneo. L'assenza di eventi write, combinata con abbondanti Describe/List, è pattern tipico di ricognizione GUI. Per ambienti multi-account, CloudTrail Lake o Athena permettono query cross-account su periodi lunghi.

Su Azure, i log rilevanti sono SignInLogs, AuditLogs e AzureActivity. Il campo ConditionalAccessStatus rivela se la sessione ha bypassato policy MFA, mentre DeviceDetail contiene fingerprint del browser (family, version, OS) utile per correlare più login sospetti allo stesso attore. AppDisplayName pari a "Azure Portal", "Microsoft Graph" o "Windows Azure Service Management API" con ResourceDisplayName enterprise-critical merita attenzione.

Su Google Workspace e GCP, gli Admin Audit Logs e Cloud Audit Logs (categoria Data Access) registrano visualizzazioni di risorse. Il campo protoPayload.methodName con valori come google.cloud.securitycenter.v1.SecurityCenter.ListFindings indica navigazione nel Security Command Center.

Sul lato endpoint, se l'analista ha accesso al workstation compromesso, gli artefatti di browser diventano corroboranti. Su Windows, la cronologia di Chrome/Edge (%LocalAppData%\Google\Chrome\User Data\Default\History, SQLite) contiene URL dei portali visitati con timestamp. Il file Cookies può ancora contenere session token cloud. ChromeCacheView e BrowsingHistoryView (entrambi gratuiti, NirSoft) semplificano l'estrazione. Su macOS gli artefatti equivalenti risiedono in ~/Library/Application Support/Google/Chrome/Default/, mentre Safari salva in ~/Library/Safari/History.db.

Un caso documentato è quello di Scattered Spider (G1015), che ha abusato di AWS Systems Manager Inventory per enumerare gli host compromessi prima del movimento laterale. Nella timeline forense l'analista cerca chiamate ssm:GetInventory, ssm:ListInventoryEntries e visite al servizio Systems Manager nella console, correlate a sessioni provenienti da IP anomali.

Elementi chiave della timeline: instante di ConsoleLogin, sequenza di servizi visitati, durata della sessione, ultimo evento prima della disconnessione o del token expiration. La preservazione dei log richiede l'export tempestivo verso storage immutabile — CloudTrail S3 con Object Lock, o SIEM esterno — perché la retention di default nei portali è limitata a 90 giorni.

Il panorama degli attori che abusano di T1538 è dominato da gruppi con forte specializzazione in credential theft e social engineering verso account cloud e SaaS. La dashboard rappresenta lo strumento naturale per operatori che privilegiano tecniche living-off-the-land e riducono al minimo il malware custom.

Il profilo di riferimento nei dati MITRE per questa tecnica è Scattered Spider (G1015), tracciato anche come UNC3944, Octo Tempest e 0ktapus. Il gruppo, composto prevalentemente da attori anglofoni, si distingue per catene d'attacco che iniziano con vishing verso help desk IT per ottenere reset di password o registrazione di dispositivi MFA controllati dagli attaccanti. Una volta ottenuto l'accesso all'identity provider — tipicamente Okta o Azure AD — il gruppo si muove verso le console cloud amministrative. L'abuso specifico documentato di AWS Systems Manager Inventory rappresenta un pattern ricorrente: invece di installare agent di ricognizione sulle istanze, sfruttano il servizio nativo per enumerare software installato, patch level e configurazioni degli host compromessi, restando invisibili agli EDR perché non toccano gli endpoint.

Il target di Scattered Spider si è evoluto da telco e BPO nordamericani, presi di mira nelle prime campagne per SIM swapping, verso settori più remunerativi come hospitality, gaming e retail, con incidenti di alto profilo che hanno portato a estorsioni multi-milionarie in partnership con ransomware-as-a-service. La combinazione tra social engineering vocale sofisticato, familiarità nativa con l'inglese e capacità tecniche cloud è ciò che rende il gruppo particolarmente pericoloso in questa tecnica specifica.

Il pattern operativo tipico osservato include: compromissione dell'account di un dipendente con privilegi cloud, login alla dashboard da infrastruttura VPN commerciale o proxy residenziali per aggirare geofencing, navigazione sistematica dei portali AWS/Azure/GCP per identificare crown jewel — database di clienti, backup, snapshot — e ricognizione via console prima di attivare il payload finale.

La tecnica trova terreno fertile in trend più ampi dell'ecosistema cyber criminale: la centralizzazione dell'identità in provider SaaS crea single point of failure che, se compromessi, aprono l'intera infrastruttura; la sofisticazione dei kit di phishing adversary-in-the-middle come Evilginx (open source) e i servizi commerciali di phishing-as-a-service abbassano la barriera d'ingresso per il furto di sessioni MFA; l'espansione dei perimetri cloud multi-provider aumenta la superficie di dashboard esposte.

Dal punto di vista predittivo, l'aumento di detection basate su UEBA e Identity Threat Detection & Response (ITDR) spinge gli attori verso tecniche di evasione più raffinate — device spoofing coerente con il browser fingerprint della vittima, timing delle azioni allineato agli orari lavorativi, uso di proxy nel medesimo ASN dell'organizzazione target.

Dati tecnici estratti dal framework MITRE ATT&CK: tecnica T1538, gruppo G1015 (Scattered Spider), mitigazione M1018 (User Account Management), analitiche di detection DET0291 (AN0808-AN0811). Riferimenti aggiuntivi al framework MITRE D3FEND per il mapping delle contromisure difensive su artefatti di autenticazione cloud. Per comandi, tool operativi (aws-vault, Leapp, ROADrecon, AzureHound, ScoutSuite, Prowler, Evilginx, ChromeCacheView, BrowsingHistoryView) e procedure forensi è stata utilizzata conoscenza professionale di dominio in ambito cybersecurity cloud e incident response.