Technical documentation on DNS Hijacking. Understand the attack technique and learn how to defend against...
Medium ThreatIntermediate
Updated April 2026
4 min read
MalwareZero Research Team
Updated April 2026
id="how-it-works" id="how-dns-hijacking-works">How DNS Hijacking Works
When you connect to a WiFi network and your device gets its IP configuration via DHCP, it also receives the address of a DNS server. In a normal setup, this is the router's IP or the ISP's DNS server. In a DNS hijacking setup, the attacker has already configured their dnsmasq to respond to all DNS queries with the attacker's own IP address.
Normal DNS Resolution:
[Your Device] ──DNS query: google.com──→ [8.8.8.8] (Google DNS)
[Your Device] ←──IP: 142.250.185.46 ───── [8.8.8.8]
[Your Device] ──HTTPS──→ 142.250.185.46 [Google Server]
DNS Hijacked Resolution:
[Your Device] ──DNS query: google.com──→ [192.168.1.1] (Attacker's Evil Twin)
[Your Device] ←──IP: 192.168.1.1 ───────── [192.168.1.1] (Attacker's server)
[Your Device] ──HTTPS──→ 192.168.1.1 [Attacker's phishing server]
[Attacker's server] ───proxies──→ Google (for HTTPS, if desired)
[Victim types google.com, sees google.com, but is at attacker's server]
dnsmasq Configuration for DNS Hijacking
dnsmasq is the standard tool for DNS hijacking in Evil Twin attacks. It simultaneously acts as the DHCP server (assigning IPs to victims) and DNS server (resolving all domain names to the attacker's IP).
$ cat /etc/dnsmasq.conf# Interface bound to the attacker's AP interfaceinterface=wlan1# DHCP: Assign IPs from this rangedhcp-range=192.168.1.100,192.168.1.200,12h# Tell victims the gateway is the attacker's IPdhcp-option=3,192.168.1.1# Tell victims DNS is the attacker's IPdhcp-option=6,192.168.1.1# Catch-all DNS: resolve EVERY domain to attacker's IPaddress=/#/192.168.1.1# Logging for analysislog-querieslog-dhcplog-facility=/var/log/dnsmasq.log
$ sudo systemctl start dnsmasq[All DNS queries from connected victims now resolve to attacker]
Real Scenario: Redirecting to a Phishing Site
Attacker "Marco" is at a co-working space in Singapore. He runs Mana Toolkit + dnsmasq as above. When victims connect to his Evil Twin and try to visit their corporate email (outlook.office365.com), dnsmasq returns 192.168.1.1 — Marco's phishing server.
Marco's phishing server serves a perfect copy of the Microsoft login page. It uses a valid SSL certificate (Let's Encrypt, for marco-phishing.io). The victim's browser shows the padlock. The URL shows outlook.office365.com (because Marco's DNS told the victim's browser to go to his IP, and the URL was set to match).
$ tail -f /var/log/dnsmasq.logquery[A] outlook.office365.com from 192.168.1.147[redirected to 192.168.1.1]query[A] login.microsoftonline.com from 192.168.1.147[redirected to 192.168.1.1]query[A] www.linkedin.com from 192.168.1.147[redirected to 192.168.1.1][Victim enters credentials: attacker@acmecorp.com / Password123!][POST captured] email=attacker%40acmecorp.com&pass=Password123%21[Credentials saved to /var/log/phishing.log][Victim redirected to real Microsoft — and logs in successfully][Victim never knows their credentials were just stolen]
The SSL Problem — And Its Limits
Modern browsers perform certificate pinning for major sites like Microsoft, Google, and Apple. If the victim has previously logged into Office 365, their browser remembers the certificate and will show a warning if a different certificate is presented. However: (1) many users click through warnings, (2) some apps don't implement pinning, and (3) if the victim is on a device that hasn't previously visited the site, there's no pin to check.
The "Crypto Wallet Drain" Scenario
This is one of the highest-value DNS hijacking targets. A crypto investor connects to public WiFi. Their device uses the attacker's DNS. They open their browser and go to what they think is their exchange — but DNS redirected them to a phishing site.
Crypto Wallet Drain Attack Sequence:1. Victim connects to Evil Twin "Airport_Free_WiFi"2. dnsmasq catch-all redirects all DNS to 192.168.1.13. Victim types: binance.com4. dnsmasq returns: 192.168.1.1 (attacker's phishing server)5. Phishing server serves perfect Binance clone6. Victim enters: email + password + 2FA code7. Attacker captures credentials in real-time8. Attacker logs into real Binance immediately9. Attacker initiates: Withdraw ALL USDT → attacker's wallet10. Binance sends 2FA approval notification to victim's phone11. Victim sees: "Was this you? Withdraw $47,000 to wallet 0x3F..."12. If victim approves (or doesn't see it in time): funds gone
The real danger with crypto is the combination of DNS hijacking + real-time credential capture + the irreversibility of blockchain transactions. There's no chargeback on Ethereum. By the time the victim realizes what happened, the funds are gone.
Even if the victim has 2FA enabled, an attacker with captured credentials can sometimes initiate a withdrawal and receive the 2FA code if the victim's phone is also compromised (through malware injection or SIM swapping — a separate attack).
Defense Against DNS Hijacking
Enable DNS over HTTPS (DoH): Encrypts DNS queries so attackers can't see or redirect them. See the DNS Security page.
Use a VPN on public WiFi: Routes all traffic (including DNS) through the VPN's encrypted tunnel.
Check the URL carefully: Look for subtle misspellings in phishing domains (binance.com → binance-verify.io).
Never click through certificate warnings: This is how phishing + HTTPS works — the padlock gets your trust, then the wrong certificate triggers a warning you shouldn't dismiss.
Use a hardware wallet for significant crypto holdings: Ledger or Trezor devices require physical button confirmation for transactions, making remote drain attacks impossible without physical access to the device.
Enable withdrawal whitelists: Most exchanges allow you to whitelist specific wallet addresses. Enable this.