Blackhat Training is almost here!

I am gearing up for the Blackhat Training session on Monday-Tuesday of next week. We have made room for 30 students. We spent almost four weeks working on materials, remastering the demo and recap videos, and collecting malware samples that illustrated each of the subjects we are presenting. The task was alot harder than I originally expected, especially the collection of malware. I discovered a great trick using our feed processor, which is the clever use of search terms against strings to locate malware that were using specific techniques, keylogging methods, hooking styles, even specific languages. We have a solid methodology we teach behind our Responder product, so I had to find malware that illustrated specific concepts, as opposed to tailoring a training around whatever malware happened to be available. I will try to keep the training as high level as I can, and stay out of disassembly code as much as possible, but as expected there are some key reversing skills that can never be avoided, such as the reconstruction of parameters passed to a call. But, as for arithmetic and hard logic reconstruction, the only exercise where we get into that level of detail will be the one on crypto and stego. We have one coding exercise using the new built-in scripting interface, so thats a short bit of hardcore fun as well. But most of the material is about getting reverse engineering done rapidly, getting what you need, and not bogging down - which is the name of the game.

Reverse engineering process-injecting malware

I posted a video demonstrating some RE work with Responder:

Process Injecting Malware

The RE process starts by searching a livebin's symbols for "remote". A livebin is the in-memory version of an EXE as extracted by Responder. It’s not an executable format, but instead represents the exact layout of the PE formatted file once it loads into virtual memory. Section information does not need to be interpreted to remap the binary in this case, as the OS loader has already done that, including remapping and any other modifications that are made to the layout of code and data at runtime. Many malware programs will be packed on disk, but the livebin will contain large unpacked sections that can be analyzed without the RE having to know anything about the packing methods used, as in effect they are already unpacked for you.

The symbol "CreateRemoteThread" is of interest. For process injection malware you will find this API call almost 100% of the time. There are a few other API calls that are used in conjunction. We drag the symbol to the canvas and examine the region around it. Specifically, we see WriteProcessMemory and VirtualAllocEx - this is a dead giveaway that process injection is in use. Usually a malware will inject a thread that points to the function "LoadLibrary" with the first argument being a path to a DLL that was decompressed to disk - typically in a temporary directory. This is part of the malware's installation system.

In the example, we find that a PID is used to locate a process to inject into. We follow this PID and find the argument is used with LEA. In this case, the LEA is like using the address-of operator in 'c' code.

Imagine the following code:
void *myFunctionPointer;
some_function_call( &myFunctionPointer );


The "some_function_call" is getting a reference to myFunctionPointer, and this means it has the ability to initialize or assign a value into myFunctionPointer. The LEA instruction you see in the video is the assembly version of this same operation. We see this, and follow the function to find a loop where ToolHelpSnapshot32 is used. The toolhelp API set is another very suspicious behavior - if you see this in a potential malware you are very likely dealing with something that enumerates other processes on the system. This is usually a step prior to injection (or an attempt to find a virus scanner or firewall exe and kill it).

There is a string comparison in the process hunting loop - so the malware author is attempting to find a process by name. We follow the arguments back up and see that it's searching for "explorer.exe". The steps shown in the video require moderate-level RE skills, but are not daunting. With a little practice you can follow arguments in and out of function calls without losing your place. The trick is simply to remember that arguments are usually a positive base off of EBP, and local variables are a negative offset. "Parameters are Positive" - use that rule to remember.

The is one exception that is likely to drive you crazy - malware written in Delphi (and there is ALOT of that) usually passes parameters in registers. This can be harder to follow, but again if you label the arguments going into the function you can see these labels at the function boundaries so you don't lose your place.