Office Address
45 Ivan Allen Jr Blvd NW
Atlanta, GA 30308
Phone Number
+1 (888) 808-7330
Email Address
General: [email protected]
Sales: [email protected]
Support: [email protected]
45 Ivan Allen Jr Blvd NW
Atlanta, GA 30308
+1 (888) 808-7330
General: [email protected]
Sales: [email protected]
Support: [email protected]
by Trurion Staffs
Most breach narratives start with something an organization did: a server it failed to patch, a credential it failed to rotate, a phishing email an employee clicked. A quieter category starts with something an organization stopped doing.
A marketing team spins up a campaign microsite on a cloud storage bucket, points a CNAME at it, and moves on. Three years later, the bucket is gone, and the CNAME is not. A company acquires a competitor, migrates the customers, and lets the acquired brand's domain lapse. An engineering team decommissions an EC2 instance and releases the elastic IP, but the A record persists in the zone file, which nobody has updated since the person who wrote it left. A startup shuts down, and its domain goes back on the market with the SaaS accounts of every former employee still keyed to it.
None of this looks like an attack surface on a dashboard. There is no vulnerable software to scan, no CVE to track, no unpatched appliance to inventory. The asset simply ceased to exist on the organization's side of the ledger while continuing to exist — and to be trusted — on everyone else's.
Attackers noticed this some time ago. What has changed over the last two years is the scale, the industrialization, and the quality of the public evidence. There is now a documented threat actor whose entire business model is hijacking other people's forgotten cloud resources, a spam operation running on thousands of resurrected brand subdomains, and a body of research showing that live production systems worldwide are still fetching executable code from storage locations their owners deleted.
This post separates what has been confirmed as exploited in the wild from what researchers have demonstrated is exploitable but not yet observed being abused. That distinction matters more than usual here, because the "exploitable" pile is enormous and the temptation to treat it as breach data is strong.
The category is broader than "old subdomain." A useful working definition: any identifier or reference that other systems still resolve, trust, or fetch from, after the organization has stopped controlling the thing behind it.
In practice, that includes:
include: entries, WHOIS server addresses, and CloudFormation template locations. These are the reasons the other categories are dangerous: they are what keep traffic flowing to an asset long after the owner stopped thinking about it.The unifying property is trust inheritance. An attacker who claims a residual artifact need not build a reputation, evade domain-age heuristics, or bypass authentication. They inherit all of it from the previous owner.
The clearest evidence that this is an operational technique rather than a conference talk comes from Infoblox's tracking of an actor it named Hazy Hawk. The group hijacks abandoned cloud resources belonging to high-profile organizations — S3 buckets, Azure endpoints, and resources on Akamai, Bunny CDN, Cloudflare, GitHub, and Netlify — by exploiting misconfigured DNS records, then uses the hijacked domains to host URLs routing victims to scams and malware through traffic distribution systems.
Infoblox first identified the actor after it gained control of several subdomains associated with the U.S. Centers for Disease Control and Prevention in February 2025, and subsequently determined that government agencies worldwide, prominent universities, and firms, including Deloitte, PricewaterhouseCoopers, and Ernst & Young, had been victimized by the same actor since at least December 2023. Other identified victims include the University of California, Berkeley, healthcare companies, and regional government entities.
Two details are worth pulling out. First, the motive is mundane. Infoblox's investigation began with a tip that the CDC's domain was suddenly hosting dozens of URLs pointing to pornographic videos and advertisements, many of which ranked highly in search results precisely because they sat on a trusted CDC subdomain. This is not espionage. It is fraud monetization riding on a borrowed reputation.
Second, the research explicitly frames this as an escalation from theory to practice. Infoblox's Renée Burton noted that prior discussion of this kind of domain hijacking had been limited to theory or isolated examples, and that the value of the Hazy Hawk work lies in demonstrating it is being done consistently by an identifiable actor. She also observed that finding records pointing to cloud service endpoints is considerably harder than finding records pointing to IP addresses, which is a defender problem, not an attacker's.
The campaign has not stopped. Follow-on research published in April 2026 documented the same technique applied across more than thirty U.S. universities, including MIT, Harvard, and Stanford, with a Department of Defense Education Activity domain also flagged as vulnerable to the same pattern.
Guardio Labs documented a campaign that industrialized the same idea for email. The operation, dubbed SubdoMailing, hijacked abandoned subdomains and domains belonging to well-known companies to send malicious email that inherited those companies' trust — bypassing spam filters and, in some cases, exploiting existing SPF and DKIM policies that told secure email gateways the messages were legitimate.
<Guardio identified roughly 8,800 hijacked domains and more than 13,000 associated subdomains, sending approximately five million emails per day, with the abused inventory growing by hundreds daily. Domains previously belonging to MSN, CBS News, New York City, Philips, Cornell University, VMware, Swatch, Scotiabank, and McAfee were among those identified.
The mechanics are instructive for anyone who has ever inherited an SPF record. Since at least late 2022, the actor had been locating long-forgotten subdomains whose DNS records — CNAMEs or SPF entries — still referenced registrable external names, then registering those names and using the surviving records to send mail with a far better chance of reaching an inbox than a freshly registered domain would have. An SPF include: pointing at a domain that has lapsed is an authorization to send mail as you, handed to whoever buys it next.
One example Guardio described involved a subdomain Microsoft had used more than two decades earlier for a promotional sweepstakes. Nobody at Microsoft in 2024 was thinking about a 2002 marketing campaign. The DNS was.
Infoblox and Eclypsium documented a related but distinct failure — one that does not require deleting any resources at all, only that a delegation be left pointing at a provider account nobody owns.
The attack works when a domain or subdomain uses authoritative DNS from a provider other than its registrar, and the delegation is "lame," meaning the authoritative name server has no information about the domain and cannot resolve queries for it. The researchers estimated roughly one million exploitable domains and confirmed more than 30,000 hijacked since 2019. A parallel account puts the figure at more than 35,000 domains hijacked over six years and abused for brand impersonation, data theft, malware delivery, and phishing.
Infoblox reported multiple Russian-nexus criminal groups using this vector since 2018–2019 for spam, scams, malware delivery, phishing, and data exfiltration, and named additional actors, Hasty Hawk and Horrid Hawk, that adopted the technique in 2022 and 2023, respectively, with some domains hijacked repeatedly by different groups over time.
The cruelest detail: many of the hijacked domains were defensive registrations acquired through brand-protection registrars specifically to deny them to typosquatters, which is likely why nobody noticed they had gone lame. Hijacking a brand's primary domain gets caught immediately; hijacking the lookalike it registered to protect itself does not.
Infoblox's follow-up reporting identified a McDonald 's-registered domain that one actor had hijacked repeatedly over several years, and that remained lame as of publication — a reminder that discovery and remediation are separate problems.
Not every case involves abandonment in the strict sense. Sometimes the asset is sold.
In February 2024, the Polyfill.io domain and its GitHub account were acquired by Funnull, a Chinese CDN company. Malware subsequently injected via cdn.polyfill.io began redirecting users to malicious sites, affecting reported figures of over 100,000 websites, including JSTOR, Intuit, and the World Economic Forum. Sansec, which first documented the attack, found that the injected code was generated dynamically from HTTP headers and included specific anti-reverse-engineering protections.
The headline number understates it. Later analysis noted that the widely quoted 100,000 figure was the default result cap of the code-search tool researchers used, and that the true count exceeded 490,000 websites; Censys independently counted 384,773 affected hosts. As of May 2026, more than 61,000 pages still embedded the reference.
Editorial note on attribution: the Funnull acquisition and the malicious behavior are well established. A later claim linking the operation to North Korean involvement, based on infostealer-derived credentials for the Funnull DNS portal and Polyfill Cloudflare tenant, comes from Hudson Rock and reframes Funnull as a front rather than the principal.</ Treat that layer as a single-vendor inference rather than settled attribution.
The lesson that generalizes is not about any particular vendor. Is that a <script src> pointing at a third-party domain is a standing grant of code execution in your users' browsers, renewable at the discretion of whoever owns that domain next.
The following cases are research. Nobody has published evidence that criminals exploited them first. They matter anyway, because each one measured how much live traffic was still flowing to an abandoned asset — and that traffic is the actual risk.
The most recent and most direct measurement comes from Eye Security's February 2026 research into Azure Blob Storage. Storage account names are globally unique; when an account is deleted, the name eventually becomes available again, with no approval process and negligible cost.
The researchers analyzed more than 15,000 Azure Blob Storage names that are still referenced across the internet. Of those, 621 were unregistered and available; roughly 4 percent had been abandoned; and approximately half began receiving traffic immediately after registration, with several cases reaching millions of requests per day from corporate environments, SaaS platforms, public-sector domains, and security organizations.
One abandoned account was still serving PowerShell scripts downloaded nearly 10,000 times per day from thousands of unique IP addresses — control of that single name would have enabled remote code execution on Windows systems that were voluntarily retrieving and executing whatever was hosted there, without exploiting a vulnerability in any conventional sense. A controlled proof of concept limited to the researchers' own IP address confirmed that injected JavaScript executed in multiple live environments, including within Microsoft-owned web properties, which was disclosed through MSRC and addressed. The Ghidra maintainers were separately notified of a legacy reference to one of the namespaces.
This mirrors watchTower's earlier work on AWS. The team re-registered approximately 150 abandoned S3 buckets for $420.85 and logged incoming requests over two months, receiving more than eight million requests for Windows, Linux, and macOS executables; virtual machine images; JavaScript files; CloudFormation templates; and SSL VPN server configurations — from NASA and other U.S. government networks, UK and other foreign government organizations, military networks, Fortune 500 companies, a major payment card network, and a major industrial manufacturer. Requests originated from government networks in the U.S., UK, Poland, Australia, South Korea, Turkey, Taiwan, and Chile. The buckets were subsequently handed to AWS for sinkholing.
The range of consequences scales with what is being requested: from website code injection and defacement, to takeover of an AWS account and the infrastructure it manages, to full compromise of a software development environment and everything downstream of it.
The most conceptually alarming result in this space involved no cloud provider at all.
After the .mobi WHOIS server migrated away from whois.dotmobiregistry.net, that domain was allowed to expire; watchTowr registered it for $20 and, within days, received about 2.5 million WHOIS queries from more than 135,000 unique systems still configured to treat it as authoritative. Queries arrived from government, military, and university mail servers, from security firms and tools, and from well-known registrars and DNS lookup sites.
The consequential part was downstream. Certificate authorities issuing TLS certificates for names like google.mobi and microsoft.mobi were using the researchers' WHOIS server to determine domain ownership and where verification mail should go; the team demonstrated with GlobalSign that for microsoft.mobi it would parse their response and present an address they controlled as authoritative. The researchers stressed they did not obtain any fraudulent certificates. ShadowServer subsequently sinkholed the domain and hostname.
One lapsed registration, twenty dollars, and a plausible path to trusted certificates for a top-level domain's worth of names.
Two further results extend the pattern into identity and into attacker infrastructure.
Truffle Security identified more than 100,000 domains from failed startups available for purchase, and demonstrated by buying one that "Sign in with Google" would grant access to former employee accounts across the SaaS products the company had used — with the most sensitive being HR systems containing tax documents, pay stubs, insurance information, and Social Security numbers, along with interview platforms holding candidate feedback and chat platforms holding direct messages. The researcher estimated roughly ten million accounts potentially at risk. Google initially treated the report as intended behavior, later reopened it, awarded a $1,337 bounty, classified it as an abuse methodology with high impact, and pointed downstream providers toward using the immutable sub field as the user identifier rather than the email address.
And in a demonstration that the problem is symmetric: watchTowr registered expired domains that abandoned web shells were still calling home to, and received check-ins from over 4,000 compromised systems — including government and university infrastructure — theoretically inheriting control of every one of them. More than forty domains at roughly $20 each; the results were sinkholed with the Shadowserver Foundation. Attackers abandon infrastructure, too, yet their victims remain connected to it.
Datadog's whoAMI research showed that publishing an Amazon Machine Image with a carefully chosen name could yield code execution in AWS accounts whose code retrieved AMI IDs via ec2:DescribeImages without specifying an owner, then selected the most recent match — a pattern the researchers found in public Python, Go, Java, Terraform, Pulumi, and Bash code, affecting roughly 1 percent of the organizations they monitored. That translates to over 10,000 AWS accounts.
Editorial note: <>AWS stated that its investigation found the technique had only been executed by the authorized researchers, with no evidence of use by other parties. This one belongs firmly in the "exposed, not confirmed compromised" column.
The persistence of this problem is structural, not a matter of carelessness.
Lifecycle decoupling. Creating a DNS record and creating the resource behind it are two actions, usually taken by two teams, often in two systems. Destroying the resource is one action. The record survives by default. This is why practitioners increasingly recommend inverting the decommissioning order — remove the DNS record first, then delete the resource, so the window in which the name points at an unclaimed target never opens.
Namespaces with no ownership memory. Cloud providers reissue globally unique names to whoever asks next. There is no equivalent of a domain redemption period for a storage account name.
Organizational churn. Mergers, divestitures, rebrands, and campaign work all produce assets with a defined end date and no defined owner after it. Attackers know this: organizations undergoing M&A and those running frequent marketing campaigns are specifically favorable targets.
Nobody watches the assets they registered defensively. As Sitting Ducks demonstrated, the domains bought specifically to be unused are the ones least likely to be monitored.
Asymmetry of effort. Enumerating subdomains and validating CNAME targets is trivially automatable at the Internet scale. Auditing your own zone files is a manual project that competes for budget with everything else.
And the payoff for the attacker is unusually high relative to effort, because the escalation ladder from a claimed artifact is steep: content control under a trusted name, then a valid TLS certificate for that name via ACME, then session cookies if they are scoped to the parent domain, then credential harvesting on a URL that survives user scrutiny because the domain genuinely is correct, then — if the artifact serves scripts, updates, or images — code execution on the systems that fetch from it.
None of these requires a specific vendor. They do require someone to own the problem.
Treat DNS as an inventory, not a configuration. Export every zone you control and validate each record against a resource you can prove you still own. Records that resolve to NXDOMAIN targets, unclaimed cloud endpoints, or IPs outside your allocated ranges are findings, not noise. Microsoft publishes a PowerShell tool, Get-DanglingDnsRecords, to identify these in Azure environments; open-source tooling exists for dangling elastic IPs and untrusted AMIs.
Invert the decommissioning order. Make DNS removal the first step in any teardown runbook, and resource deletion the second. Bind DNS lifecycle to resource lifecycle in infrastructure-as-code so the two cannot drift.
Audit SPF include: chains for registrable names. Every external domain in your SPF record is a delegation of your sending authority. If any of them can be bought, they have been delegated to a stranger.
Adopt a domain retirement policy, not a domain expiry default. High-value, brand-associated, and infrastructure-referenced domains should be retired — held in perpetuity with records nulled — rather than released. Where release is unavoidable, treat it as a change with a security review. Consolidate the registrar and authoritative DNS where practical, enable registry lock, and specifically monitor for lame delegation.
Monitor Certificate Transparency logs for your own names. A certificate issued for a subdomain you did not request is one of the few reliable external signals that a takeover has already happened.
Inventory what your code fetches from names you do not own. Third-party script tags, update endpoints, and package mirrors are standing trust grants. Self-host what is critical, apply Subresource Integrity where you cannot, and pin resource lookups to specific owners rather than name patterns.
Make the domain wind-down part of the company and subsidiary wind-down. Deprovisioning SaaS should precede the release of the email domain that authenticates to it, not follow it. Where you consume OAuth identity, key users on immutable identifiers rather than email addresses.
Put DNS and domain portfolios into M&A due diligence. Acquiring a company means acquiring its dangling records, its lapsing registrations, and its forgotten buckets.
Security leaders are not unaware of this. In CSC's CISO Outlook 2026 survey of 300 senior security and technology executives, domain and DNS hijacking and subdomain takeover attacks ranked as the single top cyber threat identified, yet only 14% described themselves as very confident in their organization's ability to mitigate domain attacks.
That gap is the whole story. This is not an emerging threat that needs to be explained to executives. It is a recognized threat that lacks an owner, a budget line, and a repeatable process — because the assets in question are, by definition, the ones nobody is responsible for anymore.
The organizations that get breached this way will not have been targeted for anything they built. They will have been targeted for something they stopped maintaining, which is a materially harder thing to defend, and a materially cheaper thing to attack.
Why Organizations Choose Zaxtron
Organizations face increasingly sophisticated ransomware campaigns that exploit unpatched systems, stolen credentials, exposed remote access, and third-party weaknesses. To stay protected, they need actionable intelligence, not just alerts, to identify and reduce cyber risks before disruption occurs. Zaxtron provides Cybersecurity Risk Management, AI Risk Management, and Cyber Threat Intelligence services that deliver continuous visibility and risk-based insights. By combining attack surface intelligence, vulnerability data, threat and breach intelligence, and third-party risk analysis, Zaxtron offers a complete view of cyber exposure. This helps security leaders respond to threats, improve vendor security, and make informed decisions. Contact Zaxtron to strengthen cyber resilience today.
Cookie preferences