{"id":14354,"date":"2025-12-18T12:58:40","date_gmt":"2025-12-18T11:58:40","guid":{"rendered":"https:\/\/www.axitea.com\/?post_type=approfondimenti&p=14354"},"modified":"2025-12-18T13:01:44","modified_gmt":"2025-12-18T12:01:44","slug":"adversary-in-the-middle-aitm-una-minaccia-evoluta-che-bypassa-anche-l-autenticazione-multi-fattore-mfa-il-caso-studio","status":"publish","type":"approfondimenti","link":"https:\/\/www.axitea.com\/it\/blog\/adversary-in-the-middle-aitm-una-minaccia-evoluta-che-bypassa-anche-l-autenticazione-multi-fattore-mfa-il-caso-studio\/","title":{"rendered":"Adversary in the Middle (AitM), una minaccia evoluta che bypassa anche l\u2019autenticazione multi fattore (MFA): il caso studio"},"content":{"rendered":"

Negli ultimi anni il phishing \u00e8 diventato sempre pi\u00f9 sofisticato, ma oggi assistiamo a un\u2019evoluzione ancora pi\u00f9 insidiosa: gli attacchi Adversary in the Middle<\/strong> (AitM). Non si tratta di semplici email fraudolente, ma di una tecnica in cui un attore malevolo si frappone tra due soggetti intercettando credenziali e sessioni di autenticazione, aggirando persino i meccanismi di Multi-Factor Authentication (MFA)<\/strong>.<\/p>\n

Per le aziende, questo significa che non basta pi\u00f9 \u201cattivare l\u2019MFA\u201d per sentirsi al sicuro<\/strong>. Gli attaccanti hanno imparato a sfruttare le debolezze dei processi e delle architetture, soprattutto quando la sicurezza \u00e8 frammentata in silos tecnologici che non comunicano tra loro<\/strong>.<\/p>\n

Cos\u2019\u00e8 un attacco AitM e perch\u00e9 \u00e8 diverso dal phishing tradizionale<\/h2>\n

Un attacco AitM si basa su un concetto semplice ma devastante: creare un proxy malevolo<\/strong> (un \u201cintermediario\u201d) tra l\u2019utente e il servizio legittimo. Quando la vittima clicca su un link di phishing, non viene indirizzata direttamente al sito falso, ma al proxy che inoltra le richieste al sito reale.<\/p>\n

In questo modo, l\u2019utente vede la pagina autentica, inserisce le credenziali e completa l\u2019autenticazione MFA\u2026 ma il proxy cattura tutto, inclusi i token di sessione<\/strong>.<\/p>\n

Con questi token, l\u2019attaccante pu\u00f2 accedere all\u2019account senza bisogno di password o autenticazione multi fattore (MFA), sfruttando la sessione gi\u00e0 validata. \u00c8 un salto di qualit\u00e0 rispetto al phishing classico<\/strong>, perch\u00e9 non si limita a rubare credenziali: prende il controllo della sessione attiva.<\/p>\n

Come avviene un attacco AitM<\/h2>\n

Per capire meglio, ecco le fasi tipiche di un AitM:
\n1. Email di phishing<\/strong> sofisticato con link malevolo.
\n2. Proxy malevolo<\/strong> che si interpone tra utente e servizio legittimo.
\n3. L\u2019utente inserisce credenziali e MFA sul sito reale (tramite proxy).
\n4. Il proxy cattura token di sessione<\/strong> e li consegna all\u2019attaccante.
\n5. L\u2019attaccante accede all\u2019account<\/strong> come se fosse l\u2019utente, senza ulteriori autenticazioni.<\/p>\n

Questo meccanismo rende inefficace la protezione MFA se non \u00e8 accompagnata da controlli aggiuntivi<\/strong> come il monitoraggio delle sessioni e l\u2019analisi comportamentale.<\/p>\n

AitM: il caso reale gestito dal SOC Axitea<\/h2>\n

Qualche mese fa, il Security Operation Center (SOC) Axitea<\/strong> ha intercettato un attacco AitM ai danni di un\u2019azienda italiana del settore manifatturiero.<\/p>\n

Tutto \u00e8 iniziato con un alert anomalo: un accesso da un Paese insolito, subito dopo un login legittimo da parte di un dipendente.<\/p>\n

Il cliente aveva investito nelle migliori tecnologie di mercato. Tuttavia, analizzati singolarmente, gli strumenti avevano generato dei\u202f”Falsi Negativi<\/em>“.<\/p>\n

Dove la tecnologia vede eventi isolati, il Soc di Axitea \u201cha visto una storia\u201d. Non si \u00e8 limitato a raccogliere log, ma ha fatto correlazioni per identificare pattern di attacco complessi.<\/p>\n

Ecco come il Security Operation Center ha unito i puntini che i singoli vendor avevano mancato:<\/h4>\n

1. L\u2019indizio<\/strong>:\u202fil SOC Axitea nota che l’email proveniva da un mittente esterno con cui il CEO non aveva mai interagito prima (segnale debole).
\n2. Il contesto<\/strong>:\u202fpochi secondi dopo la ricezione, il firewall registra una connessione in uscita verso un dominio a bassa reputazione (appena registrato), anche se non bloccato (segnale medio).
\n3. L’anomalia<\/strong>:\u202favviene un login di successo, ma da un indirizzo IP geolocalizzato in un paese diverso rispetto all’ultimo check-in del dispositivo mobile del CEO.
\n4. La “prova schiacciante” (analisi comportamentale Axitea)<\/strong>:\u202fmeno di un minuto dopo il login viene rilevata l’aggiunta di un\u202fnuovo metodo di autenticazione sull’account del CEO.<\/p>\n

La Deduzione dell’Cyber Analyst di Axitea:<\/strong><\/p>\n

“Login IP anomalo + Traffico web sospetto + Modifica immediata delle impostazioni di sicurezza =\u202fAccount Takeover in corso.<\/em>”<\/p>\n

Il SOC: risposta immediata e remediation<\/h2>\n

Mentre i sistemi automatici consideravano l’operativit\u00e0 “normale”, il Security Operation Center Axitea ha attivato il protocollo di emergenza C-Level:<\/p>\n