📍 Journey Navigation Prev: Day 5 — HTTP, Reverse Shells & Three Minds | Day 1 | Day 3 | Day 5 | Day 6 |
Status: Day 6 of 90-day AI Security journey Labs Completed: 18–20 (The Advanced MITM Trilogy)
Where Yesterday Left Off
Yesterday, I was an "Intruder" sitting on a compromised server. Today, I became the Network itself.
I moved from the Application Layer down to the Data Link and Network Layers. I learned that the protocols we rely on for basic connectivity — ARP and DNS — were built for an "honest" world that no longer exists. On a local network, identity is a matter of opinion, and as an attacker, my job is to offer the most convincing opinion.
The Pre-Flight Battle: Environment vs. Tools
Before the labs worked, I faced the "Dual IP Conflict." My Kali machine had two IPs on one interface: a DHCP address for the internet and a static one for the lab. This created a "Routing Split Brain." The attack tools were firing, but the responses were getting lost in the noise of the wrong gateway.
The Fix: I killed NetworkManager, flushed the routing table, and locked all VMs into the 192.168.100.0/24 subnet — the same lab network I built on Day 3.
The Lesson: You cannot manipulate traffic if you do not strictly control the pipes it flows through.
Phase 1: ARP Spoofing & The "Same Subnet" Breakthrough
ARP (Address Resolution Protocol) is how computers ask: "I have this IP, who has the MAC address?" It is inherently trust-based. It doesn't ask for a password; it just records the first answer it gets. I first saw this trust gap when examining ARP tables in Day 4's Lab 1 — today I weaponised it.
The Breakthrough: The Subnet Logic
In my early attempts, I tried to sit between the Client and the Router. I saw nothing. I realized a fundamental networking truth: internal traffic stays internal.
If the Client (.20) wants to talk to the Webserver (.30) on the same subnet, it doesn't send that packet to the Router. It looks up the Server's MAC address and sends it directly across the wire. To intercept this, I had to stop pretending to be the Gateway and start pretending to be the Endpoint.
The Double-Sided Lie
To become the Man-in-the-Middle (MITM), I had to run two simultaneous attacks on Kali:
To the Client: "I am the Webserver. Send your data to me."
To the Webserver: "I am the Client. Send your data to me."
sudo arpspoof -i eth0 -t 192.168.100.20 192.168.100.30
sudo arpspoof -i eth0 -t 192.168.100.30 192.168.100.20
The result: Traffic flowed from Client → Kali → Webserver. I became a "Transparent Proxy." Every HTTP request, every login, every secret was now visible in my tcpdump.
Phase 2: DNS Spoofing — The Psychology of Trust
If ARP is the map of the office, DNS is the phonebook of the world. Humans don't remember 192.168.100.30; they remember google.com.
The Attack: Winning the Race
DNS over LAN is a race. When a victim asks for a domain, their computer waits for the first response. As a MITM, I am milliseconds closer to the victim than the real DNS server in the cloud.
The Execution:
I created a mapping file (dns.txt) on Kali: 192.168.100.30 google.com
I ran dnsspoof.
When the victim typed google.com, I "shouted" the wrong answer before the real one could arrive.
The Psychological Edge
This is where technical skill meets human behavior. The victim sees google.com in their URL bar. They see a login page (that I am hosting). Because the name is correct, the trust is established.
The Three Minds View
Applying the Three Minds framework from Day 5:
Attacker: I don't need to hack Google's servers. I just need to hack the victim's perception of where Google is.
Developer: Applications should never trust DNS alone. This is why hardcoding IPs is bad, but using Certificate Pinning (checking if the site's "ID card" matches the name) is vital.
Defender: This is why we use DNSSEC (digitally signed DNS) and DoH (DNS over HTTPS). If the DNS request is encrypted and signed, my "shouting" becomes meaningless noise.
Phase 3: SSL Strip & The HSTS Wall
Encryption (HTTPS) is the "Final Boss" for a network sniffer. If the traffic is encrypted, being in the middle only lets me see scrambled gibberish. SSL Strip is the attacker's attempt to "strip" that armor off.
The Mechanism: The Downgrade Hook
Most people don't type https://. They type the name, and the server sends a 301 Redirect saying: "Wait, come over to the secure HTTPS version!"
sslstrip intercepts that redirect. It talks to the server over HTTPS, but it talks to the victim over HTTP.
The Discovery: The HSTS Wall
During the lab, I noticed that modern browsers often refused to connect. This is HSTS (HTTP Strict Transport Security).
How it works: Sites like Google or Facebook tell the browser: "Remember me. Never, ever talk to me over HTTP again."
The browser stores this in a "Pre-load list."
When my sslstrip tried to downgrade the connection to HTTP, the browser saw the violation and killed the connection.
The Insight
SSL Stripping is a "legacy" attack. It works perfectly on internal, poorly configured company portals or old IoT devices, but it hits a brick wall against the modern web. This is the "arms race" in action — security evolved specifically to kill this attack.
Reflections: The LAN Is a Hostile Environment
The biggest takeaway from today is a complete destruction of the "Internal Network" trust model.
Most companies spend millions on their "Perimeter" (the big firewall at the front door) but leave their internal LAN wide open. Today proved that once an attacker gets a single device — a printer, a guest laptop, or a rogue Wi-Fi AP — on the internal wire, the entire network's integrity can be dismantled using 30-year-old protocols like ARP and DNS. This is the same "perimeter is already broken" lesson from Day 5's Lab 12, but at the network layer instead of the application layer.
The Mindset Shift
Yesterday: I learned how to break into a house.
Today: I learned how to redirect the mail, tap the phone lines, and change the address on the front door.
The Core Realization: You don't need to be a "Zero-Day" exploit developer to be dangerous. You just need to understand how computers talk to each other and find the places where they stop asking for ID.
Tomorrow — Session Hijacking & Rogue DHCP
Tomorrow, I move into Session Hijacking and Rogue DHCP. I'm going from intercepting traffic to stealing identities and fully automating the "Middleman" role.
Day 6 of 90 | Labs 18–20: ✅ Complete | ARP Spoofing: ✅ | DNS Spoofing: ✅ | SSL Stripping: ✅ | HSTS Discovery: ✅ | Tomorrow: Session Hijacking + Rogue DHCP 🔴
🔗 Related Posts
- Day 5 — HTTP, Reverse Shells & Three Minds — The three-perspective model and the exploitation labs that led to today's MITM
- Day 4 — Nmap, Firewalls & the Attacker's View — Where I first observed ARP trust and firewall behavior
- Day 3 — From Theory to Packets — The lab network that all these MITM attacks ran on
- Why I'm Learning AI Security — The bigger picture: why infrastructure security matters before AI security