Internal pentest scope documents sometimes include a line that quietly carries a lot of weight: traffic inside the corporate LAN doesn't need testing for interception, since it's already behind the firewall. Nobody writes that line to be careless. It just reflects an assumption that holds up fine right up until someone actually stands inside that network with a laptop and starts testing it.
Plug into the same VLAN as a cluster of workstations and run ARP spoofing between one of them and the default gateway, arpspoof, bettercap, whatever sends gratuitous ARP replies, and you don't need a single application vulnerability to start reading that "trusted" traffic. ARP dates to 1982 and has no authentication mechanism at all. It believes whichever device most recently claims to own a given IP address. Tell a workstation the gateway's MAC address is yours. Tell the gateway the workstation's MAC address is yours. Every packet between the two now routes through your laptop first, and neither end has any way to notice.
What's actually sitting in that traffic tends to be more useful than people expect from something labeled "internal only." A helpdesk tool that never got HTTPS because nobody thought it needed it. A legacy app still authenticating over plain HTTP because it predates the org's TLS rollout. DNS queries, which were never encrypted to begin with, so one spoofed response redirects a workstation's software update check, internal service lookup, or auth flow wherever you want it to go for the rest of the assessment window.
The wireless version of this trust gap works differently but lands in the same place. Laptops remember the names of networks they've previously joined and reconnect automatically to anything broadcasting a matching SSID, without prompting the user. Stand up an access point in a parking lot broadcasting the exact name of the office guest network, and devices walk onto it on their own, because as far as the OS is concerned, that name is already trusted.
The part worth getting right when you write this up: none of it touches modern TLS. Try classic SSL-stripping against a site with HSTS preloaded and the connection just breaks, it doesn't downgrade. So the honest finding usually isn't "we defeated encryption." It's "here is the specific service that was quietly never covered by the assumption that internal traffic didn't need protecting," which is a scoping and design gap as much as a technical one, and clients tend to remember it longer than a missing header.
Turning "I ran a tool and it worked" into actually being able to explain ARP's authentication gap, why DNS spoofing is its own separate finding, and why evil-twin Wi-Fi succeeds on trust nobody ever examines, is the full arc the Man-in-the-Middle Attack Book PDF walks through as a hands-on guide, not 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 a solid place to start building the wireless half of this hands-on: https://codelivly.com/learning-paths/wireless-social-engineering
(Standard disclosure: any of this only applies within written, authorized engagement scope. ARP/DNS spoofing on a network you don't have permission to test is just illegal, not a finding.)
Source: r/u/Potential-Couple-745 · by /u/Potential-Couple-745