What is Dangling Domain? Your Forgotten DNS Records Are a Hacker's Dream

🕸️ Understanding the concept of ‘Dangling Domains’

Imagine you have a favorite bakery, "Sweet Treats," that always bakes the best cookies.

1. Your "DNS Record" is like your mental map of how to get there. You know their address (e.g., 123 Main Street) and how to drive there. You trust that address to lead you to Sweet Treats.

2. "SecureCorp" (Sweet Treats) decides to close that specific location. Maybe they open a new one across town, or just stop selling cookies from that address altogether. They delete their signage and clear out the shop.

3. The "Service is Deleted," but your mental map (your DNS record) isn't updated. You still have 123 Main Street in your head as "Sweet Treats." This is your dangling domain – the address exists, but the original, trusted business is no longer there.

4. An "Attacker" (a less reputable cookie seller) notices the empty shop. They think, "Hey, that's a prime spot! And people already associate that address with cookies." So, they move in, put up their own, similar-looking sign, and start selling their not-so-great (or even bad!) cookies.

5. You, the "User," drive to 123 Main Street, expecting Sweet Treats. Because your mental map hasn't updated, you see a cookie shop there, assume it's your usual place, and go in.

6. Final Result: You end up buying cookies from the new, untrustworthy seller, thinking you're at Sweet Treats. Your trust has been exploited, and you might get a disappointing (or even harmful) cookie!

In this analogy:

• Your mental map/address book entry = DNS Record

• Sweet Treats (the legitimate business) = The original service/website

• The empty shop at 123 Main Street = The dangling DNS record (pointing to an unused resource)

• The new, untrustworthy cookie seller = The Attacker

• You, buying bad cookies = Users being directed to a malicious site

🤷‍♂️ What is a Dangling Domain?

A dangling domain is a domain name (like your-old-project.com) where:

1. The domain name is still active and registered to the original owner.

2. However, the target service it points to (like a specific server, cloud storage bucket, or application) has been decommissioned, deleted, or de-provisioned by the original owner.

🎯 The Scenario: Why It's a Problem

The danger arises because the company has stopped using the hosting service (the "empty lot") but hasn't removed the custom domain name record (the "street sign").

An attacker can easily claim the now-empty hosting spot. Once they do, anyone who types in the company's old, legitimate domain name is unknowingly directed straight to the attacker's newly created malicious website.

This is a serious security risk because:

1. Trust: The domain name is familiar and trusted (e.g., your-old-project.com), so users are more likely to enter credentials or download malware.

2. Reputation: It damages the company's brand and trust.

3. Phishing/Malware: It can be used for sophisticated phishing attacks, credential harvesting, or serving malware.

This is called Subdomain Takeover or Dangling DNS.

📝 Classic Example

Let's imagine a company, TechCorp, creates a temporary marketing site: promo.techcorp.com.

1. The Setup (Original State)

TechCorp sets up a CNAME record in their DNS settings for promo.techcorp.com. This record points to a unique address managed by a cloud provider, let's call it super-app-id-9876.cloudservice.com.

DNS Record for promo.techcorp.com → CNAME → super-app-id-9876.cloudservice.com

2. The Dangling Domain (Mistake)

A few months later, the marketing campaign is over. A TechCorp employee deletes the cloud service (super-app-id-9876) to save money.

Crucially, they forget to delete the DNS record for promo.techcorp.com.

The domain now points to an address (super-app-id-9876.cloudservice.com) that is unclaimed and dangling—it leads nowhere useful for now.

promo.techcorp.com → CNAME → {super-app-id-9876.cloudservice.com} {Unclaimed/Deleted}

3. The Takeover (Attack)

An attacker, using a Dangling Domain Detection tool, discovers this vulnerability.

The attacker goes to the cloud service provider and registers a brand new service using the exact same unique name: super-app-id-9876.

Attacker Registers: super-app-id-9876.cloudservice.com

The Result: Since the original DNS record was never changed, when a customer types promo.techcorp.com, their browser follows the original, unmodified instructions, and now lands directly on the attacker's site! The attacker can use this trusted link to host phishing pages, spread malware, or damage TechCorp's reputation.

🧙How Wiz Detects Dangling Domains

Wiz's primary method is to look for a mismatch between your organization's Domain Name System (DNS) records and your actual cloud assets.

1. Agentless Discovery: Wiz connects to your cloud accounts (AWS, Azure, GCP, etc.) via their native security APIs, meaning you don't need to install any software or "agents" on your servers. It uses this connection to automatically discover all your cloud resources and configurations.

2. DNS Record Mapping: It specifically scans your DNS service (like AWS Route 53 or Azure DNS) to find all the records (especially CNAME records) that point to external or cloud-managed services.

3. Cross-Check for Existence: Wiz then checks to see if the target resource specified in the DNS record actually exists and is currently owned by your organization.

   • The Check: If the DNS record points to a service (like a specific S3 bucket name or an Azure App Service URL) that has been deleted, decommissioned, or is unclaimed, Wiz flags that DNS entry as dangling.

4. Continuous Monitoring: Since cloud environments change constantly, Wiz performs this check daily (or near real-time based on cloud events) to catch new dangling domains as soon as they are created due to a forgotten decommissioning step.

🪄Why Wiz's Approach is Effective

1. Context and Prioritization (The Security Graph)

Instead of just giving you a list of thousands of security alerts, Wiz uses its Security Graph to show you the context and criticality of the dangling domain.

Attacker View: It can tell you, "This dangling domain is dangerous because it's pointed to a service that is easy to claim and, if taken over, could lead directly to a phishing campaign against your customers.”

Risk Scoring: It prioritizes the fix based on risk, so you know which dangling domain to address first—for instance, one that affects a high-traffic, customer-facing service is prioritized over a forgotten internal testing domain.

2. Visibility into the "Toxic Combination"

Dangling Domain Detection is part of Wiz's broader focus on Cloud Security Posture Management (CSPM). It doesn't just find the abandoned record; it puts it into context with other risks.

Wiz shows that the danger is not just the dangling domain, but the toxic combination of:

Dangling DNS Record + Unclaimed Cloud Resource = Subdomain Takeover Risk

By centralizing the risk analysis, Wiz ensures that this misconfiguration isn't missed, even when your organization has thousands of cloud assets and domain records.

Read more - https://www.wiz.io/blog/wiz-introduces-dangling-domain-detection-to-help-you-prevent-subdomain-takeovers

\=====

Update: About the RBI’s new directive on moving to .bank.in domains -

The RBI's directive for banks to migrate to the .bank.in domain is a proactive cybersecurity measure designed to prevent different types of vulnerability, specifically phishing and domain spoofing. The change/migration itself introduces a manageable risk of Dangling Domains/Subdomain Takeover with respect to the banks' old domains.

While the primary goal of migrating to .bank.in is to prevent phishing and domain spoofing on the new, secure platform, the process of decommissioning the old domains creates a window of vulnerability.

⚠️ Risk of Dangling Domains on Old URLs

The core risk arises from the management of the old domains (e.g., bankname.com or bankname.co.in) during and after the migration.

1. Dangling DNS Records (CNAME Risk):

   • Banks often use CNAME or other DNS records to point a subdomain of their old domain (like mobilebanking.oldbank.com) to a third-party service (like a cloud-hosted payment gateway or a content delivery network).

   • If the bank retires the third-party service but forgets to remove the corresponding DNS record from their old domain's DNS zone, that record becomes "dangling."

   • A threat actor can then register the abandoned service name/resource and "take over" the old, trusted subdomain (mobilebanking.oldbank.com) to host malicious content, effectively using the bank's old brand reputation for phishing.

2. Redirect Vulnerability:

   • For a seamless customer experience, banks will likely set up a redirect from their old main domain (oldbank.com) to the new one (bankname.bank.in).

   • If this redirection process is not strictly managed and the old domain is later allowed to expire without its DNS records being cleaned up, it could lead to potential hijacking of the entire domain, although the primary traffic would be expected to shift to the new, verified .bank.in address.