Hi Carlos,
UPX packed files will automatically decompress when they’re loaded into memory (whether
its an exe or dll). Therefore, when you dump it with procdump, dlldump, or another plugin
its already unpacked. Remember to try the “--memory” option with those plugins to preserve
slack space, which may show you different results than you’ve previously seen. If you see
section names like UPX0 in the dumped files, that doesn’t mean its STILL packed, it just
means the PE file’s original section names didn’t change when the code inside the section
was decompressed/decrypted.
MHL
--------------------------------------------------
Michael Ligh (@iMHLv2)
GPG:
On Jun 10, 2014, at 3:43 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
>>>
>