Hotel Wi-Fi DNS Poisoning: Defending Against Corporate Credential Harvesting

Introduction

Researchers at ReliaQuest have issued a critical warning regarding a wave of cyber espionage campaigns targeting the hospitality sector. Adversaries are actively compromising Wi-Fi routers in hotels to conduct DNS poisoning attacks, with the specific goal of stealing corporate login credentials from business travelers.

For security practitioners, this threat represents a significant blind spot in perimeter defense. While we focus on securing the corporate network, our executives and sales teams are often most vulnerable when they are off-network. The attack chain is sophisticated: by compromising the gateway infrastructure of hotels, attackers ensure that any attempt to access corporate resources (VPN portals, OWA, SSO) is silently redirected to malicious infrastructure designed to harvest credentials. This is not opportunistic crime; it is targeted espionage.

Technical Analysis

The Attack Vector

The attack leverages the inherent trust users place in the local network infrastructure provided by hotels.

Router Compromise: Adversaries gain access to the hotel's Wi-Fi router or gateway. This is typically achieved through:
- Unpatched firmware vulnerabilities.
- Default or weak administrative credentials (e.g., admin/admin).
- Remote management interfaces exposed to the internet.
DNS Configuration Tampering: Once access is established, the attacker modifies the DNS settings on the router. Instead of using the ISP's legitimate DNS resolver or a trusted public DNS (like Google 8.8.8.8 or Cloudflare 1.1.1.1), the router is configured to use a malicious DNS server controlled by the threat actor.
The Poisoned Resolution: When a victim connects to the hotel Wi-Fi and attempts to visit a website (e.g., vpn.company.com), the request goes to the compromised router. The router forwards the query to the malicious DNS server.
Credential Theft: The malicious DNS server resolves the domain to an IP address hosting a look-alike phishing site or a proxy that performs a Man-in-the-Middle (MITM) attack. The user enters their credentials, believing they are on the legitimate corporate portal, and the data is captured by the adversary.

Affected Components

Platform: SOHO and Enterprise-grade Wi-Fi Routers/Gateways in hospitality environments.
Protocol: DNS (UDP/TCP 53).
Impact: Credential Theft, Session Hijacking, Potential Malware Delivery.

Note: While specific CVEs were not disclosed in the initial reporting, the technique relies on the compromise of the router management interface or underlying OS. Defensive efforts must focus on the detection of DNS tampering rather than a specific software flaw.

Detection & Response

Detecting this attack requires visibility into two distinct areas: the integrity of the router configuration (for hospitality security teams) and the DNS resolution behavior of endpoints (for corporate SOC teams protecting travelers).

SIGMA Rules

YAML

---
title: Potential Router DNS Configuration Change
id: 8c4d2a1e-5f6b-4a2c-9b1d-0e3f5a7b9c8d
status: experimental
description: Detects modifications to DNS configuration files on Linux-based routers or gateways, which may indicate a DNS poisoning setup.
references:
  - https://www.infosecurity-magazine.com/news/hotel-wifi-dns-poisoning/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.defense_evasion
  - attack.t1562.001
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    Image|endswith:
      - '/vi'
      - '/vim'
      - '/nano'
      - '/sed'
    CommandLine|contains:
      - '/etc/resolv.conf'
      - '/etc/dnsmasq.conf'
      - '/etc/bind/named.conf.options'
  condition: selection
falsepositives:
  - Legitimate administrator network configuration changes
level: high
---
title: DNS Query to Suspicious New Domain
id: 9d5e3b2f-6a7c-5b3d-0c2e-1f4a6b8c0d9e
status: experimental
description: Detects endpoints querying domains recently registered or associated with high entropy, often used in phishing campaigns triggered by DNS poisoning.
references:
  - https://www.infosecurity-magazine.com/news/hotel-wifi-dns-poisoning/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1185
logsource:
  category: dns
  product: windows
detection:
  selection:
    QueryTypeName: 'A'
  filter:
    ResponseName|endswith:
      - '.microsoft.com'
      - '.google.com'
      - '.apple.com'
  condition: selection and not filter
falsepositives:
  - Legitimate browsing to new legitimate sites
level: medium

KQL (Microsoft Sentinel / Defender)

This query hunts for endpoints resolving internal corporate domains (like corp.local or vpn.company.com) to external IP addresses. If a corporate domain resolves to a public IP, it is a strong indicator of DNS poisoning or misconfiguration.

KQL — Microsoft Sentinel / Defender

let CorpDomains = dynamic(["company.com", "corp.internal", "vpn.company.com", "mail.company.com"]);
DeviceNetworkEvents
| where ActionType in ("DNSResolutionSuccess", "ConnectionSuccess")
| where RemoteUrl has_any (CorpDomains)
| extend IsExternal = iff(RemoteIP matches regex @"^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$" and 
                              (toint(parse_(split(RemoteIP, ".")[0])) >= 8 or 
                               toint(parse_(split(RemoteIP, ".")[0])) == 192 or 
                               toint(parse_(split(RemoteIP, ".")[0])) == 172), 
                              true, false)
// Note: Refined logic for external IPs implies non-RFC1918 usually, but specifically checking for non-corporate-allocated ranges is key here.
// Simplified: Just flag if corporate domain hits an IP not in known corporate blocks. 
| project Timestamp, DeviceName, InitiatingProcessAccountName, RemoteUrl, RemoteIP

Velociraptor VQL

This artifact hunts for suspicious DNS cache entries on the endpoint. If an internal corporate domain is resolved in the cache but points to an IP outside the expected scope (e.g., an AWS/Azure IP when it should be on-prem), it warrants investigation.

VQL — Velociraptor

-- Hunt for suspicious DNS cache entries on Windows endpoints
SELECT Fqdn, 
       Data, 
       Timestamp,
       
       -- Check if the IP is a private IP (RFC1918)
       if( regex_match(data="^10\.", re=""), "Private", 
       if( regex_match(data="^172\.(1[6-9]|2[0-9]|3[0-1])\.", re=""), "Private",
       if( regex_match(data="^192\.168\.", re=""), "Private", 
       if( regex_match(data="^127\.", re=""), "Localhost", "Public")))) AS IpType
FROM parse_dns_cache(filename="C:\\Windows\\System32\\drivers\\etc\\hosts") 
-- Note: Windows doesn't keep a persistent text file for DNS cache like hosts.
-- Real DNS cache inspection requires API calls, which Velociraptor handles via the windows.dns.cache artifact.
-- Using the standard artifact approach:

SELECT * FROM Artifact.Windows.System.DNSCache()
WHERE Data =~ "^(?!127\.|192\.168\.|10\.|172\.(1[6-9]|2\d|3[01])\.).*"
  AND Name =~ "company.com" 
  OR Name =~ "vpn.company.com"

Remediation Script (Bash)

For hospitality network administrators or MSPs managing these devices. This script audits the DNS configuration on a Linux-based gateway/router against a whitelist of expected safe DNS servers.

Bash / Shell

#!/bin/bash
# Hotel Router DNS Audit Script
# Audits /etc/resolv.conf and dhcpcd.conf for rogue DNS entries

AUTHORIZED_DNS=("8.8.8.8" "1.1.1.1" "192.168.1.1") # Replace with ISP/Corporate DNS
ALERT_FLAG=0

LOG_FILE="/var/log/dns_audit.log"
echo "[$(date)] Starting DNS Audit" >> $LOG_FILE

# Function to check file for rogue DNS
check_dns_file() {
    local file=$1
    if [ -f "$file" ]; then
        # Extract IPs that look like nameservers
        current_dns=$(grep -Eo "([0-9]{1,3}\.){3}[0-9]{1,3}" "$file")
        
        for ip in $current_dns; do
            is_authorized=0
            for auth_ip in "${AUTHORIZED_DNS[@]}"; do
                if [ "$ip" == "$auth_ip" ]; then
                    is_authorized=1
                    break
                fi
            done
            
            if [ $is_authorized -eq 0 ]; then
                echo "[CRITICAL] Unauthorized DNS found in $file: $ip" >> $LOG_FILE
                ALERT_FLAG=1
            fi
        done
    fi
}

check_dns_file "/etc/resolv.conf"
check_dns_file "/etc/dhcpcd.conf"
check_dns_file "/etc/dnsmasq.conf"

if [ $ALERT_FLAG -ne 0 ]; then
    echo "[ACTION REQUIRED] Rogue DNS detected. Please review $LOG_FILE immediately."
    exit 1
else
    echo "[OK] DNS configuration looks clean." >> $LOG_FILE
    exit 0
fi

Remediation

For Hospitality Providers (Venue Security)

Change Default Credentials: Ensure all routers have strong, unique administrative passwords. Default credentials are the primary entry point for these attacks.
Firmware Updates: Audit all Wi-Fi infrastructure and apply the latest firmware patches immediately.
Disable Remote Management: Turn off WAN-side administration (Web GUI, SSH, Telnet) on all routers unless strictly necessary and protected by VPN ACLs.
DNS Locking: Configure routers to use static DNS entries and, if supported, disable the ability for DHCP clients to push arbitrary DNS changes to the router upstream.
Segmentation: Isolate the guest Wi-Fi network from the hotel's operational back-office network (PCI-DSS compliance).

For Corporate Defenders (Protecting the Workforce)

Enforce Always-On VPN: Require remote workers to use an Always-On VPN profile. This encrypts DNS queries and routes them through the corporate secure resolver, bypassing the hotel's malicious DNS entirely.
DNS Filtering: Implement enterprise-grade DNS security (e.g., Cisco Umbrella, Cloudflare Gateway) on endpoints. This can block resolution to known malicious domains even if the local router tries to poison the cache.
Phishing-Resistant MFA: Deploy FIDO2/WebAuthn hardware keys. Even if credentials are harvested via DNS poisoning, attackers cannot reuse them without the physical token.
Traveler Education: Brief high-risk travelers on the dangers of public Wi-Fi. Instruct them to verify HTTPS certificates (look for the lock icon) and alert IT if they receive certificate warnings on known legitimate sites.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub