Modlishka e phishing con bypass MFA: cosa dovrebbero simulare in sicurezza i team di sensibilizzazione
Come formare in sicurezza la consapevolezza sul bypass dell’MFA senza trasformare le simulazioni per i dipendenti in acquisizione di credenziali o sessioni.

Modlishka è un nome importante nelle discussioni sul phishing per il bypass dell’MFA, ma non è una base normale per la formazione di awareness dei dipendenti. È uno strumento di phishing reverse-proxy, molto noto negli ambienti di sicurezza perché ha contribuito a dimostrare quanto i flussi di phishing possano risultare convincenti quando interagiscono con l’autenticazione moderna e con i prompt di multi-factor.
Quella lezione conta. La categoria degli strumenti operativi no.
I team di sicurezza dovrebbero assolutamente formare i dipendenti sul rischio di bypass dell’MFA, sui prompt di accesso sospetti, sulla push fatigue, sui flussi di login con QR code, sui prompt di consenso OAuth e sulle impersonificazioni dell’helpdesk. Ma dovrebbero farlo tramite simulazioni controllate che evitino la raccolta di credenziali, evitino materiali di sessione, rispettino la privacy e producano dati comportamentali utili.
Il punto utile di Modlishka non è "eseguire phishing reverse-proxy contro i dipendenti". Il punto utile è "l’MFA cambia il rischio di phishing, ma non elimina la necessità di consapevolezza, segnalazione e abitudini di verifica".
Perché Modlishka ha ancora risonanza
Modlishka ha una forte memorabilità perché si colloca all’incrocio tra autenticazione, phishing e MFA. L’attività pubblica su GitHub mostra che il progetto resta visibile, con migliaia di stelle e aggiornamenti recenti del repository. Non è un vecchio toolkit abbandonato nella stessa categoria di alcuni framework di phishing legacy.
Questo cambia l’angolo del contenuto.
Per GoPhish, Phishing Frenzy, King Phisher o Simple Phishing Toolkit, la domanda dell’acquirente è spesso "è ancora mantenuto abbastanza da poterlo usare?". Per Modlishka, la domanda migliore è:
Come dovrebbe un programma di awareness coprire il phishing per il bypass dell’MFA senza trasformare la formazione in intercettazione di credenziali?
È una vera domanda di sicurezza. Merita una risposta più sicura.
L’MFA ha ridotto il rischio, ma non ha eliminato il phishing
L’autenticazione a più fattori rende molti attacchi più difficili. Riduce il valore della compromissione basata solo sulla password e offre alle organizzazioni una base più solida. Ma i dipendenti possono comunque trovarsi di fronte a situazioni rischiose:
- falsi prompt di accesso dopo un’email convincente
- affaticamento da approvazioni push
- chiamate all’helpdesk che pressano per un reset o una registrazione dell’MFA
- esche per login tramite QR code
- schermate di consenso OAuth che richiedono accessi eccessivi
- prompt sospetti di registrazione dispositivo
- flussi con fornitori o documenti che portano a un’autenticazione inattesa
La formazione di awareness dovrebbe aiutare i dipendenti a riconoscere questi momenti e a segnalarli rapidamente. Non dovrebbe insegnare loro che ogni prompt MFA sia sicuro, o che una pagina di login dall’aspetto familiare sia affidabile per definizione.
Le linee guida pubbliche sulla sicurezza awareness di agenzie governative e centri nazionali per la cybersicurezza arrivano di solito alla stessa base pratica: il comportamento difensivo è la verifica e la segnalazione, non dimostrare quanto un attacco possa essere realistico.
Gli strumenti reverse-proxy non sono software di awareness
Gli strumenti di phishing reverse-proxy appartengono a test di sicurezza specialistici con autorizzazione esplicita, scope rigoroso, revisione legale e operatori esperti. La formazione di awareness per i dipendenti ha uno scopo diverso.
Un normale programma di awareness dovrebbe ottimizzare per:
- comportamenti più sicuri sotto pressione realistica
- fiducia dei dipendenti
- misurazioni attente alla privacy
- cadenza ripetibile
- reporting sicuro per i manager
- coaching utile
- evidenze comprensibili per la leadership
Non dovrebbe normalizzare la cattura di password, codici MFA, token o sessioni come parte della formazione ordinaria.
Anche quando una simulazione insegna il rischio del bypass dell’MFA, può fermarsi prima della raccolta di segreti. Può mostrare un prompt inatteso, misurare se il dipendente lo segnala e poi fornire un feedback immediato. Questo basta per insegnare il comportamento senza creare un rischio di dati inutile.
Cosa simulare invece
Gli scenari di awareness sull’MFA più sicuri si concentrano sui punti decisionali, non sulla cattura dei segreti.
Esempi utili includono:
- un prompt di accesso inatteso dopo un’email per la condivisione di file
- una notifica push che arriva senza un login avviato dall’utente
- un messaggio in stile helpdesk che chiede al dipendente di "confermare" la registrazione MFA
- un flusso di accesso con QR code mostrato come screenshot o come pagina di destinazione sicura
- un prompt di consenso OAuth che richiede un ampio accesso alla casella di posta o ai documenti
- un invito a un portale fornitore che usa un dominio simile a quello reale
L’obiettivo è allenare domande che i dipendenti possano davvero usare:
- Sono stato io ad avviare questo login?
- È il dominio o l’applicazione abituale?
- Questa richiesta si adatta al contesto aziendale?
- Dovrei segnalarla prima di interagire ancora?
- Esiste un percorso di verifica approvato?
È così che la consapevolezza sul bypass dell’MFA diventa pratica e non teatrale.
Non raccogliere segreti reali
Il confine di sicurezza più chiaro è semplice: non raccogliere password reali, codici MFA, risposte di recupero, cookie di sessione o token nelle campagne di awareness per i dipendenti.
Misura il comportamento senza raccogliere segreti:
- recapitato
- aperto
- cliccato
- prompt sospetto raggiunto
- segnalazione inviata
- feedback visualizzato
- microtraining completato
- riduzione delle interazioni rischiose ripetute
Se serve una landing page, usa una pagina sicura che spieghi il rischio e si fermi prima dell’azione sensibile. Il dipendente dovrebbe uscire dall’esercizio capendo cosa fare la volta successiva, non chiedendosi se la sicurezza lo abbia indotto a esporre qualcosa di reale.
Per un angolo di sicurezza MFA strettamente correlato, la guida di AutoPhish sulle alternative a CredSniper per un awareness phishing MFA sicuro è un modello migliore che cercare di imitare il flusso di lavoro di uno strumento offensivo.
Costruisci il programma attorno alla segnalazione
Le simulazioni di bypass dell’MFA dovrebbero premiare la segnalazione. È questo il comportamento che aiuta il team di sicurezza a rispondere agli attacchi reali.
Un programma utile dovrebbe rispondere a:
- Quanto rapidamente i dipendenti hanno segnalato i prompt di accesso sospetti?
- Quali reparti hanno segnalato prima di cliccare?
- Quali scenari hanno creato confusione?
- I dipendenti hanno usato il canale di segnalazione approvato?
- L’esposizione ripetuta ha migliorato il comportamento?
- Quali prompt necessitano di una guida interna più chiara?
È qui che l’awareness sul phishing diventa davvero utile sul piano operativo. Fornisce ai team di sicurezza evidenze che possono migliorare i controlli, non solo un grafico dei clic.
Per la progettazione della segnalazione, la guida di AutoPhish su phishing simulation reporting si abbina bene alle campagne focalizzate sull’MFA.
Dove si inserisce il red-team testing
C’è ancora spazio per test specialistici. Un’organizzazione matura può eseguire esercizi autorizzati di red-team o purple-team che includono scenari di autenticazione in stile avversario. Questi esercizi dovrebbero essere definiti separatamente dalla formazione di awareness per i dipendenti:
- meno partecipanti
- approvazione esplicita
- revisione legale e privacy definita
- gestione rigorosa dei dati
- operatori esperti
- integrazione chiara con l’incident response
- pulizia post-esercizio
È un workflow diverso dalla normale formazione di awareness per una popolazione ampia di dipendenti.
Non confondere i due piani. I programmi di awareness hanno bisogno di fiducia. Gli esercizi red-team hanno bisogno di realismo avversario controllato. Mescolarli con leggerezza indebolisce entrambi.
Cosa dovrebbe offrire una piattaforma più sicura
Se il tuo team sta cercando Modlishka perché il phishing per il bypass dell’MFA è nel registro dei rischi, confronta le piattaforme in base alla loro capacità di simulare il tema in modo sicuro.
Cerca:
- supporto per scenari MFA e prompt di accesso senza raccolta di segreti
- landing page e screenshot sicuri
- targeting basato sui ruoli per IT, finance, HR, executive e assistenti
- misurazione del flusso di segnalazione
- controlli sulla privacy e limiti di conservazione
- reporting aggregato sicuro per i manager
- evidenze di audit chiare
- controlli di approvazione delle campagne
- feedback automatico e microtraining
L’alternativa giusta non è "un reverse proxy meno offensivo". È una piattaforma di awareness che possa insegnare gli stessi punti decisionali difensivi senza creare rischi operativi inutili.
FAQ
Modlishka è stato abbandonato?
No. I segnali pubblici del repository mostrano che Modlishka resta visibile e ha attività recente. Il motivo per non usarlo per la normale awareness dei dipendenti non è l’abbandono. È l’adattamento allo scopo: uno strumento di phishing reverse-proxy non è la stessa cosa di una piattaforma di awareness governata.
I dipendenti dovrebbero essere formati sul phishing per il bypass dell’MFA?
Sì. I dipendenti dovrebbero capire i prompt di accesso sospetti, la push fatigue, il rischio del consenso OAuth, le esche di login via QR e la pressione dell’helpdesk. La formazione dovrebbe evitare la raccolta di credenziali o token reali.
Le simulazioni di phishing possono coprire l’MFA senza raccogliere segreti?
Sì. Una simulazione può mostrare un prompt sospetto, misurare se il dipendente segnala o prosegue e fornire feedback prima che venga inserito un segreto reale. Di solito è questo il modello di awareness più sicuro.
Qual è un’alternativa più sicura a Modlishka per la formazione di awareness?
Usa una piattaforma di simulazione phishing che supporti scenari a tema MFA, landing page sicure, reporting attento alla privacy e formazione di follow-up. Non trattare uno strumento offensivo reverse-proxy come software di awareness ordinario.
Forma il rischio, non la catena d’attacco
Modlishka è un promemoria utile del fatto che le difese di autenticazione fanno parte di un flusso di lavoro umano. L’MFA aiuta, ma i dipendenti devono comunque riconoscere i prompt sospetti e segnalarli.
L’obiettivo dell’awareness non è ricreare una catena d’attacco. È costruire abitudini più sicure attorno ai prompt di login, alle approvazioni, alle schermate di consenso e alla verifica.