Hi, minions:
This work should have been published earlier, but
Blogger has decided not to do so by removing, up to twice, the content of the
draft as it progressed.
When I published
the article "Choose
your weapon well. Calculate the impact", in which I made a comparison
of some free tools to perform a memory dump, taking into account the time
invested in the process and the system resources used, I said a lot of nonsense.
Some of the stupid things I said were that data can survive in memory for a certain amount of time, that key data can be obtained for the
satisfactory resolution of the case, that the same actions can be carried out on a memory dump as on a forensic
image of a hard disk, or that sometimes
it is not enough to analyze non-volatile data. I said a lot more nonsense,
but I invite you to read
the article that, by the way, some people have thought interesting.
After I published
the article, some users told me that they would like me to publish something
related to that kind of nonsense. Likewise, I have been observing for
some time how some people have problems correctly identifying a memory dump
profile with Volatility.
So, I have decided
to do this small work on a few 'first steps with Volatility', in which I will
place special emphasis on the correct identification of a profile, (since it is a critical step in the analysis),
and show what kind of information, and how, it can be extracted from a memory
dump.
I'm not going to
perform a complex analysis of an advanced super-mega-ultra malware. I'm going
to show a practical example, about a user, purpose of an investigation. I'm
going to... investigate myself.
Introduction
Why Volatility? It is true that
you can process the memory dump with Bulk Extractor, as I explained in the
article "Who
is Mr ‘X’? Let’s find out it with #BulkExtractor & #Egrep #Patterns – We
are what we browser". It is also true that there are some forensic
suites that are capable of processing a memory dump. But I prefer to show you a manual work, which seems to generate more
impact than 'fat buttons' in an exhibition. Volatility is a
Framework capable of working with 32-bit and 64-bit memory dumps of
Windows, MacOS, Linux and Android systems. It has a modular design, so it has a
good adaptation to new versions of the different systems. It is open source,
which means that it is very useful to understand how it works in the
background, how an analysis of a dump works. It is written in Python, so it can
work in any system that supports this language. It supports a good list of
memory file formats. And, perhaps most importantly, it has good support and
contribution from the DFIR community.
For the
development of this work I have chosen to use my own system, as a study
objective. After logging in, I lifted a few applications, (processes), and
captured the RAM memory with DumpIT, version
3.0.20190124.1. For analysis I chose to use the virtual machine SIFT WorkStation,
which you can download from its official site.
If you look at the
image above, you can see that DumpIt generates a report in which, among other
interesting data, shows the information of the version of the system that has
been captured. In this case it is a Windows 10, version 17763, as can be seen in
the section "osVersion". But I
ask you to ignore this information, because not all the tools will tell you
which version it is, or it is possible that the dump was carried out by a third
person and the version of the system was not communicated to them.
Before you begin,
you should know that you need to update your system and your applications. In
the case of Volatility, you will see that it is not the same to use a version
2.6, than a version 2.6.1, since you do not recognize the same number and type
of profiles. Updates to the tools are
made for some reason. So, the first thing you have to do is clone the
latest repository available from your GitHub site.
Identifying a profile, long version
If you have a
memory dump and you want to identify it, maybe you could start by using the 'imageinfo'
plugin. This plugin will provide you with a short summary of the dump,
including the time of the memory dump and a list of suggested profiles. Among
these suggested profiles are the latest versions of Windows.
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp imageinfo
Once you have finished
running the 'imageinfo'
plugin, how do you determine the correct profile? Then you can use the 'crashinfo'
plugin. This plugin will show you the header information of the dump, with
another set of data, such as the type of dump or the time that the system has
been started in that last session. To run this plugin you can specify any
profile suggested by the plugin 'imageinfo'.
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64 crashinfo
If you look at the
value presented by the parameter "Minorversion", you will see that it
indicates that it is a version of Windows 10, 17763. So the profile that will
be used in this case is the "--profile=Win10x64_17763". So, with this
information, could you start listing running processes? You
can see it below.
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 pslist
As you can see in
the image above, despite indicating to Volatility the correct profile, it has
shown an error indicating "Could not list task, please verify your
--profile with kdbgscan”. This happens because some Volatility plugins look for
a set of values in the KDBG structure, which is a structure maintained by the
Windows kernel and used for debugging purposes. It is a common error when
encountering several suggested profiles or working with a large memory dump.
KDBG contains a list of running processes and loaded kernel modules. So, you
should use the 'kdbgscan'
plugin, which scans the KDBG header for each available profile and will show,
among other data, such as the scanned profile, information about a memory
address that should be indicated later. As you already have the system version,
(a Windows 10, 17763), you can indicate it when you run the plugin 'kdbgscan'
so that, only, it scans that profile instead of all the available ones. It will
be a faster process.
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 kdbgscan
When this plugin
finishes its execution, you should look for the "Build string
(NtBuildLab)" parameter to contain information. The information it
contains corresponds to the version of the system profile. In this example, the
value of this parameter is "17763.1.amdfre.rs5_release180". Just
below this parameter you can see another one, named
"PsActiveProcessHead", which will indicate the number of processes
that are running. One value cannot exist without the other. That is, where
there is information about the profile version, there should be information about
the processes running and this will take you to the KDBG address, which is
found in the "KdCopyDataBlock" parameter and that you should write
down. In
this case, the memory address is "0xf8051f3391b8".
I mean. In the
case that I am going to expose you in this article is going to be used as a
basis for working with Volatility line,
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8
Please note that
this memory address can be found in various profiles.
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp kdbgscan | egrep .-B 3 0xf8051f3391b8
But that doesn't
mean that you can use any profile, with indication of the KDBG's memory
address, because you may find that one plugin works well with the right profile
and the wrong profile, but then you may find that another plugin only works
correctly with the right profile and not the wrong one. And
maybe this will give you some headache.
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_15063 --kdbg=0xf8051f3391b8 pslist | egrep DumpItpython Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_15063 --kdbg=0xf8051f3391b8 timeliner --output=body | egrep DumpItpython Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 pslist | egrep DumpItpython Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 timeliner --output=body | egrep DumpIt
Identifying a profile, short version
There is a simpler
method to correctly identify a memory profile with Volatility, with which you
can save some steps, but I thought it appropriate to explain one step at a time
so that you can see how that information is handled. Please note that if you do not identify a profile correctly,
you will not be able to process the memory dump correctly. So it's a
critical step.
What you can do is
run the 'kdbgscan'
plugin directly, without any further parameters.
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp kdbgscan
You only have to
look at one profile to see which one is the right one, with the memory address
of the KDBG you need to work with. You only have to set two parameters. The
first is "Build string (NtBuildLab)" which, as I said before,
contains the system version information, (17763.1.amdfre.rs5_release.180). If
that profile parameter contains information, you only have to scroll eight
lines higher, where you will be able to find the memory address that you must
use next to the pertinent plugin, (0xf8051f3391b8).
Given the correct
identification of the memory dump it is time to go to the next level.
Before starting
the analysis itself, I am going to tell you that the RAM memory does not only record information related to that last active
session. And before we begin, I want you to see what I saw on the screen
before generating the memory dump.
Carving
I love to start a
memory dump analysis by performing a carving, a raw file recovery. Very
interesting information can be extracted from the carving. Personally, I'm
indifferent to using Foremost,
foremost -t all -i N4RR34N6-20190307-072825.dmp -o Foremost
Or Photorec,
sudo photorec N4RR34N6-20190307-072825.dmp
I am going to
explain this aspect to you with a couple of clear examples.
For example, you
can extract images that have been opened, or thumbnail views of images that
have not been opened, that have simply been previewed in a folder, or
screenshots that have taken the target and have not even previewed.
You can extract
images that correspond to the websites the target has visited, even if it was
not viewing them at the time of the memory capture.
Or, to finish with
these examples, you can extract shortcuts, which will tell you what activity
has had the objective, with filenames and full paths.
All this carving will
not take more than a few minutes and you will be able to see content, both
complete and fragmented, which will give you clues, (like the timelines), on
the type of activity has carried out the objective of the research. Information
that, in some types of investigations, could be the subject of further OSINT
analysis (a branch closely related to forensic analysis in some cases).
Processes
Volatility has
several interesting options for the visualization of running processes,
finished, hidden, ...
So, you could use
the plugin 'pslist',
to make a list of running processes, with start and exit dates, if applicable.
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 pslist
Or you can use the
plugin 'pstree'
to make a visualization in tree view, in a graphical environment, where the
information of dates is shown, with parent processes and child processes.
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 pstree --output=dot --output-file=pstree.dot
So, for example,
you can see that the target has been executed, through Windows Explorer,
Outlook applications, Keepass, Winword, Telegram, ... with their execution
dates.
Once you have seen
the processes that are in the system, you can see for example, that there are
several instances, (processes), to the Edge browser. One instance for each tab
opened in the browser. These processes can be filtered with egrep to then use
the plugin 'vaddump'
and extract the range of all the memory pages that correspond to that list of
processes.
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 pslist | egrep Edgepython Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 vaddump -p 6268, 7580, 7704, 6364, 7276, 9756, 9900, 10080, 10228, 4636, 10416, 10688, 10912, 11072, 11516, 11880, 12360, 12804, 13040, 1448, 13588, 13772, 6564, 7040 --dump-dir=Edge
Once you have
finished the process of extracting the memory pages corresponding to the
instances of the Edge browser, you can start searching for information, making
use of egrep and strings. For example, you can search for text strings directly
over the directory using strings.
strings Edge/MicrosoftEdgeC.23ab41080.0x0000025a71600000-0x0000025a717fffff.dmp | egrep -in “Password|Referer|Date”
To find access
credentials of some websites, in plain text, with the user name, the site in
question and some time stamps.
Or you can extract
text strings from that directory to perform faster searches later, using the
same method as before.
cat Edge.txt | egrep -n --colour=never ‘”ID”: |”Order”: |”Subject”: |”Address”: |”Name”: ‘
To extract, for
example, some information related to a session from a service as secure as
Protonmail's email service. A service in which I was logged in, without opening
any email.
You can even see
the text of the websites that were open for the purpose of the investigation,
without the need to have them on screen.
cat Edge.txt | egrep –i “toolcatalog” | uniqcat Edge.txt | egrep –I “The primary goal” | uniq
For example, you
have seen that an application as secure as Keepass, a widely used password
manager, was running. Good. You could try to extract the information using KeeFarce, or you could simply
search the appropriate directory after extracting its range of memory pages,
using the 'vaddump'
plugin.
egrep –i ‘</KeePassFile>’ KeePass/*strings KeePass/KeePass.exe.276ba5080.0x00000000033b0000-0x000000001b3affff.dmp | egrep -i -B 50 -A 50 '</KeePassFile>'
Or, for example,
you have been able to see that the target was running the Microsoft Word
application, so you can download that range of memory pages to search, then,
the content of the document that was open.
python volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 vaddump -p 14172 --dump-dir=Winwordfile Winword/WINWORD.EXE.216b70080.0x00000000135a0000-0x000000001369ffff.dmpstrings Winword/WINWORD.EXE.216b70080.0x00000000135a0000-0x000000001369ffff.dmp | egrep DFIR
Vaddump is a very
powerful and very useful plugin. An analyst can find very interesting
information through this method, and more taking into account the habits of
some users.
I'm very curious
about the way memory is shared between processes. If you don't find something
you're looking for you can, for example, use the 'memdump'
plugin, which is the little brother of 'vaddump'
because it performs the same function but only extracts all the content to a
single file. And once extracted you can perform a type of content search that,
in principle, would not have to do with the memory pages of the process in
question.
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 memdump -p 15260 -D nirsoftstrings nirsoft/15260.dmp | egrep -o "\b[a-zA-Z0-9.-]+@[a-zA-Z0-9.-]+\.[a-zA-Z0-9.-]+\b" | egrep -i 'gmail|protonmail|hotmail' | sort | uniqstrings nirsoft/15260.dmp | egrep -Eo "(http|https|www)://[a-zA-Z0-9./?=_-]*" | egrep -i 'Minion|DFIR|Google|StartPage|Forensic' | sort | uniq
Timelines
You know, because
I like to say it a lot, that the time lines are very useful to quickly get a
list of all the activity. Volatility also has some methods to generate
timelines, with some options in the output of the files. You can use the 'timeliner'
plugin to generate that display of events in chronological order.
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 timeliner --output=body --output-file=timeliner.txtmactime –b timeliner.txt >> Timeline.csvcat Timeline.csv | headcat Timeline.csv | tail
The ‘timeliner’
plugin also allows the generation of timelines from a single type of artifact.
Thus, for example, you can generate a Registry timeline or a timeline with the
timestamps of the different executables.
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 timeliner --output=body --output-file=timestamp.txt --type=TimeDateStamppython Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 timeliner --output=body --output-file=timeline_registry.txt --type=Registry --user=Marcosmactime –b timeline_registry.txt >> Timeline_Registry.csvcat Timeline_Registry.csv | head -n 20cat Timeline_Registry.csv | tail -n 20
In any case, the
output of that file will be a timeline that must be studied and that can deal
with mactime to make it readable, and can even format that timeline to make a visualization
with Gource.
Registry
Volatility has
some very interesting options to study the Registry system. To get started, you
can use the 'hivelist'
plugin to list the available Registry hives, with their full path.
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 hivelist
Once you have the
available beehives on screen, with their complete route and memory address, you
can navigate through them, making use of the 'printkey'
plugin, which will show you the different keys and subkeys, values and types of
data.
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 printkey -o 0xffffe681b57ae000python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 printkey -o 0xffffe681b57ae000 -K “Root”
Until you find
what you are looking for, for example, devices that the target has connected to
the system, not necessarily in that last session, studying the Amcache.hve
hive.
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 printkey -o 0xffffe681b57ae000 -K “Root\InventoryDevicePnp\usbstor/disk&ven_&prod_usb_disk_3.0&rev_pmap/070b59bb1cb22334&0”
python Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 hivedump -o 0xffffe681af64a000 >> System.csvpython Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 hivedump -o 0xffffe681b21e1000 >> Software.csvpython Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 hivedump -o 0xffffe681b57ae000 >> Amcache.csvpython Volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 hivedump -o 0xffffe681b56dd000 >> Usrclass.csvcat *.csv >> Hivedump.csv
That way you can study that list in search of a
key that you are looking for or that catches your attention and then study it
directly with the plugin 'printkey'.
cat Hivedump.csv | headcat Hivedump.csv | tailpython volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 printkey -K "Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{D6886603-9D2F-4EB2-B667-1971041FA96B}\S-1-5-21-2873627039-561819860-3666567838-1001\UserNames"
Finally, you also
have the option to use the 'dumpregistry'
plugin, to dump all available Registry hives in memory, to disk.
python volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 dumpregistry -D Registry/
And this point is
very interesting because it will allow you to study the Registry with the
relevant tools, such as RegRipper, of which I spoke in the article "Windows
Registry? Prepare the coffee maker! Using #RegRipper".
perl rip.pl -r Registry/registry.0xffffe681af64a000.SYSTEM.reg -p mountdevperl rip.pl -r Registry/registry.0xffffe681b21e1000.SOFTWARE.reg -p removdev
Event Logs
You have a couple
of methods to extract and study the '.evtx' files loaded into a system's
memory. The first method consists of using evtxtract, which will
scan and extract all system event logs, from the first to the last, to a single
file in '.xml' format.
evtxtract N4RR34N6-20190307-072825.dmp
python volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 dumpfiles --regex=.evtx$ --ignore-case --name --dump-dir evtxpython volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 dumpfiles -D EVTX/ -r evtx -i -n -S EVTX/Summary.txt
And in this way
you will be able to start looking for the information you want, such as, for
example, the networks to which the target has connected, with the connection
dates, making use of the evtx_dump
tool.
evtx_dump.py EVTX/file.1596.0xffffc306331e1be0.vacb | egrep -i -A 7 -B 15 Movistar
Or you can, for example,
search through an event ID to know, for example, which users are assigned
administration privileges in the system, the date on which the event was
generated.
evtx_dump.py EVTX/file.1596.0xffffc30632fc6d60.vacb | egrep -i -B 1 -A 31 4672
MFT
MFT can, and
should, also be the subject of a timeline, as I explained in the article "About
the timelines: The limit, your imagination". Volatility has a plugin
to study this Windows artefact. This is the plugin 'mftparser',
which has some interesting options.
The first thing
you could do is generate an MFT timeline, in the same way that was done
previously with the 'timeliner'
plugin. In fact, both plugins can be combined causing an output to a single
file.
python volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 mftparser --output=body --output-file=mft.txtmactime -b mft.txt >> MFT.csvcat MFT.csv | headcat MFT.csv | tail
You have several
options available to play with this plugin. For example, you can see in a
legible way the content of the MFT, extracted to a text file and, in turn,
download the resident data files. In the first case it could be useful to see
some information related to files hosted in the MFT.
python volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 mftparser --output-file=MFTVerbose.txt -D MFT/cat mft_verbose.txt | egrep –colour=never -i -B 2 “NameCh”
Or examine the
downloaded content of those data that were resident in the memory cache
because, I assure you, you will be more than pleasantly surprised. For example,
you can find data relating to websites that the target has visited.
egrep fuentesmartinez MFT/*strings MFT/file.0x159250c00.data0.dmp
Or you can search
for IP addresses, starting with the local IP of the system, with information
from the physical computer.
egrep IPAddress MFT/*strings MFT/file.0x1e3104c00.data0.dmp
Or you could find
yourself with some images that might be of interest to you.
file MFT/* egrep “PNG image data, 32 x 32, 8-bit/color RGB, non-interlaced”strings MFT/file.0x4068f7000.data0.dmp
To finish with the
MFT, you also have the option to download the raw MFT, making use of the
'filescan' plugin, which lists all open files, with egrep and the 'dumpfiles'
plugin, with indication of the memory address of the MFT file.
Currently I have had problems downloading files using
the 'dumpfiles' plugin with memory address indication. You can see the issue on
the corresponding GitHub site.
Downloading Cached Files
Volatility has a
very useful function which consists of downloading cached files into memory.
This action, as I mentioned before, is carried out with the 'dumpfiles' plugin. You have the option of downloading all the
files residing in the memory at once.
python volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 dumpfiles -S DumpfilesSummary.txt -n -D Dumpfiles
In this way, you
might find some logs of some applications that the target has used.
egrep -io “Telegram” Dumpfiles/*strings Dumpfiles/file.14868.0xffffc3063a1d2c40.log.txt.vscb
Or you could find
themselves with this office automation document that had the objective of
and that you can
open in a graphical environment.
List of open files
As I mentioned
before, you can use the ‘filescan’
plugin to see which files the target had open. In this way, you can combine the
use of that plugin with egrep to search for types of elements and download
them.
python volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 filescan | egrep -i ‘[.]docx|[.]pst’file Dumpfiles/* | egrep ‘Interview.docx’file Dumpfiles/* | egrep ‘[.]pst’
Types of elements
that, once downloaded, you can study with the appropriate tools. For example,
in this case you can see some '.pst' files that belong to the Outlook
application and that you can start studying, for example, with the readpst tool.
file PST/*ls -s PST/*readpst -o PST -r PST/*
Or you can look
for other types of artifacts, such as tracking events, to download and study
them, as I explained in the article ""UserNotPresent",
When does Windows understand that the user is not present?", to see,
for example, what type of activity the target system has presented.
python volatility/vol.py -f N4RR34N6-20190307-072825.dmp --profile=Win10x64_17763 --kdbg=0xf8051f3391b8 filescan | egrep -i '[.]etl'
Strings
If for some reason
you do not find what you want, perhaps you can resort to text strings. First of
all you have to extract all the text from the memory dump and generate the
output to a text file. A text file that will be studied by cat and egrep. In
this way, if you know what you are looking for, you will be able to carry out
very precise searches, with information that you have been able to see before,
in one of the methods described.
strings Strings.txt | egrep -i "DFIR Review "strings Strings.txt | egrep -i "Practicing DFIR"strings Strings.txt | egrep -i "[\]Device[\]HarddiskVolume6[\]" | sort | uniqstrings Strings.txt | egrep -i "[\]Device[\]HarddiskVolume4[\].*Marcos.Downloads" | egrep -vi Telegram | sort | uniq
Conclusions
These are just a few basic examples to analyze a memory dump, because Volatility has much more potential, but...
You have seen, the
memory contains a great deal of information that can be lost if it is not
captured. You have seen the amount of actions that can be carried out in a
memory dump, such as carving, generating timelines, studying the Registry,
searching for a certain event, downloading memory pages with very volatile
information, listing open files, downloading content stored in the memory
cache.... Almost any action that can be carried out on a forensic image of a
hard drive can be carried out on a memory dump.
You have seen that
the information that can be found in a memory dump is critical information for
the possible resolution of a case. Data that may not be
found in other artifacts inside the hard drive.
You have seen that
not only is information about that last active session of the system cached.
That both old and new information is stored, both seen by the target and not
seen by the target.
For all these
reasons, as I told you in the article "Choose
your weapon well. Calculate the impact.”, RAM can, and should, be analyzed in any case, because data can
actually survive in memory for a certain time. Therefore it is also vital to
act quickly.
References:
That's
all.
Entradas
Hey Marcos ! I had a similar experience last month, where I compared Vol 2_6_1 or 2 and Vol3... have you had time to do the same ?
ResponderEliminar