Protect Corporate Credentials on Public Wi-Fi

When your team connects to hotel Wi-Fi during business trips, they're trusting that network to route their traffic safely. That trust is being systematically exploited. A DNS poisoning campaign targeting hospitality venues shows how attackers compromise Wi-Fi routers to intercept corporate credentials without touching user devices or sending a single phishing email. Your security controls must account for this invisible threat.

This checklist helps you implement technical controls and employee safeguards to protect corporate data when your team uses public Wi-Fi networks. Each item addresses a specific attack vector identified in recent DNS poisoning campaigns targeting business travelers.

Checklist Overview

This checklist focuses on preventing credential theft through compromised public Wi-Fi infrastructure. It covers VPN enforcement, DNS security, authentication hardening, and employee awareness. These controls apply to any device that connects to untrusted networks: hotels, conference centers, airports, co-working spaces, and similar venues.

Prerequisites

Before starting this checklist, confirm you have:

• Inventory of corporate devices used for travel. Know which laptops, tablets, and phones connect to public networks.
• VPN infrastructure capable of full-tunnel configuration. Split-tunnel VPNs won't protect against DNS poisoning.
• Access to identity provider settings. You'll need admin rights to modify authentication flows in systems like Microsoft Entra ID.
• Proxy and authentication log access. You need visibility into where authentication requests originate.

Checklist Items

1. Enforce Always-On VPN with Full-Tunnel Configuration on All Corporate Devices

Requirement: All DNS requests must route through corporate resolvers, not through untrusted public Wi-Fi gateways.

Configure your VPN client to:

• Activate automatically before network connection completes
• Use full-tunnel mode
• Block all traffic if VPN connection fails
• Prevent users from disabling the VPN without administrative credentials

Good looks like: A user connects to hotel Wi-Fi, the VPN activates before any application traffic flows, and all DNS queries resolve through your corporate DNS servers. Test by examining DNS query logs while connected to a public network.

2. Disable Web Proxy Auto-Discovery (WPAD) on Corporate Endpoints

Requirement: Prevent attackers from using WPAD to redirect traffic through malicious proxies.

In your endpoint configuration management:

• Set registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoDetect to 0
• Disable "Automatically detect settings" in browser proxy configurations
• Deploy this setting via Group Policy or mobile device management

Good looks like: Running netsh winhttp show proxy on a Windows device returns "Direct access (no proxy server)" or shows only your explicitly configured corporate proxy. WPAD should never appear in the output.

3. Block Device Code Authentication Flow at Your Identity Provider

Requirement: Eliminate authentication methods that don't verify the requesting device's legitimacy.

In Microsoft Entra ID (or equivalent identity provider):

• Create a Conditional Access policy targeting all users
• Set grant controls to block when authentication flow equals "Device code flow"
• Apply the policy to all cloud applications
• Document the business justification for blocking this flow

Good looks like: An attacker attempting device code authentication receives an immediate block, logged with policy name and timestamp. Your security team receives an alert for blocked device code attempts from unexpected locations.

4. Configure Proxy Authentication Log Monitoring for Unknown Host Sources

Requirement: Detect when credentials are submitted from infrastructure you don't control.

Set up automated monitoring that:

• Parses proxy authentication logs in real-time
• Maintains a whitelist of known corporate IP ranges and VPN exit points
• Flags authentication attempts from IP addresses outside your whitelist
• Generates alerts for authentications from hosting providers or known malicious infrastructure

Good looks like: Your SIEM generates a high-priority ticket when an employee's credentials appear in proxy logs from an IP address in India (if you don't operate there). The security team investigates within 15 minutes.

5. Implement Certificate Pinning for Critical Internal Applications

Requirement: Prevent man-in-the-middle attacks from presenting fraudulent certificates for your internal services.

For your most sensitive applications:

• Pin the expected certificate or public key in the application code
• Configure the application to reject connections if the certificate doesn't match
• Maintain a certificate rotation process that updates pins before expiration
• Test pinning by attempting to connect through a proxy with a different certificate

Good looks like: An attacker presents a valid-looking certificate for your VPN portal. The VPN client refuses the connection because the certificate doesn't match the pinned value, and logs the mismatch attempt.

6. Train Employees to Verify URLs and Certificates Before Entering Credentials

Requirement: Employees must check for authentication page legitimacy, especially on public Wi-Fi.

Your training program should include:

• How to check the full URL in the address bar
• How to view and interpret SSL certificate details in common browsers
• What a valid certificate for your corporate services looks like
• When to contact IT instead of proceeding with login

Good looks like: An employee connects to conference Wi-Fi and sees a login page for your corporate portal. They click the padlock icon, notice the certificate is issued to a different organization, and report it to your security team instead of entering credentials. You test this quarterly with simulated attacks.

7. Disable Automatic Network Connection on Corporate Devices

Requirement: Prevent devices from connecting to public networks without user awareness.

Configure devices to:

• Require explicit user action before joining any non-corporate network
• Forget public Wi-Fi networks after disconnection
• Display a warning before connecting to open networks
• Log all network connection attempts with timestamps

Good looks like: A device in a hotel lobby doesn't automatically join "Hotel_Guest_WiFi." The user must manually select the network, acknowledge a warning about untrusted networks, and wait for VPN activation before applications can communicate.

Common Mistakes

Assuming split-tunnel VPN provides adequate protection. If DNS queries bypass the VPN tunnel, attackers can still poison responses and redirect traffic. Full-tunnel configuration is non-negotiable for protecting against this attack vector.

Relying solely on HTTPS for security. While HTTPS encrypts traffic content, DNS poisoning can redirect users to attacker-controlled servers with valid certificates. Users see the padlock icon but send credentials to the wrong destination.

Training employees once and considering awareness complete. Credential harvesting techniques evolve. Your training must include recent examples and quarterly simulations that test whether employees actually verify certificates before authentication.

Monitoring only for malware or phishing. DNS poisoning doesn't require malicious code on the endpoint. You need to monitor authentication sources, not just endpoint behavior.

Forgetting about mobile devices. Tablets and smartphones connect to public Wi-Fi as frequently as laptops. Your VPN enforcement and certificate verification requirements apply equally to iOS and Android devices.

Next Steps

After completing this checklist:

1. Test your controls in a controlled environment. Set up a test access point that mimics DNS poisoning. Verify that your VPN prevents exploitation and your monitoring detects the attempt.

2. Review authentication logs for the past 90 days. Look for patterns that suggest credential harvesting you might have missed: authentications from unexpected geographic locations, multiple failed attempts followed by success, or logins from hosting provider IP ranges.

3. Document your public Wi-Fi security policy. Include specific requirements for VPN use, prohibited actions (like disabling security tools), and incident reporting procedures. Make this policy part of your travel security briefing.

4. Schedule quarterly security awareness updates. Share recent examples of DNS poisoning campaigns. Keep the threat concrete and current.

5. Plan for incident response. Define what happens when monitoring detects credential submission from an unknown host. Who investigates? How quickly do you force a password reset? When do you escalate to executive leadership?

The campaign targeting hospitality Wi-Fi infrastructure shows that attackers don't need to compromise your endpoints when they can compromise the network itself. Your controls must assume that any public network is actively hostile.