Indice dei contenuti
- Cos’è un cloud breach senza malware
- Il concetto di living off the cloud
- Il ruolo delle identità nel cloud
- Token e session hijacking
- Configurazioni errate: il vero punto debole
- Abuso delle API cloud
- Persistenza senza malware
- Movimento laterale nel cloud
- Logging e detection: perché è difficile rilevare questi attacchi
- Strategie di difesa avanzate
- Rotazione dei token e gestione delle credenziali
- Monitoraggio continuo e detection comportamentale
- Micro-segmentazione e controllo del contesto
- Automazione e risposta agli incidenti
- Caso reale: compromissione di un tenant Microsoft 365
Negli ultimi anni la cloud security e la sicurezza informatica hanno vissuto un cambiamento radicale. Se fino a poco tempo fa il concetto di attacco informatico era legato principalmente alla presenza di malware, virus o exploit evidenti, oggi lo scenario è completamente diverso. Sempre più spesso gli attaccanti riescono a compromettere infrastrutture cloud senza installare alcun software malevolo, sfruttando esclusivamente configurazioni errate, token di accesso e API legittime.
Questo tipo di attacco viene comunemente definito living off the cloud, un’evoluzione del concetto di living off the land già noto nei sistemi on-premise. L’idea è semplice ma estremamente efficace: utilizzare strumenti e funzionalità già presenti nell’ambiente target per muoversi lateralmente, mantenere la persistenza e accedere ai dati.
In questo articolo analizzeremo in profondità cosa significa realmente un cloud breach senza malware, come avviene la compromissione di un tenant, quali sono le tecniche più utilizzate dagli attaccanti e, soprattutto, come difendersi in modo efficace. Lo faremo con esempi concreti, scenari realistici e anche con codice, per comprendere davvero la logica di questi attacchi avanzati.
Cos’è un cloud breach senza malware
Quando si parla di cloud breach, si fa riferimento a una compromissione di un ambiente cloud, come ad esempio un tenant Microsoft 365, AWS o Google Cloud. Tradizionalmente si immagina un attacco che coinvolge malware, exploit o vulnerabilità software. Tuttavia, nel modello moderno, spesso non serve nulla di tutto questo.
Un attacco senza malware si basa su tre pilastri fondamentali:
- configurazioni errate
- credenziali compromesse
- abuso delle API
Questo significa che l’attaccante non deve violare il sistema, ma semplicemente utilizzarlo meglio del legittimo proprietario.
Immagina un ambiente in cui un utente ha privilegi eccessivi, oppure un’applicazione ha accesso a risorse più ampie del necessario. In questi casi, un attaccante può ottenere accesso e muoversi indisturbato, senza mai generare un comportamento che sembri anomalo a livello tradizionale.
Il concetto di living off the cloud
Il paradigma living off the cloud rappresenta una delle evoluzioni più sofisticate della sicurezza offensiva. L’attaccante non introduce elementi esterni, ma sfrutta le funzionalità native del cloud provider.
Questo approccio offre diversi vantaggi:
- riduce la superficie di rilevamento
- evita l’uso di file sospetti
- sfrutta strumenti considerati affidabili
In pratica, se un attaccante utilizza le API ufficiali di Azure o AWS, il traffico generato sarà indistinguibile da quello legittimo, a meno di un’analisi molto avanzata.
Esempio
L’uso delle API Microsoft Graph per accedere alle email, ai file e alle identità. Non c’è malware, non ci sono exploit: solo chiamate API perfettamente valide.
Il ruolo delle identità nel cloud
Nel cloud moderno, il vero perimetro di sicurezza non è più la rete, ma l’identità. Questo significa che compromettere un account equivale, di fatto, a compromettere l’intero ambiente.
Le identità possono essere sfruttate in diversi modi:
- accesso diretto con credenziali rubate
- utilizzo di token OAuth
- abuso di service principal
Uno degli aspetti più critici è che molti sistemi cloud utilizzano token a lunga durata, che permettono accessi persistenti senza necessità di reinserire le credenziali.
Ecco un esempio di richiesta API utilizzando un token OAuth:
curl -X GET https://graph.microsoft.com/v1.0/me/messages \
-H “Authorization: Bearer ACCESS_TOKEN”
Se un attaccante riesce a ottenere questo token, può accedere alla posta elettronica senza bisogno della password.
Token e session hijacking
I token rappresentano uno degli elementi più vulnerabili nel cloud. A differenza delle password, spesso non sono protetti da autenticazione multifattore e possono essere riutilizzati.
Un attacco tipico prevede:
- phishing o token theft
- utilizzo del token per accesso API
- escalation dei privilegi
In molti casi, il token viene memorizzato nel browser o in applicazioni locali. Se un attaccante riesce a intercettarlo, può impersonare l’utente.
Esempio di utilizzo di un token AWS:
aws s3 ls –access-key ACCESS_KEY \
–secret-key SECRET_KEY \
–session-token SESSION_TOKEN
Questo comando permette di accedere direttamente alle risorse senza autenticazione aggiuntiva.
Configurazioni errate: il vero punto debole
Uno dei fattori più comuni nei cloud breach senza malware è la presenza di configurazioni errate. Questo può includere:
- bucket pubblici
- ruoli IAM troppo permissivi
- API esposte
Ad esempio, un bucket S3 configurato come pubblico può esporre dati sensibili senza alcuna violazione tecnica.
Ecco un esempio di policy errata:
{
“Effect”: “Allow”,
“Principal”: “*”,
“Action”: “s3:GetObject”,
“Resource”: “arn:aws:s3:::example-bucket/*”
}
Questa configurazione consente a chiunque di leggere i file nel bucket.
Abuso delle API cloud
Le API rappresentano il cuore del cloud. Tutto passa da lì: gestione utenti, accesso ai dati, configurazione dei servizi.
Un attaccante può utilizzare le API per:
- enumerare risorse
- creare nuovi utenti
- modificare configurazioni
Esempio con Azure CLI:
az ad user list –output table
Questo comando restituisce l’elenco degli utenti, utile per identificare target privilegiati.
Persistenza senza malware
Uno degli aspetti più pericolosi è la capacità di mantenere accesso nel tempo senza installare nulla.
Le tecniche includono:
- creazione di nuovi utenti
- aggiunta di chiavi API
- registrazione di applicazioni OAuth
Esempio:
az ad app create –display-name “backup-access”
Questa applicazione può essere usata per accedere ai dati anche dopo la rimozione dell’utente compromesso.
Movimento laterale nel cloud
Nel cloud, il movimento laterale avviene principalmente attraverso le identità e i ruoli.
Un attaccante può:
- assumere ruoli IAM
- sfruttare trust relationships
- accedere a risorse cross-account
Esempio AWS:
aws sts assume-role \
–role-arn arn:aws:iam::123456789012:role/Admin \
–role-session-name attack-session
Questo consente di ottenere privilegi elevati.
Logging e detection: perché è difficile rilevare questi attacchi
Uno dei problemi principali dei living off the cloud attacks è la difficoltà di rilevamento. A differenza degli attacchi tradizionali, che spesso introducono elementi estranei come malware, script sospetti o exploit, in questo caso tutto avviene utilizzando strumenti perfettamente legittimi e previsti dal sistema. Questo rende estremamente complesso distinguere tra attività normale e attività malevola.
Le attività sembrano legittime:
- accessi da API ufficiali
- utilizzo di credenziali valide
- nessun file sospetto
Per questo motivo, la sicurezza deve evolversi verso:
- analisi comportamentale
- monitoraggio delle identità
- correlazione degli eventi
Il punto chiave è che, nel cloud, la superficie di attacco coincide quasi completamente con la superficie operativa. Tutto ciò che un amministratore può fare, può farlo anche un attaccante se riesce a ottenere accesso. Non esiste più una distinzione netta tra comportamento lecito e illecito basata sugli strumenti utilizzati, perché gli strumenti sono gli stessi.
Un ulteriore elemento che complica la detection è la standardizzazione delle operazioni cloud. Le API sono progettate per essere utilizzate in modo automatizzato e su larga scala. Questo significa che anche operazioni potenzialmente pericolose, come la creazione di utenti o la modifica dei privilegi, possono avvenire centinaia di volte al giorno in ambienti complessi. In questo contesto, identificare una singola azione malevola diventa come cercare un ago in un pagliaio.
Esempio
Può chiarire meglio questo concetto. Supponiamo che un attaccante utilizzi le API per elencare tutte le risorse disponibili in un tenant:
aws ec2 describe-instances
Questa operazione è identica a quella eseguita da un amministratore durante una normale attività di gestione. Senza un contesto adeguato, non è possibile distinguere tra le due.
Un altro fattore critico è la mancanza di visibilità sulle intenzioni. I sistemi di logging registrano cosa è stato fatto, ma non perché è stato fatto. Questo significa che anche sequenze di azioni apparentemente innocue possono nascondere un attacco strutturato. Ad esempio:
- accesso a un account
- lettura di file
- creazione di una nuova applicazione
Singolarmente, queste operazioni sono normali. Ma se eseguite in sequenza e in un contesto anomalo, possono indicare una compromissione.
Un problema spesso sottovalutato è quello della latenza nella rilevazione. Molti sistemi di sicurezza analizzano i log in modalità batch o con ritardi significativi. In un attacco cloud, invece, tutto avviene molto rapidamente: un attaccante può ottenere accesso, creare persistenza e iniziare l’esfiltrazione dei dati in pochi minuti. Se la detection arriva troppo tardi, il danno è già stato fatto.
Inoltre, gli attaccanti più sofisticati adottano tecniche per ridurre ulteriormente la probabilità di rilevamento. Tra queste:
- esecuzione di azioni a bassa frequenza per evitare picchi anomali
- utilizzo di orari compatibili con quelli lavorativi dell’utente compromesso
- accesso da indirizzi IP simili o geograficamente plausibili
Queste strategie rendono ancora più difficile identificare comportamenti sospetti basandosi su regole statiche.
Un altro elemento fondamentale è la frammentazione dei log. In molti ambienti cloud, i dati sono distribuiti tra diversi sistemi:
- log di autenticazione
- log delle API
- log delle applicazioni
- log di rete
Se questi dati non vengono centralizzati e correlati, è praticamente impossibile ricostruire una catena di attacco completa. Un evento isolato non è quasi mai sufficiente per generare un alert significativo.
Per affrontare queste sfide, è necessario adottare un approccio basato sulla telemetria avanzata e sulla contestualizzazione. Non basta sapere che un’azione è stata eseguita: bisogna sapere da chi, quando, da dove e in quale sequenza rispetto ad altre azioni.
Ad esempio, un sistema avanzato potrebbe rilevare che:
- un utente accede da una nuova posizione
- pochi minuti dopo crea una nuova chiave API
- successivamente accede a grandi quantità di dati
Questa sequenza, analizzata nel suo insieme, rappresenta un chiaro indicatore di compromissione.
Infine, è importante sottolineare che la difficoltà di rilevamento non è solo un problema tecnico, ma anche organizzativo. Molte aziende non hanno ancora sviluppato competenze adeguate per analizzare i log cloud in modo efficace. Senza un team preparato e strumenti adeguati, anche le migliori tecnologie rischiano di essere inutili.
In conclusione, gli attacchi living off the cloud sono difficili da rilevare perché non violano le regole del sistema, ma le sfruttano in modo intelligente. Per questo motivo, la difesa deve spostarsi da un approccio basato su firme e indicatori statici a un modello dinamico, basato su comportamento, contesto e correlazione. Solo così è possibile individuare minacce che, a prima vista, sembrano indistinguibili dalla normale operatività.
Strategie di difesa avanzate
Difendersi dagli attacchi cloud breach senza malware richiede un cambio di paradigma profondo rispetto alla sicurezza tradizionale. Non si tratta più di bloccare file malevoli o rilevare comportamenti evidenti, ma di comprendere e governare in modo rigoroso l’uso legittimo delle risorse cloud. Gli attacchi living off the cloud sfruttano infatti esattamente ciò che dovrebbe essere consentito: accessi validi, API ufficiali e configurazioni apparentemente corrette.
Per questo motivo, le strategie di difesa devono concentrarsi su tre pilastri fondamentali: least privilege, gestione dei token e monitoraggio continuo, ma devono anche essere integrate in un’architettura più ampia basata su identità, contesto e comportamento.
Principio del least privilege: oltre la teoria
Il principio del least privilege (privilegio minimo) è spesso citato, ma raramente implementato correttamente. In un ambiente cloud complesso, significa garantire che ogni identità, utente, servizio o applicazione, abbia accesso solo alle risorse strettamente necessarie e per il tempo strettamente necessario.
Il problema reale è che molti ambienti cloud crescono rapidamente e accumulano privilegi nel tempo. Un utente che inizialmente aveva bisogno di accesso amministrativo potrebbe non averne più bisogno, ma mantiene comunque quei permessi. Questo crea una superficie di attacco enorme.
Un approccio avanzato prevede:
- Just-In-Time (JIT) access
i privilegi elevati vengono concessi solo temporaneamente - Just-Enough-Access (JEA)
accesso limitato a specifiche operazioni - Segregazione dei ruoli (RBAC avanzato)
Esempio AWS di policy più restrittiva rispetto a un accesso globale:
{
“Effect”: “Allow”,
“Action”: [
“s3:GetObject”
],
“Resource”: “arn:aws:s3:::company-data/reports/*”
}
Qui l’accesso è limitato solo alla lettura di una specifica cartella, evitando esposizioni inutili.
Un altro esempio in Azure (role assignment limitato):
az role assignment create \
–assignee user@example.com \
–role “Reader” \
–scope /subscriptions/xxxx/resourceGroups/prod-rg
In questo caso, l’utente può solo leggere risorse in un gruppo specifico, senza possibilità di modificarle.
Rotazione dei token e gestione delle credenziali
Nel contesto degli attacchi senza malware, i token rappresentano il punto più critico. A differenza delle password, spesso non vengono gestiti con la stessa attenzione e possono rimanere validi per lunghi periodi.
Un attaccante che ottiene un token OAuth o una chiave API può accedere alle risorse senza essere rilevato, soprattutto se il traffico API è considerato legittimo.
Per mitigare questo rischio è fondamentale:
- implementare token a breve durata (short-lived tokens)
- utilizzare refresh token controllati
- revocare automaticamente token inutilizzati
- adottare Managed Identity dove possibile
Esempio AWS: generazione di credenziali temporanee tramite STS:
aws sts get-session-token –duration-seconds 3600
Questo comando limita la validità del token a un’ora, riducendo drasticamente la finestra di attacco.
Esempio di revoca token in Azure:
az account revoke-session –user user@example.com
Un altro approccio avanzato è l’uso di secrets manager, evitando completamente la gestione manuale delle chiavi:
aws secretsmanager get-secret-value –secret-id my-secret
In questo modo, le credenziali non sono mai hardcoded nel codice.
Monitoraggio continuo e detection comportamentale
Il monitoraggio continuo è probabilmente l’elemento più importante nella difesa contro attacchi living off the cloud. Poiché le azioni dell’attaccante sono spesso indistinguibili da quelle legittime, è necessario analizzare il comportamento, non solo gli eventi.
Un sistema avanzato di detection deve essere in grado di identificare:
- accessi da località anomale
- utilizzo insolito di API
- escalation improvvise di privilegi
- creazione sospetta di nuove identità
Esempio: query su log AWS CloudTrail per rilevare attività anomale:
{
“eventName”: [“CreateUser”, “AttachRolePolicy”],
“sourceIPAddress”: “0.0.0.0/0”
}
Oppure in Azure con Kusto Query Language (KQL):
SigninLogs
| where Location != “Italy”
| where ResultType == 0
| project UserPrincipalName, IPAddress, Location, TimeGenerated
Questa query identifica login riusciti da località insolite.
Un altro esempio utile è il rilevamento di creazione di app OAuth sospette:
AuditLogs
| where OperationName == “Add service principal”
| project TargetResources, InitiatedBy, TimeGenerated
Micro-segmentazione e controllo del contesto
Un’evoluzione naturale del least privilege è la micro-segmentazione, che limita ulteriormente l’accesso in base al contesto:
- indirizzo IP
- dispositivo
- orario
- livello di rischio
La policy che hai riportato è un esempio classico di controllo basato su IP:
{ "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "IpAddress": { "aws:SourceIp": "192.168.1.0/24" } } }
Questa policy nega qualsiasi accesso se la richiesta non proviene da una rete specifica. È efficace, ma da sola non basta.
Un approccio più avanzato combina più condizioni:
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": "192.168.1.0/24"
},
"Bool": {
"aws:MultiFactorAuthPresent": "false"
}
}
}Qui l’accesso viene negato se:
- l’IP non è autorizzato
- l’MFA non è presente
Automazione e risposta agli incidenti
Un aspetto spesso sottovalutato è la risposta automatizzata. In un attacco cloud, la velocità è tutto. Se un attaccante crea un token o una nuova identità, ogni minuto conta.
È fondamentale implementare:
- playbook automatici (SOAR)
- revoca immediata dei privilegi sospetti
- isolamento delle risorse
Esempio: revoca automatica di una chiave IAM sospetta:
aws iam update-access-key \
–access-key-id ABC123 \
–status Inactive
Oppure eliminazione di un utente compromesso:
aws iam delete-user –user-name compromised-user
Verso una sicurezza identity-driven
Tutte queste strategie convergono verso un modello di sicurezza identity-driven, in cui:
- ogni accesso è verificato
- ogni azione è tracciata
- ogni anomalia è analizzata
Non esiste più un “interno sicuro” e un “esterno pericoloso”. Esiste solo un flusso continuo di richieste che devono essere validate in tempo reale.
Conclusione operativa
Proteggere un ambiente cloud da attacchi senza malware significa accettare una verità fondamentale: non puoi più fidarti delle apparenze. Un accesso valido non è necessariamente legittimo.
Per questo motivo, una strategia efficace deve combinare:
- controllo rigoroso dei privilegi
- gestione dinamica delle credenziali
- monitoraggio comportamentale avanzato
- automazione della risposta
Solo così è possibile contrastare attacchi che non lasciano tracce evidenti, ma che possono compromettere completamente un tenant utilizzando esclusivamente ciò che è già disponibile.
Zero Trust e sicurezza cloud
Il modello Zero Trust è fondamentale per contrastare questi attacchi.
I principi chiave sono:
- verificare sempre
- non fidarsi mai
- monitorare continuamente
Questo significa che ogni accesso deve essere autenticato e autorizzato, indipendentemente dalla provenienza.
Caso reale: compromissione di un tenant Microsoft 365
Immaginiamo uno scenario reale:
- phishing → ottenimento credenziali
- accesso → generazione token
- creazione app OAuth
- accesso persistente ai dati
Nessun malware, nessun exploit. Solo uso intelligente delle funzionalità cloud.
Il futuro degli attacchi cloud
Gli attacchi diventeranno sempre più invisibili. L’uso di AI e automazione permetterà agli attaccanti di:
- analizzare configurazioni
- sfruttare errori
- muoversi rapidamente
Tra le sfide più importanti della cyber security moderna
Il concetto di cloud breach senza malware rappresenta una delle sfide più importanti della cyber security moderna. Gli attacchi living off the cloud dimostrano che non serve violare un sistema per comprometterlo: basta comprenderlo meglio del suo proprietario.
Per questo motivo, la sicurezza deve evolvere. Non basta più proteggere la rete o installare antivirus. È necessario adottare un approccio basato sulle identità, sulle configurazioni e sul monitoraggio continuo.
Domande e risposte
- Cos’è un cloud breach senza malware?
È una compromissione di un ambiente cloud senza uso di software malevolo. - Cosa significa living off the cloud?
Sfruttare strumenti e API legittime del cloud per attaccare. - I token sono pericolosi?
Sì, perché possono essere riutilizzati senza autenticazione. - Le API possono essere usate per attacchi?
Sì, se abusate possono permettere accessi non autorizzati. - Cos’è un tenant?
È un ambiente isolato all’interno di un servizio cloud. - Come si prevengono questi attacchi?
Con controllo delle identità e monitoraggio continuo. - Il malware è ancora usato?
Sì, ma sempre meno in contesti cloud avanzati. - Cos’è Zero Trust?
Un modello che non si fida di nessun accesso. - AWS e Azure sono vulnerabili?
Non direttamente: il problema sono le configurazioni. - Qual è il rischio principale?
L’accesso non rilevato e persistente ai dati.
