Detecting DNS Hijacking: Real-World Attack Patterns

DNS hijacking is not a theoretical risk. It is an active, evolving attack vector used by nation-state actors, organized cybercriminals, and opportunistic threat groups to intercept traffic, steal credentials, distribute malware, and conduct espionage at scale. The attacks documented in this article are not hypothetical scenarios. They are real incidents, sourced from government advisories and threat intelligence reports, that illustrate exactly how DNS infrastructure gets compromised and what automated monitoring could have caught.

This is a technical breakdown of the attack patterns, the indicators of compromise (IOCs) they produce, and the specific detection mechanisms that would flag them.

Attack Pattern 1: Router Level DNS Redirection (APT28 / Forest Blizzard)

In April 2026, the U.S. Department of Justice announced the disruption of a DNS hijacking network operated by Russia's GRU Military Unit 26165, the group tracked as APT28 or Forest Blizzard. Microsoft's threat intelligence team identified over 200 organizations and 5,000 consumer devices impacted by the group's malicious DNS infrastructure.

How the Attack Worked

The attack chain followed a methodical sequence. First, APT28 exploited known vulnerabilities in TP-Link and MikroTik SOHO routers to steal credentials and gain administrative access. Once inside, they modified the router's DHCP DNS server settings, replacing the legitimate upstream DNS resolver with IP addresses pointing to GRU controlled Virtual Private Servers. These malicious VPS nodes operated as rogue DNS resolvers.

The critical detail is what happened next. The rogue resolvers did not redirect all DNS traffic. Instead, they implemented an automated filtering process. Most queries passed through normally to avoid detection. But when a query matched specific domains of interest, particularly those associated with Microsoft Outlook Web Access and other email login pages, the resolver returned a fraudulent A record pointing to an attacker controlled adversary in the middle (AitM) node. This AitM node proxied the real service, presenting a valid looking login page while harvesting unencrypted passwords, authentication tokens, and email content in transit.

According to the UK's National Cyber Security Centre (NCSC), which published its own advisory with indicators of compromise, the campaign ran from at least 2024 into 2026. At its peak in December 2025, Lumen's Black Lotus Labs detected over 18,000 unique IPs from at least 120 countries communicating with APT28's infrastructure.

The DNS Indicators

From a DNS monitoring perspective, this attack produced specific, detectable artifacts. The compromised routers began resolving certain domains to IP addresses that differed from the authoritative DNS records. If you queried outlook.office365.com from a compromised network, the A record returned would not match Microsoft's published infrastructure. The SOA records, NS delegation, and TTL values for the targeted domains would also show inconsistencies compared to baseline checks from uncompromised resolvers.

How DNS Assistant Detects This

DNS Assistant's alert rule system monitors A, AAAA, NS, SOA, MX, TXT, CNAME, and CAA records at configurable intervals. When you create an alert rule for a critical domain like your email provider's login endpoint, the system periodically resolves those records from trusted resolvers and compares the results against the last known baseline stored in dns_checks. If the A record for a monitored domain suddenly resolves to an IP outside the expected range, an alert event fires immediately through your configured notification channels: email, Slack, Teams, webhook, or SMS.

The key architectural advantage is that DNS Assistant resolves from its own infrastructure, not from the potentially compromised local resolver. This means the attack pattern above, where only local DNS is poisoned, would produce a detectable discrepancy: your DNS Assistant alerts would show the correct records while your local network returns fraudulent ones. Any organization running baseline DNS checks from an external monitoring platform would have seen the divergence within minutes.

Attack Pattern 2: Dangling CNAME Exploitation (Hazy Hawk)

In May 2025, Infoblox's threat intelligence team published research on a threat actor dubbed Hazy Hawk that had been hijacking abandoned cloud resources from high profile organizations since at least December 2023. The group gained widespread attention after successfully taking control of subdomains belonging to the U.S. Centers for Disease Control and Prevention (CDC) in February 2025.

How the Attack Worked

Hazy Hawk's methodology targets a specific class of DNS misconfiguration: dangling CNAME records. The attack works like this. An organization provisions a cloud resource, such as an AWS S3 bucket, Azure Web App, or GitHub Pages site, and creates a CNAME record pointing their subdomain to the cloud provider's endpoint (e.g., app.example.gov CNAME example-bucket.s3.amazonaws.com). Later, the organization decommissions the cloud resource but forgets to remove the DNS CNAME record. The record is now "dangling," pointing to a resource that no longer exists.

Hazy Hawk systematically discovers these dangling records, likely using commercial passive DNS services, and then registers the abandoned cloud resource under the original name. Because the CNAME record still exists in the victim's DNS zone, traffic to that subdomain now routes to the attacker's newly claimed resource. The attacker inherits the trust and SEO reputation of the parent domain.

The investigation revealed that Hazy Hawk had compromised subdomains across government agencies globally, prominent universities, and major international corporations including Deloitte, PricewaterhouseCoopers, and Ernst & Young. The hijacked domains were used to host URLs that redirected users through traffic distribution systems (TDSes) to scams, malware, and malicious push notification schemes. Infoblox noted that the hijacking component may be offered as a service within the Russian cybercriminal ecosystem.

The DNS Indicators

Dangling CNAME exploitation produces a clear DNS signature. The CNAME chain resolves successfully (it did not before the attacker claimed the resource), but the content served at the endpoint changes dramatically. From a pure DNS perspective, the indicators are: a CNAME record pointing to a cloud provider endpoint that previously returned NXDOMAIN or SERVFAIL but now resolves to a new IP, and the A record at the end of the CNAME chain changing to infrastructure not associated with the original cloud deployment.

The deeper problem is that the CNAME record itself never changed. It has been sitting in the DNS zone the entire time. The vulnerability is not a DNS record modification; it is the absence of the cloud resource the record points to. This makes it invisible to monitoring systems that only watch for record value changes.

How DNS Assistant Detects This

This is precisely the attack pattern that DNS Assistant's Dangling DNS Detection engine was built for. Unlike standard DNS record monitoring, which watches for changes to record values, the dangling DNS scanner actively probes the CNAME chain to determine whether the target resource is alive, abandoned, or claimable.

The scanner works by resolving each subdomain's CNAME records, following the chain to its terminal endpoint, and then performing HTTP probes against that endpoint. The response is checked against a database of cloud provider fingerprints covering 22+ providers (AWS S3, Azure, GitHub Pages, Heroku, Netlify, Cloudflare, and others). Each fingerprint contains the error page signatures that cloud providers return when a resource does not exist. If the CNAME points to an endpoint that returns one of these "resource not found" signatures, the system flags it as dangling with a CRITICAL severity rating.

When configured as a dangling_dns monitor type alert rule, the system runs these scans on a recurring schedule. It compares each scan against previous results stored in dangling_dns_results, and only generates new alert events when previously unseen dangling records are detected. This differential approach prevents alert fatigue while ensuring new exposures are caught promptly.

In the Hazy Hawk scenario, the CDC's abandoned Azure endpoint would have been flagged the moment the cloud resource was decommissioned but the CNAME record remained. The alert would have fired weeks or months before Hazy Hawk discovered and claimed it.

Attack Pattern 3: State Sponsored DNS Infrastructure Compromise (Sea Turtle)

Sea Turtle, a Turkey aligned APT group tracked since 2017, represents one of the most sophisticated DNS hijacking campaigns ever documented. Dutch security firm Hunt & Hackett reported that the group expanded its operations into the Netherlands between 2021 and 2023, targeting telecommunications companies, media organizations, ISPs, IT service providers, and Kurdish websites.

How the Attack Worked

Unlike APT28's router level approach, Sea Turtle operates at a higher level of the DNS hierarchy. The group's methodology involves compromising DNS registrars and registries directly, allowing them to modify the authoritative NS records for target domains. When they control the NS delegation, they control where all DNS queries for that domain are resolved, enabling man in the middle attacks on a domain's entire traffic flow.

In the Netherlands campaign, Sea Turtle also compromised cPanel hosting accounts via stolen credentials, then used SSH access to deploy a persistent Linux reverse shell called SnappyTCP. The group's goals were political intelligence collection: gathering personal information on minority groups, tracking political dissidents, and exfiltrating email archives. The stolen data was assessed to be used for surveillance aligned with Turkish geopolitical interests.

What makes Sea Turtle particularly dangerous from a DNS perspective is the targeting of the DNS infrastructure itself. By compromising registrars, they can modify NS records for any domain managed by that registrar. This is not a localized attack; it affects every resolver worldwide that queries the compromised domain.

The DNS Indicators

NS record modifications are among the highest severity DNS changes possible. When a domain's NS records change, the entire resolution chain shifts. The indicators include: NS records pointing to unfamiliar nameserver hostnames or IPs, SOA records reflecting a different primary nameserver, TTL values on NS records being shortened (attackers often reduce TTLs to accelerate propagation of their malicious records), and the WHOIS registrar information showing unexpected transfer or modification timestamps.

How DNS Assistant Detects This

DNS Assistant monitors NS records as a first class alert field. When you create an alert rule that includes NS in its monitored record types, the system compares the current NS delegation against the stored baseline on every check cycle. An unexpected NS record change triggers an alert event with the old and new values included in the notification payload.

The WHOIS monitoring layer adds a second detection surface. DNS Assistant's WHOIS engine periodically polls domain registration data and alerts on changes to registrar, nameserver, expiration date, and contact information fields. In the Sea Turtle scenario, the registrar level compromise would produce both an NS record change (detected by DNS monitoring) and a WHOIS modification event (detected by WHOIS monitoring), creating two independent alert signals from a single attack.

The combination of DNS record monitoring and WHOIS change tracking is critical here because it catches both the symptom (NS records changed) and the root cause (registrar account was modified).

Attack Pattern 4: Massive Domain Hijacking via DNS Server Compromise

In 2024, security researchers documented a large scale DNS hijacking incident affecting approximately 70,000 domains. Attackers compromised the DNS servers responsible for managing these domains and altered the DNS records to redirect legitimate traffic to malicious sites. The attack exploited weaknesses in domain management practices and outdated DNS security configurations.

How the Attack Worked

This category of attack targets the authoritative DNS server infrastructure directly. Rather than compromising individual routers (APT28) or exploiting abandoned resources (Hazy Hawk), the attackers gained access to the DNS management plane, the administrative interface where DNS records are created and modified. With this access, they could modify A records, MX records, TXT records, and any other record type for every domain hosted on the compromised server.

The scale of 70,000 domains indicates this was likely a hosting provider or managed DNS service compromise, where a single point of access controls records for thousands of customers. The modified records redirected web traffic to attacker controlled servers that served phishing pages, malware droppers, or credential harvesting forms.

The DNS Indicators

A mass DNS server compromise produces a distinctive pattern: simultaneous record changes across many domains managed by the same provider. Individual domain monitoring would detect the A record change for each affected domain. But the broader signal, many domains changing at once outside of a known maintenance window, is what distinguishes a server compromise from routine administrative activity.

How DNS Assistant Detects This

DNS Assistant's per domain alert rules would catch each individual record change as it happens. When you have alert rules configured across your domain portfolio, a mass DNS server compromise would produce a burst of simultaneous alerts, one for every affected domain with monitoring enabled. This correlated burst is itself a signal: if you receive twenty A record change alerts within the same minute for domains hosted on the same provider, that pattern strongly indicates a server level compromise rather than legitimate administrative changes.

The alert history in DNS Assistant preserves all events with timestamps, old values, new values, and affected record types, giving your incident response team the forensic data they need to scope the compromise, identify which domains were modified, and coordinate remediation with the hosting provider.

Attack Pattern 5: DNS Poisoning for Software Supply Chain Attacks (Evasive Panda)

Evasive Panda (also tracked as Bronze Highland and StormBamboo) is a China linked APT group that has been conducting DNS poisoning campaigns since at least November 2022 to deliver malware through hijacked software update mechanisms. In a documented campaign, the group compromised an internet service provider's DNS infrastructure to intercept update requests for legitimate Chinese software applications like Sogou Pinyin, a popular input method editor.

How the Attack Worked

Evasive Panda's approach is a hybrid of DNS poisoning and supply chain attack. By compromising the ISP's DNS resolver, they intercepted DNS queries for the software vendor's update server domain. Instead of returning the legitimate IP address, the poisoned resolver returned the IP of an attacker controlled server hosting a trojanized update package. When the victim's application checked for updates, it downloaded and installed the malicious payload, believing it came from the legitimate vendor.

This technique is particularly insidious because the software itself performs the DNS query and download without user interaction. There is no phishing email, no malicious link to click. The attack is invisible at the application layer because the DNS resolution, the foundation of the entire transaction, has been silently subverted.

The DNS Indicators

DNS poisoning attacks against software update domains produce a specific indicator: the A record for the update server domain resolves to a different IP address than the one published by the software vendor. Additionally, the TTL on the poisoned response may differ from the authoritative TTL, and the response may lack DNSSEC signatures if the legitimate domain is DNSSEC signed.

How DNS Assistant Detects This

DNS Assistant's monitoring resolves records from its own trusted infrastructure, bypassing any potentially compromised local or ISP level resolvers. If you create alert rules for your critical vendor domains, particularly software update endpoints, the system will detect when the authoritative A record diverges from the expected value.

Additionally, DNS Assistant checks DNSSEC status as part of its standard DNS resolution. If a domain that was previously DNSSEC signed (status: Secure) suddenly returns unsigned responses (status: Insecure), the system captures that state change. A DNSSEC validation failure or status change on a critical domain is a strong indicator of DNS infrastructure tampering.

Detection Principles: What These Patterns Have in Common

Across all five attack patterns, several consistent detection principles emerge.

Baseline comparison is fundamental. Every attack produced a change from the known good state of DNS records. Whether it was an A record pointing to a new IP, an NS record delegating to an unfamiliar nameserver, or a CNAME chain that suddenly started resolving after being dormant, the common thread is deviation from baseline. DNS Assistant's architecture is built around this principle: every check is compared against the last known state stored in the database, and deviations generate alert events.

External resolution is essential. APT28's attack only affected queries from compromised local resolvers. Evasive Panda's attack only affected queries from the compromised ISP. In both cases, resolving the same domain from an independent, trusted resolver would have returned the correct answer. DNS monitoring that resolves from your own network is vulnerable to the same poisoning it is trying to detect. Monitoring must happen from external infrastructure.

Multi-layer monitoring catches what single-layer misses. Sea Turtle's registrar level compromise produced both DNS record changes and WHOIS modifications. Hazy Hawk's dangling CNAME exploitation produced no record change at all; only active probing of the CNAME chain's target could detect it. No single monitoring technique catches every attack pattern. The combination of DNS record monitoring, WHOIS tracking, dangling DNS scanning, and TLS certificate validation creates overlapping detection surfaces where each layer covers the blind spots of the others.

Speed of detection determines impact. APT28's campaign ran for over a year before disruption. Hazy Hawk operated for over a year before the CDC subdomains were noticed. Sea Turtle's Netherlands campaign persisted for two years. In every case, automated monitoring with alerting would have reduced the detection window from months or years to minutes. The difference between a months long credential harvesting operation and a contained incident that lasted minutes comes down to whether someone, or something, was watching the DNS records.

Building Your Detection Posture

Based on these real world attack patterns, a technical DNS monitoring posture should cover the following at minimum.

Monitor A and AAAA records on every domain that handles authentication, email, or customer facing traffic. These are the records that get modified in credential harvesting and traffic redirection attacks.

Monitor NS records on every domain you own. NS changes represent the highest severity DNS modification because they shift the entire resolution chain. Alert on any NS change outside of planned maintenance.

Monitor MX and TXT records on email sending domains. MX record hijacking redirects inbound email. TXT record modifications can weaken SPF, DKIM, and DMARC policies, enabling email spoofing that appears to originate from your domain.

Run dangling DNS scans on domains with CNAME records pointing to cloud provider endpoints. This is the only way to detect the Hazy Hawk class of attack, where the DNS record itself never changes but the underlying resource becomes claimable.

Enable WHOIS monitoring for registrar changes, nameserver updates, and expiration date modifications. This catches registrar level compromises and provides an independent detection signal alongside DNS record monitoring.

Check DNSSEC status as part of regular DNS resolution. A domain that transitions from DNSSEC signed to unsigned without a planned change is a strong indicator of DNS infrastructure compromise.

DNS hijacking is not getting simpler. It is getting more sophisticated, more targeted, and more consequential. The attackers documented in this article include Russian military intelligence, Turkey's state backed espionage apparatus, China linked APT groups, and organized cybercriminal operations. They are investing significant resources into DNS as an attack vector because it works, and because most organizations still do not monitor it with the same rigor they apply to endpoints and applications.

The technical capability to detect every attack pattern described above exists today. The question is whether your organization has deployed it.