Tuesday, December 13, 2016

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.

    Friday, April 8, 2016

    Pazuzu: reflective DLL to run binaries from memory

    Most of the times I use Meterpreter in my pentest but sometimes I missed the possibility to run my own binaries from memory to carry out very specific tasks. In this type of scenario I needed a way to run a binary (a simple C application) on the victim host making as little noise as possible (so payloads like download_exe were not an option). To get this I wrote a tiny tool called Pazuzu I would like to share (currently an alpha release with ugly code; no types or macros, etc).

    Pazuzu is a Python script that allows you to embed a binary within a precompiled DLL which uses reflective DLL injection. The goal is that you can run your own binary directly from memory.

    To run the payload,  you just have to choose the stager you like (reverse TCP, HTTP, HTTPS, etc.) and set the DLL generated by Pazuzu. Pazuzu will execute the binary within the address space of the vulnerable process as long as it has the .reloc section.


    Thursday, June 4, 2015

    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:

    Monday, May 11, 2015 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.

    Wednesday, November 12, 2014

    Metasploit: Getting outbound filtering rules by tracerouting

    Deciding between a bind or reverse shell depends greatly on the network environment in which we find ourselves. For example, in the case of choosing a bind shell we have to know in advance if your machine is reachable on any port from outside. Some time ago I wrote how we can get this information (inbound filtering rules) using the packetrecorder script from Meterpreter. Another alternative is to use a IPV6 bind shell (bind_ipv6_tcp). The idea of this payload is to create an IPv6 tunnel over IPv4 with Teredo-relay through which it will make the bind shell achievable from an IPv6 address. You can read more info about this in the post: Revenge of the bind shell

    On the other hand, in the case of using a reverse shell, we must know the outbound filtering rules of the organization to see if our shell can go outside. In most situations, we usually choose 80 or 443 ports since these ports are rarely blocked for an ordinary user. However, there are cases in which we have a much more restrictive scenario. For example, if we get access to a server from an internal network and want to install a reverse shell from that server to the outside, maybe outgoing connections on ports 80 and 443 are denied. The reverse_tcp_allports() payload was created to work in such environments. This payload will attempt to connect to our handler (installed on certain external machine) using multiple ports. The payload supports the argument LPORT by which we specify the initial connection port. If It can not connect to the handler it will increase the port number 1 by 1 until a connection is done. The problem with this approach is that it is very slow due to timeouts of blocked connections. In addition, much noise is generated as a result of each of these connections.