Nobody asked you!

Hi, minions:

I didn't have anything in mind to write for a while, because I'm embarking on a job that I don't quite know how to approach, yet. But one person has dedicated to me a "Fuck off", (with the relevant block), and that has been the trigger for this article.

If someone disrespects another person, he will lose all reason, even if he is. He loses all argument. Education must always be at the forefront.

I recently read an opinion article that the user z3roTrust wrote on July 18, 2018. The article in question is entitled "Why it’s Probably Best to Leave Digital Forensics and Incident Response (DFIR) to the Professionals".

I must admit that I had to read the title a couple of times before going into it, fearing what I was going to find inside it.

After reading it I had the audacity, (I don't know what the hell I was thinking), to replicate the author to his Twitter publication, with a personal opinion.

I'm not going to recreate the conversation held on Twitter with the author of the article, but I invite you to read it, draw your own conclusions and, if you wish, participate in it, either through comments on this article, or through direct responses on Twitter.

Regarding that conversation, I consider that at no time have I said any nonsense, (and sometimes I say many). But if I am wrong, I would like you to correct me, because I love to learn; I am eager to learn, whoever that knowledge comes from.

I want to make clear something that I have also said to the author, whom I see annoyed by my replies, I do not yet know why. My English is bad and sometimes I get lost in context. At no time have my comments been put forward with malicious intent. I think they were not malicious, but if they were unfortunate, I am sorry. I have simply told the author that I do not agree with some points in his article, (not all), specifying one of those points and asking a clear question, without making any criticism or assessment of its content, at that time.

I would also like to clarify, in case you don't know it yet, that I am not a DFIR professional. So I speak and ask from my complete ignorance, from my point of view, from my own common sense, (although sometimes it is the least of the senses). All because I am curious to know and understand things.

It goes without saying, therefore, that I am no 'great guru' of the DFIR. I am nobody in the industry.

I'm just curious. I don't know everything, nor do I aspire to know everything, (I would rather say that I don't know almost anything). I have no idea how the Community works, or the industry, whatever you want to call it.

Just as I told the author of the article in question, I invite you to read what I think, in a quite clear way, about the DFIR Community and its training, among other things, in the first article I wrote in this Blog, "DFIR: A matter of attitude and aptitude". 

It is very true that nobody has asked me but, if something has been published, I believe that anyone can react to that publication. There is a reason why it is public.

If you don't like it, (if you don't assimilate well), receive feedback, stay in your cave and don't publish anything. Save it for yourself and don't share it because that way you don't become a Community.

We complain a lot about not receiving the necessary feedback within the Community. Personally, I am willing to receive it, to be given it, whether positive or negative. I love being criticized, wherever they come from, (although I don't get any comments). But it's reactions like this that prevent it from existing in the amount it deserves on many occasions. This fact seems to me to be a real pity.

No one possesses the absolute truth about all things.

It is true that there are different approaches when it comes to disagreeing. But expressing disagreement on some points of a text does not mean disagreeing with someone else's work, especially when another question is asked. I believe that I have the strength to be considered and to choose well the words that I will use before speaking.

People can be great because of their knowledge. But they can be even bigger because of their humility.

I do not disagree with each of the points made by the author. In fact, I agree with almost everyone. But it is true that I disagree with some of them.

I have no way of knowing whether working at DFIR is discouraging and/or rewarding. But I can say that I find it an exciting career. A career in which the breadth of knowledge to be possessed requires constant training, but not only for professionals, as the author states. There are many people who, although they are not professionals, carry out very interesting research work.

It is true that no one can know everything. And whoever makes this statement lies. Anyone who does this, by hobby or profession, must specialise in one field, because DFIR, like other subjects, is a multidisciplinary subject.

The author states that the DFIR Professional Community is highly valued for its knowledge and skills. I must disagree on this point. I would say that it is some people within that DFIR Professional Community who are highly valued, because they have chosen DFIR as a way of life and not as a business option. There are people who have only decided to choose that branch for money, (for example).

In all families there are 'black sheep'.

The author makes a statement, which is the one that has caught my attention the most. He states that no attempt at computer forensic investigation should be made, except by qualified and trained professionals. 

Both that point in your article, and the comments you have made to me on Twitter, seem critical to me because we go back to the article in which I express my opinion about it and where I ask myself a lot of questions: Who qualifies and qualifies to practice DFIR? Are there people without training who can perform a forensic investigation better than a professional? Who certifies and authorizes to do DFIR?....

I don't want to go back into those thoughts which, on the other hand, have been shown to be useless.

I would say to you that I expect your opinion, both positive and negative, but it probably won't do any good.

That's all.

Marcos

Continue Reading...

¡Nadie te ha preguntado!

Hola, secuaces:

No tenía en mente escribir nada durante un tiempo, porque ando embarcado en un trabajo que no sé muy bien cómo enfocar, aún. Pero me han dedicado un "Vete a la mierda", (con el bloqueo pertinente), y eso ha sido el desencadenante para el presente artículo.

Si alguien falta el respeto a otra persona, perderá toda la razón, aunque la tenga. Pierde todo argumento. La educación debe ir siempre por delante.

Recientemente he leído un artículo de opinión que el usuario z3roTrust escribió el día 18 de julio de 2018. El artículo en cuestión lleva por título "¿Por qué es probablemente mejor dejar la investigación forense digital y la respuesta a incidentes (DFIR) a los profesionales?".

Debo reconocer que tuve que leer el título un par de veces antes de adentrarme en él, temiendo lo que me iba a encontrar en su interior.

Después de leerlo he tenido la osadía, (no sé en qué demonios estaba yo pensando), de replicar al autor a su publicación de Twitter, con una opinión personal.

No voy a recrear la conversación mantenida en Twitter con el autor del artículo, pero les invito a que la lean ustedes, saquen sus propias conclusiones y, si lo desean, participen en ella, bien mediante comentarios a este artículo, o bien mediante respuestas directas en Twitter.

Respecto a esa conversación, considero que en ningún momento he dicho ninguna tontería, (y a veces digo muchas). Pero si estoy equivocado, quisiera que me corrigieran ustedes, porque me encanta aprender; estoy deseoso de aprender, venga de quien venga ese conocimiento.

Quiero dejar claro algo que también le he dicho también al autor, al que veo molesto por mis réplicas, no sé aún porqué razón. Mi inglés es malo y a veces me pierdo en el contexto. En ningún momento mis comentarios han sido expuestos con mala intención. Creo que no han sido malintencionados, pero si han sido desafortunados, lo lamento. Simplemente le he dicho al autor que no estoy de acuerdo con algunos puntos en su artículo, (que no con todos), especificando uno de esos puntos y realizando una pregunta clara, sin realizar crítica alguna o hacer valoraciones de su contenido, en ese momento.

Quiero aclarar también, por si ustedes no lo saben aún, que no soy ningún profesional DFIR. Así que hablo y pregunto desde mi completa ignorancia, desde mi punto de vista, desde mi propio sentido común, (aunque a veces es el menor de los sentidos). Todo ello porque tengo curiosidad por saber y por entender las cosas.

Por ende, huelga decir que no soy ningún 'gran gurú' del DFIR. No soy nadie dentro de la industria. Sólo soy un mero curioso. No lo sé todo, ni aspiro a saberlo todo, (más bien yo diría que no sé casi nada). No tengo ni idea de cómo funciona la Comunidad, o la industria, como lo quieran llamar ustedes.

Igual que le dije al autor del artículo en cuestión, les invito a que lean lo que pienso, de una forma bastante clara, sobre la Comunidad DFIR y su capacitación, entre otras cosas, en el primer artículo que escribí en este Blog, "DFIR: Una cuestión de actitud y de aptitud".

Es muy cierto que nadie me ha preguntado pero, si algo ha sido publicado, creo que cualquier persona puede reaccionar ante esa publicación. Por algo es pública.

Si no te gusta, (si no asimilas bien), recibir feedback, quédate en tu cueva y no publiques nada. Guárdatelo para ti y no lo compartas porque así no se hace Comunidad.

Nos quejamos mucho de que no se recibe el feedback necesario dentro la Comunidad. En lo personal, estoy deseoso de recibirlo, de que me lo proporcionen, sea positivo o sea negativo. Me encanta recibir críticas, vengan de donde vengan, (aunque no recibo apenas ningún comentario). Pero son reacciones como esta las que impide que, en muchas ocasiones, exista en la cantidad que se merece. Este hecho me parece que es una verdadera lástima.

Nadie posee la verdad absoluta sobre todas las cosas

Es cierto que hay diferentes enfoques cuando se trata de discrepar. Pero manifestar un desacuerdo en algunos puntos de un texto no significa discrepar con el trabajo de otra persona, más aún cuando se plantea otra pregunta. Creo que tengo la suficiente entereza para ser considerado y elegir bien las palabras que voy a utilizar antes de hablar.

Las personas pueden ser grandes por sus conocimientos. Pero pueden aún más grandes por su humildad.

No discrepo con cada uno de los puntos que expone el autor. De hecho, estoy de acuerdo con casi todos. Pero sí es cierto que discrepo alguno de ellos.

No tengo manera de saber si trabajar en DFIR es desalentador y/o gratificante. Pero sí puedo afirmar que me parece una carrera apasionante. Una carrera en la que la amplitud de conocimientos que hay que poseer requiere de una formación constante, pero no únicamente para los profesionales, como manifiesta el autor. Existen muchas personas que, a pesar de no ser profesionales, realizan unas muy interesantes labores de investigación.

Es cierto que nadie puede saberlo todo. Y quien haga esta afirmación, miente. Cualquier persona que se dedique a esto, por hobby o por profesión, se debe especializar en un campo, porque DFIR, como otras materias, es una materia multidisciplinar.

El autor afirma que la Comunidad profesional DFIR es altamente valorada por sus conocimientos y habilidades. En este punto debo discrepar. Yo diría que son algunas personas de dentro de esa Comunidad profesional DFIR las que están altamente valoradas, porque han elegido DFIR como un estilo de vida y no como una opción de negocio. Existen personas que sólo han decidido elegir esa rama por dinero, (por poner un ejemplo).

En todas las familias hay ovejas negras.

El autor hace una afirmación, que es la que más me ha llamado la atención. Manifiesta que ningún intento de investigación informática forense debe ser realizado, excepto por profesionales cualificados y entrenados.

Tanto ese punto de su artículo, como los comentarios que me ha hecho por Twitter, me parecen críticos porque volvemos al artículo en el que expreso mi opinión sobre ello y donde me planteo un montón de preguntas: ¿Quién cualifica y capacita para practicar DFIR? ¿Existen personas sin capacitación que pueden desempeñar una labor de investigación forense mejor que un profesional? ¿Quién certifica y autoriza para hacer DFIR?...

No quiero adentrarme de nuevo en esos pensamientos que, por otro lado, ha quedado demostrado que no sirven para nada.

Les diría a ustedes que espero su opinión, tanto positiva como negativa, pero probablemente no sirva de nada.



Esto es todo.

Marcos

Continue Reading...

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:

https://github.com/volatilityfoundation/volatility/wiki/Command-Reference

https://www.amazon.es/Art-Memory-Forensics-Detecting-Malware/dp/1118825098

That's all.

Marcos

Continue Reading...