I punti ciechi nel logging dell'autenticazione cloud

Un team di sicurezza di TrustedSec ha recentemente rivelato il terzo e il quarto metodo per aggirare il logging dei sign-in di Azure. Sono quattro tecniche indipendenti per autenticarsi ai servizi cloud Microsoft senza che l'autenticazione compaia nei log su cui i team di sicurezza fanno affidamento per il rilevamento. L'accesso c'è stato. I log non l'hanno registrato. Chiunque monitorasse quei log alla ricerca di attività sospette non ha visto nulla.

Non è un problema teorico. Se un attaccante ruba delle credenziali e le usa per accedere al tuo ambiente Azure, la prima cosa che fa il team di sicurezza è controllare i log dei sign-in. Se quei log sono incompleti, cioè se intere categorie di autenticazione non generano voci di log, la tua capacità di rilevamento ha una falla di cui non eri a conoscenza. E hai preso decisioni di sicurezza basandoti sul presupposto che i log fossero completi.

Perché i log di autenticazione hanno delle lacune

L'ipotesi ingenua è che il logging dell'autenticazione sia semplice: qualcuno si autentica, tu lo registri. In pratica, l'autenticazione cloud è un sistema complesso con decine di protocolli, endpoint e tipi di token, e la copertura del logging varia da uno all'altro.

Azure Active Directory (ora Entra ID) gestisce l'autenticazione per Microsoft 365, le risorse Azure, le app di terze parti tramite SAML/OIDC, le app on-premises legacy tramite App Proxy, le service principal, le managed identity e altro ancora. Ognuno di questi percorsi di autenticazione ha il proprio backend, la propria pipeline di logging e i propri casi limite. I log dei sign-in sono generati dal servizio di autenticazione, ma alcuni flussi bypassano il servizio standard o usano percorsi legacy che precedono l'attuale infrastruttura di logging.

Lacune dei protocolli legacy

Microsoft mantiene la retrocompatibilità con protocolli di autenticazione dei primi anni 2000, protocolli che precedono la sua infrastruttura di logging moderna. Alcuni percorsi di autenticazione SMTP, IMAP e POP3 usano flussi ‘Basic Auth’ che si autenticano a livello di trasporto della posta invece che tramite il normale endpoint dei token di Azure AD. Queste autenticazioni potrebbero non generare le stesse voci di log dei sign-in che generano i flussi OAuth/OIDC moderni.

Microsoft sta deprecando la Basic Auth da anni, ma nelle aziende la dismissione è lenta. Le organizzazioni con client di posta legacy, scanner che inviano documenti via email o applicazioni line-of-business più vecchie potrebbero avere ancora la Basic Auth abilitata. Ogni percorso legacy è un potenziale punto cieco nel logging.

Autenticazione delle service principal

Le service principal, cioè identità non umane usate da applicazioni e automazioni, si autenticano in modo diverso dagli utenti. I loro eventi di sign-in compaiono in un flusso di log separato (sign-in delle service principal contro sign-in interattivi e non interattivi). I team di sicurezza che monitorano solo il log dei sign-in interattivi non vedono affatto l'attività delle service principal.

Questo conta perché le service principal compromesse sono un vettore d'attacco comune. Un attaccante che ottiene le credenziali o il certificato di una service principal può autenticarsi come quell'applicazione e accedere a tutte le risorse per cui ha i permessi. Se il team di sicurezza guarda solo i sign-in degli utenti, non lo vedrà mai.

Replay e refresh dei token

Non ogni accesso comporta una nuova autenticazione. I refresh token OAuth permettono di continuare ad accedere senza riautenticarsi. Se un attaccante ruba un refresh token valido (tramite un dispositivo compromesso, traffico intercettato o malware), può scambiarlo con nuovi access token senza generare le stesse voci di sign-in che produrrebbe un'autenticazione con password. Il sign-in iniziale è stato registrato, ma i successivi refresh dei token possono apparire come sign-in non interattivi, che molte regole di rilevamento non monitorano.

Il problema dell'ingegneria del rilevamento

Le lacune nel logging dell'autenticazione rivelano un problema più ampio della sicurezza cloud: costruiamo sistemi di rilevamento sopra log che diamo per completi, e poi ci sorprendiamo quando gli attaccanti trovano percorsi che non generano log.

L'architettura di sicurezza standard per gli ambienti cloud funziona così: i servizi cloud generano log → i log confluiscono in un SIEM (Security Information and Event Management) → le regole di rilevamento analizzano i log alla ricerca di schemi sospetti → gli alert avviano le indagini. Questo funziona solo se i log catturano tutta l'attività rilevante. Se non lo fanno, il tuo SIEM è un modo molto costoso per monitorare un quadro incompleto.

Typical detection rule logic:
IF sign-in from unusual location
AND sign-in at unusual time
AND multiple failed attempts followed by success
THEN alert: possible credential compromise
What this misses:
- Authentication via legacy protocol → no sign-in log entry
- Stolen refresh token → appears as normal non-interactive sign-in
- Service principal abuse → in a different log stream entirely
- Authentication bypasses → sign-in doesn't appear at all
The rule is correct. The data it operates on is incomplete.

Cosa puoi fare concretamente

Non puoi correggere le lacune di logging dei cloud provider, che è compito di Microsoft (o di AWS, o di Google). Ma puoi costruire strategie di rilevamento che non dipendano esclusivamente dalla completezza dei log di autenticazione.

Monitora più fonti di log

I log di autenticazione sono un segnale. I log di attività sono un altro. Anche se il sign-in di un attaccante non compare nei log di autenticazione, le sue azioni successive (leggere email, accedere a file, interrogare database, modificare configurazioni) generano comunque le proprie voci di log. Correlare i log di attività con quelli di autenticazione fa emergere le incongruenze: un'attività da un'identità senza un sign-in recente corrispondente è sospetta, indipendentemente dal motivo per cui il sign-in non è stato registrato.

-- Detection query: activity without recent authentication
-- (KQL-style for Azure Sentinel/Microsoft Sentinel)
let timeframe = 24h;
let activity_logs = AuditLogs
| where TimeGenerated > ago(timeframe)
| summarize Actions = count() by Identity, bin(TimeGenerated, 1h);
let signin_logs = SigninLogs
| where TimeGenerated > ago(timeframe)
| summarize LastSignIn = max(TimeGenerated) by UserPrincipalName;
activity_logs
| join kind=leftanti signin_logs
on $left.Identity == $right.UserPrincipalName
| where Actions > 5  // filter noise
// Results: identities with activity but no sign-in log entry
// These need investigation — either a logging gap or a bypass

Disabilita l'autenticazione legacy

Se non usi protocolli legacy (Basic Auth per SMTP, IMAP, POP3), disabilitali. Questo elimina intere categorie di lacune, perché i percorsi di autenticazione che bypassano il logging moderno semplicemente non possono più essere usati. Le policy di Accesso Condizionale di Azure possono bloccare l'autenticazione legacy per singolo utente, per gruppo o per l'intero tenant.

Prima di disabilitarli, verifica l'uso attuale. I log dei sign-in di Azure (ironicamente) mostrano alcuni tentativi di autenticazione legacy, e la workbook di Entra ID per l'auth legacy aiuta a identificare le applicazioni che usano ancora protocolli vecchi. Sistema prima quelle applicazioni, poi blocca l'auth legacy.

Monitora l'attività dei token

Implementa la Continuous Access Evaluation (CAE) se il tuo ambiente la supporta. La CAE permette ad Azure AD di revocare i token quasi in tempo reale quando cambiano le condizioni (utente disabilitato, sign-in ad alto rischio rilevato, variazione della posizione IP). Senza CAE, un access token rubato resta valido fino alla scadenza, tipicamente un'ora, indipendentemente da ciò che fa il team di sicurezza.

Monitora anche la durata dei token e i pattern di refresh. Un refresh token usato da un nuovo indirizzo IP, da un nuovo dispositivo o in orari insoliti dovrebbe essere segnalato: spesso è l'unico segnale del furto di un token.

Testa il tuo logging

La cosa più utile che puoi fare è verificare regolarmente che il logging catturi davvero ciò che credi. Autenticati con ogni metodo supportato dal tuo ambiente (interattivo, non interattivo, service principal, protocollo legacy) e verifica che ognuno generi le voci di log attese. Se non lo fa, hai trovato una lacuna prima di un attaccante.

È una forma di test nell'ingegneria del rilevamento che poche organizzazioni fanno in modo sistematico. La maggior parte dei team scrive regole di rilevamento e presume che funzionino. Validare la qualità dei dati sottostanti, confermando che gli eventi da cui dipendono le regole vengano effettivamente registrati, è probabilmente più importante delle regole stesse.

La lezione più ampia

I bypass dei log di accesso di Azure non sono un caso unico di Microsoft. Ogni cloud provider ha percorsi di autenticazione con logging incompleto. AWS CloudTrail ha le sue lacune note: alcune operazioni del control plane in certe regioni, certe assunzioni di ruoli service-linked e pattern di concatenazione di ruoli cross-account che possono oscurare l'identità originale. I log di audit di Google Cloud hanno casi limite simili.

La lezione non è ‘il logging di Azure è rotto’. È che tutto il logging è incompleto, e le architetture di sicurezza che presumono il contrario falliranno. La difesa in profondità non significa solo avere più controlli di sicurezza, ma avere più fonti di visibilità indipendenti. Se il tuo rilevamento dipende interamente dal fatto che una sola fonte di log sia completa, hai un single point of failure nella tua postura di sicurezza.

Costruisci il tuo rilevamento partendo dal presupposto che qualsiasi singola fonte di log possa essere incompleta o aggirata. Correla log di autenticazione, log di attività, log di rete e telemetria degli endpoint. Cerca incongruenze tra le fonti, perché spesso indicano esattamente le lacune che gli attaccanti sfruttano. E testa il tuo logging regolarmente, perché la lacuna che non conosci è quella che verrà usata contro di te.