Phishing-as-a-Service con AI e OTP in tempo reale: cosa cambia per la difesa aziendale

L’analisi di Google Threat Intelligence sul PhaaS in lingua cinese mostra phishing più automatizzato, localizzato e capace di aggirare OTP. Le organizzazioni devono spostare la difesa da awareness a controlli tecnici phishing-resistant.

Dal phishing statico al crimine come piattaforma

Google Threat Intelligence Group ha pubblicato un’analisi sull’evoluzione dei servizi di phishing-as-a-service, o PhaaS, in lingua cinese. Secondo GTIG, questo ecosistema non si limita a copiare modelli già osservati in altri contesti criminali: offre piattaforme mature, pannelli di amministrazione, servizi accessori, registrazione domini, hosting, invio messaggi, vendita di dati personali e supporto alla monetizzazione.

Il punto operativo per le organizzazioni è chiaro: il phishing non va più trattato come una sequenza di email mal scritte intercettabili con filtri e formazione periodica. Le campagne descritte da GTIG sono progettate per essere industrializzate, localizzate e adattabili. In alcuni casi usano canali come RCS e iMessage, dove la cifratura end-to-end può limitare la capacità dei controlli server-side di ispezionare i link malevoli. In parallelo, l’uso di pannelli live consente all’attaccante di interagire con la vittima mentre questa inserisce credenziali e codici temporanei.

Questo cambia la valutazione del rischio. Un’organizzazione che basa la protezione degli account su password più OTP può essere esposta a scenari nei quali l’OTP viene catturato e usato entro pochi secondi. La formazione resta utile, ma non basta più come controllo principale. Serve progettare architetture in cui la credenziale sottratta sia difficile, o idealmente inutile, da riutilizzare.

Perché OTP, SMS e approvazioni deboli diventano un punto critico

GTIG osserva uno spostamento dalla semplice raccolta di password all’intercettazione in tempo reale e alla tokenizzazione. In pratica, l’utente inserisce credenziali e codice monouso in una pagina fraudolenta; l’operatore criminale vede i dati nel pannello, avvia una richiesta sul servizio legittimo e sfrutta il codice prima che scada. Questo modello riduce molto il margine di reazione.

Per aziende, banche, e-commerce, pubbliche amministrazioni e piattaforme con aree riservate, la conseguenza è concreta: non è sufficiente chiedersi se la MFA sia attiva, ma quale tipo di MFA sia in uso e contro quali attacchi protegga. OTP via SMS, codici generati da app e push approval non contestuali possono essere vulnerabili a social engineering, relay attack o consenso indotto. Le soluzioni basate su FIDO2/WebAuthn e passkey, se implementate correttamente, sono invece più resistenti al phishing perché legano l’autenticazione al dominio legittimo e al dispositivo.

Questo non elimina tutti i rischi. Come ricorda la fonte, una security key non impedisce a un utente di inserire dati di pagamento in un sito falso. Riduce però la possibilità che credenziali e codici vengano trasformati in accesso valido. Per questo la migrazione verso autenticazione phishing-resistant dovrebbe essere accompagnata da controlli di sessione, conditional access, verifica del dispositivo, alert su login anomali e procedure rapide di revoca token.

AI, localizzazione e brand abuse: il problema non è solo l’accesso interno

Un altro elemento rilevante dell’analisi GTIG riguarda l’automazione basata su AI. Alcune piattaforme PhaaS, secondo la fonte, usano generatori di pagine e strumenti di browser automation per clonare siti legittimi partendo dall’URL target. L’effetto pratico è che ogni pagina può essere abbastanza diversa dalle altre da ridurre l’efficacia di controlli puramente basati su firme statiche.

La localizzazione aumenta ulteriormente il rischio. GTIG cita il caso YY Lai Yu, piattaforma che avrebbe supportato campagne in numerosi Paesi e sviluppato centinaia di template legati a marchi, abitudini di consumo, programmi punti, sussidi e servizi locali. Per un’organizzazione europea questo significa che il brand può essere abusato anche fuori dal proprio perimetro IT: domini simili, pagine clonate, messaggi su canali consumer e campagne mirate ai clienti possono produrre danni reputazionali, frodi e carico sul customer care.

La difesa deve quindi includere attività spesso trascurate: monitoraggio di domini typosquatting, rilevazione di pagine clone, procedure di takedown, comunicazioni coordinate con clienti e partner, integrazione tra security team, marketing, legale e assistenza. Per chi gestisce piattaforme transazionali, marketplace o servizi finanziari, è opportuno rivedere anche i flussi di enrollment di nuovi dispositivi, cambio password, recupero account e provisioning di wallet digitali.

In questo ambito, un percorso di Cyber & Cloud può aiutare a collegare hardening tecnico, gestione identità, monitoraggio e risposta agli incidenti. La componente di consulenza governance è altrettanto importante quando servono policy, ruoli, responsabilità e processi decisionali chiari.

Checklist operativa per ridurre il rischio

La prima azione è mappare i metodi di autenticazione realmente usati: dipendenti, amministratori, fornitori, clienti e account di servizio. Gli account privilegiati dovrebbero essere i primi candidati per FIDO2/WebAuthn o passkey gestite, con eliminazione progressiva di OTP via SMS dove possibile.

Secondo: introdurre controlli di accesso basati sul rischio. Posizione, reputazione del dispositivo, impossibile viaggio, cambio improvviso di browser, uso di proxy sospetti e richieste di provisioning wallet dovrebbero modificare il livello di verifica richiesto. Non tutti gli eventi devono bloccare l’utente, ma quelli ad alto rischio devono generare step-up authentication, quarantena o revisione.

Terzo: aggiornare logging e incident response. Se un OTP viene intercettato, il tempo utile è minimo. I playbook devono prevedere revoca sessioni, reset credenziali, invalidazione token, blocco dispositivo, controllo delle regole di inoltro email, verifica di accessi successivi e comunicazione agli utenti coinvolti. In ambienti cloud, il lavoro va integrato con IAM, SIEM, alerting e automazioni: aree in cui un servizio di Cloud Managed DevOps può rendere i controlli più continui e meno manuali.

Quarto: misurare la resilienza, non solo la compliance. Un test utile non è “abbiamo fatto formazione?”, ma “un codice rubato può ancora aprire una sessione?”, “un dominio clone viene rilevato in ore o in settimane?”, “il customer care sa riconoscere una campagna in corso?”, “chi decide il takedown?”.

La direzione indicata dall’analisi GTIG è netta: la difesa moderna dal phishing deve puntare a rendere l’attacco meno monetizzabile. Non basta riconoscere il messaggio falso; bisogna impedire che credenziali, OTP e dati inseriti possano trasformarsi rapidamente in accesso, frode o tokenizzazione non autorizzata.

Approfondimenti Dedaloop

Fonti