Come gli attaccanti sfruttano l’impersonazione del helpdesk per aggirare l’MFA

Immagina che un ladro non debba rompere la porta principale della tua azienda, ma semplicemente chiamare l’ufficio di supporto e fingere di essere un dipendente bloccato. Questa è la realtà dell’impersonazione del helpdesk, una tattica di ingegneria sociale che si è trasformata nel punto di ingresso principale per le intrusioni basate sull’identità. Mentre molte aziende si concentrano sul bloccare la chiamata iniziale, il vero pericolo inizia dopo: una volta che l’attaccante ha ottenuto un password resettata o un nuovo token MFA, può muoversi silenziosamente nella rete.

La soluzione rapida è fondamentale: non basare la sicurezza solo sulla detection della chiamata originale. Devi monitorare le quattro fasi successive all’accesso che generano segnali forensi chiari. Se il tuo team di sicurezza opera aggiorna le sue regole per rilevare questi comportamenti specifici, potrai bloccare l’attacco prima che i dati siano sottratti, anche se la chiamata fraudolenta non è mai stata identificata. In questo articolo, esploreremo come avviene questo processo e quali strumenti tecnici adottare per fermarlo.

Il meccanismo di inganno: come l’impersonazione supera l’MFA

L’impersonazione del helpdesk non richiede competenze informatiche avanzate, ma un’abilità psicologica raffinata. Gli attaccanti raccolgono informazioni pubbliche da fonti come LinkedIn o siti aziendali per costruire identità credibili, spesso citando dettagli interni o utilizzando un linguaggio tecnico appropriato [1]. Una volta stabilito il contatto, utilizzano tattiche di pressione psicologica, come l’urgenza di partecipare a una riunione importante o la necessità di accedere a piattaforme di videoconferenza, per spingere gli operatori del supporto a bypassare le procedure standard [1][4].

Il risultato è spesso un reset della password o un cambio del dispositivo MFA senza la verifica corretta dell’identità del richiedente [4]. In alcuni casi, gli attaccanti utilizzano anche cloni vocali generati dall’AI o video deepfake live per rendere indistinguibili la loro voce e il loro aspetto da quelli del dipendente vero [4]. Questo accesso iniziale permette agli aggressori di entrare nei sistemi aziendali, spostarsi lateralmente nella rete ed esfiltrare dati senza attivare allarmi immediati [1].

Le quattro fasi post-ingresso: segnali di sicurezza rilevabili

Una volta che l’attaccante ha superato il primo ostacolo, il processo di attacco si divide in quattro fasi distinte. Ogni fase genera segnali forensi che possono essere rilevati indipendentemente dalla chiamata iniziale. Questi segnali sono cruciali perché permettono ai CISO (Chief Information Security Officers) di identificare l’intrusione anche se l’inganno sociale è passato sotto silenzio.

1. Enumerazione dei privilegi e movimento laterale

Il primo movimento dopo l’accesso non è l’esfiltrazione dei dati, ma l’enumerazione dei privilegi. L’attaccante utilizza comandi per scoprire quali risorse la nuova identità può raggiungere, queryando directory come Azure Active Directory (ora Microsoft Entra ID) per ottenere informazioni sui gruppi, sui ruoli e sulle autorizzazioni [1]. Questo comportamento è anomalo se un utente esegue comandi di scoperta account che non ha mai usato prima, o se lo fa in orari insoliti, come le 2:00 del mattino in un ambiente dove l’accesso umano avviene solo durante l’orario di lavoro [1].

Dopo aver mappato i privilegi, l’attaccante esegue il movimento laterale. Utilizzano strumenti di gestione remota legittimi (RMM) come AnyDesk o TeamViewer, che gli endpoint aziendali già considerano sicuri, per spostarsi tra i dispositivi senza attivare controlli basati su firme [1]. Il segnale chiave è l’esecuzione di un binario RMM da un account utente che non ha mai utilizzato tali strumenti prima. Se un account esegue un software di accesso remoto per la prima volta entro 72 ore da un cambio MFA, questo è un indicatore forte che richiede un’analisi immediata [1].

2. Meccanismi di persistenza

Per garantire che l’accesso non venga revocato con un futuro reset della password, gli attaccanti implementano meccanismi di persistenza. Una tattica comune è registrare nuovi dispositivi MFA contro gli account compromessi, creando una copia del loro punto di appoggio [1]. Il segnale di rilevamento è il nuovo enrollment di un dispositivo MFA proveniente da una geografia, un range IP o un tipo di dispositivo mai utilizzato prima per quell’account specifico [1]. I log di audit dei provider di identità, come Microsoft Entra ID o Okta, producono nativamente questo evento, ma spesso le regole di allerta non sono configurate per rilevare il primo enrollment da un dispositivo nuovo [1].

Un secondo meccanismo di persistenza è il SIM-swapping del numero di telefono del vittima, per far indirizzare l’MFA basato su voce all’hardware controllato dall’attaccante [1]. Il segnale è la modifica del numero mobile nel profilo MFA del provider di identità che non proviene da una sessione self-service autenticata dal dispositivo esistente [1].

3. Segnali di esfiltrazione

L’esfiltrazione dei dati in queste campagne avviene spesso attraverso servizi di sincronizzazione cloud legittimi, come SharePoint e OneDrive, per bypassare i controlli di prevenzione della perdita di dati (DLP) [1]. Il segnale di rilevamento è una anomalia di volume: un utente che carica dati a una velocità statisticamente fuori dalla sua baseline storica personale, non rispetto a una soglia globale dell’azienda [1]. Una soglia globale di 500 MB al giorno potrebbe non rilevare un attaccante che carica 1 GB da un account con una baseline storica di meno di 5 MB per settimana [1].

4. Controlli indipendenti dall’impersonazione originale

Ogni fase di questa catena offre una superficie di rilevamento che funziona indipendentemente dall’avere identificato la chiamata di ingegneria sociale. Un team di sicurezza che configura questi quattro segnali non ha bisogno di aver identificato l’impersonazione iniziale per contenere intrusioni simili a quelle di Scattered Spider prima che l’esfiltrazione sia completata [1].

Technical Deep Dive: Implementazione tecnica e best practice avanzate

Per i tecnici e gli esperti di sicurezza, l’implementazione di queste detection richiede una configurazione precisa dei sistemi di log e delle regole di allerta. Ecco i dettagli tecnici necessari per costruire una difesa efficace.

Configurazione delle regole di allerta per l’enrollment MFA

Ogni nuovo enrollment di un authenticator entro 72 ore da un cambio di password o MFA guidato dal helpdesk deve generare un evento di triage di livello 1. L’advisory di CISA AA23-347A identifica questo evento combinato come il segnale post-impersonazione ad più alta fedeltà disponibile per i team di identità [1]. È fondamentale configurare i log di audit di Microsoft Entra ID, Okta o Ping Identity per rilevare eventi di enrollment da dispositivi nuovi, non solo per qualsiasi enrollment [1].

Baseline per utenti RMM e detection di primo utilizzo

La costruzione di baseline profili per utente per l’uso di software RMM è essenziale. L’esecuzione di un binario di accesso remoto da un account senza storico precedente di RMM è un indicatore di movimento laterale ad alto segnale che i controlli basati su firme non rilevano [1]. La documentazione MITRE ATT&CK T1219 descrive questa tecnica; ciò che manca in molti ambienti è la baseline per utente che rende l’esecuzione di primo utilizzo rilevabile come un valore booleano, non solo come soglia di volume [1].

Adattamento dei controlli DLP e CASB alle baseline per utente

I controlli DLP e CASB (Cloud Access Security Broker) devono essere configurati con baseline di egress per utente. L’esfiltrazione di sincronizzazione cloud che colpisce account con attività di upload historicamente bassa non attivirà un allarme di volume giornaliero globale. Secondo le indicazioni di NIST SP 800-92 per la gestione dei log, la rilevazione efficace basata sui log richiede l’istituzione di baseline comportamentali specifiche per l’utente prima di applicare le soglie di anomalia [1].

Verificazione out-of-band per i reset MFA di account privilegiati

L’advisory di CISA AA23-347A raccomanda un secondo canale di verifica per i reset MFA su account che detengono privilegi amministrativi, diverso dal canale di impersonazione [1]. Un attaccante che ha effettuato la chiamata al helpdesk non può intercettare una conferma inviata al manager del titolare dell’account tramite un percorso di autenticazione separato [1]. Questa misura chiude il cancino prima che qualsiasi delle quattro fasi forensi debba essere attivata, prevenendo l’intrusione in anticipo [1].

In sintesi, la difesa contro l’impersonazione del helpdesk richiede un approccio che combina la consapevolezza umana con una rigorosa configurazione tecnica dei sistemi di monitoraggio. Monitorando queste quattro fasi critiche, le organizzazioni possono mitigare efficacemente i rischi associati a queste intrusioni sofisticate.

Fonte: https://www.cybersecurity-insiders.com/helpdesk-impersonation-post-mfa-attack-chain-detection/