Hi Carlos, If you see the injected code with malfind, you can just use malfind --pid=PID --dump-dir=OUTDIR and it will automatically extract it to disk. Most likely the legitimate EXE isn’t removed from the process address space, so it still resides at _EPROCESS.Peb.ImageBaseAddress (which is what procexedump extracts). In other words, the process contains two EXE files now, the original one at ImageBaseAddress, and the injected one (wherever malfind says it exists). Let me know if that *doesn’t* work as expected and we can look at some other options. MHL -------------------------------------------------- Michael Ligh (@iMHLv2) GPG: http://mnin.org/gpg.pubkey.txt Blog: http://volatility-labs.blogspot.com On Apr 14, 2014, at 6:51 PM, Carlos Angeles <cangeles(a)gmail.com> wrote:

Hi Carlos, Indeed, whether you use procexedump -p PID or -o OFFSET, you’re doing the same thing - dumping the EXE located at _EPROCESS.Peb.ImageBaseAddress (in this case, the legitimate EXE). The only difference between -p and -o in this case is that the later allows you to dump a process that’s unlinked from the PsActiveProcessHead list. However, since you’ve done this and found that its not the malicious EXE, we can ignore procexedump for now. It sounds like the malicious EXE starts at 0xc80000 (this is different from _EPROCESS.Peb.ImageBaseAddress) inside the process with PID 3836. There are multiple ways to dump the malicious EXE: * malfind --pid=3836 --dump-dir=OUTDIR will create a file named according to the 0xc80000 address. That will be a copy of the unpacked malicious EXE. you may also get other files dumped if there are multiple injections in the same process. * dlldump --pid=3836 --base=0xc80000 --dump-dir=OUTDIR will explicitly extract the injected EXE, and nothing more. * use the dumpfiles plugins to find file.exe (but it will be the cached copy from disk, not unpacked) Hope this helps, Michael -------------------------------------------------- Michael Ligh (@iMHLv2) GPG: http://mnin.org/gpg.pubkey.txt Blog: http://volatility-labs.blogspot.com On Apr 15, 2014, at 6:26 PM, Carlos Angeles <cangeles(a)gmail.com> wrote:

Hello again! I have another piece of malware that is also doing process hollowing. It's the same situation as my previous email, dumping the hollowed process by PID appears to give me the same file as it exists on the filesystem, but if I use dlldump with the PID of the process and the offset given my malfind I get a different file (it even has the same offset value, 0xc80000). Dumping with dlldump gives me what appears to be an executable file. pescanner identifies it as a PE file that is UPX compressed. Using a couple PE tools I see UPX0, UPX1 and .rsrc sections but trying to decompress it with UPX gives me an error. I'm able to load it OllyDbg but I can't step through it. My question is this, is there a way to get the dumped file to a point where I can use UPX to decompress it, or manually step through it with Olly? I know with the dynamic nature of memory I may not have all the pieces to it but I'm hoping to be able to dig deeper into this malware. Thanks! Carlos On Tue, Apr 15, 2014 at 7:48 PM, Michael Ligh <michael.ligh(a)mnin.org> wrote: > Hi Carlos, > > Indeed, whether you use procexedump -p PID or -o OFFSET, you’re doing the same thing - dumping the EXE located at _EPROCESS.Peb.ImageBaseAddress (in this case, the legitimate EXE). The only difference between -p and -o in this case is that the later allows you to dump a process that’s unlinked from the PsActiveProcessHead list. However, since you’ve done this and found that its not the malicious EXE, we can ignore procexedump for now. > > It sounds like the malicious EXE starts at 0xc80000 (this is different from _EPROCESS.Peb.ImageBaseAddress) inside the process with PID 3836. There are multiple ways to dump the malicious EXE: > > * malfind --pid=3836 --dump-dir=OUTDIR will create a file named according to the 0xc80000 address. That will be a copy of the unpacked malicious EXE. you may also get other files dumped if there are multiple injections in the same process. > > * dlldump --pid=3836 --base=0xc80000 --dump-dir=OUTDIR will explicitly extract the injected EXE, and nothing more. > > * use the dumpfiles plugins to find file.exe (but it will be the cached copy from disk, not unpacked) > > Hope this helps, > Michael > > -------------------------------------------------- > Michael Ligh (@iMHLv2) > GPG: http://mnin.org/gpg.pubkey.txt > Blog: http://volatility-labs.blogspot.com > > On Apr 15, 2014, at 6:26 PM, Carlos Angeles <cangeles(a)gmail.com> wrote: > >> Thanks, Michael. I think I'm seeing the process having two EXE files. >> When I use procexedump with either the PID (-p) or physical offset >> (-o), the dumped file has the same strings as the original. >> >> The psscan plugin shows the offset to be 0x09bafc68 (I used this >> address to dump the process by offset). Below is the output for >> malfind for the suspect process. I seem to remember from class that >> we converted from a "relative" address to a physical address. Did we >> do that or am I imagining that? >> >> Thanks, >> Carlos >> >> >> Process: file.exe Pid: 3836 Address: 0xc80000 >> Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE >> Flags: CommitCharge: 22, MemCommit: 1, PrivateMemory: 1, Protection: 6 >> >> 0x00c80000 4d 5a 50 00 02 00 00 00 04 00 0f 00 ff ff 00 00 MZP............. >> 0x00c80010 b8 00 00 00 00 00 00 00 40 00 1a 00 00 00 00 00 ........@....... >> 0x00c80020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >> 0x00c80030 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 ................ >> >> 0xc80000 4d DEC EBP >> 0xc80001 5a POP EDX >> 0xc80002 50 PUSH EAX >> 0xc80003 0002 ADD [EDX], AL >> 0xc80005 0000 ADD [EAX], AL >> 0xc80007 000400 ADD [EAX+EAX], AL >> 0xc8000a 0f DB 0xf >> 0xc8000b 00ff ADD BH, BH >> 0xc8000d ff00 INC DWORD [EAX] >> 0xc8000f 00b800000000 ADD [EAX+0x0], BH >> 0xc80015 0000 ADD [EAX], AL >> 0xc80017 004000 ADD [EAX+0x0], AL >> 0xc8001a 1a00 SBB AL, [EAX] >> 0xc8001c 0000 ADD [EAX], AL >> 0xc8001e 0000 ADD [EAX], AL >> 0xc80020 0000 ADD [EAX], AL >> 0xc80022 0000 ADD [EAX], AL >> 0xc80024 0000 ADD [EAX], AL >> 0xc80026 0000 ADD [EAX], AL >> 0xc80028 0000 ADD [EAX], AL >> 0xc8002a 0000 ADD [EAX], AL >> 0xc8002c 0000 ADD [EAX], AL >> 0xc8002e 0000 ADD [EAX], AL >> 0xc80030 0000 ADD [EAX], AL >> 0xc80032 0000 ADD [EAX], AL >> 0xc80034 0000 ADD [EAX], AL >> 0xc80036 0000 ADD [EAX], AL >> 0xc80038 0000 ADD [EAX], AL >> 0xc8003a 0000 ADD [EAX], AL >> 0xc8003c 0001 ADD [ECX], AL >> 0xc8003e 0000 ADD [EAX], AL >> >> >> >> On Tue, Apr 15, 2014 at 6:08 AM, Michael Ligh <michael.ligh(a)mnin.org> wrote: >>> Hi Carlos, >>> >>> If you see the injected code with malfind, you can just use malfind --pid=PID --dump-dir=OUTDIR and it will automatically extract it to disk. Most likely the legitimate EXE isn’t removed from the process address space, so it still resides at _EPROCESS.Peb.ImageBaseAddress (which is what procexedump extracts). In other words, the process contains two EXE files now, the original one at ImageBaseAddress, and the injected one (wherever malfind says it exists). >>> >>> Let me know if that *doesn’t* work as expected and we can look at some other options. >>> >>> MHL >>> >>> -------------------------------------------------- >>> Michael Ligh (@iMHLv2) >>> GPG: http://mnin.org/gpg.pubkey.txt >>> Blog: http://volatility-labs.blogspot.com >>> >>> On Apr 14, 2014, at 6:51 PM, Carlos Angeles <cangeles(a)gmail.com> wrote: >>> >>>> Hello all, >>>> >>>> I'm analyzing a malware sample that is doing process hollowing. While >>>> doing dynamic analysis, with Process Explorer open, I can see the >>>> legitimate EXE (that appears to get hollowed) get started by the >>>> malware, and is then orphaned as the malware terminates itself. A few >>>> seconds later I see network communication starting. >>>> >>>> The malfind plugin identifies the process as malware but when I try to >>>> dump process from memory, the strings on the dumped process look the >>>> same as the strings of the legitimate file in the System32 folder. >>>> >>>> Using the yarascan plugin (following the example on the wiki) I'm able >>>> to locate some strings (domain name, IP address, file requested by >>>> GET) that are associated with the PID of the suspected hollowed >>>> process. >>>> >>>> Oh, and the malware is packed so I assume the unpacked code is being >>>> placed into the address space of the legitimate file in memory. >>>> >>>> The capture is a .vmem from a VM snapshot. >>>> >>>> Any thoughts on how I can locate the unpacked code in memory? >>>> Shouldn't dumping the PID with procexedump contain the unpacked code? >>>> I've dumped the process by PID and physical offset (from psscan). >>>> >>>> Thanks, >>>> Carlos >>>> _______________________________________________ >>>> Vol-users mailing list >>>> Vol-users(a)volatilityfoundation.org >>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >>> >