Il Google Threat Intelligence Group ha descritto tre distinti gruppi di attività di cyber spionaggio con legami russi. Le operazioni hanno colpito persone che lavorano in ambito accademico, governativo, diplomatico, aerospaziale, difesa e ricerca, soprattutto in Europa e negli Stati Uniti.
È una notizia che colpisce per il riferimento alla Russia. Per chi difende un’organizzazione, però, il dettaglio più importante è il metodo: gli attaccanti non imitano sempre il login. In diversi casi inducono la persona a usare una procedura vera, su un servizio vero, per autorizzare l’accesso sbagliato.
Il richiamo è la Russia, il problema è l’autorizzazione
Google traccia i gruppi con le sigle UNC6293, UNC7005 e UNC5976. Le campagne sono selettive e orientate allo spionaggio: non rappresentano quindi un’ondata indiscriminata contro qualsiasi impresa. Questo limite va mantenuto chiaro.
Le tecniche osservate, invece, hanno un valore più generale. Inviti a conferenze, condivisioni sicure di documenti, chiamate riservate e contatti diplomatici costruiscono un contesto credibile. A quel punto la vittima viene accompagnata verso una funzione reale di autenticazione o collegamento dell’account.
La pagina del provider può essere autentica. Anche il dominio su cui si inseriscono le credenziali può esserlo. Ciò che cambia è chi ha avviato il flusso e quale sessione viene autorizzata alla fine.
Quando l’MFA conferma la richiesta dell’attaccante
Uno degli esempi riguarda il device code phishing. Il codice dispositivo è un meccanismo OAuth pensato per apparecchi con un’interfaccia limitata: il dispositivo mostra un codice e la persona completa l’accesso da un browser. Microsoft ha documentato come un attaccante possa iniziare la procedura, consegnare il proprio codice alla vittima e convincerla ad approvarlo sul sito legittimo.
L’autenticazione a più fattori può quindi funzionare esattamente come previsto e confermare comunque la sessione sbagliata. Non è una debolezza intrinseca dell’MFA: è l’abuso del contesto e del consenso. La richiesta tecnica è valida, ma nasce da un’iniziativa che la persona non ha realmente avviato.
OAuth e app password: accesso senza chiedere la password
Altre operazioni hanno utilizzato il consenso OAuth. La vittima accede al proprio account e autorizza un’applicazione controllata dall’attaccante, che può così ricevere token utili ad accedere a dati o servizi. La password non deve necessariamente essere rubata.
Google segnala anche l’uso delle app password, codici creati per consentire l’accesso ad applicazioni o dispositivi che non supportano le modalità di autenticazione più recenti. Gli aggressori hanno impersonato interlocutori istituzionali e guidato le persone nella creazione e nella consegna di questi codici, aggirando di fatto la protezione aggiuntiva del secondo fattore.
Il segnale da ricordare è semplice: una password per le app non serve a verificare l’identità e non deve essere condivisa. Dove non è necessaria, la possibilità di crearla dovrebbe essere limitata o disabilitata.
Anche WhatsApp può diventare una porta laterale
In alcune campagne, false chiamate o condivisioni riservate hanno portato le vittime a collegare il proprio account WhatsApp a un dispositivo controllato dall’attaccante. Il codice e il QR visualizzati appartenevano a una vera procedura di collegamento; era la finalità a essere ingannevole.
Questo aspetto è importante perché molte relazioni professionali proseguono su canali personali. Un dirigente, un ricercatore o un responsabile tecnico può ricevere contatti sensibili fuori dalla posta aziendale. Per l’organizzazione nasce così una zona poco visibile, nella quale un account compromesso può essere usato anche per raggiungere colleghi e partner con un’identità ormai attendibile.
Cinque controlli che riducono lo spazio di manovra
- Limitare i metodi legacy: disabilitare le app password quando non servono e preferire fattori resistenti al phishing, come passkey e chiavi di sicurezza.
- Governare i consensi OAuth: controllare quali applicazioni possono essere autorizzate, con quali permessi e da quali utenti.
- Rivedere sessioni e dispositivi: verificare periodicamente accessi attivi, applicazioni collegate e dispositivi associati agli account di lavoro e di messaggistica.
- Osservare il comportamento: correlare nuovi consensi, accessi anomali, cambi di dispositivo e uso insolito dei token, invece di fermarsi al solo esito positivo del login.
- Verificare fuori dal messaggio: confermare inviti e richieste sensibili usando un contatto ottenuto da una fonte indipendente, non rispondendo allo stesso mittente.
Un login riuscito non è la fine della verifica
Queste campagne legate alla Russia mostrano una trasformazione precisa: l’identità digitale non viene sempre forzata o imitata. Può essere guidata, con pazienza, verso un’autorizzazione formalmente corretta.
Per questo la sicurezza delle identità non può limitarsi a chiedere un secondo fattore. Servono visibilità sulle applicazioni autorizzate, controllo delle sessioni, procedure di revoca rapide e attenzione agli account personali delle persone più esposte. La domanda non è soltanto “il login è riuscito?”, ma “chi lo ha iniziato e che cosa abbiamo appena autorizzato?”.