|Memory of Injected Process|
|Start of Injected Code|
Horrible C code is ahead. I have not coded in C in years and even then it was not much. I should probably remove that skill from my resume. I tried to include all links or references I used. The following code was for me to learn and get back into C. Nothing original. More of me just sketching out ideas. I would not apply these techniques for incident response. It would be much much better to use Volatility for something like this.
If we were to use a tool like Process Explorer we would not see the malware running on the machine. A lot of the time the watcher process is running in the memory space of explorer.exe. Usually the injected process is wanting to be injected into iexplorer.exe, firefox.exe or chorme.exe. If we wanted to detect the malware or dump the malware the best choice would be to help out the malware by starting a browser. Then enumerate all memory sections with a protection of RWE. If we find a block of memory with this protection we dump the block of memory to a file. After that we close down the browser and exit.
Let's walk through that process. We can get the address of iexplorer.exe on Windows XP and Windows 7 by reading the default value at the registry key HKEY_CLASSES_ROOT\applications\iexplore.exe\shell\open\command, once we have the file path we open iexplorer.exe in debug mode using CreateProcessA. This will ensure that iexplorer.exe doesn't start messing with the memory protections. At this point the malware will see the new process and inject into it. We can now use VirtualQueryEx to query the memory protection. If the protection is PAGE_EXECUTE_READWRITE we will use ReadProcessMemory to read the contents and finally dump the contects to a file with the name of the memory address. What would this look like on a machine infected with Citadel and Cridex?
|Scan results on a machine infected with Cridex and Citadel|
Bibucket Repo - LINK
Source code highlighted with hilite.me