Trick 1: "DNS poisoning most commonly works by compromising the DNS server directly, since that method affects the most users." True or False?
FALSE — DNS servers are well-protected, making direct server compromise the least common of the three DNS poisoning vectors, not the most common.
This trick plays on the intuition that "more impact = more common." It sounds logical: if you want to poison DNS for many users, attack the server. But the security course specifically notes that DNS servers are very well-protected, which is precisely why attackers more often use the other two vectors.
Why DNS server modification is rare:
Compromising a DNS server requires either obtaining admin credentials through brute force or social engineering, or exploiting a known vulnerability in the DNS software — both of which require significant skill and are increasingly difficult against hardened infrastructure. Modern DNS servers run minimal services, are network-segmented, and often have MFA on administrative access.
Why host file and on-path attacks are more accessible:
Modifying the host file requires only malware with elevated privileges on the target device — achievable through a phishing email or drive-by download. On-path attacks require network positioning — achievable on public Wi-Fi, within a compromised network segment, or through ARP poisoning. Both are significantly lower barriers to entry than compromising a DNS server.
Exam tip: When the course says "requires some crafty hacking," it is signaling that DNS server modification is the hardest and least common vector. Don't let "most impact" become "most common" in your thinking. The exam may present all three vectors and ask which is least likely to be used — the answer is direct server compromise.
This trick plays on the intuition that "more impact = more common." It sounds logical: if you want to poison DNS for many users, attack the server. But the security course specifically notes that DNS servers are very well-protected, which is precisely why attackers more often use the other two vectors.
Why DNS server modification is rare:
Compromising a DNS server requires either obtaining admin credentials through brute force or social engineering, or exploiting a known vulnerability in the DNS software — both of which require significant skill and are increasingly difficult against hardened infrastructure. Modern DNS servers run minimal services, are network-segmented, and often have MFA on administrative access.
Why host file and on-path attacks are more accessible:
Modifying the host file requires only malware with elevated privileges on the target device — achievable through a phishing email or drive-by download. On-path attacks require network positioning — achievable on public Wi-Fi, within a compromised network segment, or through ARP poisoning. Both are significantly lower barriers to entry than compromising a DNS server.
Exam tip: When the course says "requires some crafty hacking," it is signaling that DNS server modification is the hardest and least common vector. Don't let "most impact" become "most common" in your thinking. The exam may present all three vectors and ask which is least likely to be used — the answer is direct server compromise.
Trick 2: "Domain hijacking requires the attacker to gain access to the victim organization's web servers or network infrastructure to redirect traffic." True or False?
FALSE — domain hijacking requires only the domain registrar account. The victim's web servers, firewalls, and internal network are entirely irrelevant.
This is the most important concept in domain hijacking and the fact that distinguishes it from DNS server poisoning. In a domain hijacking attack, the attacker never touches the victim's infrastructure at all.
Why the registrar account is the only target:
The registrar is the authoritative source for where a domain's DNS points. When the registrar's records say "professormesser.com = 100.100.100.100," every DNS server on the internet that looks up that domain will receive that answer and cache it. The victim's own DNS servers are bypassed entirely — they are downstream of the registrar, not upstream.
The Brazil bank case study makes this concrete:
The bank had hardened servers, firewalls, DDoS protection, intrusion detection, and a security operations center — all completely useless because the attack didn't involve the bank's infrastructure. The bank's perimeter was never breached. The attack occurred at the registrar — an external third-party service — and redirected all customer traffic to attacker infrastructure for six hours.
Exam tip: When a question describes traffic being redirected "without any compromise of the victim's servers," domain hijacking is the correct classification. The phrase "you don't need to touch the actual servers" is from the course material — that is the exam's way of signaling domain hijacking.
This is the most important concept in domain hijacking and the fact that distinguishes it from DNS server poisoning. In a domain hijacking attack, the attacker never touches the victim's infrastructure at all.
Why the registrar account is the only target:
The registrar is the authoritative source for where a domain's DNS points. When the registrar's records say "professormesser.com = 100.100.100.100," every DNS server on the internet that looks up that domain will receive that answer and cache it. The victim's own DNS servers are bypassed entirely — they are downstream of the registrar, not upstream.
The Brazil bank case study makes this concrete:
The bank had hardened servers, firewalls, DDoS protection, intrusion detection, and a security operations center — all completely useless because the attack didn't involve the bank's infrastructure. The bank's perimeter was never breached. The attack occurred at the registrar — an external third-party service — and redirected all customer traffic to attacker infrastructure for six hours.
Exam tip: When a question describes traffic being redirected "without any compromise of the victim's servers," domain hijacking is the correct classification. The phrase "you don't need to touch the actual servers" is from the course material — that is the exam's way of signaling domain hijacking.
Trick 3: "Implementing DNSSEC completely prevents DNS poisoning attacks." True or False?
FALSE — DNSSEC prevents only one of the three DNS poisoning vectors (forged DNS responses via on-path attacks) and provides no protection against host file modification, direct DNS server compromise, domain hijacking, or typosquatting.
This is a classic "one technology = complete protection" misconception. DNSSEC is a valuable control but it is not a DNS security silver bullet.
What DNSSEC specifically does:
DNSSEC attaches cryptographic signatures to DNS records. A validating resolver verifies the signature before accepting the response. If an on-path attacker injects a forged DNS response, that response will lack a valid signature and will be rejected. This is the attack it was designed to prevent.
What DNSSEC does NOT address:
(1) Host file modification — the host file is checked before DNS; DNSSEC applies to DNS responses, which are never sent when the host file has an answer. The entire DNS query path is bypassed. (2) Direct DNS server compromise — if the attacker controls the DNS server, they also control the private signing key used to create DNSSEC signatures. They can sign fraudulent records with the legitimate key. DNSSEC validates "this was signed by the key for this zone," not "this server was not compromised." (3) Domain hijacking — the attacker controls the domain at the registrar and can re-sign records at will. DNSSEC gives them no obstacle. (4) Typosquatting — the attacker owns a legitimately registered domain. DNSSEC correctly validates responses for that domain because it is a real domain with a real signing key.
Exam tip: DNSSEC = validate DNS responses. The moment the question describes an attack that bypasses DNS responses (host file), controls the zone signing key (server compromise or domain hijacking), or uses a legitimately owned domain (typosquatting), DNSSEC is not the answer. The correct defense for each: host file → endpoint protection; domain hijacking → MFA on registrar; typosquatting → preemptive registration and user awareness.
This is a classic "one technology = complete protection" misconception. DNSSEC is a valuable control but it is not a DNS security silver bullet.
What DNSSEC specifically does:
DNSSEC attaches cryptographic signatures to DNS records. A validating resolver verifies the signature before accepting the response. If an on-path attacker injects a forged DNS response, that response will lack a valid signature and will be rejected. This is the attack it was designed to prevent.
What DNSSEC does NOT address:
(1) Host file modification — the host file is checked before DNS; DNSSEC applies to DNS responses, which are never sent when the host file has an answer. The entire DNS query path is bypassed. (2) Direct DNS server compromise — if the attacker controls the DNS server, they also control the private signing key used to create DNSSEC signatures. They can sign fraudulent records with the legitimate key. DNSSEC validates "this was signed by the key for this zone," not "this server was not compromised." (3) Domain hijacking — the attacker controls the domain at the registrar and can re-sign records at will. DNSSEC gives them no obstacle. (4) Typosquatting — the attacker owns a legitimately registered domain. DNSSEC correctly validates responses for that domain because it is a real domain with a real signing key.
Exam tip: DNSSEC = validate DNS responses. The moment the question describes an attack that bypasses DNS responses (host file), controls the zone signing key (server compromise or domain hijacking), or uses a legitimately owned domain (typosquatting), DNSSEC is not the answer. The correct defense for each: host file → endpoint protection; domain hijacking → MFA on registrar; typosquatting → preemptive registration and user awareness.
Trick 4: "An attacker performing DNS poisoning always leaves visible traces in DNS server logs, making detection straightforward." True or False?
FALSE — two of the three DNS poisoning vectors leave no trace in DNS server logs, making detection significantly harder than this statement implies.
DNS server logs record queries and responses processed by the DNS server. But two attack vectors don't involve the DNS server at all.
Host file modification — invisible to DNS logs:
When an entry exists in the host file, the operating system resolves the name locally and never sends a DNS query. The DNS server receives no query, generates no response, and creates no log entry. A victim whose host file maps bankofamerica.com to an attacker IP will never query the DNS server for bankofamerica.com again — and the DNS server will record nothing unusual.
On-path attack — DNS server appears normal:
The attacker intercepts the query in transit and responds before the real server. The DNS server may receive the original query (and generate a log entry showing it responded correctly), but the attacker's forged response arrives at the client first. The server logs look completely clean — it processed the request and sent the legitimate answer. What the logs don't show is that a faster, forged response was also sent by the attacker and arrived first.
Direct DNS server modification — leaves traces:
This is the one vector that does leave traces in DNS server logs (record changes, admin login events). This is partly why it's harder — more forensic evidence remains. The attacker would need to clean up logs as well.
Exam tip: "Clean DNS logs" as an investigative finding helps narrow the attack type: it strongly suggests either host file modification (check the local hosts file on affected systems) or an on-path attack (analyze network captures for racing UDP responses), not direct server compromise.
DNS server logs record queries and responses processed by the DNS server. But two attack vectors don't involve the DNS server at all.
Host file modification — invisible to DNS logs:
When an entry exists in the host file, the operating system resolves the name locally and never sends a DNS query. The DNS server receives no query, generates no response, and creates no log entry. A victim whose host file maps bankofamerica.com to an attacker IP will never query the DNS server for bankofamerica.com again — and the DNS server will record nothing unusual.
On-path attack — DNS server appears normal:
The attacker intercepts the query in transit and responds before the real server. The DNS server may receive the original query (and generate a log entry showing it responded correctly), but the attacker's forged response arrives at the client first. The server logs look completely clean — it processed the request and sent the legitimate answer. What the logs don't show is that a faster, forged response was also sent by the attacker and arrived first.
Direct DNS server modification — leaves traces:
This is the one vector that does leave traces in DNS server logs (record changes, admin login events). This is partly why it's harder — more forensic evidence remains. The attacker would need to clean up logs as well.
Exam tip: "Clean DNS logs" as an investigative finding helps narrow the attack type: it strongly suggests either host file modification (check the local hosts file on affected systems) or an on-path attack (analyze network captures for racing UDP responses), not direct server compromise.
Performance Task: You are on-call at a managed security provider. At 11:45 PM on a Saturday, you receive an automated alert: DNS records for three domains belonging to a financial services client have changed in the last 15 minutes. The client's primary banking site, mobile API, and password reset service are all pointing to unknown IP addresses. A secondary alert indicates the client's SSL certificate is no longer resolving correctly on the new IP. Your investigation confirms the client's web servers, internal DNS, and network perimeter are all uncompromised. Describe your immediate response actions, your investigation to confirm the attack type, your steps to restore service, and the long-term controls you recommend to prevent recurrence.
Model Answer:
Immediate Response (First 15 minutes):
(1) Confirm the attack type is domain hijacking. DNS records changed without any compromise of the client's own infrastructure — the registrar account is the attack surface. Verify by querying the current authoritative nameservers for the affected domains and comparing against the known legitimate nameservers. If the nameservers themselves have changed (NS records), the registrar account has been fully taken over. (2) Contact the client's incident response team immediately. This is a P0 event — a financial services client is actively redirecting customers to attacker infrastructure. Every minute of delay means additional credentials captured. (3) Contact the domain registrar's emergency support line. All major registrars have 24/7 emergency contact for domain hijacking. Provide the account details and request an emergency lock on the domain and immediate record revert. Request them to disable any further changes until identity is re-verified. (4) Issue a public-facing statement if the client has a status page. Warn customers not to log into any banking services until further notice. A brief clear warning prevents ongoing credential harvesting.
Investigation — Confirm and Document:
(1) Capture the attacker's IP addresses from the current DNS records before any revert. These are evidence and may be useful for threat intelligence and law enforcement. (2) Check what else changed: were MX records also modified? If so, the attacker may be intercepting email as well — potentially including password reset emails, regulatory notifications, and customer service messages. (3) Determine the entry method: review the registrar account's access logs for the time of the change — what IP address made the modifications? Was a password reset initiated earlier in the day? Review the email account linked to the domain registration for suspicious login activity. (4) Estimate exposure window: determine the TTL (Time to Live) on the affected DNS records. If TTL was 300 seconds (5 minutes), the attacker's IP was being served globally within 5 minutes of the change. If TTL was 86400 (24 hours), many users' DNS caches still have the legitimate IP — but any user who queried after the change received the malicious IP. (5) Document everything for the incident report, regulatory notification assessment (financial institutions may have breach notification obligations), and law enforcement referral.
Service Restoration:
(1) Get registrar account access restored. If the attacker changed the account password, work with the registrar to re-verify identity and restore access. Once authenticated, immediately change the password to a strong new credential and enable MFA if not already done. (2) Restore DNS records to legitimate values. Revert all changed DNS records to the known-good IPs. Also verify nameserver (NS) records if those were changed. (3) Lower TTL temporarily during transition (e.g., to 60 seconds) so that the corrected records propagate quickly across caches worldwide. Restore TTL to a normal value once propagation confirms clean. (4) Verify SSL/TLS is working correctly. If the attacker obtained their own certificate for the domain during the hijack window (which is possible via Let's Encrypt), those certificates remain valid until expired — check certificate transparency logs (crt.sh) for any certificates issued for client domains that the client did not request. (5) Monitor DNS records continuously for the next 72 hours for any secondary changes.
Long-Term Controls (Prevent Recurrence):
(1) Enable MFA on the domain registrar account. This is the single highest-impact change. A stolen password cannot be used to change DNS records if a second factor is required at login. (2) Enable MFA on the email account associated with the domain registration. Registrars allow password resets via email. MFA on the associated inbox closes this secondary path. (3) Enable domain lock / registrar-lock. Most registrars offer a "registry lock" service that requires out-of-band authentication (phone call, in-person verification) before any DNS change is processed. This applies a second layer of friction beyond MFA on the web portal. (4) Set up DNS change monitoring with real-time alerts. The attack was discovered by automated monitoring — that monitoring saved time. Ensure alerts are configured for any change to A records, NS records, MX records, and registrar account login events, with <15 minute detection time targets. (5) Reduce TTL on critical records during normal operations. A 300-second TTL means a hijacking event propagates in 5 minutes but is also corrected in 5 minutes after restoration. A 24-hour TTL means the hijacked records linger in DNS caches worldwide for 24 hours after restoration. For financial services clients, shorter TTLs (300–900 seconds) on critical records are worth the minor increase in DNS query volume. (6) Register common TLD variants and typosquats. While this incident was domain hijacking, not typosquatting, the post-incident review is a good moment to audit all domain registrations and register defensive variations.
Immediate Response (First 15 minutes):
(1) Confirm the attack type is domain hijacking. DNS records changed without any compromise of the client's own infrastructure — the registrar account is the attack surface. Verify by querying the current authoritative nameservers for the affected domains and comparing against the known legitimate nameservers. If the nameservers themselves have changed (NS records), the registrar account has been fully taken over. (2) Contact the client's incident response team immediately. This is a P0 event — a financial services client is actively redirecting customers to attacker infrastructure. Every minute of delay means additional credentials captured. (3) Contact the domain registrar's emergency support line. All major registrars have 24/7 emergency contact for domain hijacking. Provide the account details and request an emergency lock on the domain and immediate record revert. Request them to disable any further changes until identity is re-verified. (4) Issue a public-facing statement if the client has a status page. Warn customers not to log into any banking services until further notice. A brief clear warning prevents ongoing credential harvesting.
Investigation — Confirm and Document:
(1) Capture the attacker's IP addresses from the current DNS records before any revert. These are evidence and may be useful for threat intelligence and law enforcement. (2) Check what else changed: were MX records also modified? If so, the attacker may be intercepting email as well — potentially including password reset emails, regulatory notifications, and customer service messages. (3) Determine the entry method: review the registrar account's access logs for the time of the change — what IP address made the modifications? Was a password reset initiated earlier in the day? Review the email account linked to the domain registration for suspicious login activity. (4) Estimate exposure window: determine the TTL (Time to Live) on the affected DNS records. If TTL was 300 seconds (5 minutes), the attacker's IP was being served globally within 5 minutes of the change. If TTL was 86400 (24 hours), many users' DNS caches still have the legitimate IP — but any user who queried after the change received the malicious IP. (5) Document everything for the incident report, regulatory notification assessment (financial institutions may have breach notification obligations), and law enforcement referral.
Service Restoration:
(1) Get registrar account access restored. If the attacker changed the account password, work with the registrar to re-verify identity and restore access. Once authenticated, immediately change the password to a strong new credential and enable MFA if not already done. (2) Restore DNS records to legitimate values. Revert all changed DNS records to the known-good IPs. Also verify nameserver (NS) records if those were changed. (3) Lower TTL temporarily during transition (e.g., to 60 seconds) so that the corrected records propagate quickly across caches worldwide. Restore TTL to a normal value once propagation confirms clean. (4) Verify SSL/TLS is working correctly. If the attacker obtained their own certificate for the domain during the hijack window (which is possible via Let's Encrypt), those certificates remain valid until expired — check certificate transparency logs (crt.sh) for any certificates issued for client domains that the client did not request. (5) Monitor DNS records continuously for the next 72 hours for any secondary changes.
Long-Term Controls (Prevent Recurrence):
(1) Enable MFA on the domain registrar account. This is the single highest-impact change. A stolen password cannot be used to change DNS records if a second factor is required at login. (2) Enable MFA on the email account associated with the domain registration. Registrars allow password resets via email. MFA on the associated inbox closes this secondary path. (3) Enable domain lock / registrar-lock. Most registrars offer a "registry lock" service that requires out-of-band authentication (phone call, in-person verification) before any DNS change is processed. This applies a second layer of friction beyond MFA on the web portal. (4) Set up DNS change monitoring with real-time alerts. The attack was discovered by automated monitoring — that monitoring saved time. Ensure alerts are configured for any change to A records, NS records, MX records, and registrar account login events, with <15 minute detection time targets. (5) Reduce TTL on critical records during normal operations. A 300-second TTL means a hijacking event propagates in 5 minutes but is also corrected in 5 minutes after restoration. A 24-hour TTL means the hijacked records linger in DNS caches worldwide for 24 hours after restoration. For financial services clients, shorter TTLs (300–900 seconds) on critical records are worth the minor increase in DNS query volume. (6) Register common TLD variants and typosquats. While this incident was domain hijacking, not typosquatting, the post-incident review is a good moment to audit all domain registrations and register defensive variations.