#DFIR: First steps with Volatility

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”


You can generate a recursive list of keys and subkeys of as many beehives as you wish, as long as you are shown by the 'hivelist' plugin, making use of the 'hivedump' plugin. And if you list several beehives, you can unify them to a single file.
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


Another method available to you is the use of the 'dumpfiles' plugin, which allows you to download files stored in the memory cache (mapped files), specifying with regex the type of file you want to extract. And you have several methods to play with the plugin 'dumpfiles' and regex.
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.


Share:
spacer

No hay comentarios:

Publicar un comentario