Venom Mode: Automated Credential Harvesting with Responder and mitm6
TL;DR
Venom mode on the Phantom runs Responder, mitm6, NTLM relay, ARP poisoning, and rogue DHCP in parallel to harvest credentials from Windows networks unattended. Captured NTLMv2 hashes are cracked locally or relayed to servers with SMB signing disabled, and all results exfiltrate automatically over 4G to the operator dashboard.
Venom mode turns the Phantom into an unattended credential harvesting platform. It runs a coordinated set of Layer 2 and Layer 3 attacks that exploit the inherent trust assumptions in Windows networking -- specifically the way Windows clients resolve names, negotiate authentication, and configure proxies. The attacks run continuously, captured credentials exfiltrate over 4G in real time, and the entire process requires zero operator interaction after initial deployment.
How Does Responder Poison Name Resolution?
The foundation of Venom mode is Responder, Laurent Gaffie's tool for poisoning Link-Local Multicast Name Resolution (LLMNR), NetBIOS Name Service (NBT-NS), and multicast DNS (mDNS). These are fallback name resolution protocols that Windows clients use when DNS fails to resolve a hostname.
The attack is straightforward. When a user types a UNC path like \\fileserverr\share (note the typo), the client queries DNS first. DNS returns NXDOMAIN because "fileserverr" does not exist. The client then falls back to LLMNR, broadcasting a multicast query to the local subnet: "Who is fileserverr?" Responder answers: "I am." The client initiates an SMB connection to the Phantom, and as part of the SMB negotiation, it sends an NTLMv2 authentication hash. Responder captures the hash and logs it.
This happens constantly on enterprise networks. Typos in UNC paths, stale mapped drives pointing to decommissioned servers, scripts referencing hosts that no longer exist, WPAD lookups for "wpad.domain.local" -- all of these generate LLMNR/NBT-NS queries that Responder can poison. On a busy network with a few hundred Windows clients, Venom mode typically captures dozens of unique NTLMv2 hashes within the first hour.
How Does NTLMv2 Hash Capture and Offline Cracking Work?
The NTLMv2 hash captured by Responder is not the user's password, but it is derived from the password. It is a challenge-response hash: the server (Responder, in this case) sends a challenge, and the client responds with an HMAC-MD5 computed over the challenge, a client-generated nonce, a timestamp, and the NT hash of the user's password. Cracking this hash means testing candidate passwords until one produces the correct response.
The Phantom runs hashcat against captured hashes using a preloaded wordlist and rule set. The N150 processor is not a GPU, so cracking is slow by hashcat standards -- hundreds of thousands of candidates per second rather than billions. But many enterprise passwords fall to dictionary attacks with common rule mutations (append digits, substitute characters, capitalize first letter). The Phantom cracks what it can locally and flags the rest for offline cracking on your own hardware. Cracked credentials are pushed to the dashboard immediately over 4G.
For accounts that resist cracking, the raw NTLMv2 hashes are still valuable. They can be relayed (see below), and they reveal which accounts are active, which naming conventions the organization uses, and which users are on the network at which times.
NTLM Relay Attacks
Instead of cracking a captured NTLMv2 hash, you can relay it -- forward the authentication to a different server and use it to access that server as the victim user. This works when SMB signing is not required (the default for most Windows domain members, excluding domain controllers) and when the target server accepts NTLM authentication.
The relay flow: Responder captures the NTLMv2 challenge-response from the victim. Instead of just logging it, Venom mode simultaneously opens an SMB connection to the relay target (another server on the network) and forwards the victim's authentication. If the victim has administrative access on the relay target, you get a fully authenticated SMB session that can read shares, execute commands via SMBExec, or dump SAM hashes.
Venom mode automates relay target selection. During initial Scope recon, the Phantom identifies servers with SMB signing disabled by analyzing SMB negotiation responses in captured traffic. These servers become automatic relay targets. When a hash comes in from Responder, Venom mode attempts to relay it to every viable target in parallel. Successful relays -- where the victim had local admin on the target -- are flagged in the dashboard with the extracted data.
What Happens When LLMNR Is Disabled? mitm6 Takes Over
Security-conscious organizations disable LLMNR and NBT-NS via Group Policy, which kills the primary Responder attack vector. mitm6, developed by Dirk-jan Mollema, provides an alternative that works even when LLMNR is fully disabled.
mitm6 exploits Windows' default behavior of requesting IPv6 configuration via DHCPv6, even on networks that are purely IPv4. The Phantom responds to DHCPv6 solicitations, assigning itself as the victim's IPv6 DNS server. From this position, it can respond to any DNS query the victim makes with an attacker-controlled address.
The primary target is WPAD (Web Proxy Auto-Discovery). Windows clients query for "wpad.domain.local" to find a proxy configuration file. With DNS control, the Phantom responds with its own IP address, serves a malicious WPAD configuration file that directs HTTP traffic through the Phantom, and captures NTLM authentication when the client connects. This produces the same NTLMv2 hashes as Responder, through a completely different mechanism that does not depend on LLMNR or NBT-NS.
mitm6 is particularly effective because disabling it requires disabling IPv6 entirely or deploying RA Guard and DHCPv6 Guard on every switch port -- configurations that many organizations have not implemented. Venom mode runs mitm6 alongside Responder automatically, so both attack vectors operate in parallel regardless of which name resolution protocols the target has disabled.
ARP Cache Poisoning for Targeted MitM
When you need to intercept traffic between two specific hosts -- rather than waiting for name resolution failures -- ARP cache poisoning puts you directly in the path. The Phantom sends gratuitous ARP replies to both the target host and the gateway, associating its own MAC address with the other's IP address. Both hosts update their ARP caches and begin sending traffic destined for each other through the Phantom.
Venom mode uses ARP poisoning selectively, not broadly. Poisoning every host on the subnet is noisy and likely to trigger alerts or cause network disruptions. Instead, it targets specific host-gateway pairs identified during Scope recon -- typically high-value targets like domain controllers, file servers, or management interfaces. The Phantom forwards all intercepted traffic (maintaining connectivity for the victim), while extracting credentials, session tokens, and other sensitive data from cleartext protocols and performing SSL stripping where applicable.
Rogue DHCP Server
A rogue DHCP server is the blunt instrument in the Venom arsenal. The Phantom responds to DHCP Discover broadcasts with DHCP Offers that configure the Phantom as the default gateway, DNS server, or WPAD server. If the Phantom's DHCP Offer arrives before the legitimate DHCP server's response, the client accepts the rogue configuration.
This is most effective during DHCP scope exhaustion (when the legitimate server has no available leases) or during a race condition at scale (when many devices request addresses simultaneously, such as after a power event or network outage). Venom mode does not attempt rogue DHCP by default because it is the most detectable technique in the stack. It is an option you enable from the dashboard for specific situations where the risk-reward calculation justifies it.
Unattended Operation and Auto-Exfiltration
The entire Venom stack runs without operator intervention. After deployment, the Phantom continuously cycles through all enabled attack vectors, captures credentials, attempts relay attacks, and pushes results to the dashboard over 4G. The operator sees a live credential feed: usernames, NTLMv2 hashes, cracked passwords, successful relay targets, and captured cleartext credentials, all timestamped and tagged with the attack vector that produced them.
Attack scheduling is configurable. By default, Venom mode activates the noisier techniques (ARP poisoning, rogue DHCP) only during business hours to blend with normal traffic patterns. Responder and mitm6 run 24/7 because they are passive listeners that only respond when queried -- they do not generate traffic that stands out on a quiet network at 3 AM. This scheduling is configurable per technique in the dashboard, and automated playbooks can chain Venom with other modes based on time of day or trigger conditions.
How Is Venom Mode Detected and Countered?
Being transparent about detection is important for pentesters who need to calibrate their approach to the target's monitoring capability. Responder poisoning is detectable by monitoring for LLMNR/NBT-NS responses from unexpected sources. mitm6 is detectable by monitoring for rogue DHCPv6 servers or unexpected IPv6 DNS assignments. ARP poisoning is detectable by Dynamic ARP Inspection (DAI) on managed switches. Rogue DHCP is detectable by DHCP snooping.
In practice, most organizations have at most one or two of these countermeasures deployed, and few have all of them. Venom mode's value is that it runs every technique in parallel and lets the ones that work produce results while the ones that are blocked fail silently. The dashboard reports which techniques are generating results and which are being blocked, giving you real-time visibility into the target's defensive posture.