Attacker-in-the-Browser - Form Grabbing e Zeus Case Study#
L'Attacker-in-the-Browser (AiTB) e' una variante dell'attacco on-path che non agisce sulla rete ma direttamente dentro il processo del browser della vittima, tramite malware installato come estensione, plugin o BHO (Browser Helper Object). Il malware intercetta le transazioni dopo che TLS le ha gia' decifrate: da quel punto di vista, TLS non offre alcuna protezione.
Come bypassa TLS#
TLS cifra il canale di rete tra browser e server. Il browser deve pero' decifrare il traffico ricevuto per mostrarlo all'utente -- e a quel punto il malware AiTB si inserisce. Il malware opera dopo la decifrazione, dentro il processo del browser, con accesso diretto al DOM e ai form HTML. Dal punto di vista della rete, tutto sembra normale: la connessione HTTPS e' integra, nessun certificato sospetto, nessuna anomalia di latenza.
Questa e' la differenza fondamentale rispetto a un attacco on-path classico: un MITM esterno deve interporsi sul canale di rete, gestire i certificati TLS e rischia di generare certificate warnings nel browser della vittima. L'AiTB non ha nessuno di questi problemi perche' agisce gia' dentro il processo dove i dati sono in chiaro.
| On-path classico (AiTM) | Attacker-in-the-Browser | |
|---|---|---|
| Posizione | tra i due sistemi, layer rete | dentro il browser, dopo TLS |
| Vede traffico cifrato? | si', deve gestire certificati | no, vede gia' il plaintext |
| Certificate warnings? | si' | no |
| Introduce delay? | si' | no |
| Rilevabile via rete? | piu' facile (Wireshark) | molto difficile |
| Rilevabile via endpoint? | meno ovvio | EDR puo' rilevare hook sul processo |
Tecniche principali#
Form Grabbing -- il malware aggiunge un hook all'evento submit dei form HTML. Quando l'utente clicca "Conferma bonifico" o "Accedi", il malware cattura tutti i campi del form dal DOM prima che la richiesta HTTPS parta verso il server. Cattura username, password, numero carta, IBAN -- qualsiasi dato l'utente abbia inserito. Funziona anche se il campo e' type="password": il DOM contiene il valore in chiaro nel processo browser.
Transaction Tampering -- tecnica piu' sofisticata usata in attacchi bancari. Il malware intercetta la transazione in uscita, modifica i campi critici (IBAN destinatario, importo) prima che vengano inviati al server, poi ripristina la visualizzazione originale per non insospettire l'utente. L'utente vede la schermata di conferma con i propri dati corretti; il server riceve i dati modificati dall'attaccante.
Keystroke Logging -- il malware registra ogni tasto digitato nel contesto del browser. Piu' grezzo del form grabbing ma piu' universale: cattura qualsiasi campo, in qualsiasi pagina, anche senza attendere il submit.
Zeus Trojan -- il case study classico#
Zeus (ZeuS, Zbot) e' il malware AiTB piu' documentato della storia. Attivo dal 2007, raggiunse il picco tra il 2009 e il 2010 infettando oltre 3,6 milioni di PC Windows. Il vettore principale era il drive-by download da siti compromessi e campagne phishing.
Zeus implementava form grabbing preciso sui siti bancari: aspettava che l'utente visitasse la propria banca online, catturava le credenziali al login, e applicava transaction tampering sui bonifici -- cambiando l'IBAN del destinatario mantenendo importo e causale identici. L'utente vedeva la schermata di conferma normale; il denaro finiva su conti mulo offshore.
Il codice sorgente di Zeus fu rilasciato pubblicamente nel 2011, generando una proliferazione di varianti: Citadel (2012), GameOver Zeus (2011-2014, con infrastruttura P2P), e numerosi fork ancora attivi.
Difese#
Transaction signing out-of-band -- la difesa piu' efficace contro il transaction tampering. Il server invia un SMS con i dettagli reali della transazione (importo + IBAN destinatario come ricevuto lato server) e richiede conferma con OTP. Anche se il malware ha modificato i dati nel browser, l'SMS mostra i dati arrivati al server -- l'utente vede la discrepanza tra cio' che ha inserito e cio' che il server ha ricevuto.
EDR comportamentale -- un Endpoint Detection and Response con analisi comportamentale puo' rilevare processi browser che caricano DLL insolite, hook su API di sistema, o connessioni di rete inattese da processi browser.
Allowlist estensioni -- in ambienti enterprise (Chrome Enterprise, Edge for Business), si possono consentire solo estensioni approvate. Riduce drasticamente la superficie di attacco via plugin.
Content Security Policy -- aiuta parzialmente: blocca script da domini non autorizzati caricati nelle pagine. Non protegge pero' da un'estensione malevola gia' installata, che ha accesso diretto al DOM indipendentemente dalla CSP.
| Tecnica AiTB | Cosa cattura | Quando agisce | Difesa specifica |
|---|---|---|---|
| Form Grabbing | dati form (username, password, carta) | al submit, prima della richiesta HTTPS | Virtual keyboard, EDR |
| Transaction Tampering | modifica IBAN/importo in volo | durante invio transazione | OTP out-of-band su dati server-side |
| Keystroke Logging | qualsiasi tasto digitato nel browser | continuo durante la sessione | EDR, virtual keyboard |
Dev parallel: In un'app bancaria Node/PHP, la difesa contro AiTB e' la transaction signing out-of-band: il server invia un SMS con i dettagli della transazione cosi' come li ha ricevuti (importo + IBAN destinatario) e richiede conferma con OTP. Anche se il malware ha modificato i dati nel browser prima dell'invio, l'SMS mostra i dati reali arrivati al server -- l'utente vede la discrepanza e puo' annullare. L'implementazione richiede che il back-end invii l'SMS con i dati gia' validati, non con quelli del form originale.
Dev parallel: Content Security Policy nel back-end PHP/Node aiuta solo parzialmente: blocca script iniettati da domini esterni non in allowlist, ma un'estensione browser malevola ha accesso diretto al DOM con permessi superiori alla CSP. La CSP e' difesa contro XSS (Stored/Reflected), non contro malware installato sull'endpoint.
