Malfind cannot detect an injected DLL

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Running my own .exe file which will inject my own DLL into explorer.exe, 
running on a VM machine.

2. Acquiring the memory dump of that VM and running malfind plugin using 
volatility.

What is the expected output?
According to the documentations, I should have malfind flagging explorer.exe 
out with VadS tag.

What do you see instead?
explorer.exe was not flagged out at all.

What version of the product are you using? On what operating system?
Volatility-2.0 on a WinXP SP2/3 memory dump.

Please provide any additional information below.
Only process such as winlogon.exe was shown by malfind, which I filtered out as 
false positive. This was due because the image was a brand new set-up.

The simple DLL created pops up a message box and runs the notepad.exe.

Using Process Explorer, I'm able to see Project1.dll is loaded into 
explorer.exe.

I've attached both the source code for the .exe and .dll file before 
compilation, using c++. Is there a problem with malfind or is there a problem 
with my code?

Original issue reported on code.google.com by AntiqueS...@gmail.com on 13 Jan 2012 at 6:10

Attachments:

• main.cpp
• Project1.cpp

[GoogleCodeExporter]

Original comment by jamie.l...@gmail.com on 13 Jan 2012 at 2:28

[GoogleCodeExporter]

> Is there a problem with malfind or is there a problem with my code?

Neither. The technique you use (CreateRemoteThread->LoadLibraryA) injects the 
DLL but doesn't hide it. Since its not hidden, you can just use 
[http://code.google.com/p/volatility/wiki/CommandReference#dlllist dlllist]. 
The purpose of malfind is to locate DLLs that aren't visible with standard 
tools/methods. The fact that you can see Project1.dll with Process Explorer is 
a good hint that malfind will not detect it...because there's no reason to flag 
it - it's already visible. 

> According to the documentations, I should have malfind flagging explorer.exe 
out with VadS tag.

Negative. The malware we wrote about in the documentation injected a DLL, but 
not using the CreateRemoteThread->LoadLibraryA technique. If you find the 
address where Project1.dll is loaded in explorer.exe using the  
[http://code.google.com/p/volatility/wiki/CommandReference#vadinfo vadinfo] 
command, you'll see it has a Vad or Vadl tag (as do all DLLs loaded with 
LoadLibrary). 

Original comment by michael.hale@gmail.com on 13 Jan 2012 at 3:43

[GoogleCodeExporter]

By the way, I updated our command reference to clarify 
(http://code.google.com/p/volatility/wiki/CommandReference#malfind). Thanks and 
good question!

Original comment by michael.hale@gmail.com on 13 Jan 2012 at 4:15

[GoogleCodeExporter]

I'm marking this as invalid, simply because it wasn't about a bug in 
volatility.  Hopefully it answered your question Antique?  If not, do please 
feel free to reopen the issue...

Original comment by mike.auty@gmail.com on 13 Jan 2012 at 7:46

• Changed state: Invalid

[GoogleCodeExporter]

Thanks a lot Michael! Your reply really helped me answer my question.

Yes, my doubts have been cleared. Please do mark it as invalid. Thanks Mike.

Original comment by AntiqueS...@gmail.com on 16 Jan 2012 at 1:33