Reverse DNS Tunneling Shellcode

What is Reverse DNS Tunneling Shellcode?

Reverse DNS Tunneling Shellcode was created by Ty Miller. He presented and released this attack technique and tool at Blackhat USA 2008. As a part of this presentation, Ty launched Project Shellcode (www.projectshellcode.com) which is aimed at being the main point for shellcode resources as well as creating a Shellcode Development Framework. Ty is the Chief Technical Officer and Penetration Tester for Pure Hacking, and is also one of the authors of the latest Hacking Exposed Linux, Third Edition.

DNS Tunneling has been around since 1998 and allows an attacker to bypass outbound security controls and devices by tunneling IP over DNS.

Reverse DNS Tunneling Shellcode allows a penetration tester to remotely exploit a client-side vulnerability, such as within a web browser or local workstation software, and tunnel the command prompt for the system back over DNS to the tester bypassing various layers of outbound security controls.

This provides penetration testers with the ability to reliably compromise an internal system and gain a remote command prompt, which they can then use as a foothold within the organization's internal network.

Why was this shellcode developed?
Over the past 4-5 years we have seen a shift in "vulnerability location" from publicly accessible systems, such as web or mail servers, to client-side systems, such as workstations.

In earlier days of penetration testing, externally accessible systems contained a large number of vulnerabilities, where as these days there are far fewer exploitable vulnerabilities within publicly available systems.

Fortunately for penetration testers, vulnerabilities are still rampant within client-side software, such as web browsers and plugins, PDF readers, audio and video software, as well as software such as Word, PowerPoint and Excel.

The "exploit development location" also shifted to focus on client-side vulnerabilities. The problem that appeared was that the "shellcode development location" didn't shift as fast, which meant that penetration testers were left using shellcode that was unable to bypass any outbound security controls that exist around client-side systems. These security controls include various layers of firewalls and web proxies that may require authentication.

This meant that even if the exploit was successful against the client-side system, the shellcode would fail to connect back to the penetration tester, and they would not have successfully compromised the victim host.

Finance "We initially engaged Pure Hacking to conduct a number of tests in accordance with a set of objectives. Their approach and execution were highly commendable and all objectives were met or exceeded. Based on the experience we had no hesitation in re-engaging Pure Hacking on another assignment. In the area of internet security, I would highly recommend Pure Hacking for a penetration test." IT. Security Manager, International Financial Institution