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.
