DNS Rebinding Attack Framework – Singularity

Last Commit: 05/03/2019

DNS Rebinding Attack Framework – Singularity


Singularity is a tool which can perform DNS rebinding attacks. It includes the necessary components to rebind the IP address of the attack server DNS name to the target machine’s IP address and to serve attack payloads to exploit vulnerable software on the target machine.

Singularity: A DNS Rebinding Attack Framework

Singularity also comes with sample payloads to exploit several vulnerable software versions – from simple homepage capture to remote code execution. This DNS rebinding attack framework tends to facilitate the exploitation of software vulnerable and to raise awareness about DNS rebind attacks prevention.

DNS rebinding changes the IP address of an attacker controlled machine name to the IP address of a target application, bypassing the same-origin policy and thus allowing the browser to make arbitrary requests to the target application and read their responses. When the victim browses to the Singularity manager interface, the Singularity’s DNS server first responds with the IP address of Singularity itself where the client-side code (payload) is hosted.

Singularity Interface

After DNS record times out, the Singularity DNS server responds with the target host IP address and the victim’s browser can access the target application, circumventing the browser’s same-origin policy.

DNS rebinding can also be triggered before a cached DNS record expires, but it depends on target platform and combination of techniques.


  • Complete DNS rebinding attack delivery stack:
    1. Custom DNS server to rebind DNS name and IP address mapping from the attacker web server address to the target machine address
    2. HTTP server to serve HTML pages and JavaScript code to targets and to manage the attacks
    3. Sample attack payloads (you can adapt them to perform new and custom attacks)
  • Supports concurrent users
  • Provides several DNS rebinding strategies (including sequential mapping and random mapping to minimize the impact of IDS/IPS interfering with the attack)
  • A lot of technical controls to maximize the reliability and speed of attacks:
    1. Disabling HTTP keep alive, caching, DNS prefetching
    2. Aggressive DNS response TTLs
    3. Option to use DNS CNAME instead of A records to evade several DNS filtering solutions
    4. Near instant rebinding for several browser and OS combinations, using multiple DNS answers and dynamic HTTP port blocking.
  • Ability to allocate HTTP servers at startup or dynamically thereafter:
    1. A convenience feature to avoid restarting Singularity to listen on a different HTTP port.
    2. To lay the ground work to attack vulnerable ports discovered after a scan.


Minimum required ports:

  • UDP 53 (DNS)
  • TCP 8080 (configurable default port for the manager web interface)
  • The port where the vulnerable application is running (e.g. Ruby on Rails Web Console – port 3000  or VS Code Chrome DevTools – port 9333)


First of all, you need to configure appropriate DNS records to delegate management of test subdomain (example.yourdomain.com) of your own domain (yourdomain.com) to the Singularity’s DNS server:

  • A Name: “rebinder”, IPv4: ip.ad.dr.ss
  • NS Name: “dynamic”, Hostname: rebinder.yourdomain.com

Then install Golang (instructions here).

Type the following command to obtain Singularity:

$ go get -v github.com/nccgroup/singularity/

Then compile it:

$ cd ~/go/src/github.com/nccgroup/singularity/cmd/singularity-server
$ go build

To deploy run:

$ cd ~/
$ mkdir -p singularity/html
$ cp ~/go/src/github.com/nccgroup/singularity/cmd/singularity-server ~/singularity/
$ cp ~/go/src/github.com/nccgroup/singularity/html/* ~/singularity/html/*

To start Singularity-server run:

sudo ./singularity-server --HTTPServerPort 8080
Note: Make sure you verify that other services do not listen on ports required by Singularity.

Ubuntu 18.04 LTS:

By default,systemd-resolved is listening on the localhost UDP port 53, which will prevent Singularity from starting. Make sure you disable systemd-resolved with the following command:

$ sudo systemctl disable --now systemd-resolved.service

Then update /etc/resolv.conf file and make sure it doesn’t contain nameserver, but contains nameserver You need to replace with the IP address of DNS server of your choice.

Singularity Usage

By default, without any arguments, the Singularity’s manager web interface listens on TCP port 8080. There you can configure and launch the DNS rebinding attack.

To see server arguments, launch the Singularity binary, (singularity-server), with the -h parameter.

  • DNSRebindStrategy string : Specify how to respond to DNS queries from a victim client. The supported strategies are:
    • DNSRebindFromQueryRoundRobin
    • DNSRebindFromQueryFirstThenSecond (default)
    • DNSRebindFromQueryRandom
    • DNSRebindFromQueryMultiA (requires Linux iptables)
  • HTTPServerPort value : Specify the attacker HTTP Server port that will serve HTML/JavaScript files. Repeat this flag to listen on more than one HTTP port.
  • ResponseIPAddr string : Specify the attacker host IP address that will be rebound to the victim host address using strategy specified by flag -DNSRebingStrategy (default value is
  • ResponseReboundIPAddr string : Specify the victim host IP address that is rebound from the attacker host address (default value is
  • dangerousAllowDynamicHTTPServers Identify if any target can dynamically request Singularity to allocate an HTTP Server on a new port. This feature may be dangerous as it allows opening new ports via the unauthenticated web interface.
  • responseReboundIPAddrtimeOut int : Specify a delay in seconds for which we will keep responding with Rebound IP Address after the last query. After the delay, we will respond with ResponseReboundIPAddr. The default is 300 seconds.

Attack payloads:

  • Basic fetch request (payload-simple-fetch-get.html)
  • Basic XHR request (payload-simple-xhr-get.html)
  • Chrome DevTools (payload-exposed-chrome-devtools.html)
  • etcd (payload-etcd.html)
  • pyethapp (payload-pyethapp.html)
  • Rails Web Console (payload-rails-webconsole.html)
  • AWS Metadata (payload-aws-metadata.html)

How to prevent DNS Rebinding Attacks

  • Validate the “Host” HTTP header on the server-side to only allow a set of whitelisted values. This set of whitelisted host (for services listening on the loopback interface) values should only contain localhost and all reserved numeric addresses;
  • Authentication should be required to prevent unauthorized access, for all services that are exposed on the network;
  • Filtering DNS responses containing private, link-local or loopback addresses, both for IPv4 and IPv6, should not be relied upon as a primary defense mechanism against DNS rebinding attacks;
  • See advanced techniques to prevent DNS rebind attacks.
Documentation Box