Pages

Friday, November 1, 2019

Retro shellcoding for current threats: rebinding sockets in Windows

In previous posts we saw two techniques to bypass firewalls through custom stagers to locate and reuse the connection socket; on the one hand, taking advantage of socket's lifetime and on the other, embedding OOB (Out Of Band) data in the stream of our exploit.

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.


Let's see another example. In March 2013, researchers from Malware.lu CERT published a report about APT1 in which they describe how they designed a custom shellcode to maintain access to the bad guys' infrastructure who used Poison Ivy to infect their victims. Initially, they run a standard stager (reverse shell) to gain access to the Poison Ivy server; however the attackers detected connections from their C2 server without going through its proxy identifying this way the intrusion. In order to stay stealth the people of Malware.lu crafted a shellcode to reuse the Poison Ivy socket and thus be able to connect to it through their proxy imitating a legitimate malware infection. Cool!

Related to this last example, and continuing with the one-way shellcodes saga, I would like to share a shellcode to rebind sockets. Remember that these kind of techniques are useful when network conditions prevent running a reverse shell and when it is not possible to do socket-hunting (and of course when the socket is in the same exploited process). Unlike the two cases described in previous posts, with this approach we are not doing brute force of the process handles, but we are simply trying to execute a bind shell in the same port as the one used by the vulnerable service. Of course this idea is not new, you can take a look for example at Phrack 62 (Rebind socket shellcode implementation) to see in detail this kind of techniques. Or you can look at this 2002 presentation of "The Last Stage of Delirium" hacker group: "Win32 Assembly Components". Yes, almost 20 years ago old-school hackers already devised these kind of nifty techniques.

The interesting thing is that despite the age of these techniques, their use today can still be of great help in some scenarios; for example, I have found it useful when it comes to exploit some C2 servers used by certain malware (mainly because many of them are not very complex in terms of managing connections)

The proofs of concept that I have seen to do rebinding are mainly based on 2 approaches: using setsockopt along with the SO_REUSEADDR option which allows the socket to be bound to an address that is already in use, or ending the vulnerable service to reuse the same port. Since the first option is unstable and not useful in applications that use SO_EXCLUSIVEADDRUSE I will focus on the second option contributing with some nuances regarding the POCs I've seen.

Well, the goal of this approach is that once the corresponding service is exploited, the shellcode generates a new process in which it will inject the payload responsible for configuring the bind shell in the appropriate port. However, there are two problems here. The first and more important is that if you try to run a bind shell in the address space of a process, by default, Windows firewall will block it (most of the POCs I have seen migrate to a different process, for example cmd.exe, however, in practice this is not feasible precisely because of the Windows firewall). The second minor problem is that, even if the firewall allowed to open the socket, we would have to wait for the legitimate process (the one we just exploited) to finish its execution since we have to bind it in the same port (some shellcodes configure a kind of loop that tries to bind it until the main process "releases" it).


Friday, March 15, 2019

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.


Thursday, December 27, 2018

DNS Polygraph: tool designed to make easier the identification of techniques such as DNS Hijacking/Poisoning

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.

Organizing the answers in this way saves me a lot of work, allowing me to focus only on the apparently unrelated responses.

The graphical interface of the application is shown below.  You just have to select the network interface and click on the Capture button. After clearing the cache DNS it will start getting the responses from your resolver.  The datagrid columns are self-explanatory except perhaps the one called "R". This indicates the DoH resolver selected (G for Google and C for CloudFlare). Here an example:


Sunday, June 3, 2018

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.


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.