7:19 p.m.
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
3:13 p.m.
New subject: 29c3 defeating windows memory forensics
This paper may be of interest to the list:
http://events.ccc.de/congress/2012/Fahrplan/attachments/2231_Defeating%20Wi….
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!
A few comments on the author's conclusions:
1. Acquisition tools should utilize drivers correctly!
Duh!
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.
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.
4. Perform anti-rootkit scanning before acquisition?
Easier said than done. Just ask A/V industry.
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.
4:09 p.m.
New subject: 29c3 defeating windows memory forensics
Hi George,
Nice find, thanks for posting. What ever happened to Tribble?
A few things that appear to be missing, virtualisation and "cold boot".
The greatest challenge is the ability to acquire physical memory remotely or within a
sensible time. A certain amount of preparedness is required which is sadly lacking when it
comes to system hardening.
Jon.
________________________________
From: George M. Garner Jr. <ggarner_online(a)gmgsystemsinc.com>
To: vol-users(a)volatilityfoundation.org
Sent: Saturday, December 29, 2012 8:13 PM
Subject: [Vol-users] 29c3 defeating windows memory forensics
This paper may be of interest to the list:
http://events.ccc.de/congress/2012/Fahrplan/attachments/2231_Defeating%20Wi….
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!
A few comments on the author's conclusions:
1. Acquisition tools should utilize drivers correctly!
Duh!
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.
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.
4. Perform anti-rootkit scanning before acquisition?
Easier said than done. Just ask A/V industry.
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.
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilesystems.com/mailman/listinfo/vol-users
5:56 p.m.
New subject: 29c3 defeating windows memory forensics
On 12/29/2012 4:09 PM, Echo6 wrote:
Also has two problems:
1. Incident responder must be smarter than average bear to accomplish
without wiping memory. This may be overly burdensome for some
organizations. :-)
2. Like DMA memory acquisition, "cold boot" view of memory may not be
identical to the processor's view of memory. "Cold boot" memory needs
to be reconstructed. Also, some degradation is inevitable. Of course
if all you are doing is scanning memory for encryption keys that doesn't
take much.
Hi George,
Nice find, thanks for posting. What ever happened to Tribble?
Two problems:
1. Is hardware-based and therefore $$$; and
2. Must be pre-deployed and not on a lot of systems that you want to
analyze because of $$$.
A few things that appear to be missing, virtualisation
Yes, interesting topic and a lot of possibilities but needs to be
addressed critically because process of "suspending/freezing" guest VM
may not be lossless. In principle, it should be possible to reconstruct
the memory address space of the guest VM's from the memory of the root
partition. In the case of VirtualBox and KVM you have the source code
so I don't know why someone doesn't do it. The root partition is also a
VM when hypervisor is enabled, btw.
and "cold boot".
The greatest challenge is the ability to acquire
physical memory
remotely <
Ambiguous statement. Do you mean:
1. Acquire memory to the net with physical access; or
2. Acquire memory (and other evidence) from a remote networked system
with which you have a trust relationship (e.g. is part of your domain)?
or within a sensible time. <
A better question would be how to acquire memory RELIABLY within a
sensible time WITHOUT CORRUPTING THE MEMORY OF YOUR MISSION CRITICAL
SERVERS which will continue running for an extended period of time after
you acquire memory. There are a number of memory acquisition tools
which acquire memory fast. But then they will crash some systems and
sometimes you get a memory dump with all zeroes in it. That's if you
are lucky. The more probable result of fast memory acquisition is to
corrupt some random data with no apparent consequence, until one day...
Back about 10 years ago Rob Lee gave a talk at one of the first SANS
conferences back when he was still auditioning to teach at SANS in which
he described acquiring a hard drive a few bytes at a time from an
infected system to avoid tipping off the "bad guy." Very smart guy that
Rob Lee! In the typical case a computer has been infected for ~4 months
before the infection is discovered (according to a Verizon threat report
from a few years ago). So what is it that you hope to accomplish by
being "fast." What most people need is some software to generate a nice
pretty report for their boss to read while they quietly collect the real
evidence. :-)
Regards,
George.
6:09 p.m.
New subject: 29c3 defeating windows memory forensics
On 12/29/2012 5:56 PM, George M. Garner Jr. wrote:
Back about 10 years ago Rob Lee gave a talk at one of
the first SANS
conferences back when he was still auditioning to teach at SANS in which
he described acquiring a hard drive a few bytes at a time from an
infected system to avoid tipping off the "bad guy." Very smart guy that
Rob Lee!
A few bytes at a time over a one month period, I meant to say.
10:07 p.m.
Hi Dave,
Actually I have looked a little at carving prefetch files from memory-
it hasn't yet proved fruitful in a case. It seems that prefetch files
may not be entirely in memory, but you can find the header (which
actually differs a little bit from the one on disk) and some partial
data, like up to the prefetch file name ([name-hash.pf]).
The prefetch name alone has been helpful in some cases where we were
able to tell where malicious files had been run from, by analyzing the
hash. I have a script that generates the prefetch filename based on
the path (except for hosted programs in this script) that I released a
little over two years ago:
https://github.com/gleeda/misc-scripts/blob/master/prefetch/prefetch_hash.py
and I have other versions that brute force paths and use precalculated
whitelists of known executables etc.
It also appears that prefetch files are not obtainable using the
dumpfiles plugin.
As far as I know no one has yet released a plugin that scans
for/carves out prefetch files. It will be interesting to see what you
come up with! Let us know if you want to write up a plugin and need
any help.
All the best,
-gleeda
On Thu, Dec 27, 2012 at 7:19 PM, David Nardoni <dnardoni(a)gmail.com> wrote:
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
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
--
PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
11:37 a.m.
This is helpful information. The mft parser in volatility led me down
this path. I will see what I can find and if I get anywhere I will
share it with the group. Thanks again!
Sent from my iPhone
On Jan 3, 2013, at 7:07 PM, Jamie Levy <jamie.levy(a)gmail.com> wrote:
Hi Dave,
Actually I have looked a little at carving prefetch files from memory-
it hasn't yet proved fruitful in a case. It seems that prefetch files
may not be entirely in memory, but you can find the header (which
actually differs a little bit from the one on disk) and some partial
data, like up to the prefetch file name ([name-hash.pf]).
The prefetch name alone has been helpful in some cases where we were
able to tell where malicious files had been run from, by analyzing the
hash. I have a script that generates the prefetch filename based on
the path (except for hosted programs in this script) that I released a
little over two years ago:
https://github.com/gleeda/misc-scripts/blob/master/prefetch/prefetch_hash.py
and I have other versions that brute force paths and use precalculated
whitelists of known executables etc.
It also appears that prefetch files are not obtainable using the
dumpfiles plugin.
As far as I know no one has yet released a plugin that scans
for/carves out prefetch files. It will be interesting to see what you
come up with! Let us know if you want to write up a plugin and need
any help.
All the best,
-gleeda
On Thu, Dec 27, 2012 at 7:19 PM, David Nardoni <dnardoni(a)gmail.com> wrote:
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
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
--
PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
4332
days inactive
4339
days old
vol-users@lists.volatilityfoundation.org
6 comments
5 participants
participants (5)
-
david nardoni -
David Nardoni
-
Echo6 -
George M. Garner Jr. -
Jamie Levy