Una semplice configurazione errata di un server può trasformarsi in una miniera di informazioni per chi analizza le minacce. In un caso recente, un operatore di phishing contro Microsoft 365 ha lasciato esposto un web server Python su una porta pubblica con directory listing attivo, rendendo consultabili file e cartelle del sistema.
Da questa svista sono emerse tre operazioni distinte basate su Evilginx, un framework open source usato come proxy adversary-in-the-middle per intercettare le sessioni di accesso e rubare cookie e token anche in presenza di autenticazione multi fattore.
La directory aperta ha rivelato configurazioni di phishing, log di raccolta credenziali, archivi di backup, elenchi di password, installer di strumenti RMM per la persistenza e perfino file di sessione utili agli attaccanti per gestire le campagne. Sullo stesso host risultavano attivi sia il proxy Evilginx sia una console di assistenza remota, segnale di un ecosistema già pronto a trasformare un accesso rubato in controllo duraturo degli endpoint.
Tre campagne e due tecniche per aggirare la MFA
Le tre campagne hanno aggirato la MFA in due modi diversi.
- Reverse proxy (Evilginx): la vittima effettua il login su una pagina clonata ma collegata in tempo reale al vero portale Microsoft. In questo scenario passkey e FIDO2 sono efficaci perché legano la procedura di accesso al dominio reale e riducono l’efficacia del proxy.
- Device code flow (OAuth): metodo più insidioso che sfrutta un flusso legittimo pensato per dispositivi con input limitato. L’attaccante genera un codice reale, lo presenta in una pagina esca in stile Authenticator e induce la vittima a inserirlo su microsoft.com/devicelogin. La MFA non viene bypassata: viene completata correttamente dalla vittima su infrastruttura Microsoft, ma autorizza la sessione dell’attaccante che nel frattempo recupera i token.
Difesa su Microsoft 365: contromisure e rilevazione
Dal punto di vista della difesa su Microsoft 365 è fondamentale distinguere le contromisure.
- Device code phishing: la leva principale è Conditional Access, con la raccomandazione di bloccare il device code flow dove non necessario, testando prima in modalità report-only.
- Riduzione dell’impatto dei token rubati: ulteriori strati includono policy basate su posizione IP e Continuous Access Evaluation per ridurre la durata utile dei token.
- Detection: conviene monitorare nei log di Entra i grant di refresh token e correlare eventi anomali con IP insoliti, oltre a cercare sugli endpoint la presenza di tool RMM usati per mantenere l’accesso.