Originally published at https://monstadomains.com/blog/dangling-dns-hijacking/
The CDC, MIT, Harvard, Stanford, and more than 30 other universities did not get breached in any traditional sense. No zero-day was exploited. No phishing email compromised an admin account. A financially motivated threat group called Hazy Hawk simply used dangling DNS hijacking to silently claim subdomains those organizations had forgotten they still owned. Users searching for legitimate content found CDC links in Google results that routed them to scareware. Students clicking .edu domain links landed on explicit material – all served from university subdomains the institutions had no idea were still active.
How Hazy Hawk Turned the CDC and 34 Universities Into Malware Hosts
Infoblox, a DNS security intelligence firm, first detected Hazy Hawk in February 2025 after discovering malicious content being served under CDC subdomains. The group’s campaign had actually started as far back as December 2023. Infoblox published their full threat intelligence report in May 2025, documenting how Hazy Hawk operated on a repeating cycle: locate a dangling DNS hijacking opportunity, claim the abandoned cloud resource, flood the subdomain with malicious content, then release it and move on to the next target. The CDC was just the first major institution to be publicly documented.
The story might have remained a footnote in threat intelligence reports if not for DNS security researcher Alex Shakhov of SH Consulting. In April 2026, while conducting routine DNS security audits for US and Canadian clients, Shakhov discovered that Hazy Hawk’s dangling DNS hijacking campaign had swept through at least 34 universities. The list included MIT, Harvard, Stanford, UC Berkeley, Columbia, Johns Hopkins, Washington University in St. Louis, University College London, and more. On April 30, 2026, the University of Washington’s student newspaper confirmed that UW subdomains were appearing in hundreds of Google search results serving pornographic content.
The Dangling DNS Hijacking Method Hazy Hawk Used
Dangling DNS hijacking exploits a gap between DNS management and infrastructure decommissioning. Organizations routinely alias subdomains to third-party cloud services using CNAME records – a record type that points one hostname to another. A CNAME might point blog.example.edu to a Netlify deployment, or cdn.example.gov to an AWS S3 bucket. When that cloud resource is shut down, engineers decommission the Netlify site or delete the S3 bucket. What they frequently fail to do is remove the DNS record that still points to it.
When a CNAME Points to a Resource That No Longer Exists
Once the cloud resource is gone but the DNS record remains, the result is a dangling DNS hijacking vulnerability sitting exposed in the organization’s zone file. The CNAME still resolves – it points to a cloud endpoint that no longer belongs to anyone. Hazy Hawk monitors passive DNS data to identify exactly these orphaned records. They then create a new account with the cloud provider using the same endpoint name. DNS resolution picks up immediately. The organization loses control of their own subdomain without any alert or notification from anyone.
The success of dangling DNS hijacking as an attack method depends entirely on this invisibility. The CNAME record sits exactly where the organization’s DNS team placed it, months or years earlier. Nothing looks broken from the outside. DNS queries resolve. SSL certificates can even be issued against hijacked subdomains. The only visible sign something is wrong is the content being served – which Hazy Hawk fills with scam pages, malware download links, and in the universities’ case, explicit content optimized to rank in Google under high-authority .edu domain names.
Shakhov’s Discovery and What the University of Washington Confirmed
Shakhov published his findings on the SH Consulting blog in April 2026, detailing how his dangling DNS hijacking discovery revealed university subdomains generating Google search impressions on pornographic keywords, with the university domain names appearing in results alongside content that violated every institutional policy imaginable. The subdomains were being served from records those universities did not know were still active. The University of Washington acknowledged the issue after The Daily – UW’s student newspaper – broke the story on April 30. Responses from other affected institutions were slower and more fragmented.
What made the campaign particularly difficult to detect is also what makes dangling DNS hijacking so effective as an attack strategy: the parent domain’s trust transfers entirely to the compromised subdomain. Google treats a subdomain of harvard.edu with the same domain authority as harvard.edu itself. Hazy Hawk was not trying to break into anyone’s systems – they were harvesting the SEO equity that legitimate institutions had built over decades, using it to serve content that no search engine would otherwise rank.
The Cloud Platform Gap That Makes This Attack Possible
The Services Hazy Hawk Most Commonly Targeted
Hazy Hawk focused on the cloud services that almost every major institution relies on: AWS Elastic Beanstalk, AWS S3, Azure Web Apps, GitHub Pages, Netlify, Bunny CDN, and Akamai. Researchers found approximately 9,000 dangling CNAME records pointing to elasticbeanstalk.com alone in the public DNS dataset. These are enterprise platforms used by universities, government agencies, and large corporations – which is what made them the ideal target surface for dangling DNS hijacking operations. The more widely adopted the platform, the larger the pool of forgotten records pointing to it.
The attack requires no compromise of the cloud providers themselves. Hazy Hawk simply needs to create a free or low-cost account and claim the resource name that the DNS record still points to. AWS S3 uses bucket names that map directly to domain naming conventions. If a university decommissioned a bucket named cdn.university.edu without removing the corresponding CNAME, that bucket name sits open for anyone to register. The entire operation costs almost nothing to execute at scale – which is exactly why dangling DNS hijacking is such an attractive low-effort, high-yield attack model.
317,000 Dangling Domains and the True Scale of the Problem
The Hazy Hawk campaign is not an isolated incident. It is a symptom of an industry-wide DNS hygiene failure. A Palo Alto Networks Unit 42 study detected 317,000 unsafe dangling records in passive DNS data. A longitudinal study covering 2020 to 2023 across 12 major cloud platforms identified 20,904 confirmed hijacks actively hosting malicious content. Security firm Certitude placed the number of organizations with at least one vulnerable subdomain at over 1,000 – almost certainly an undercount given the scale of what Shakhov found at universities alone.
The dangling DNS hijacking problem has been documented in security research for years. A 2021 USENIX paper on same-site attacks detailed the mechanics of subdomain takeover in depth. OWASP includes it as a recognized category in their web security testing guide. The difference in 2026 is that groups like Hazy Hawk have fully automated the discovery process, converting what was once an opportunistic one-off attack into a profitable, repeating operation. Infoblox documented over 13,000 malicious subdomains generated by Hazy Hawk during active operations – each one leveraging a domain whose real owner had long forgotten it existed.
Scareware, Porn and Phishing Served Under .edu and .gov Addresses
Hazy Hawk’s business model runs on volume. Once they control a subdomain through dangling DNS hijacking, they generate hundreds of URLs from that single domain and route traffic through content networks that monetize via affiliate fraud, scareware popups, and adult ad networks. Content indexed under the CDC’s subdomain included pages designed to trigger fake antivirus popup warnings. Under university subdomains, the content was pornographic – indexed under .edu domain names that surfaced in Google for entirely unrelated search queries.
Users had no visible reason to be suspicious. A URL displaying a .gov or .edu hostname carries an implicit trust signal that most people will not question. The group cycles through targets rapidly – claim a dangling record, monetize the subdomain, release it, move on. By the time institutional IT teams or security researchers flag the issue, Hazy Hawk has already moved to the next target on their passive DNS watchlist. Infoblox documented the group generating more than 13,000 malicious subdomains from trusted parent domains – a direct consequence of dangling DNS hijacking left unchecked across institutional infrastructure.
Why Dangling DNS Hijacking Is Surging in 2026
The root cause of the dangling DNS hijacking surge is the operational mismatch between how quickly organizations adopt cloud services and how poorly they manage decommissioning. Cloud-native infrastructure means engineering teams spin up services constantly – testing a new CDN, running a short campaign on Netlify, standing up a temporary AWS endpoint for a feature launch. Each deployment often gets its own subdomain. Most organizations have no centralized process for tracking which DNS records correspond to active cloud resources and which have been abandoned.
When a cloud service is shut down, the team that decommissioned it typically has no access to or responsibility for DNS management. The DNS team, in turn, is rarely notified when cloud resources are retired. The record persists in the zone file indefinitely. Hazy Hawk’s dangling DNS hijacking scanning operation is designed to find exactly those workflow gaps. The larger and older the institution, the more abandoned records they accumulate – which explains why universities and government agencies are consistently the most exposed targets.
The shift to multi-cloud and serverless architectures has made the problem exponentially harder to audit. Organizations accumulate hundreds or thousands of subdomains over years of operation. Many are not actively maintained by anyone currently employed at the organization. Dangling DNS hijacking thrives in institutional environments precisely because no single person maintains full visibility into the DNS namespace – and no single team owns the intersection of cloud resource management and DNS hygiene at the same time.
What to Check After the Hazy Hawk Report
The Hazy Hawk research makes one practical point undeniable: every CNAME record in your zone file is a potential dangling DNS hijacking vector the moment the service it references is decommissioned without removing the corresponding record. For organizations and individuals running websites on subdomains – which covers most domain owners operating online – the immediate step is auditing every CNAME and verifying the cloud resource it points to still exists and remains under your control.
Running a DNS Record Audit After This Discovery
Pull a complete list of your DNS records, focusing on CNAMEs pointing to cloud service endpoints: amazonaws.com, azurewebsites.net, netlify.app, github.io, elasticbeanstalk.com, and similar. For each record, verify the cloud resource is still active and owned by your organization. If it has been decommissioned, remove the DNS record immediately. MonstaDomains’ DNS lookup tool lets you query your domain’s current CNAME records and see exactly where each one resolves – a fast first step for identifying your exposure.
Build DNS cleanup into every cloud decommissioning checklist going forward. The dangling DNS hijacking risk that Hazy Hawk exploited is not a new discovery – Infoblox, Unit 42, and academic researchers have documented it for years. The gap is procedural, not technical. Decommissioning a cloud service and leaving the DNS record in place is the equivalent of canceling a lease but leaving a set of keys under the doormat for anyone who cares to look.
Domain owners at the individual level should also review their records, particularly if they have migrated away from services like GitHub Pages, Netlify, or cloud hosting platforms in the past two to three years. Check your public domain exposure with a WHOIS lookup to confirm what records are visible. The recent cPanel authentication bypass showed how legacy infrastructure configurations become active attack vectors over time – dangling DNS hijacking operates on the same principle at the DNS layer instead of the application layer.
The Bottom Line
Hazy Hawk did not need sophisticated tools to hijack subdomains at MIT, Harvard, Stanford, and the CDC. They needed passive DNS monitoring and the operational reality that most organizations decommission cloud services without cleaning up the DNS records that point to them. Dangling DNS hijacking is not a warning about emerging future risks – it is documentation of an active, ongoing campaign that has already compromised some of the most trusted domain names on the internet, and is almost certainly still running.
The practical response is a DNS audit: find every CNAME pointing to a third-party cloud service, verify the resource still exists and still belongs to you, and delete any record that does not. Make DNS cleanup a required step in every cloud decommissioning process. Your DNS records are public infrastructure – treat them accordingly. If you are looking for a registrar that keeps your identity private regardless of how thoroughly your domain gets scrutinized, register your domain with MonstaDomains – no KYC required, crypto payments accepted, and privacy built in from day one.
Top comments (0)