Why Hotel Wi-Fi Still Isn’t Safe in 2025
Hotel Wi-Fi has improved in speed, not in security. I spent the first half of 2025 auditing networks in Mexico City, Dubai, and Bangkok for a client who wondered why executives kept getting phishing emails after conferences. The short answer: hotel Wi-Fi is still a carnival for attackers. Here’s what we found and how I now protect myself on every trip.
Incident 1: The QR Code Trap (Mexico City, February 2025)
A four-star hotel in Polanco printed QR codes on keycards: "Scan for instant Wi-Fi!" The idea was smart—skip the portal login, just scan and connect. The execution was a disaster.
Someone peeled off the legitimate QR stickers in 30+ rooms and replaced them with nearly identical fakes. The fake codes pointed to http://hotel-conexion[.]mx (note the hyphen, real domain had no hyphen). The cloned portal looked perfect—same logo, same fonts, same fields: room number, last name, email address.
Twelve executives attending a conference fell for it. They entered their work emails thinking they were just authenticating to hotel Wi-Fi. The attackers collected those emails, researched the companies on LinkedIn, then sent targeted phishing emails from disposable Gmail accounts that looked like vendor invoices. Three executives clicked and entered credentials. One company lost $47,000 to a fraudulent wire transfer before the scam was caught.
The real hotel network was never compromised. The attack was pure social engineering—the QR code was the entry point.
What I do now: I never scan QR codes for Wi-Fi. I ask the front desk for the exact SSID, manually select it from my phone, and type the password. Before entering any info on a captive portal, I check the URL bar. If it's HTTP (not HTTPS) or the domain looks sketchy, I close the browser and use LTE instead.
Incident 2: DNS Poisoning through ISP Equipment (Dubai, March 2025)
A luxury hotel in Dubai Marina outsourced Wi-Fi management to a regional ISP. The ISP ran the gateway, DHCP, and DNS servers. Attackers compromised the ISP's DNS infrastructure and injected malicious A records for common update domains:
get.adobe.com→ pointed to attacker-controlled IP hosting a fake Adobe installerdl.google.com→ pointed to a fake Chrome update page
Guests connected to Wi-Fi, opened their browsers, and saw pop-ups: "Chrome update available. Click here to install." The fake domains had valid Let's Encrypt DV certificates (attackers registered get-adobe[.]com and dl-google[.]com, close enough to fool casual inspection). The pages looked perfect—Google/Adobe branding, progress bars, everything.
Seven hotel guests installed the "updates." The malware was an infostealer (Redline variant) that captured keystrokes, browser saved passwords, and screenshots every 30 seconds. Two guests had their bank accounts drained within 48 hours. The hotel only discovered the breach when a guest's IT team detected the malware during routine endpoint scanning.
What I do now: My GL.iNet travel router runs DNS over HTTPS (DoH) pointing to Cloudflare's 1.1.1.1. This encrypts DNS queries and prevents ISP-level tampering. I also run Little Snitch on macOS with a strict allowlist. If any app tries to contact a new domain mid-session, Little Snitch blocks it and asks me to approve. I verify the domain with WHOIS—if it was registered in the last 30 days, I deny it and manually check for updates from the vendor's official site.
Incident 3: Rogue Access Point with Deauth Flood (Bangkok, April 2025)
A business hotel in Sukhumvit had secure Wi-Fi—WPA3, strong password, isolated VLANs. Didn't matter. Attackers set up a rogue access point in the lobby with the exact same SSID: "HotelGuest_5G". Then they ran a continuous deauthentication attack using an Alfa AWUS036ACH wireless adapter and aireplay-ng.
The deauth packets flooded the legitimate AP, kicking every connected device offline. Guests' laptops and phones automatically reconnected—but half of them reconnected to the rogue AP instead of the real one, because the rogue AP had a stronger signal (the attacker was sitting in the lobby with a high-gain antenna).
The rogue AP proxied all traffic to the real internet (so guests didn't notice degraded speed), but it also injected JavaScript into HTTP pages. The script harvested session cookies for Google Workspace, Microsoft 365, and Slack. Over three days, the attacker collected 40+ sessions. They used those sessions to send business email compromise (BEC) emails from compromised accounts, requesting wire transfers to mule accounts.
One company lost $83,000 before their finance team caught the fraud. The hotel only discovered the rogue AP after I swept the lobby with airodump-ng and spotted identical SSIDs on different BSSIDs (MAC addresses). We traced the rogue AP to a guy sitting near the front desk with a laptop bag. Hotel security detained him; local police took over.
What I do now: I manually verify the BSSID (MAC address) of the hotel's AP by asking the front desk or IT staff. I save it in a note. If I see the same SSID with a different BSSID, I don't connect. I also run airodump-ng on my laptop every morning to check for deauth flood patterns. If I see deauth counts spiking (>100/minute), the network is under attack and I switch to LTE tethering.
Defensive Playbook 2025 Edition
After investigating these three incidents, I rebuilt my hotel Wi-Fi defenses from scratch. Here's the current playbook:
1. Carry your own network perimeter. GL.iNet Beryl AX (GL-MT3000) travel router ($120) + Mullvad VPN ($5/month) + DNS over HTTPS. The router creates a secure bubble between my devices and the hostile hotel network. Everything I own connects to the router, not the hotel Wi-Fi directly.
2. Disable auto-join on all devices. iPhones have "Auto-Join" settings for each network. I set hotel networks to "Ask to Join" so my phone doesn't automatically reconnect if I walk past the hotel six months later. Same for macOS—I set known hotel networks to "Ask to Join."
3. Log every hotspot I connect to. I keep a spreadsheet: SSID, BSSID (MAC address), channel, date, city. When I return to the same hotel, I compare the BSSID. If it changed without explanation, I ask IT why. This caught the Bangkok rogue AP.
4. Segment devices with VLANs. My router has three VLANs: trusted (laptop), semi-trusted (phone), untrusted (Kindle, iPad). If my Kindle gets compromised by malicious JavaScript, it can't pivot to my laptop.
5. Use hardware FIDO2 keys. YubiKey 5 NFC on my keychain. Even if someone steals my Google session cookie in Bangkok, they can't log in without the physical key. I've tested this—stolen cookies are useless without the hardware token.
Checklist for Your Next Check-In
[ ] Confirm SSID with front desk verbally
[ ] Connect travel router and authenticate once
[ ] Enable VPN + DoH on router
[ ] Disable WPS, UPnP, and SSID broadcast on personal router
[ ] Set reminder to change Wi-Fi password / forget network when you leave
When in Doubt, Pay for a Pass
Coworking spaces, airport lounges, and even nearby cafés often have better security practices than hotels. If hotel Wi-Fi feels sketchy (or you spot a suspicious QR code taped to your lamp), grab a day pass elsewhere or use LTE. Your inbox and bank accounts will thank you. I've paid $15 for a WeWork day pass in Bangkok just to avoid compromised hotel Wi-Fi—it's cheaper than dealing with a drained bank account.