What Is DNS Rebinding? [Examples + Protection Tips]

DNS rebinding is an attack that tricks a browser into treating an external domain as if it belongs to the internal network.

It works by repeatedly resolving the same domain name to different IP addresses, starting with one controlled by the attacker and later switching to an internal address. This allows scripts from a malicious site to bypass browser security controls and interact with devices on the private network.

How does DNS rebinding work?

Here's how DNS rebinding works: 

It starts when a user visits a malicious site set up by the attacker. That site is tied to a domain the attacker owns, which points to a DNS server under their control.

The attacker's DNS server first resolves the domain to the attacker's own web server. The page loads normally. But behind the scenes, it serves client-side code—usually JavaScript—that makes additional requests back to the same domain.

Here's the trick. 

The attacker sets a very short time-to-live (TTL) on the original DNS record. When the browser makes another DNS request for the same domain, the attacker responds with a new IP address—this time, one that points to a device inside the victim's private network.

In other words: the domain now resolves to a private IP address, but the browser still considers it the same origin. That means the original script can now reach internal systems—like routers, printers, or internal APIs—without triggering cross-origin restrictions.

From there, the attacker can probe the local network or extract data. 

The attack works because DNS is separate from browser origin checks, and DNS records can be changed mid-session. It’s a method that bypasses one of the core safeguards of modern browsers—the same-origin policy—without directly breaking it.

What are some examples of DNS rebinding?

DNS rebinding has shown up in various real-world attacks across both consumer and enterprise environments. In each case, attackers used browsers as a pivot point to reach internal systems that would normally be off-limits.

Let's look at a few examples that show how this works in practice.

Penetrating private networks with DNS rebinding

In one example, attackers used a tool called Singularity to scan an internal network through a victim's browser. 

The process began like most phishing-based attacks: convincing the victim to visit a malicious website. Once loaded, the site used timing-based techniques to identify internal IPs and open ports.

From there, the attacker’s site issued repeated DNS requests to rebind its domain name to an internal IP.

After the rebind, the script could interact with local devices as if it were part of the same network. That’s how attackers gained access to systems running on private IPs—without the victim ever knowing.

Attacking routers and IoT devices

Another common use case involves targeting consumer-grade routers and smart devices.

These often run local web interfaces that aren't exposed to the public internet but are reachable from inside the network. Many also use default credentials or have weak access controls.

Here’s why this matters.

Attackers can guess the default IP address of these devices and rebind their malicious domain to it. Once that happens, scripts can open admin panels, change DNS settings, or even reroute traffic.

Smart devices with web-based controls or open APIs are especially at risk.

Accessing internal enterprise applications

In a simulated environment, Unit 42 researchers demonstrated an attack on a Hadoop management interface.

The service wasn’t publicly accessible. But once the browser rebounded the hostname to its internal IP, the attacker could reach the page from the malicious domain.

From there, they could view cluster status or even kill jobs on the management page.

That’s a serious problem—especially in enterprise environments where admin portals control critical workflows.

Without strong internal segmentation and DNS protections, these interfaces become easy targets.

Bypassing CSRF protections

DNS rebinding can also be used to bypass cross-site request forgery (CSRF) defenses.

Normally, CSRF protections rely on the same-origin policy to block attackers from reading tokens embedded in pages. But rebinding removes that safeguard.

In one Unit 42 test, a Rails application used session-specific tokens to authorize commands.

The attacker used DNS rebinding to fetch the main page, extract the token, and then send a valid request to a vulnerable API. That request executed a command on the server.

The test showed how even token-based protections can be bypassed if origin checks are undermined.

What are the potential consequences of DNS rebinding?

DNS rebinding opens the door to a range of security issues that affect both individuals and organizations. 

Here's a breakdown of the most common and impactful outcomes:

• Unauthorized access to internal systems

  Attackers can use DNS rebinding to reach devices and services inside a private network. These might include routers, development consoles, or APIs that are normally inaccessible from the internet. Once connected, they can interact with those resources without triggering standard security protections.

• Data exfiltration

  By gaining access to internal systems, attackers can extract sensitive information. That could include credentials, configuration data, or customer records stored in backend applications. In many cases, this happens silently through the victim's own browser.

• Service manipulation or abuse

  Some internal applications allow configuration changes or administrative actions. DNS rebinding can let attackers reach those interfaces and issue commands. This could involve disabling security settings, restarting systems, or interrupting services.

  Note:

  Some internal web apps expose functionality via undocumented or legacy endpoints, which are often overlooked in standard vulnerability scans but may still be accessible via DNS rebinding.

• Bypassing CSRF protection

  DNS rebinding can undermine web application defenses against cross-site request forgery. Normally, these protections rely on the same-origin policy to prevent attackers from reading tokens. But if the attacker's domain is rebound to a private system, those restrictions no longer apply.

  Note:

  Because rebinding removes the origin mismatch, attackers can capture dynamic tokens from initial page loads and reuse them in subsequent forged requests—essentially chaining session-dependent actions within a trusted context.

• Compromise of IoT and smart devices

  DNS rebinding is especially effective against smart devices that expose local web services. These often include limited authentication. Once rebound, attackers can control features, extract sensor data, or use the device for further scanning.

• Network reconnaissance

  Attackers can use the victim's browser to probe internal networks. Timing-based techniques or WebRTC requests can reveal available services and open ports. That information helps attackers map the environment for later stages of compromise.

  Note:

  DNS rebinding-based reconnaissance is difficult to detect in real time because it piggybacks on legitimate browser activity, often leaving no obvious traces in conventional intrusion detection systems.

• Compliance violations and regulatory risk

  If DNS rebinding leads to a breach of personal or regulated data, organizations may face legal consequences. This includes fines, audits, or sanctions under laws like GDPR or CCPA. Even unintentional exposure can trigger regulatory action.

  Note:

  Even when no data is exfiltrated, the mere exposure of internal systems via DNS rebinding may be considered a reportable security incident under some regulatory frameworks, depending on jurisdiction and industry.

• Reputational harm

  Security incidents involving DNS rebinding can erode stakeholder trust. Customers may lose confidence in the organization's ability to protect data. Rebuilding that trust can take time and require significant public communication efforts.

How to protect against DNS rebinding attacks

While DNS rebinding itself is a technique, its implications are broad. It can be difficult to detect and even harder to prevent.

So the response needs to be layered. Detect early, block suspicious behavior, and configure systems to reject unauthorized access—regardless of how the request got through.

Here's how to approach the issue from a detection, mitigation, and prevention standpoint.

Detection

• Check for private IPs in DNS responses

  Use DNS lookup tools like dig to inspect whether a domain resolves to both public and private IP addresses. If the response alternates between external and internal IPs, it could indicate DNS rebinding.

• Monitor browser behavior

  Look for signs like repeated DNS queries to the same domain or unexpected requests to internal IP ranges. JavaScript errors related to cross-origin restrictions can also point to DNS rebinding in progress.

• Scan DNS and network logs

  Examine DNS logs and firewall activity for patterns such as frequent A record changes from a single domain. Tools like Zeek or Wireshark can help identify external sites attempting to reach private IPs through a victim browser.

  Tip:

  Look for DNS queries that alternate between public and private IPs from the same domain within a short time window—especially when the public IP appears only briefly before switching. These short-lived records are often overlooked in coarse-grained log reviews.

Mitigation

• Enable DNS pinning in browsers

  Modern browsers may implement DNS pinning, which caches DNS results for a set time regardless of the TTL. This can block basic time-based rebinding attempts by reusing the original IP.

• Filter DNS responses with private IPs

  Configure DNS resolvers to block responses that return private, loopback, or non-routable IPs. This can reduce exposure to attacks that try to rebind hostnames to internal systems.

  Tip:

  Also monitor for CNAME chains that ultimately resolve to private IPs. Attackers may use this to bypass direct A-record filtering by rebinding to internal systems via an intermediate alias.

• Use HTTPS for internal services

  HTTPS helps validate server identities during connection setup. Since rebinding changes the domain but not the certificate, browsers will reject mismatched SSL handshakes—making rebinding less effective.

• Require authentication on internal services

  Strong credentials add another barrier. If attackers reach a service via DNS rebinding, authentication can stop them from interacting with it.

Prevention

• Use DNS services with rebinding protections

  Some DNS solutions automatically block responses that resolve external hostnames to internal IP addresses. Choose providers or local resolvers that include this protection.

  Tip:

  Choose DNS services that maintain contextual threat intelligence—such as historical rebinding behavior or associations with known exploit kits—rather than relying solely on static IP blocklists.

• Restrict JavaScript execution

  Limit where and how scripts can run in the browser. This can reduce the ability of attacker-controlled websites to issue repeated DNS queries or execute rebinding payloads.

• Enforce host header validation on servers

  Configure internal web servers to reject requests with unexpected or unknown Host headers. This ensures that even if rebinding is successful, the server won't respond to requests sent through falsified domains.

• Apply CORS and content security policies

  Use strict cross-origin resource sharing (CORS) rules and content security policies on internal applications. These browser-level protections make it harder for scripts to interact with resources that aren't explicitly allowed.

• Segment internal networks

  Limit which devices can talk to each other. Even if DNS rebinding grants access to a particular resource, segmentation can prevent lateral movement to other sensitive areas.

DNS rebinding FAQs