Scope notes for an internal engagement sometimes include a line like this: traffic inside the corporate LAN doesn't need testing for interception, it's already behind the firewall. That line is usually written by someone who has never actually stood inside that LAN with a laptop and bad intentions.
Plug into the same VLAN as a cluster of workstations and run ARP spoofing between one of them and the default gateway, arpspoof or bettercap, anything that sends gratuitous ARP replies, and you don't need a single application vulnerability to start reading that "trusted" traffic. ARP has no authentication built in. It dates to 1982, and it will believe whichever device claims to own an IP address most recently. Tell a workstation the gateway's MAC address is yours, tell the gateway the workstation's MAC address is yours, and every packet between them routes through your laptop first.
Within minutes on a typical internal segment, something is usually still moving in cleartext: an internal helpdesk tool that never got HTTPS because it's "internal only," a legacy application still authenticating over plain HTTP, or DNS queries that were never going to be encrypted regardless. Unencrypted DNS is its own opening. Spoof one response and that workstation's next software update check, internal tool lookup, or authentication redirect goes wherever you decide, for the rest of the assessment window.
Off the wired network, the same instinct plays out differently. Laptops broadcast the names of networks they've previously joined and reconnect automatically to anything answering with a matching SSID, open or not. An access point broadcasting the office guest network's name, sitting in the parking lot, catches devices that never prompt the user for anything, because as far as the laptop is concerned it already trusts that name. Combined with DNS spoofing, that's interception without ever touching the wired segment at all.
What this doesn't get you, and this matters for how you write the finding, is modern TLS. Trying classic SSL-stripping against a site with a preloaded HSTS header just breaks the connection, it doesn't downgrade it. So the actual finding usually isn't "we broke TLS." It's "here is the specific service that was never covered by the assumption that internal traffic doesn't need it," which is a scoping and design finding as much as a technical one, and it's the kind of thing a client remembers longer than a missing header.
Getting from "I ran a tool" to being able to explain ARP's authentication gap, why unencrypted DNS is its own separate finding, and why evil-twin Wi-Fi works on trust nobody examines, is the full arc the Man-in-the-Middle Attack Book PDF walks through: ARP and DNS spoofing through evil-twin Wi-Fi through SSL interception, as a hands-on guide rather than a tool changelog: https://resources.codelivly.com/product/practical-man-in-the-middle-attacks-in-computer-networks/
The free Wireless & Social Engineering learning path on codelivly.com is the place to start building the Wi-Fi side of this hands-on: https://codelivly.com/learning-paths/wireless-social-engineering
Top comments (0)