Advisory: DNS Poisoning — Three Attack Vectors Against the Internet's Address Resolution Layer
Executive Summary
DNS (Domain Name System) is the resolution layer that translates human-readable domain names into IP addresses. Every internet connection begins with a DNS lookup. An attacker who can corrupt a DNS response can redirect a user to an attacker-controlled server while the legitimate domain name remains in the browser's address bar — the user sees no indication that the destination has changed. This advisory documents the three primary DNS poisoning vectors, their relative difficulty, and the mitigations applicable to each.
The Trust Foundation DNS Provides — and Its Limits
When a user types a domain name, their browser queries a DNS resolver. The resolver consults authoritative DNS servers for the zone and returns the IP address. The browser connects to that IP without further verification of whether the IP actually belongs to the intended domain. The entire trust chain rests on the integrity of the DNS response. If the response is falsified — through any of the three methods below — the user connects to the wrong destination, the legitimate domain name appears in the address bar, and there is no visible indication of the misdirection.
Attack Vector Analysis
| Vector | Method | Scope of Impact | Attacker Requirement |
|---|---|---|---|
| DNS server compromise | Attacker gains access to the DNS server and modifies authoritative records directly — changing the A record for target.com from the real IP to an attacker-controlled IP | All users querying that server for the affected domain; potentially millions | Compromise of DNS server credentials or exploitation of DNS server software vulnerability; significant technical capability required |
| Host file modification | Malware rewrites the local host file on the victim's machine to map a target domain to the attacker's IP. The host file takes precedence over DNS — the system never queries a DNS server for domains listed locally | Single affected machine only; all DNS queries for that domain from that machine are affected | Malware already present on the machine; typically requires elevated privileges to write to the host file |
| On-path response injection | Attacker positioned on the network path intercepts DNS queries (which use UDP with no authentication) and injects a forged response before the legitimate DNS server's answer arrives. Client accepts the first valid-looking response it receives | All clients whose DNS traffic passes through the attacker's intercept position | Network access on the query path; no server compromise or client malware required; no credentials needed |
Host File Location Reference
The host file is a local override for DNS resolution on the client system:
Linux / macOS: /etc/hosts
Format: IP_ADDRESS domain.name — one entry per line. Any domain listed in the host file is resolved to the specified IP without querying DNS. Malware targeting host file modification typically requires Administrator (Windows) or root (Linux/macOS) privileges to write to the file. Endpoint security tools can monitor for unauthorized host file modifications and alert or restore the file to a known-good state.
Recommended Mitigations
- DNSSEC (DNS Security Extensions): Adds cryptographic signatures to DNS records. When a resolver returns a signed answer, the client can verify the signature using the zone's public key. An on-path attacker injecting a forged response cannot produce a valid signature for the target zone — the injected response will fail signature validation and be rejected. DNSSEC addresses the on-path injection vector directly. It does not protect against DNS server compromise or host file modification.
- Endpoint protection with host file integrity monitoring: Security tools that monitor the host file for unauthorized changes and restore it to a known-good baseline mitigate the local poisoning vector. Alert on any modification to the hosts file not initiated through an authorized change management process.
- Network segmentation and encrypted DNS (DoH/DoT): DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the DNS query in transit, preventing on-path observers from reading or injecting responses. Restricting recursive DNS resolution to known internal resolvers via firewall policy limits exposure to rogue external resolvers.
Advisory: Domain Hijacking — Full Traffic Redirection Without Compromising a Single Server
Executive Summary
Domain hijacking is the unauthorized modification of a domain name's DNS records through compromise of the domain registrar account. Unlike DNS server attacks, which require technical exploitation, domain hijacking requires only access to the registrar's web portal — an account credential or a successful social engineering of registrar support staff. Once an attacker controls the registrar account, they can redirect every domain registered under that account to any IP they choose. All servers, all security controls, and all digital infrastructure associated with those domains become irrelevant — traffic simply goes somewhere else. The October 2016 attack against a major Brazilian bank is the canonical modern example of this technique at scale.
Case Study — Brazilian Bank Domain Hijacking, October 22, 2016
At approximately 1:00 PM on a Saturday, attackers modified the domain registration settings for 36 domains belonging to a major Brazilian bank. The affected domains included the bank's desktop banking websites, mobile banking application domains, and ATM support system domains.
The attackers' method: they gained access to the bank's domain registrar account and updated the DNS A records for all 36 domains to point to attacker-controlled servers. The bank's actual servers were not touched. No malware was deployed on the bank's network. No bank employee credentials were stolen. The physical servers remained online and uncompromised. None of this mattered — because traffic never reached them.
For approximately six hours, every customer attempting to access the bank's services connected to attacker-controlled infrastructure. The fake sites were visual replicas of the legitimate bank interfaces. Customers entered usernames, passwords, one-time authentication codes, account numbers, and additional personal information — all captured by the attackers. The bank's own certificates had been replaced: the attackers had obtained TLS certificates for the hijacked domains, so HTTPS padlocks appeared as valid on the fake sites.
The bank's customer population at the time exceeded five million. Assets under management: approximately $27 billion USD. The entire attack surface was one compromised credential: the registrar account password.
Why the Registrar Account Is the Master Key
| What Controlling the Registrar Account Allows | Consequence |
|---|---|
| Change A records for any registered domain | All web traffic for that domain redirected to attacker IP |
| Change MX records | All inbound email intercepted by attacker mail server |
| Change nameserver delegation | Total DNS control over all associated domains transferred to attacker infrastructure |
| Obtain TLS certificates via DNS challenge validation | Attacker acquires valid HTTPS certificates for the hijacked domains — padlock shows as valid to users |
| Transfer domain registration to a new registrar | Removes domain from victim's control permanently until resolved through dispute process |
Common Registrar Account Compromise Methods
- Credential stuffing using passwords leaked in prior breaches applied against the registrar portal
- Phishing email targeting the individual who manages domain registrations
- Social engineering of registrar customer support — requesting account recovery or DNS record changes by impersonating the account holder
- Compromise of the email account associated with the domain registration — many registrars allow password resets via email; controlling the inbox controls the registration
Recommended Mitigations
- Multi-factor authentication on the domain registrar account: The single highest-impact control. A stolen password alone cannot change DNS records if MFA is enforced. Implement MFA on every registrar account; use authenticator app or hardware token, not SMS (SMS is subject to SIM-swapping attacks).
- MFA on the associated email account: Registrars permit password resets via email. If the attacker controls the registrar email account, they can reset the registrar password. Equally strong MFA is required on the email account used for domain management.
- Domain locking / registry lock: Most registrars offer a "registrar lock" that prevents unauthorized transfers and record changes without an additional verification step. For high-value domains, engage registry-level lock services that require out-of-band verification for any modification.
- DNS change monitoring and alerting: Configure alerts for any modification to DNS records. Most registrars offer this via email or webhook. A six-hour attack window is possible only if changes go undetected; a five-minute alert could enable rapid response and record restoration.
Advisory: URL Hijacking and Typosquatting — Harvesting Misdirected Traffic via Lookalike Domains
Executive Summary
Typosquatting — also called brandjacking, URL hijacking, or sting-site operation — involves registering domain names that closely resemble a legitimate organization's domain, in order to capture traffic from users who mistype the URL, misread it, or are directed to it through phishing. Tens of millions of URL typos occur daily across the internet. The registrant of a typosquatted domain can monetize this misdirected traffic through advertising revenue, credential harvesting (phishing), malware drive-by download, or domain resale to the legitimate organization. No technical compromise of the target organization is required.
Typosquatting Pattern Taxonomy
| Pattern Type | Example (target: professormesser.com) | Primary Use |
|---|---|---|
| Character substitution (misspelling) | professormessor.com, professormesser.com → professormeser.com | Advertising revenue, phishing |
| Character omission | professormeser.com (one 's' dropped) | Advertising, phishing |
| Character addition / doubling | professormessers.com (extra 's') | Advertising, phishing, domain resale |
| Adjacent key substitution | professormesaer.com ('s' and 'a' transposed on keyboard) | Advertising, phishing |
| Alternative TLD | professormesser.org, .net, .co when target is .com | Advertising, phishing, competitor redirection |
| Hyphenation insertion | professor-messer.com | Phishing, brand confusion |
Malicious Use Cases
- Advertising revenue (most common): The typosquatted domain serves a page of advertising links and comparison shopping. The domain owner earns per-click revenue from the misdirected traffic. Multiplied across thousands of typo variations and millions of annual visitors, revenue is significant.
- Credential harvesting: The typosquatted site presents a pixel-perfect replica of the legitimate site's login page. Users who don't check the address bar enter usernames and passwords that are captured by the attacker. Particularly effective against banking, email, and enterprise login portals.
- Drive-by malware delivery: Visiting the typosquatted domain silently attempts to exploit browser vulnerabilities to install malware without the user's interaction. The user believes they briefly reached the wrong URL and hit back — the malware has already executed.
- Domain resale extortion: Attacker registers the typosquatted domain and contacts the legitimate organization offering to sell it. Organizations that failed to pre-register common typos of their own domain may pay significant sums to recover them.
- Competitor redirection: The typosquatted domain redirects visitors to a competitor's site. May give rise to legal claims but is difficult to prevent after the fact.
Recommended Mitigations
- Defensive domain registration: Register the most likely typo variations of your primary domains before attackers do. Priority targets: common misspellings, missing/doubled characters, and alternative TLDs (.net, .org, .co) for all customer-facing domains. Redirect all registered variants to the legitimate domain.
- UDRP complaint process: The Uniform Domain-Name Dispute-Resolution Policy provides a mechanism to recover domains registered in bad faith to exploit a trademark. Successful complaints can result in domain transfer or cancellation. Trademark registration strengthens UDRP claims.
- Typosquatting monitoring services: Automated services continuously monitor new domain registrations for lookalike domains similar to your monitored brand assets. Early detection enables rapid legal or takedown response before significant traffic is misdirected.
- User awareness — URL verification: Train users to verify the full URL in the address bar before entering credentials. Browser security warnings for known phishing domains provide a secondary signal but are not comprehensive for newly registered typosquatted domains.