A DNS obfuscation technique proof of concept

For my Deadswitch project, I've always been conscious of threat model and wanted to ensure the architecture employed a layered approach. One consideration was DNS tracking mitigations, and what I could do to help make efforts to identify customers more expensive to an adversary.

One of the ways Deadswitch works is each customer is issued a uniquely generated subdomain that they can access in order to trigger/terminate their individual switch. These subdomains point to automatically spun up 'user instances', which host a lightweight web app portal that the customer can authenticate into in order to trigger/terminate their switch.

One of the threats to user instances hosted on unique subdomains are sophisticated adversaries (such as APTs) that may occupy and monitor network level traffic. This means that when a Deadswitch customer visits their issued subdomain to access the trigger/terminate form, that HTTP traffic will be easy for the ISP to identify in their traffic logs. If the ISP is cooperating with a state actor, then the ISP could share knowledge of the subdomain which could enable the user instance to be identified and attacked (such as DoS).

On this page I have created a JavaScript-driven PoC which aims to help obfuscate the destination subdomain from ISP identification. In practice, when a customer creates their own switch, the following will occur:

1. A unique link will be sent to their email inbox along with a 6 digit code (for example 133337).
2. The link will direct them to a Deadswitch web page.
3. On that web page will be a form field (like the form field below).

4. When the correct 6 digit code is entered (for example 133337), the customer will be presented with a button on the page.
5. When clicked, the button will execute JavaScript which cycles the customer's browser through 9 uniquely generated Deadswitch subdomains randomly in the background.
6. These 9 subdomains point to honeypot user instances, and help to obfuscate the 1 subdomain that hosts the real user instance, which is then presented to the customer in a new browser window.

Since the ISP traffic logs will show 10 GET requests to randomly generated Deadswitch subdomains, the ISP will not know which 1 of these 10 is legitimate (if any). The idea of this is to help obfuscate customer's access to their user instance when not already employing the use of a VPN.

As can be seen from the video above, the client browser automatically makes all GET requests to honeypots silently in the background. This is further supported by the Wireshark packet capture video below, where all requests at network level share no unique characteristics that might enable an adversary to identify the legitimate switch subdomain.

To further support the above experiements, here is a diff covering the packet capture of the request to the honeypot (left) against legitimate switch subdomain (right):

https://www.diffchecker.com/rYxzcrG9

And here is the control test diff covering the packet capture of the request to the honeypot (left) to another honeypot (right):

https://www.diffchecker.com/yGeoRuRH

This PoC example is made using JavaScript for demonstration purposes, but in practice the authentication would take place server-side (using PHP). In such circumstances, if the 6 digit code supplied was valid, then the server would dynamically generate the JavaScript responsible for the honeypot URLs and serve this back to the client in the response. All flows and code execution would be silent, seemless, and occur in the background so not to impact the user experience.

In my view the costs to deploy this approach are minimal, as the network overhead is small and honeypots represent lightweight single-page applications. Furthermore, employing the use of a wildcard SSL certificate on the *.deadswitch.com parent domain means that certificate transparency logs will not expose the existence of individual subdomains.

If anyone is interested in leveraging this approach in their own projects, I've added a PHP example implementation here.

Follow Jacob Riggs

Jacob Riggs

Jacob Riggs is a Security Lead based in the UK with almost a decade of experience working to improve the cyber security of media and third sector organisations. His contributions focus on expanding encryption tools, promoting crypto-anarchist philosophy, and pioneering projects centred on leveraging cryptography to protect the privacy and political freedoms of others.

E3FE 4B44 56F5 69BE 76C1 E169 E3C7 0A52 9AEF DB6F