Credential Harvesting via Man-in-the-Middle: A Bettercap Methodology
A practical guide to executing and analyzing ARP spoofing and DNS poisoning attacks using Bettercap in a controlled lab environment.
Credential Harvesting via Man-in-the-Middle: A Bettercap Methodology
Despite the widespread adoption of HTTPS, a significant number of internal legacy systems, development environments, and misconfigured web applications continue to transmit data over unencrypted HTTP. In a corporate or shared network environment, these cleartext protocols represent a critical exposure. An attacker positioned between a target workstation and its gateway can silently intercept usernames, passwords, session tokens, and financial data without triggering a single alert.
This write-up documents a controlled Man-in-the-Middle (MitM) engagement conducted within an isolated lab environment. The objective: demonstrate the complete attack chain from network positioning through credential exfiltration using Bettercap, a modular network security framework purpose-built for offensive network analysis.
The target environment consists of a gateway at 192.168.20.1 and a Windows workstation at 192.168.20.2 communicating over an unencrypted HTTP application. The attack platform is a Kali Linux machine on the same subnet.
Environment Preparation
Bettercap is distributed as a standalone binary. The latest release is obtained directly from the official GitHub repository and installed to the system path for global execution.
unzip bettercap_linux_amd64.zip
sudo mv -v bettercap /usr/bin/
sudo bettercap
Click to zoom
Figure 1.1: The official Bettercap GitHub releases page. The linux_amd64 binary is selected for deployment on the attack platform.
Click to zoom
Figure 1.2: Extracting the archive and moving the Bettercap binary to /usr/bin for system-wide access.
Click to zoom
Figure 1.3: Bettercap's interactive console post-launch. The framework exposes a modular architecture with dedicated modules for spoofing, sniffing, and proxying.
ARP Spoofing: The Foundation
Address Resolution Protocol (ARP) operates at Layer 2 of the OSI model, mapping IP addresses to MAC addresses within a local network segment. The protocol is inherently stateless and trusts all responses without verification, a design flaw that has persisted since its introduction in RFC 826.
ARP spoofing exploits this trust model by broadcasting forged ARP reply packets. The attacker's machine announces itself as the gateway to the target, and simultaneously announces itself as the target to the gateway. Once both ARP caches are poisoned, all traffic between the target and the gateway is silently routed through the attacker's interface, establishing a full-duplex Man-in-the-Middle position.
Network Reconnaissance
Before launching the attack, the local subnet must be mapped. Bettercap's net.probe module sends probe packets across the subnet to enumerate active hosts, while net.show renders the results as a structured table.
net.probe on
net.show
The probe reveals two endpoints of interest: the default gateway at 192.168.20.1 (NetComm Wireless) and the target workstation DESKTOP-9A0CU96 at 192.168.20.2 (Giga-Byte Technology).
Click to zoom
Figure 2.1: The net.probe module sends discovery packets across the subnet, identifying active endpoints and their MAC addresses in real time.
Click to zoom
Figure 2.2: The net.show command renders discovered hosts. The gateway (192.168.20.1) and target workstation (192.168.20.2) are clearly identified with their respective MAC addresses and hardware vendors.
The ARP Spoof Module
Bettercap's arp.spoof module provides granular control over the spoofing operation. Key parameters include arp.spoof.targets for specifying victim IPs, arp.spoof.fullduplex for poisoning both the target and gateway simultaneously, and arp.spoof.internal for intercepting lateral traffic between local hosts.
Click to zoom
Figure 2.3: The arp.spoof module's command reference. Parameters such as fullduplex, internal, and targets provide precise control over the spoofing scope and behavior.
Execution and Harvesting
With the theoretical foundation established, execution follows a precise sequence. The ARP spoof is activated first to establish the MitM position, followed by the packet sniffer to capture all transiting traffic.
set arp.spoof.targets 192.168.20.2
arp.spoof on
set net.sniff.output /home/isko/Desktop/bettercap.pcap
net.sniff on
The net.sniff module operates as a passive packet capture engine. All intercepted traffic is written to a PCAP file for post-engagement analysis in Wireshark, while Bettercap simultaneously parses HTTP traffic in real time, extracting credentials and sensitive data from unencrypted requests as they transit the interface.
Click to zoom
Figure 3.1: The attack chain in execution. ARP spoofing targets 192.168.20.2 while net.sniff captures all intercepted traffic to a PCAP file for documentation.
Results and Evidence
During the engagement, the target user navigated to http://testphp.vulnweb.com/signup.php and submitted a registration form containing personal and financial data over an unencrypted HTTP connection.
Click to zoom
Figure 3.2: The target user submits a registration form on the vulnerable HTTP application. Every field — username, password, credit card number, and address — is transmitted in cleartext over the wire.
Bettercap intercepted the HTTP POST request in real time, revealing the following cleartext payload:
- Username: John Doe
- Password: Password123
- Email: johndoe@hotmail.com
- Credit Card: 1234 1234 1234 1234
- Address: 123 Fake Street
The captured POST request exposes every field submitted through the unencrypted form. No decryption was necessary. No certificate warnings were triggered on the target. The data was transmitted in the clear, and the MitM position granted complete visibility.
Click to zoom
Figure 3.3: The captured HTTP POST request to testphp.vulnweb.com. Cleartext credentials, credit card numbers, and PII are fully visible in the request body, demonstrating the catastrophic impact of unencrypted form submissions.
Key Takeaways and Mitigation
This engagement demonstrates a fundamental truth in network security: encryption is not optional. Any system transmitting data over unencrypted HTTP is broadcasting that data to every device capable of positioning itself on the network path.
Defensive Recommendations
-
Enforce HTTPS Everywhere. Deploy SSL/TLS certificates across all web-facing services, including internal applications. Free certificate authorities such as Let's Encrypt have eliminated cost as a barrier. There is no defensible reason to serve any application over HTTP in a production environment.
-
Implement HSTS Headers. HTTP Strict Transport Security instructs browsers to refuse HTTP connections entirely for a specified domain. This prevents protocol downgrade attacks and ensures that even a user typing
http://is automatically redirected to the encrypted channel before any data is transmitted. -
Deploy Static ARP Entries. In high-security network segments, configure static ARP entries on critical systems to prevent cache poisoning. While operationally intensive, this eliminates the trust-based vulnerability at the core of ARP spoofing.
-
Enable Dynamic ARP Inspection (DAI). On managed switches, DAI validates ARP packets against a trusted DHCP snooping binding table, dropping any ARP replies that do not match known IP-to-MAC mappings.
-
Segment the Network. VLANs and network segmentation limit the blast radius of a compromised host. An attacker who gains access to a guest VLAN should not be able to ARP spoof devices on the corporate management network.
-
Monitor for ARP Anomalies. Deploy network monitoring tools that alert on ARP table changes, duplicate MAC addresses, or unusual ARP traffic volumes. Early detection of ARP spoofing attempts can prevent an attacker from establishing the MitM position entirely.