The truth is that this topic has always fascinated me despite I didn't find many public shellcodes that try to circumvent restrictive network environments (especially in Windows). What is evident is that having some skills in the development of shellcodes allows you to work wonders. Look for example at this remote exploit developed by HD Moore in Veritas Backup software. Due to the space restrictions to execute code (about 50 bytes), the payload gets the recv() address from the IAT and use it to stage the rest of the payload. This is pure art.

Friday, March 15, 2019

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.

Thursday, December 27, 2018

Some time ago I had to research an alleged case of DNS Interception in a somewhat hostile Windows environment. Part of the job was to sniff all DNS responses from the corresponding resolver with tools like Tshark/RawCap and verify if these were legitimate or not. To do this check I basically used services like Whois, DoH (DNS over HTTPS), etc.

As a result of this case it occurred to me to create a simple tool that would allow me to automate this process so that I could visually analyze the DNS responses and reveal just those that could be potentially harmful. The result of this idea is: DNS Polygraph.

DNS Polygraph is developed in C# and relies on both: the nice SharpPcap library of Chris Morgan and a cute DNS library I found on the Github of Mirza Kapetanovic. At first I opted to use raw sockets but after doing some tests I realized that these had multiple limitations and performance issues. Due to this I came to the conclusion that it was more stable to rely on WinPcap for the capture of UDP packets.

The idea of DNS Polygraph is to show you in a datagrid each DNS response that your host receives (called by the tool as “untrusted response”) and compare this with a response from a trusted source made over HTTPS. So for every DNS response that your host receives a DNS request will be done over HTTPS. Currently you can choose between the Google DoH service or the Cloudflare one.

Both responses (trusted and unstrusted) will be compared and, if they do not match, different colors will indicate the level of relationship that exist between both responses. For now, the criteria I have used is the following:

Check if both responses, trusted and untrusted, belong to the same /24 network.

If not, check if both responses, trusted and untrusted, belong to the same /16 network.

If not, It makes a reverse DNS lookup of both responses and check if they have a second domain level in common.

Sunday, June 3, 2018

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.

Monday, August 14, 2017

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

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

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:

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.

The attacker uploads the payload to the PLC's memory.

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

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.