Hmm sorry, I must be reading the GMER log incorrectly:
IAT C:\Program Files\Windows NT\svchost.exe[464] @ C:\Program
Files\Windows NT\svchost.exe [KERNEL32.dll!GetFileType]
E80C244C
I thought that was saying functions in kernel32.dll's IAT were hooked, but
I think its saying the IAT entries in svchost.exe for kernel32 APIs are
hooked. So in that case I'd need you to use procexedump -p 464 and send the
extracted svchost.exe.
Also if that number at the end (E80C244C) is the address of the hook,
something is seriously wrong because that's an address in kernel space.
Hooray for log files with no meaningful labels ;-)
MHL
On Thu, Jan 17, 2013 at 1:09 PM, Mike Lambert <dragonforen(a)hotmail.com>wrote:
> MHL,
>
> Thank you very much. Attached is a ZIP. (Rocra is the short name) I used
> Volatility 2.1
>
> C:\Python27\volatility-2.1>vol.py dlldump -f
> E:\Tests\130115b\Vol\130115b.w32 --profile=WinXPSP3x86 -p 464 -D
> E:\Tests\130115b\Vol\dlldump > E:\Tests\130115b\Vol\dlldump.txt
>
> Volatile Systems Volatility Framework 2.1
>
> C:\Python27\volatility-2.1>
>
> Have a good day,
> Mike
>
> ------------------------------
> Date: Thu, 17 Jan 2013 12:47:54 -0500
> Subject: Re: [Vol-users] IAT hook question
> From: michael.hale(a)gmail.com
> To: dragonforen(a)hotmail.com
> CC: vol-users(a)volatilityfoundation.org
>
>
> Mike, if you could use dlldump and extract kernel32.dll from pid 464 and
> send it to me, I'll take a look. The necessary pages of the PE file may
> just not be memory resident.
>
> MHL
>
>
> On Thu, Jan 17, 2013 at 12:31 PM, Mike Lambert <dragonforen(a)hotmail.com>wrote:
>
> I am looking at a Red October infection. The malware is svchost PID 464,
> C:\Program Files\Windows NT\svchost.exe
>
> GMER tells me that the IAT is hooked. See attached.
>
> I wanted to see this with Volatility per the apihooks documentation here
> http://code.google.com/p/volatility/wiki/CommandReferenceMal22
>
> "As of Volatility 2.1, apihooks also detects hooked winsock procedure
> tables, includes an easier to read output format, supports multiple hop
> disassembly, and can optionally scan quicker through memory by ignoring
> non-critical processes and DLLs.
>
> Here is an example of detecting IAT hooks installed by Coreflood. The
> hooking module is unknown because there is no module (DLL) associated with
> the memory in which the rootkit code exists. If you want to extract the
> code containing the hooks, you have a few options: "
>
>
> I tried apihooks in Volatility 2.1 and 2.2, below is the result
>
> C:\Python27\volatility-2.1>vol.py -f E:\Tests\130115b\Vol\130115b.w32
> --profile=WinXPSP3x86 -p 464 apihooks
> Volatile Systems Volatility Framework 2.1
>
> C:\Python27\volatility-2.1>
>
> -------------------------
>
> C:\Python27\volatility-2.2>vol.py apihooks -f
> E:\Tests\130115b\Vol\130115b.w32 --profile=WinXPSP3x86 -p 464
> Volatile Systems Volatility Framework 2.2
>
> C:\Python27\volatility-2.2>
>
> =========================
>
> My question is, "what am I doing wrong?" It is probably something simple.
>
> Thanks for the help,
> Mike
>
>
> _______________________________________________
> Vol-users mailing list
> Vol-users(a)volatilityfoundation.org
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>
>
>
I am looking at a Red October infection. The malware is svchost PID 464, C:\Program Files\Windows NT\svchost.exe
GMER tells me that the IAT is hooked. See attached.
I wanted to see this with Volatility per the apihooks documentation here
http://code.google.com/p/volatility/wiki/CommandReferenceMal22
"As of Volatility 2.1, apihooks also detects hooked winsock procedure tables, includes an easier to read output format, supports multiple hop disassembly, and can optionally scan quicker through memory by ignoring non-critical processes and DLLs.
Here is an example of detecting IAT hooks installed by Coreflood. The hooking module is unknown because there is no module (DLL) associated with the memory in which the rootkit code exists. If you want to extract the code containing the hooks, you have a few options: "
I tried apihooks in Volatility 2.1 and 2.2, below is the result
C:\Python27\volatility-2.1>vol.py -f E:\Tests\130115b\Vol\130115b.w32 --profile=WinXPSP3x86 -p 464 apihooks
Volatile Systems Volatility Framework 2.1
C:\Python27\volatility-2.1>
-------------------------
C:\Python27\volatility-2.2>vol.py apihooks -f E:\Tests\130115b\Vol\130115b.w32 --profile=WinXPSP3x86 -p 464
Volatile Systems Volatility Framework 2.2
C:\Python27\volatility-2.2>
=========================
My question is, "what am I doing wrong?" It is probably something simple.
Thanks for the help,
Mike
Hello All,
We were writing to announce the first annual Volatility framework
plugin writing contest:
http://volatility-labs.blogspot.com/2013/01/the-1st-annual-volatility-frame…
This contest is modeled after the well-known Hex-Rays plugin contest,
and we hope to attract the same level of high-quality submissions as
seen in the IDA contests.
To the winners we offer a variety of cash prizes, recognition, and a
chance to speak at our yearly conference.
If you have any questions or comments please contact me directly or
use the contact information listed in the blog post.
Thanks,
Andrew
All,
So over the course or Luka's thread on his research the subject of testing
your acquisition tools came up.
I know this topic has been mentioned before (in one of my own past posts),
but what is the requirement for memory acquisition tools to be working
"properly"? Especially since each time you run the test against a memory
image that image has changed.
What steps, at a minimum, should you be making sure that the tool you are
using/evaluating is doing what it should be doing? Listing processes
correctly? Showing the correct artifacts if I have Zeus on the image?
The topic always seems to come up (even with physical devices) that you
have to test your tools, with no one ever saying what checkmarks you have
to make sure the tools does.
Thanks,
Tom
I think it would be a good idea to compile a list of the malware that can defeat *any* memory forensics acquisition tool as of January 2013.
Of course the tool should be identified, the technique used to defeat it, and the curent malware that has the capability. Not all tools would be vulnerable to each technique.
Does anyone think this is not a good idea?
Best,
Mike
Hi George, and everyone else on the list.
I don't know if you watched/skimmed through the presentation or the talk,
but I want to emphasize that I really like Volatility and that my work is
not a research against Volatility (or any other tool in particular) in any
way.
Volatility is my primary choice when doing memory analysis both because of
speed, abundance of features and plugins and openness of the tool.
I do however mention Volatility in couple of places, for example, I suggest
creating a plugin for scanning handle table allocations (Obtb) as an
alternative to currently used method.
> It is nice to see someone looking critically at the subject matter, even
> if in an over-simplistic manner. The gist of the article is that you
> can easily scrub evidence from a memory dump as it is being written (in
> plain text) to disk or to the net. Duh!
Thanks for your support.
Although I agree some things were over-simplified, I don't agree that my
research in whole is over-simplistic.
The idea is simple and well known enough, still, it is not that commonly
being taken into consideration when performing forensic analysis, at least
from my experience.
> A few comments on the author's conclusions:
Too bad you pulled out the conclusions since this slide is by far the
weakest in the whole presentation;)
> 1. Acquisition tools should utilize drivers correctly!
> Duh!
I didn't quite understand if you meant that ironically or not. However,
almost all tested acquisition tools utilize drivers incorrectly, meaning
that they transfer the pages back to UM and then write them to dump (usually
with completely inadequate permissions).
> 2. Use hardware acquisition tools, e.g. firewire.
> However, hardware-based acquisition also can be defeated. At a minimum
> you can program an upper limit on the memory address that the firewire
> is allowed to access and then place your rootkit above that address.
> Most new computer systems have more than 4 GiB of memory nowadays.
I didn't say that hardware acquisition methods are infallible. You're
absolutely right regarding the 4 GB limit. But from an attacker's
perspective, this method cannot be used for hiding arbitrary object, and it
might be difficult to "relocate" the driver, allocations and all resources
above the specified limit.
I'm evaluating some additional weaknesses of the firewire acquisition and
methods of hiding arbitrary objects, but so far, my research showed no
progress...
And yes, I am definitely aware of other alternatives (cold boot etc.), but I
think they are highly impractical so I didn't mention them in my
presentation.
> 3. Use crash dumps (native!) instead of raw dumps.
> Should maybe introduce the author to all those rootkits (e.g. Sinowal)
> that remove themselves from crashdump as it is being written.
I thought that I have a very good knowledge of rootkits and low level
malware, but I don't recall Torpig/Sinowal doing anything about removing
itself from the crash-dump.
In fact, I cannot remember any rootkit or malware removing its artifacts
from the crash-dump, so please introduce me to all such rootkits:)
There are some KeBugCheckEx() tampering "malware" variants, but they are
mostly related to PatchGuard bypass.
Crash dump mechanism is fairly complex, involves couple of checksums and
does not use the underlying file system - it writes the dump to raw disk
sectors.
The weakest link in this process from my perspective is the process of
booting the machine and calling of SmpCheckForCrashDump() function - this is
the point when malware can finally see the resulting crash dump and remove
the artifacts from it.
This is far from being trivial, however.
> 4. Perform anti-rootkit scanning before acquisition?
> Easier said than done. Just ask A/V industry.
This is a stupid conclusion on my side. No, really, I said that during the
talk:)
> 5. Live forensic is inherently insecure!
> Duh! Real question is not whether or not you can cheat memory
> acquisition software. It is whether you can cheat memory acquisition
> software and have no one know about it. Knowing that a system is
> infected is 90% of the battle even if you don't know how. Once I know
> that a system is infected I will find the rootkit.
My talk was all about cheating the memory acquisition software and have no
one know about it:)
It's not that my tool is invisible - the truth is actually totally opposite
ON PURPOSE.
I didn't want to add advanced self-hiding features, because I'm not trying
to create a tool that bad guys can use in the wild. I just wanted to raise
awareness and present my research.
And again, it depends on what you are trying to find:) If you're trying to
find _traces_ of malware (mostly orphaned or invalid resources, such as
locks, mutants etc.), you will most certainly succeed in this, because by
theory it is impossible to hide everything (the malware executes, therefore
it is present and visible).
If your goal is to find some more valuable artifacts (processes, memory
allocations, files, etc.), you might fail even if you are certain in rootkit
existance, simply because the rootkit (or my tool in this case) has deleted
such artifacts from the dump.
In the end, I really don't want to be perceived as a guy wearing a wrong
hat. My research is not aimed against any particular product, or the memory
forensics field in general. My research is not a revolutionary new
anti-forensic method. It's an implementation of well known anti-forensic
techniques and proof of concept for removing arbitrary artifacts from the
memory dump with the intention of raising the awareness and creating better
memory forensics software.
Best regards,
Luka
--
Luka Milković
Information security consultant
e-mail: luka.milkovic(a)infigo.hr
INFIGO IS d.o.o.
Horvatovac 20, 10000 Zagreb
www: http://www.infigo.hr
Hello,
We were writing to announce that the next public offering of Windows
malware and memory forensics training by Volatility developers has
been set for March 18-22rd in Chicago.
Full details can be found here:
http://volatility-labs.blogspot.com/2013/01/windows-malware-and-memory-fore…
If you have any questions or comments then please contact me directly
or use the information listed on the blog post.
Thanks,
Andrew (@attrc)
Please forgive my noobness.
I am new to Volatility and just viewed a discussion on memory
acquisition problems and the malware removing itself from the memory
before it was written to file for later analysis.
Does malware such as Rustock.C leave any traces behind such as portions
of the program used to "remove" itself from memory but cannot completely
remove itself?
Of if not, how do the researchers know it was present? Did they do a
controlled infection and watch it remove itself by other means?
Thanx
Julian
I have found that in Volatility 2.1 and 2.2 connscan is not supported for profile Win7SP1x86. Volatility 2.0 does not produce any results. (??)
I see that sockets and sockscan are also not supported in Volatility 2.2. See below.
pslist does work, so some commands are supported.
Is this a known issue?
----------------cut-here-------------------
C:\Python27\volatility-2.2>vol.py imageinfo -f g:\victim1.w32
Volatile Systems Volatility Framework 2.2
Determining profile based on KDBG search...
Suggested Profile(s) : Win7SP0x86, Win7SP1x86
AS Layer1 : JKIA32PagedMemoryPae (Kernel AS)
AS Layer2 : FileAddressSpace (G:\victim1.w32)
PAE type : PAE
DTB : 0x185000L
KDBG : 0x82761be8L
Number of Processors : 2
Image Type (Service Pack) : 0
KPCR for CPU 0 : 0x82762c00L
KPCR for CPU 1 : 0x807c0000L
KUSER_SHARED_DATA : 0xffdf0000L
Image date and time : 2013-01-04 20:41:23 UTC+0000
Image local date and time : 2013-01-04 14:41:23 -0600
C:\Python27\volatility-2.0>vol.py connscan -f h:\victim1.img --profile=Win7SP1x86
Volatile Systems Volatility Framework 2.0
Offset Local Address Remote Address Pid
---------- ------------------------- ------------------------- ------
C:\Python27\volatility-2.1>vol.py connscan -f h:\victim1.img --profile=Win7SP1x86
Volatile Systems Volatility Framework 2.1
Offset(P) Local Address Remote Address Pid
---------- ------------------------- ------------------------- ---
ERROR : volatility.plugins.connscan: This command does not support the selected profile.
C:\Python27\volatility-2.2>vol.py connscan -f g:\victim1.w32 --profile=Win7SP1x86
Volatile Systems Volatility Framework 2.2
Offset(P) Local Address Remote Address Pid
---------- ------------------------- ------------------------- ---
ERROR : volatility.plugins.connscan: This command does not support the selected profile.
C:\Python27\volatility-2.2>vol.py sockets -f g:\victim1.w32 --profile=Win7SP1x86
Volatile Systems Volatility Framework 2.2
ERROR : volatility.plugins.sockets: This command does not support the selected profile.
C:\Python27\volatility-2.2>vol.py sockscan -f g:\victim1.w32 --profile=Win7SP1x86
Volatile Systems Volatility Framework 2.2
Offset(P) PID Port Proto Protocol Address Create Time
---------- ------ ------ ------ --------------- --------------- -----------
ERROR : volatility.plugins.sockscan: This command does not support the selected profile.
Has anyone done any research about parsing prefetch files out of memory images? I was working with the latest version of volatility 2.3 and found the mftparser plugin very helpful. I was looking specifically at prefetch files and looking to possibly parse the prefetch files if they exist in memory to see what files may have been accessed by specific executables.
Just wondering if anyone has looked at this or thought about developing a plugin around this?
Dave
