Pages

Monday, August 14, 2017

DoublePulsar SMB implant detection from Volatility

In the last months there have been various groups of attackers as well as script kiddies that have been using the FuzzBunch Framework to compromise systems.

In a recent incident while I was analyzing a memory dump It took me some time to identify that the infection vector was EternalBlue. Once I found the ring 0 shellcode (related to DoublePulsar) I was able to approach the analysis more easily. To expedite this process for future analysis I have developed a dummy plugin to make easy to find this implant.

The plugin is not based on Yara rules. It just dumps the array of functions pointers SrvTransaction2DispatchTable from the srv.sys driver and checks that all of them points to the binary address space (take a look at the nice Zerosum0x0 analysis). Note that although the plugin dumps the whole table it would really only be necessary to verify that the SrvTransactionNotImplemented symbol points to the correct place.

The plugin resolves SrvTransaction2DispatchTable by getting the .pdb path from the debug directory section and downloads it from http://msdl.microsoft.com/download/symbols (or the server you provide with the SYMBOLS option). Once it gets the symbol offset it just dumps the array of pointers. If SrvTransactionNotImplemented (entry 14) points to an "unknown" location possibly your are dealing with DoublePulsar. It that case volshell and dis() will clear up any doubts.

Let see an example. The following image comes from a Windows 7 SP1 x64 host which has been attacked with EternalBlue + DoublePulsar:


Tuesday, May 23, 2017

Post-exploitation: Mounting vmdk files from Meterpreter

Whenever I get a shell on a Windows system with VMware installed I feel a certain frustration at not being able to access the filesystem of the available virtual machines. Although it would be possible to download the .vmdk files to my host and mount them locally this solution is very noisy and heavy due to their high size. The ideal solution would be the one where you could mount the corresponding vmdk files on the “victim's system” using the own resources offered by the VMware installation.

This made me remember the malware developed by Hacking Team, dubbed as Crisis or DaVinci. You can find a nice analysis here. One of the post-exploitation techniques used by DaVinci is the possibility to mount .vmdk files by making use of the driver vstor2 provided by some versions of VMware.  Since the source code was leaked I decided to keep an eye on it to see how they implemented that functionality. You can find that code in the HM_PDAAgent.h file.

However, the way in which they do this functionality is quite limited and not very clear. Look, for example, the following code.



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.

    reloc.png

    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: