What Is DangleGeddon?
Security research firm Silent Push has coined the term "DangleGeddon" to describe what they characterize as a coming wave of AI-amplified subdomain takeover attacks targeting the vast inventory of forgotten DNS records pointing to deleted or abandoned cloud resources. Their research demonstrates that AI tools can reduce what was once a slow, expert-level manual process to an automated campaign executable in minutes — at global scale.
The core vulnerability is simple and old: organizations deprovision cloud resources (Azure Blob Storage, AWS S3 buckets, App Gateway endpoints) but neglect to delete the corresponding DNS records. The DNS entry persists, pointing to nothing — a dangling record. An attacker who notices this can register the underlying cloud resource under their own account and instantly inherit the trusted subdomain, including whatever trust signals it carries (corporate branding, TLS certificates, email deliverability).
What's new is AI's ability to industrialize finding and exploiting these records at a scale no human attacker could achieve manually.
How AI Amplifies the Attack
Silent Push used Claude Opus 5 to develop "context-enriched takeover script generation" — automating the pipeline from subdomain discovery to exploitability assessment to attack infrastructure buildout. In their research:
- 12,500 domains were scanned for dangling DNS records
- Several hundred exploitable targets were identified
- The entire workflow — from discovery to a ready-to-exploit infrastructure — took minutes, not days
This asymmetry is the core of DangleGeddon's threat model: organizations accumulate forgotten records over years of cloud operations; AI compresses the attacker's reconnaissance and exploitation timeline to near-zero. Silent Push described the scenario as being "one button push away from Dangle Day."
Without AI assistance, subdomain takeover campaigns require expert knowledge of cloud provider behaviors, manual DNS enumeration, and slow iteration through potential targets. With AI assistance, the barrier drops to near nothing.
Real Vulnerable Organizations Identified
Silent Push's research sample of 12,500 domains turned up high-profile targets:
| Organization | Dangling Record Type | Potential Impact |
|---|---|---|
| US Federal Government domain | Azure Blob Storage | Phishing pages with .gov trust, bypassing automated safeguards |
| Société Générale | Azure Blob Storage | Credential harvesting, fraud at scale against France's largest bank |
| Ford | App Gateway | Developer credential exfiltration (API keys, auth headers) |
| Eli Lilly | Apple device guide endpoint | Brand abuse, phishing |
The US federal domain finding is particularly alarming: a phishing page hosted on a legitimate .gov subdomain would bypass many automated email and browser safeguards that check domain reputation. Victims clicking links from what appears to be a government domain would have little reason for suspicion.
Silent Push's disclosure method was unusual: they left security notices on the vulnerable subdomains themselves, notifying organizations by hosting warnings at the dangling URLs before attackers could claim them.
The Scale Problem
Silent Push projects that if DangleGeddon were weaponized across the full population of exposed domains, the potential impact spans:
- Banking: paralysis of online banking platforms, real-time payment systems, and trading infrastructure
- Pharma: estimated losses in the hundreds of billions from credential theft and platform manipulation
- Government: national security implications from
.govphishing infrastructure
These projections reflect the trust multiplier that corporate and government subdomains carry. An attacker who claims a dangling payments.majorbank.com record pointing to a deleted Azure Blob can instantly host a convincing phishing portal with full TLS and a trusted domain — no typosquatting required.
Why This Keeps Happening
Dangling DNS records are a cloud hygiene failure baked into how organizations operate:
- Development teams provision cloud resources with public-facing DNS records
- When resources are deprecated, infrastructure teams delete the cloud resource but the DNS record lives in a separate system (Route 53, Azure DNS, Cloudflare) managed by a different team
- No automated reconciliation ties cloud resource lifecycle to DNS record lifecycle
- Records accumulate silently over months and years
This is a coordination and tooling problem as much as a security one. Most organizations have no systematic way to audit their DNS inventory against their live cloud resource inventory.
Defensive Measures
-
Audit DNS against live cloud inventory — enumerate all DNS records and cross-reference against active cloud resources in Azure, AWS, and GCP. Any record pointing to a non-existent resource should be deleted immediately.
-
Automate lifecycle enforcement — integrate DNS record deletion into cloud resource deprovisioning workflows. When a resource is removed via IaC or cloud console, the DNS record should be removed in the same pipeline.
-
Use cloud provider subdomain takeover protections — Azure and AWS offer features that claim or lock storage endpoints to prevent third-party registration of released resource names. Enable these where available.
-
Continuous monitoring — tools like Silent Push's platform, or open-source equivalents, can periodically scan your DNS inventory for dangling records before attackers find them.
-
Restrict wildcard DNS records — wildcard entries (
*.example.com) dramatically expand the attack surface for dangling record scenarios.