Back
Dependencies & supply chain21 Sept 2026 · 3 min read

Hijacked subdomains: one forgotten DNS record is enough

by detektd team

Green street signs on a lamppost in front of a brick building
Photo: Candace McDaniel · CC0 · StockSnap

In February 2025, journalist Brian Krebs noticed dozens of links to pornographic videos appearing under a subdomain of cdc.gov, the site of the US Centers for Disease Control. He alerted Infoblox, whose threat intelligence team followed the trail. The result, published on May 20, 2025, describes an actor named Hazy Hawk, active since at least December 2023, who never hacked the CDC: it simply claimed a cloud resource the agency had abandoned.

The mechanism

To publish a site on a cloud service under your own domain name, you create a CNAME record: shop.example.com points to example-shop.azurewebsites.net, or to an S3 bucket. The day the project stops, the team deletes the resource at the provider, but nobody thinks to remove the DNS record, often managed by another team. The CNAME then points to a free name, which any customer of the same provider can claim.

shop.example.com is a CNAME to example-shop.azurewebsites.net
The Azure resource is deleted, the CNAME stays
The attacker creates a resource with the same name
shop.example.com serves the attacker's content, under your domain
Spotting an orphaned CNAME
$ dig +short CNAME shop.example.com
example-shop.s3-website.eu-west-3.amazonaws.com.

$ curl -s http://shop.example.com | grep -o NoSuchBucket
NoSuchBucket   # the bucket no longer exists: anyone can create it

Hazy Hawk, in numbers and names

Infoblox lists the cloud services abused: Amazon S3, EC2 and Elastic Beanstalk, Azure, Akamai, Cloudflare CDN, Bunny CDN, GitHub and Netlify. Affected domains include cdc.gov, alabama.gov, health.gov.au, berkeley.edu, stanford.edu, ucl.ac.uk, deloitte.com, ey.com, pwc.com, honeywell.com and ted.com. The French government's Olympic Games site was hijacked too, in November 2024. The researchers believe the actor has access to commercial passive DNS services, which keep resolution history and make it possible to find orphaned CNAMEs at scale.

On each subdomain, Hazy Hawk publishes hundreds of URLs that ride on the parent domain's reputation and search ranking: fake videos, fake games, pirated content. Visitors go through traffic distribution systems that send them to tech support scams, fake antivirus pages, or ask them to allow notifications so scams can be pushed later. According to Infoblox, these "push monetization" programs pay affiliates a 70 to 90% revenue share. The pattern hasn't stopped: in April 2026, according to Aviatrix, 34 US universities had subdomains pointing to deleted S3 buckets serve explicit content, indexed by search engines under their .edu domain.

0

US universities targeted in April 2026 through subdomains hijacked via deleted S3 buckets (Aviatrix, June 2026)

Worse than a spam page

Hazy Hawk uses subdomains for search ranking and scams. But an attacker controlling a subdomain of your application holds far more: to the browser and to your own trust rules, it's part of your site.

  • Cookies: a session cookie set with Domain=.example.com is sent to every subdomain, including the attacker's, which can also write cookies to overwrite yours.
  • CORS and CSP: a rule trusting *.example.com now allows the attacker's requests or scripts.
  • OAuth: a redirect URL registered on that subdomain makes it possible to receive authorization codes.
  • HTTPS: the attacker controls the content served, so they can get a valid certificate through HTTP validation. The padlock shows up as usual.

Protecting yourself

  1. Reverse the deletion order: remove the DNS record first, then the cloud resource. Infoblox recommends a process that automatically triggers removing the CNAME whenever a resource is shut down.
  2. Inventory your subdomains, including those nothing links to anymore: Certificate Transparency logs (crt.sh) list every name a public certificate was issued for.
  3. Reduce the trust given to subdomains: __Host- session cookies (with no Domain attribute), explicit CORS and CSP lists rather than wildcards.
  4. Turn on domain ownership verification when the provider offers it (a verification TXT record on Azure App Service, for example): it prevents a third party from binding your name to their resource.

What detektd checks

detektd resolves the subdomains your application references and, during an active scan, those Certificate Transparency logs associate with your domain. For each one, it follows the CNAME and recognizes the "resource does not exist" page of 31 providers (S3, Elastic Beanstalk, Azure, GitHub Pages, Heroku, Netlify, Vercel, Shopify...). It only flags a subdomain with that proof, to avoid false positives. Third-party script hosts that no longer exist are checked the same way.

Hijacked subdomains: one forgotten DNS record is enough | detektd