One-Way Shellcode for firewall evasion using Out Of Band data

In a recent post I was talking about a shellcode technique to bypass firewalls based on the socket's lifetime which could be useful for very specific exploits. Continuing with this type of shellcodes (reuse socket/connection) I would like to share another technique that I have used with certain remote exploits for Windows; especially in scenarios in which I know in advance that the outgoing traffic is blocked by a firewall and where a reverse shell is not possible.

I have to say that the idea is not new, at least for Linux systems. In fact, it was as a result of finding this old thread some years ago, in which the author bkbll (one of the collaborators of HTRAN by the way) uses a cute trick to reuse connections, the reason for making my own implementation for Windows. Remember, as I mentioned in my last post, that this kind of shellcodes are very particular and only valid for certain types of exploits,  something that requires some effort at times. Possibly the difficulty and the time required to adapt them to each target (whenever posible) is the main reason why attackers and pentesters tend to use "universal" payloads instead. 

OOB Data

Despite being little known, TCP allows you to send "out of band" data in the same channel as a way to indicate that some information in the TCP stream should be processed as soon as possible by the recipient peer. This is typically used for some services to send notice of an exceptional condition; for instance, the cancellation of a data transfer. 

A simple way to send OOB data is through the MSG_OOB flag from the send function. When this is done, the TCP-stack build a packet with the URG flag and fill the Urgent Pointer with the offset where the OOB data starts.

Windows reuse shellcode based on socket's lifetime

I've always been a big fan of the old sockets reuse techniques: findtag, findport, etc.; each with its advantages and disadvantages. This type of shellcodes usually demand multiple requirements. The main one is that the exploited process must own the socket descriptor/handle and many many times this is not possible. In addition, even if you find the right socket another thread could use it before and disrupt the process. Other hurdle is that each shellcode should be tuned for each particular exploit most of the time. For instance, by using findtag you need to know the exact amount of bytes that the application must read before being exploited in orden to send the appropiate tag at the correct offset.

In spite of these drawbacks, using these as well as other ingenious techniques to reuse sockets, whenever possible, can make the difference between getting a shell or not, especially if a restrictive firewall prevents incoming/outgoing connections (which would foil the "typical" bind/reverse stagers). 

In this post I'd like to share a new idea? to locate the socket that it might be useful in certain scenarios. Specifically I think it can be interesting in services where a normal TCP connection is relatively short: DNS services, printer/logging daemons, etc. Please leave me a comment if you have seen this or a similar shellcode in the wild.

The idea is to take advantage of the service timeout to extend the lifetime of the connection to make it distinguishable from others sockets. After that idle time we can use the getsockopt API along with SO_CONNECT_TIME (SOL_SOCKET option) to go through all the handles and identify the socket whose lifetime exceeds X seconds.  In a DNS service, for instance, where a normal TCP query could last less than one second, would be sufficient to wait several seconds after the 3-way handshake.

The following scheme illustrates this.

Modbus Stager: Using PLCs as a payload/shellcode distribution system

This weekend I have been playing around with Modbus and I have developed a stager in assembly to retrieve a payload from the holding registers of a PLC. Since there are tons of PLCs exposed to the Internet, I thought whether it would be possible to take advantage of the processing and memory provided by them to store certain payload so that it can be recovered later (from the stager).

So, the scenario is as follows:

1. An attacker locates a PLC exposed to the Internet with enough space to store certain payload. It’s easy to find Modbus devices with tens of KB available.
2. The attacker uploads the payload to the PLC's memory.
3. The attacker infects one host with a dropper that uses the stager to “speak” Modbus and to retrieve the stage from the PLC and to execute it.

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:

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

)