6:26 p.m.
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