163 organizations across more than 30 countries had gambling content served under their own trusted domain names, with valid TLS certificates, clean browser padlocks, and no security alert firing anywhere. Federal government agencies, national healthcare systems, financial institutions, critical infrastructure operators, and major universities were all affected. Some of them had been exposed for over six years.
The attackers didn't breach a single firewall. They didn't exploit an application vulnerability. They didn't phish anyone. They simply claimed DNS infrastructure that these organizations had abandoned and forgotten to clean up.
This is the "Borrowed Trust" campaign, documented by Cyble Research and Intelligence Labs in June 2026. It's one of the clearest, largest-scale demonstrations to date of how abandoned DNS delegations turn into a systematic attack surface. And it's a textbook example of exactly the risk we've written about before: dangling DNS records, exploited at industrial scale.
What Happened
The campaign was an SEO poisoning operation. The attackers wanted to rank Thai-language online gambling sites in search results, and to do it, they needed domains with strong reputation and authority. Rather than building that reputation themselves, they borrowed it from legitimate enterprises by hijacking abandoned subdomains.
The discovery started with a single anomaly. During a vulnerability assessment, Cyble researchers noticed strange DNS resolution on a Verizon subdomain environment. What looked like one misconfigured endpoint turned out to be over 1,000 individually named subdomains, each serving Thai-language gambling content under Verizon's trusted domain authority. Following that thread exposed 162 other compromised organizations.
Each compromised subdomain served a fully rendered gambling application with a valid Let's Encrypt certificate matching the victim's domain. To a browser, a search engine, or a Thai user clicking a search result, the page looked like a legitimate property of the enterprise whose domain it ran under.
The Core Vulnerability: Abandoned DNS Delegations
The primary mechanism behind the campaign was Azure DNS zone takeover, which accounted for more than 150 of the 163 victims. Understanding it requires understanding how cloud DNS delegation works.
When an enterprise provisions cloud infrastructure for a project, a common step is to delegate a subdomain to a cloud DNS zone. For Azure, this means adding NS (nameserver) records in the parent domain's DNS that point to Microsoft's Azure nameservers for that environment. The cloud DNS zone then handles all records for that subdomain. The project runs normally.
The problem is what happens at decommissioning. According to Cyble's analysis, when the project ends and the cloud resources are deleted, the NS delegation in the parent DNS zone is routinely left in place. It keeps pointing to cloud nameservers that no longer hold authoritative records for the subdomain.
This dangling delegation becomes exploitable because of how cloud DNS zone creation works. Cloud providers have historically allowed any subscriber to claim a DNS zone by name. An attacker who finds an abandoned delegation can create a new subscription, claim the orphaned zone under that subscription, and instantly inherit the DNS authority that the enterprise's parent zone never revoked.
Once the attacker controls the zone, they add a single wildcard A record pointing every possible subdomain to their server, then use the now-controlled DNS to pass ACME validation and obtain a wildcard TLS certificate. One wildcard record exposes the entire subdomain namespace of the environment, every entry carrying the victim's TLS-verified brand authority.
Four Mechanisms, One Root Cause
Cyble identified four distinct compromise mechanisms, but they all stem from the same root cause: a DNS configuration that outlived the infrastructure it was created to serve.
Azure DNS zone takeover (150+ organizations). Abandoned NS delegations to Azure nameservers, with the underlying subscription canceled. The attacker claimed the orphaned zones and added wildcard records. Cyble confirmed this with direct evidence: querying Microsoft's own nameservers returned the attacker's wildcard record, and zone SOA serials of 1 proved the zones had been created fresh by the attacker rather than modified from an existing state.
DigitalOcean DNS zone takeover (2 organizations). The same structural weakness on a different cloud provider. Abandoned DNS zones in canceled accounts became available for re-registration. The attacker's tooling targeted multiple cloud DNS providers, not just Azure.
Direct wildcard misconfiguration (2 organizations). An orphaned wildcard A record left directly in the organization's own DNS console when a project was decommissioned, or a compromised DNS management credential.
Per-subdomain A records (1 organization). The Verizon case, where over 1,000 individually named A records were created rather than a single wildcard, implying automated DNS API access or a compromised DNS management credential.
Why Nothing Detected It
The most unsettling part of this campaign is how completely invisible it was to conventional security tooling. As Cyble notes, the campaign produces no signal in standard security controls. Here's why:
- Valid TLS certificates. The attacker obtained legitimate Let's Encrypt certificates for the victim subdomains. Browsers showed a clean padlock with no warnings.
- Clean IP reputation. The delivery nodes were standard hosting with no prior threat association. Threat intelligence feeds returned nothing.
- Trusted domain names. The content was served under the victims' own legitimate domains, which carry years of accumulated reputation and trust.
- No exploit delivery. Nothing was hacked in the traditional sense. There was no malware, no exploit payload, no perimeter breach to detect.
- Geographic filtering. The backend validated request origin server-side and only served gambling content to traffic from Thailand, keeping the operation focused and limiting scanner exposure.
Every layer of the operation lived inside legitimate infrastructure: real cloud DNS, real TLS certificates, victim-owned domains, and organic search rankings. That's precisely why traditional controls produced no signal. The only place the attack was visible was at the DNS layer.
The Detection That Would Have Worked
Cyble's analysis is clear that detection required operating at the DNS layer, and identifies the controls that would have caught this campaign. Every one of them is about DNS visibility.
DNS Delegation Auditing
The structural prevention control is auditing your NS delegation records. Organizations should enumerate every NS delegation in their parent DNS zones and verify that each corresponding cloud DNS zone actually exists in a subscription they own and actively manage. An NS delegation pointing to a cloud provider where you no longer have a matching, managed zone is a dangling delegation waiting to be claimed.
Wildcard DNS Testing
A randomized, nonsense hostname query against a delegated subdomain that returns a resolution is a strong signal of compromise. If random-nonsense-12345.dev.yourcompany.com resolves to an IP, but you never created a wildcard record, someone else did. Cyble recommends treating any such resolution as a compromised zone until proven otherwise.
Certificate Transparency Monitoring
Every TLS certificate issued by a public CA is logged in public Certificate Transparency logs. An unexpected Let's Encrypt wildcard certificate appearing on a corporate subdomain, especially one that historically used a corporate or premium CA, or had no recent certificate activity, is an anomaly no legitimate provisioning produces. Cyble notes that CT log monitoring would have detected every Azure takeover victim at the moment the attacker's certificate was issued.
How DNS Assistant Addresses This
This campaign is a direct, large-scale validation of why continuous DNS monitoring matters. DNS Assistant is built around exactly the kind of visibility that would have surfaced these compromises.
Dangling DNS Detection
DNS Assistant checks for dangling DNS records, the exact vulnerability class this campaign exploited, across 22+ cloud provider fingerprints. Records and delegations pointing to decommissioned cloud infrastructure are flagged before an attacker can claim them. This is the core defensive control against the abandoned-delegation problem at the heart of Borrowed Trust.
Record and Delegation Change Detection
DNS Assistant continuously monitors your DNS records, including NS records, and alerts when they change or when resolution behavior shifts. A subdomain that suddenly begins resolving to an unfamiliar IP, or a wildcard that starts answering queries it never did before, is exactly the kind of change DNS Assistant is designed to surface.
Continuous Monitoring, Not Point-in-Time
Several victims in this campaign had abandoned delegations sitting exploitable for over six years. A one-time audit conducted before the delegation was abandoned would have shown nothing wrong. The exposure appeared later, when the cloud subscription was canceled but the delegation remained. Only continuous monitoring catches the moment a record becomes dangerous, which can be long after it was created.
Full Subdomain and Record Visibility
You cannot protect infrastructure you've forgotten you have. DNS Assistant helps you maintain visibility into your DNS records and subdomains, including the forgotten dev, staging, uat, pilot, and lab environments that are the most common source of abandoned delegations.
What Organizations Should Do Now
Drawing on Cyble's remediation guidance, here are the steps every organization should take:
- Enumerate your NS delegations. List every NS delegation record in your parent DNS zones. For each one pointing to a cloud provider, verify that a corresponding zone exists in an account or subscription you own and actively manage. Remove any delegation that no longer has a matching, managed zone.
-
Audit environment-style subdomains. Pay special attention to subdomains with names like
dev,uat,staging,preprod,pilot,lab,test, andsandbox. These project environments are the most likely to have been decommissioned while leaving delegations behind. - Test for unexpected wildcard resolution. Query randomized nonsense hostnames against your delegated subdomains. Any resolution you didn't configure is a red flag.
- Monitor Certificate Transparency logs. Watch for unexpected certificates issued against your subdomains, especially wildcard certificates from a CA you don't normally use.
- Build DNS cleanup into decommissioning. The root cause is that DNS delegations outlive the infrastructure they serve. Make removing DNS records and delegations a mandatory, verified step whenever a project or cloud resource is retired.
- Monitor continuously. Abandoned delegations can become exploitable years after they're created. Continuous DNS monitoring is the only way to catch the transition from dormant to dangerous.
The Takeaway
The Borrowed Trust campaign is a reminder that DNS is not static infrastructure you configure once and forget. It's a living attack surface, and the most dangerous parts of it are often the parts you've stopped thinking about: the project that ended, the environment that was torn down, the delegation that was never cleaned up.
The attackers in this campaign didn't need sophistication. They needed an automated scanner and a list of organizations that had left DNS delegations pointing at cloud zones they no longer owned. One abandoned delegation, beneath one wildcard record, exposed an unlimited subdomain namespace carrying the full authority of a trusted brand. Multiply that by 163 organizations, and you have one of the largest DNS-based reputation-hijacking campaigns documented to date.
The remediation is simple. The detection is well understood. The gap is visibility, and that gap is exactly what continuous DNS monitoring closes.
Check your DNS estate now. Run a Free Domain Risk Report to review your DNS configuration, or use the DNS lookup tool to inspect specific records and delegations.
For continuous dangling DNS detection and delegation monitoring across your entire domain portfolio, sign up at dnsassistant.com.
