La frase che si sente in ogni riunione: "abbiamo la MFA, quindi siamo coperti". Poi arriva un accesso da un altro Paese, in orario di ufficio, dal browser di un dipendente che in quel momento è in ferie. Nessuna richiesta di conferma, nessun avviso. La sessione era già aperta, e qualcuno l'ha usata al posto suo.
È il furto più sottovalutato del momento, perché non somiglia a un attacco. Non c'è un malware che cifra i file, non c'è un sito clonato, non c'è una telefonata. C'è una macchina infetta, spesso personale, che consegna al ladro tutto quello che il browser teneva da parte.
Cosa fa un infostealer, in pratica
Un infostealer è un programma che vive su un computer infetto e copia ciò che trova: password salvate nel browser, cookie di sessione, token di accesso, configurazioni VPN, chiavi SSH, carte salvate, cronologia. Poi impacchetta tutto e lo manda a chi lo ha installato.
Non gli serve bucare il server dell'azienda. Gli basta il portachiavi di una persona, e quel portachiavi contiene l'accesso alla posta, a Salesforce, a Okta, a GitHub, al gestionale. Le macchine si infettano come sempre: software scaricato da un sito sbagliato, programmi piratati, allegati, estensioni, finti aggiornamenti.
I numeri di novembre 2026 danno la misura. Su un campione di 1.856 grandi organizzazioni in 36 Paesi, l'89,6% ha almeno una credenziale aziendale nei log degli infostealer, con una mediana di 32 per organizzazione. In Italia la percentuale è 91,3% e la mediana sale a 44,5: le aziende italiane analizzate hanno più credenziali esposte della media del campione. Nel mese osservato sono state aggiunte 28.473 credenziali, circa 950 al giorno, e il 55,5% delle organizzazioni ne ha guadagnata almeno una.
C'è un dato ancora più importante, che quasi nessuno guarda: accanto alle password, nello stesso tipo di archivio, girano 1,18 miliardi di cookie di sessione, 49,3 milioni raccolti nell'ultimo mese. Un cookie valido non è una password. È una sessione già autenticata, con la MFA già superata.
Perché la MFA non chiude questa porta
Quando un utente fa l'accesso, il sito gli consegna un gettone (token): per le ore successive il browser lo presenta a ogni richiesta e il sistema lo riconosce. Il gettone è il cookie di sessione. Chi lo copia può importarlo nel proprio browser e risultare, a tutti gli effetti, quella persona.
Il server non vede un ladro. Vede un utente autenticato, con la stessa impronta del browser, la stessa lingua, gli stessi permessi. Non c'è nessun codice da chiedere, perché la verifica è già avvenuta prima.
Lo stesso meccanismo si sfrutta con l'intercettazione (phishing man in the middle): un proxy si mette tra l'utente e il sito vero, l'utente inserisce password e codice su una pagina che è davvero quella originale, e il proxy si tiene il cookie che arriva dopo. I codici via SMS, le app di autenticazione e le notifiche push si lasciano intercettare e reinviare, perché sono segreti che il proxy può inoltrare. Le chiavi hardware e le passkey no: sono legate al dominio, e su un dominio diverso non producono una risposta valida.
Qui sta la differenza che conta. Non è "MFA sì o no", è "quale MFA". Un codice a sei cifre protegge dalla password rubata, non dalla sessione rubata.
Il 2026 ha aggiunto un pezzo
Ad aprile Google ha reso disponibile su Chrome per Windows una funzione che lega il cookie di sessione all'hardware del dispositivo: la chiave privata vive nel chip di sicurezza e non esce da lì, quindi un cookie copiato non funziona su un'altra macchina.
È un passo avanti reale, ma va letto per quello che è. Vale per Chrome su Windows, non per gli altri browser e non per i telefoni. Funziona solo se il sito che riceve l'accesso implementa la parte lato server: Google e pochi altri l'hanno fatto, la gran parte dei gestionali e dei portali interni no. Non protegge le password, non protegge le chiavi VPN, e soprattutto non ripulisce quello che è già stato rubato e messo in vendita.
Le passkey, di cui abbiamo scritto in Passkey: la fine delle password, risolvono il problema del phishing sulle credenziali. Non risolvono il problema della sessione già aperta su un altro dispositivo. Sono due porte diverse, e chi ne chiude una sola resta esposto sull'altra.
Perché riguarda le PMI più di quanto sembri
La voce che contiene la tua email aziendale spesso non arriva da un server: arriva dal portatile personale di un collaboratore, o dal PC del consulente che lavora per te, o dalla macchina di casa su cui è stata salvata la password dell'ufficio perché "così faccio prima".
Le aziende piccole non hanno modo di vedere queste infezioni. Non hanno un agente su ogni dispositivo, non controllano i dispositivi personali, non monitorano se il proprio dominio compare in un archivio di credenziali rubate. Scoprono il problema quando l'accesso anomalo è già avvenuto, e a quel punto la domanda "come è entrato" ha una risposta scomoda: dalla porta principale, con le chiavi di casa.
Sei passi che cambiano il rischio
- Revoca le sessioni, non solo la password. Quando sospetti un accesso, cambiare la password non basta: il cookie rubato continua a funzionare. Serve invalidare tutte le sessioni attive, su tutti i servizi, e forzare un nuovo accesso.
- Metti MFA resistente al phishing sui privilegiati. Chiavi hardware o passkey per amministratori, accesso remoto e caselle della direzione. Per gli altri utenti l'app di autenticazione è meglio degli SMS, ma non è equivalente.
- Gestisci le password con uno strumento aziendale. Il salvataggio automatico del browser è comodo e finisce dritto nei log degli infostealer. Un gestore aziendale con cassaforte condivisa, ruoli e revoca è la differenza tra un furto e un fastidio.
- Accorcia la vita delle sessioni. Sessioni che scadono in otto ore invece di trenta giorni, riautenticazione per le operazioni delicate, blocco delle sessioni "ricordami" sui sistemi che muovono denaro.
- Guarda se il tuo dominio è nei log. Esistono servizi che dicono quante credenziali aziendali sono in circolazione. È un controllo che si fa una volta e poi si ripete: non è una vergogna, è igiene.
- Trova il dispositivo infetto. Un log di infostealer è la prova che una macchina è compromessa. Se non la trovi, cambiare le password è inutile: la prossima volta il malware registrerà quelle nuove.
Sul lato umano, la solita regola serve più che mai: nessuno salva credenziali aziendali su un dispositivo personale. Ne parliamo in cybersecurity awareness. E se l'accesso anomalo è già avvenuto, la sequenza da seguire è quella delle prime 24 ore: isolare, conservare le prove, capire il percorso.
La domanda da fare al fornitore
C'è una verifica che vale più di un questionario: chiedi al tuo fornitore di identità, o a chi gestisce i tuoi accessi, tre cose. Le sessioni si possono revocare in blocco, e in quanto tempo? Le politiche di accesso distinguono un dispositivo gestito da uno personale? Esistono log delle sessioni, conservati abbastanza a lungo da poter ricostruire un accesso di due mesi fa?
Se la risposta è "non lo sappiamo", il problema non è tecnico: è che nessuno ha mai chiesto. E in un'azienda dove la sessione vale più della password, quella domanda andrebbe fatta prima del prossimo accesso strano, non dopo.