Example 1 · DNS Server Modification — The IP Spoofing Scenario
This is the canonical example from the course material, using a hypothetical network to illustrate DNS server compromise.
The setup:
- Attacker machine: IP address 100.100.100.100
- DNS server: IP address 162.159.246.164
- Target domain: professormesser.com (legitimate IP ends in .164)
- Two users: User 1 (already queried DNS), User 2 (about to query)
Before the attack: User 1 queries the DNS server for professormesser.com. The server has the correct record (ending in .164). The server responds with the real IP. User 1 caches this result and successfully visits the real website.
The attack: The attacker, having obtained admin credentials or exploited a vulnerability in the DNS server, logs in and modifies the A record for professormesser.com. The new IP address is now 100.100.100.100 — the attacker's own machine.
After the attack: User 2 queries the same DNS server for professormesser.com. The server now responds with 100.100.100.100. User 2's browser connects to the attacker's machine instead of the real website. The attacker can serve a phishing page, proxy the real site while logging credentials, or deliver malware.
Key insight: User 1 is unaffected (cached correct answer). User 2 — and every subsequent user — is redirected. The attack's scope is every user who queries that DNS server after the record is changed. No modification to user devices is required.
Example 2 · Brazilian Bank Domain Hijacking — October 22, 2016
One of the most comprehensive domain hijacking attacks ever documented, this incident is a core case study for the Security+ exam.
Target: A major Brazilian bank with over 5 million customers and approximately $27 billion in assets.
Date and duration: Saturday, October 22, 2016, beginning at approximately 1:00 PM. Attackers maintained control for approximately six hours.
Scope: 36 domains were modified in the bank's domain registration account. This covered desktop banking sites, mobile banking apps, and related services — effectively every customer-facing digital channel.
Method: Attackers gained access to the bank's domain registrar account. The exact method was not publicly disclosed by the bank, but standard vectors include: brute force against the registrar login portal, compromising the email account linked to the registration (enabling password reset), social engineering registrar support staff, or using credentials obtained in a prior breach.
What the attackers did: Modified DNS records for all 36 domains to point to attacker-controlled servers. These servers hosted exact replicas of all the bank's websites and apps. Attackers also modified MX records to intercept bank email.
What happened to customers: For six hours, any customer who visited any of the bank's digital properties — regardless of their device, browser, or location — was connecting to attacker infrastructure. The sites looked identical. SSL certificates were even present (attackers obtained certificates for the domains they now controlled). Customers entered usernames, passwords, one-time codes, and account information. All of it was captured.
No bank server was touched. No bank employee's credentials were compromised. No malware was installed on bank infrastructure. The entire attack operated at the domain registration layer — one level above the bank's own systems.
The lesson: Controlling the domain name is equivalent to controlling the service. The bank's hardened servers, firewalls, intrusion detection systems, and security operations center were all rendered irrelevant by one compromised registrar account. MFA on the registrar account would have required a second factor beyond the stolen password, likely preventing or severely limiting the attack.
Example 3 · Typosquatting Variations on a Real Domain
Illustrating the four typosquatting techniques using a real-world domain as the example.
Legitimate domain: professormesser.com
| Technique | Typosquatted Domain | What Changed |
|---|---|---|
| Outright misspelling | professormessor.com | Final 'e' in "messer" changed to 'o' — looks nearly identical at a glance |
| Missing character (typing error) | professormeser.com | One 's' dropped from "messer" — easy to miss when reading quickly |
| Added character (different phrase) | professormessers.com | Extra 's' appended — the plural form looks plausible |
| Different TLD | professormesser.org | Same name, '.org' instead of '.com' — common assumption error |
How attackers monetize these: A user who types "professormessors.com" by mistake and lands on an ad-heavy page generates click revenue. If the typosquatted site installs malware via drive-by download, that visitor becomes another compromised device. If the site serves a fake login page, credentials are harvested. The attacker may simultaneously register all four variations, each serving a different malicious or revenue-generating purpose.
Legitimate owner's options: File a UDRP (Uniform Domain-Name Dispute-Resolution Policy) complaint if the domain was registered in bad faith. Pre-emptively register obvious typos before attackers do. Use trademark law if applicable. Monitor for new registrations that resemble the brand name.
Exam Scenario 1 · Identifying the DNS Attack Type
Scenario: A security analyst receives reports that employees at two specific workstations are being redirected to a fake version of the company's internal HR portal when they type the portal's URL. Other workstations on the same network are unaffected and resolve the URL correctly. The DNS server logs show no anomalous queries or responses for the affected time period.
Question: What type of DNS attack is most likely responsible?
Analysis: The attack is isolated to two specific workstations — not the entire network or the DNS server. The DNS server logs are clean. This rules out DNS server modification (would affect all users) and on-path attack (would affect network-level traffic, not just two endpoints).
Answer: Host file modification. Malware on those two workstations has modified the local host file to redirect the HR portal's domain to a fake IP. The host file is consulted before DNS, so the DNS server is never queried for these workstations — explaining why DNS logs show nothing. The attack scope matches the host file vector: local to each affected machine.
Exam Scenario 2 · Domain Hijacking vs. DNS Server Compromise
Scenario: A company's entire website traffic has been redirected to an attacker-controlled server for four hours. Investigation shows the company's web servers, firewalls, and internal DNS servers are all uncompromised. However, the company's domain registrar received a support call earlier that day requesting password assistance for the domain account, and the password was reset via phone — without proper verification.
Question: What type of attack occurred, and what is the primary control failure?
Answer: Domain hijacking. The attacker social-engineered the domain registrar's support staff to reset the account password without proper identity verification. Once the password was reset, the attacker changed DNS records for the domain, redirecting all traffic. The primary control failure was the absence of strong identity verification on the part of the registrar's support process, combined with the company's lack of MFA on the registrar account — which would have made a password reset alone insufficient to log in and change records.
Key distinction from DNS server attack: The company's own DNS servers were never touched. The attack operated entirely at the registrar layer — an external service provider — which is why internal security monitoring showed no anomalies.
Exam Scenario 3 · Classifying a URL Hijacking Incident
Scenario: A bank's fraud team notices a spike in customer complaints about unauthorized transactions. Investigation reveals that customers with recent transactions had visited "bankofwestern.net" — the bank's legitimate domain is "bankofwestern.com". The ".net" domain was registered six months ago and hosts a pixel-perfect replica of the bank's login page.
Question: What type of attack is this, and what is the attacker's likely goal?
Answer: Typosquatting / URL hijacking using an alternative TLD (.net instead of .com). The attacker registered a plausible alternative TLD variation of the bank's domain and deployed a phishing page. Customers who type ".net" instead of ".com" — or who follow a link that uses the .net version — are presented with a convincing fake login page that harvests credentials. The attacker's goal is credential theft to enable unauthorized financial transactions, which is consistent with the fraud reports.
Defense recommendation: The bank should file a UDRP complaint for the .net domain if registered in bad faith, preemptively register .net and other common TLDs for their brand, and add user awareness training about verifying the exact domain before entering credentials.