TLS Injector: running shellcodes through TLS callbacks

I would like to share a python script that lets you inject a shellcode in a binary to be executed through a TLS callback. If you don't know what I'm talking about I recommend you to read this post and this one.

Since I didn't find any script to do this automatically I made a first version to use it in my pentests; I’ve called it tlsInjector. This is not intended to be a serious tool (like the nice backdoor factory) but just an additional script to consider when you need to choose a persistence mechanism. Personally I don’t like leaving my evil binary in places where tools like Autoruns usually sniffs out.

The fact of using a TLS callback instead of the usual injection techniques has some added advantages; for example, you don’t need to modify the entry point to jump/call to the code cave and then redirect the execution flow to the original program. Another key advantage is that a TLS callback runs the code before the entry point is reached. This gives you a lot of scope for doing cool things.

The script has the following options:

reflectPatcher.py: python script to patch your reflective DLL

Here I share a tiny python script to “patch” a reflective DLL with the bootstrap needed to be executed by the respective stager. Its use is simple, just give it the DLL you want to patch and the preferred exit method (thread by default). 

I did this because I needed a faster way to patch DLLs instead of letting the msf handler did it for me. This way I don’t even have to call msfconsole.

 

The script looks for the ReflectiveLoader export function, calculate its raw offset and finally make up the stub. Then, the reflective DLL is build from the stub and the rest of the payload.

The script will also add the size of the payload (look at the bytes highlighted in the previous image) at the beginning of the reflective DLL which is necessary for some stagers to know the number of bytes to allocate in the next stage. Generally, a call to VirtualAlloc is done to reserve that memory. Note that those bytes should be removed if you are using a HTTP-based stager.

IP-Knock Shellcode: Spoofed IP as authentication method

Let's keep playing around with more shellcodes. In recent posts we have seen two alternatives to the classic bind shell. First we saw how you can add firewall capabilities to your shellcode so that only the IP you choose will be allowed to connect; I called this one "ACL bind shellcode". Then I created a  "hidden bind shell" alternative (this already included in Metasploit in its single and stager version). In this case, the shellcode will not only allow connections from the IP you want but it will remain completely hidden from outside. Thus, the shellcode won’t be seen by prying eyes since the socket will appear as "CLOSED". 

As a result of the last shellcode, some people have asked me why not make a bind shell version where you can authenticate the user, for example through a password. This way it would solve one of the major disadvantages of above shellcodes: it wouldn’t be restricted to a single IP.

This idea is not new; in fact I have recently seen very cool implementations of such type of shellcodes.  In this post, however, I would like to show other way to get the same by using another approach and considering some of the functionalities described so far to try to solve the following points:

1. The logic to do the user authentication has to be simple. This is really important if you are implementing a stager (whose main requirement is to have a reduced size)
2. If the shellcode does not use the setsockopt API with SO_CONDITIONAL_ACCEPT option It would be easily detectable as I explained in my last post

Hidden Bind Shell: Keep your shellcode hidden from scans

Many organizations use tools like Nexpose, Nessus or Nmap to perform periodic scans of their networks and to look for new/unidentified open ports. In this kind of environment it’s difficult that our bindshell goes unnotice. For this reason, after finishing the ACL Bind Shellcode it occurred to me that the payload could be further improved so that it was only visible to the IP I wanted. The result is another alternative to the ACL Bind Shell called "Hidden Bind Shell". The payload will also be a modified version of the Stephen Fewer shell_bind_tcp.

The idea is that our shellcode responds with a RST to any connection attempt coming from an IP different than the one we set in the shellcode (defined by the variable AHOST, allowed Host). This is a good way to keep the shellcode hidden from scanning tools since our socket will appear as "CLOSED" (in Windows XP you won't even see anything locally from the netstat output).

To achieve this without implementing raw sockets I have used the setsockopt API setting the SO_CONDITIONAL_ACCEPT option to true. With this configuration whenever someone tries to establish a new connection, the TCP stack will not respond with a SYN-ACK (as it does by default) but its management is delegated to the shellcode itself which will decide, based on the source IP address, whether accept or not the connection. This condition can be defined by the conditional accept callback registered with WSAAccept. 

Don't touch my shell: ACL Bind Shellcode

How many times have you used a bind shell as a persistence method? and how many of those times you have been restless thinking that someone could steal your shellcode? Personally, most of the times. Anyone snooping your target machine could get your shell using a simple netcat or even kill it with a routine Nmap scan. In the following example we have generated a bind shell (shell_bind_tcp) with a local port 12345. Once the victim (192.168.1.42) runs the payload, look what happens to the shell with the following scan:

root@krypton:~# msfvenom -p windows/shell_bind_tcp LPORT=12345 -f exe > 12345.exe
root@krypton:~# nmap -sT -p 12345 -PN 192.168.1.42 | grep open
12345/tcp open  netbus
root@krypton:~# nmap -sT -p 12345 -PN 192.168.1.42 | grep open
root@krypton:~#

The shell has gone! This is the reason why I made a shellcode that accepts requests only from the IP you want. Actually, I modified the Stephen Fewer shell_bind_tcp to add such functionality.  At first I thought to replace the accept() socket API by WSAAccept(). The reason is that this API provides a callback function that is called before a connection is accepted. Using this callback we can set conditions for accepting or not the connection (for example based on the client IP). However, implementing this in our shellcode would add too much extra weight. Since we are dealing with a single payload, where each byte is valuable, I finally opted for accept().

The syntax of this function is as follows:

SOCKET accept(

  _In_     SOCKET s,

  _Out_    struct sockaddr *addr,

  _Inout_  int *addrlen

)