Pages

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.