A full lab reproduction of the Evil Twin attack on isolated Kali Linux + airgeddon, plus a 6-rule defense framework for everyday users. Awarded 3rd place at the Lomonosov Readings 2026 research conference."
TL;DR — I reproduced an end-to-end Evil Twin attack in an air-gapped VirtualBox lab using
airgeddonon Kali Linux. From "VM boot" to "captured credentials shown on the attacker's terminal" took about 15 minutes. The attacker doesn't break cryptography — they bypass it by exploiting auto-connect and user trust. Below: the 5-stage attack chain, what actually happens at each layer, and a practical 6-rule defense framework.
This is a write-up of an individual research project I conducted at MAOU Gymnasium №16 (Tyumen, Russia), which was awarded 3rd Place at the Lomonosov Readings 2026 research conference (Informatics category). Full repository, paper, and slides are linked at the bottom.
1. Why Evil Twin still matters in 2026
You walk into a cafe. Your phone shows two networks named CoffeeHouse_Guest. You connect to the one with the stronger signal — because that's what your OS does by default. Within seconds you might be:
- Connected to a rogue laptop, not the real router
- Browsing through an attacker-controlled DNS and HTTP gateway
- One redirect away from a captive portal asking for your "Wi-Fi password" or Google credentials
The attack does not require breaking WPA2. It does not require advanced skills. The barrier is so low that the most useful contribution a researcher can make today isn't a new exploit — it's a clear, reproducible explanation of how trivial the attack already is, and what users can actually do about it.
2. Lab architecture (fully air-gapped)
Ethics first: the entire experiment ran in a VirtualBox Internal Network, with zero connectivity to any physical network. All credentials were synthetic. All hardware was mine.
[Windows host]
└─ VirtualBox Internal Network ──► no external connectivity
├── Kali Linux 2024.1 (attacker)
└── Android VM/device (victim — manually connected)
Stack:
- Kali Linux 2024.1 + USB Wi-Fi adapter capable of monitor/AP mode
- airgeddon v11.22 as the orchestration layer
- Underneath airgeddon:
airodump-ng,aireplay-ng,hostapd,dnsmasq,lighttpd,iptables
If you want to replicate: do it only on hardware you own, in an isolated network. Unauthorized deployment is a criminal offense in most jurisdictions (in Russia, Articles 272–273 of the Criminal Code).
3. The 5-stage attack chain
Recon → Rogue AP → Deauth → Interception → Phishing Portal
Stage 1 — Reconnaissance
Put the wireless interface in monitor mode and dump nearby APs and clients:
airmon-ng start wlan0
airodump-ng wlan0mon
Output gives you BSSID, channel, encryption, and connected client MACs for every AP in range. This is the targeting data for everything that follows.
Stage 2 — Rogue Access Point
hostapd is told to broadcast an SSID identical to the legitimate target — same name, attacker's BSSID, encryption deliberately disabled to look like a "guest" variant:
ssid=Free_Public_Lab
channel=6
hw_mode=g
This is the entire trick. There is no protocol violation. 802.11 simply has no built-in mechanism for a client to tell two APs with the same SSID apart.
Stage 3 — Deauthentication
To force migration from the real AP to the twin, send forged 802.11 deauth frames:
aireplay-ng --deauth 0 -a <real_BSSID> wlan0mon
Most clients will silently reconnect — and because the rogue AP is open and stronger, that's where they land. Auto-connect is what makes this stage devastating.
Stage 4 — Traffic interception
dnsmasq provides DHCP + DNS to the victim, and iptables redirects all HTTP traffic to a local web server:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 80
Now the victim has "internet" — except every DNS query and every cleartext request flows through the attacker.
Stage 5 — Captive portal
lighttpd serves a clone of a familiar login page (router admin, ISP portal, or a generic "Confirm your connection" form). The user submits credentials. They appear immediately in the attacker's terminal.
In my run, the test victim entered test_user / Sup3rSecret! — captured in plaintext within seconds.
I also validated the WPA2 variant: even when the legitimate network has a shared password (PublicPassword123), the attack still works, because the password is shared and any client (including the attacker) can use it to host a convincing twin.
4. Why the usual advice fails
A few lessons that actually mattered after running this end-to-end:
- "Just check for HTTPS" is not enough. Captive portals can serve valid Let's Encrypt certs for attacker-controlled domains. Your browser's padlock confirms the connection is encrypted to the attacker.
- "Use the password-protected network" is not enough. WPA2-PSK protects only against outsiders who don't know the key. In a public cafe, the key is on a chalkboard.
- "I'll just notice" is not enough. Modern OSes hide BSSIDs and silently roam between APs with the same SSID. The attack is invisible at the UI layer.
The attack doesn't break cryptography. It bypasses it by exploiting an architectural assumption baked into 802.11 itself: that SSIDs are trustworthy identifiers.
5. The 6-Rule Defense Framework
This is the practical output of the project — a checklist designed for non-technical users.
| # | Rule | Why it works |
|---|---|---|
| 1 | Use a VPN (WireGuard / OpenVPN, no-logs provider) | Encrypts the entire tunnel before it touches the rogue AP. The attacker sees opaque traffic to the VPN server. |
| 2 | Disable auto-connect, delete saved public networks | Removes the silent reconnection that makes deauth effective. |
| 3 | No sensitive actions on public Wi-Fi without VPN | Use 4G/5G for banking, email, work logins. Cellular has built-in link-layer encryption. |
| 4 | Enable 2FA everywhere | Captured passwords become useless without the second factor. |
| 5 | Technical verification — confirm SSID with staff, watch for duplicate BSSIDs (Wi-Fi Analyzer) | Catches the most obvious twin deployments. |
| 6 | Keep OS and browser updated | Closes vulnerabilities a MitM can exploit even inside a session. |
Comparative effectiveness (from the paper):
| Method | Protection | Speed | Accessibility |
|---|---|---|---|
| VPN (WireGuard / OpenVPN) | ★★★★★ | ★★★★☆ | ★★★★☆ |
| Personal hotspot (4G/5G) | ★★★★★ | ★★★★★ | ★★★☆☆ |
| Tor Browser | ★★★★☆ | ★★☆☆☆ | ★★★☆☆ |
| HTTPS only | ★★☆☆☆ | ★★★★★ | ★★★★★ |
| Auto-connect disabled | ★★★☆☆ | ★★★★★ | ★★★★★ |
6. What I took away from the project
Three things stuck with me after the lab work:
- The interesting layer is human, not technical. Every interesting failure mode I observed was a UX decision (auto-connect, hidden BSSID, identical SSID rendering) rather than a cryptographic weakness.
- Live demonstrations change behavior more than warnings. Showing classmates their own captured test credentials on a screen produced a sharper reaction than any infographic. That's why the deliverable is education, not tooling.
- Reproducibility is half the value. A one-off attack proves nothing. A documented, isolated, repeatable lab — with the exact tool versions and a step-by-step chain — is what makes the result useful to someone else.
7. Repository
- Repo: https://github.com/NovaCode37/eviltwin
-
Full paper (RU, ~21 pages):
materials/ru/ -
English executive summary:
docs/executive-summary.md -
Diagrams (Mermaid):
diagrams/ - Award: 3rd Place — Lomonosov Readings 2026, MAOU Gymnasium №16, Tyumen
If you build a similar lab or want to discuss any stage of the chain in more depth, I'd be glad to compare notes in the comments.
Disclaimer: All experiments were conducted on the researcher's own equipment, in a fully isolated virtual environment, using synthetic test credentials. This article is for educational and defensive purposes only.
Top comments (0)