Buste paga dirottate: quando il social engineering buca i controlli

Spesso si tende a sottovalutare il social engineering e a identificare come minacce reali principalmente malware, le backdoor e simili. Un caso evidenziato dalla Unit 42 fa riflettere circa l’equivoco dietro a questo approccio. Nel 2025 Unit 42 Global Incident Response Report: Social Engineering Edition, gli esperti portano all’attenzione un caso emblematico: un attaccante ha dirottato gli stipendi di un’azienda dopo avere raggirato più help desk interni e ottenuto il reset della password e dei fattori di autenticazione. Nessun exploit, nessuna violazione di firewall o sfruttamento di vulnerabilità: solo persuasione e manipolazione.

La dinamica del raggiro è emersa a seguito delle lamentele da parte dei dipendenti a cui non erano stati accreditati gli stipendi: qualcuno aveva cambiato le coordinate dei bonifici, dirottando i pagamenti delle buste paga su conti correnti controllati dall’attaccante. Secondo il report in oggetto, questa categoria di frodi riguarda il 36% degli incidenti gestiti nel periodo di analisi.

Ripercorriamo la catena di attacco per comprenderne le dinamiche. Il primo contatto è una semplice telefonata, svolta da una persona con un’identità fittizia ma credibile, che ha sfruttato informazioni pubblicamente disponibili sui social per presentarsi come un dipendente legittimo che aveva un problema da risolvere. Sono seguite altre telefonate, utili all’attaccante per capire quali domande di verifica vengono poste nel caso che gli interessava, quali dati personali o aziendali erano richiesti, su quali aspetti gli operatori tendeva ad allentare il controllo nel momento in cui il dipendente manifesti una forte urgenza. Chiamata dopo chiamata, l’attaccante ha potuto arricchire il proprio copione, fino a costruire un’identità quasi indistinguibile da quella di un vero collega.

Il tutto tenendo conto di un aspetto fondamentale: l’help desk è progettato per sbloccare, non per bloccare. Di fronte a un utente che lamenta di non poter lavorare, che usa la terminologia interna, che conosce contesto, ruoli e perfino nomi dei colleghi, l’operatore tende a individuare una soluzione rapida che mette da parte la sicurezza formale a favore di un approccio pratico e più elastico. L’attaccante è così riuscito a convincere gli operatori di diversi help desk (payroll, IT e HR) a resettare la password di un utente amministrativo e reimpostare i dispositivi per la multifactor authentication.

Parallelamente, il threat actor si è garantito un punto d’appoggio silente nell’infrastruttura cloud e ha registrato un indirizzo email esterno come metodo di autenticazione per un account di servizio all’interno dell’ambiente Azure AD dell’azienda target. A questo punto la fase pratica dell’attacco era semplice e veloce: l’attaccante ha modificato le coordinate bancarie associate a ciascun dipendente, reindirizzando il flusso di denaro a proprio favore.
Il modus operandi di questo attacco ha reso l’attività difficile da distinguere dal rumore di fondo delle operazioni HR. L’unico campanello di allarme si è attivato troppo tardi, ossia quando non è avvenuto l’accredito degli stipendi.

L’indagine condotta dagli analisti ha appurato l’assenza di movimenti laterali e di esfiltrazione di una quantità sospetta di dati. Non risultano movimenti su sistemi critici diversi da quelli coinvolti nelle operazioni payroll e HR, né tracce di tentativi di sfruttare l’accesso per scaricare database completi o raggiungere altri segmenti di rete interni.

La Unit 42 ha lavorato per contenere la compromissione degli account e riprendere il controllo delle identità cloud coinvolte, ha revocato gli accessi sospetti, verificato i dispositivi MFA associati e annullato le modifiche fraudolente ai dati di pagamento, per garantire che gli accrediti successivi andassero effettivamente al legittimo destinatario.

Resta il fatto che il caso ha messo a nudo un punto debole comune a molte aziende: i processi operativi legati alle identità, in particolare quelli gestiti dai help desk, non sono ancora trattati con la stessa disciplina e rigore dei flussi di autenticazione. Password reset, iscrizione e recupero MFA, validazione di richieste “urgenti” di accesso ai sistemi critici restano spesso affidati alla capacità di giudizio del singolo operatore di riconoscere un pretesto, più che a controlli strutturati e ridondanti.

Per questo la Unit 42 sottolinea tre elementi importanti: la necessità di una visibilità unificata sull’ambiente, le skill del team di sicurezza e la centralità delle procedure di verifica per tutte le richieste legate alle identità, con particolare attenzione a quelle che passano per canali “umani” come il telefono o le chat di supporto.