 Welcome back everyone. Today is an introduction to Volatility 3 and Volatility is a RAM analysis tool that we use from the command line. It has a lot of different options for parsing information out of a memory image. On a computer, there's a lot of things running in memory that will never be written to disk. If we want to be able to extract things that were not saved to disk, they might still be in memory. We use it a lot for malware analysis and personally, I use it a lot to reconstruct user activities. So to install Volatility 3 on Windows, we need a couple of things. First off, we need Python 3. Go to python.org, go to downloads and make sure you're downloading Python 3 and installing Python is very easy. I'll have the links for all of these below. Next, you'll need Git for Windows. If you've been watching my channel for a while, I download a lot of these forensic tools using Git and knowing how to use Git is very handy for digital investigators. Go to gitforwindows.org, click download, run the installer, and then you will have Git for Windows installed in your system. The next thing we're going to need is the visualstudio.microsoft.com, visual studio CPP build tools. This is to build Python modules, that way we can run volatility. Click download build tools and then follow the installer and the C++ build tools should install. Next is the volatility foundation, so volatilityfoundation.org. You can go to downloads and then if you click on Volatility 3 tab, you'll notice that they have volatility 3, but it's version 1, the Python 3 rewrite. So instead, we want to go to the GitHub release page. This is at github.com, volatilityfoundation, volatility 3. And then we can see the code and you notice that under the releases tab, we have volatility 3 2.0. So this is actually an updated version and they haven't updated the link on their website. So this is why I prefer getting everything directly from GitHub. And then even volatility 3 2.0 was released in January, but they've had updates since then. So I want to work with these development branch directly, that way I can get all of the features that are currently available. So assuming that you've already gotten Python, you have Git, you have Microsoft C++ installed, we're now at the volatility 3 GitHub, I'm going to click the code button and copy the HTTPS URL, then I'm going to open PowerShell, for now I'm going to go to my desktop and I'm going to clone the volatility code into my desktop. So I will do git clone, right click, and then it'll copy that whole URL, hit enter, and then we'll download the current version of volatility. Now if I want to update volatility in the future, all I have to do is type git pull, and then rebuild any of the code that's pulled in. So this is an easy way to keep your software up to date. Before I actually build this, I need to install one thing and that is the Python snappy extension. And in Windows, I had a lot of trouble installing snappy. This is really the only place where I could find the wheel file that would actually work for it. For me, I'm using AMD 64. So I want to click on Python snappy when AMD 64. If you're using a different system, make sure you choose the one for your individual system. I'm going to save that file. And it's saved into my downloads folder. So next, let's check that we have Python installed. So let's type Python and then dash capital V. And you should get Python and then its version number that you have installed. Make sure that the first number is at least a three. Now, if we have Python installed, I'm going to type pip install and then I'm going to give the full path to where I downloaded the snappy dot whl or the wheel file. Python will install this wheel file directly. I already had it installed. So everything's okay. You shouldn't really get any errors if everything went well. So next I have on my desktop the volatility three folder. So I'm going to CD volatility three type LS or dir. And then you should see a list of all of the files inside the volatility three folder, I have ball dot pi. So I know this is the right folder. What we need to do now is install all the requirements to run volatility, you can do requirements minimal, and it will stall fewer things you need to download fewer things. But if you want all of the features of volatility, you should do requirements.txt, which I recommend. So what we need to type inside the volatility three folder, we type pip install dash R requirements dot txt pip install dash R requirements dot txt, press enter. And then what should happen is everything will go through and check if everything is installed. If you don't have a package that's already been installed, it will try to download the package and compile it. So this is where installing the Microsoft C++ build tools is really important. If this is not installed properly, you might have errors at this stage. So if you do have errors, go back and check that Microsoft build tools are installed properly. So we see if everything was installed correctly by running Python ball dot pi inside the volatility three folders of Python ball dot fi, and then dash lowercase v. So for Python to check the version, it was an uppercase v for volatility. It's a lowercase v. Now whenever we run this, we see a couple of things. We have the volatility three framework, and then the version of this is two dot zero dot two. So this is volatility three, version two zero two. So it is newer than the most recent release that we saw. And then I have a couple of things here. For example, the symbols path is interesting. This is where any symbols will be downloaded for analysis, and we can download additional symbols if we need to, as well as where the plugins can be installed. So volatility does have a lot of plugins that are separate that you can install into these main packages. This is the location folder where you would want to install those plugins. If that ran, then volatility is at least working. It's just installed in the volatility three folder, which is fine if that's where we want to run it from. So the next thing we need to do is actually get a memory image. So I'm going to open up and I have a folder on my Z drive called memory image. And the image that I'm going to be analyzing today is the ACTF dot mem. So I need to get the location of my memory image, Z drive memory image ACTF dot mem. And then the first thing we normally want to do is run Python ball dot pi dash f. This is the file that we're going to be analyzing. I'm going to paste in memory image and then the ACTF dot mem. So Python ball dot pi dash f and then wherever your memory image is located. And then we want to get the information about this memory image. So I'm going to run windows dot info volatility three is a little bit different in that the plugin that we're using is specified at the end here, like I'm analyzing windows and I want to get the info for windows. I'll show you how to use this as a filter shortly. So let's go ahead and run that. So now it's scanning through the memory image and this will take a little bit. We get some basic information here about the system itself. Now all this is read from memory. So for example, we have number of processors could be interesting. The system time at the time of imaging could be interesting system route was set to C drive windows that could be interesting for the rest of our investigation major operating system version things like that. So this is usually the first thing we want to do. And if I wanted to run the same command and save the output, then I would use a greater than sign and that's piping to a file called ACTF dot mem dot info dot text, something like that. And then I would run it again. And then all of this output would be saved into this text file. So that way I can use it for later reference. So let's say you're starting out with volatility and you have your memory image and you were able to get windows info, but you're thinking, okay, what else can I do with this? Maybe you don't remember the command that you want to use. What you can do is specify your memory image and then specify the plugin that you want to use just as windows instead of saying the entire name, just say windows and hit enter. And then what will this will tell you it'll give you an error. And then it will show you all of the different commands that are available right now. So everything that's installed that I can currently run on my memory image is here for windows, you can do the same for macOS or Linux, but we're focusing on windows today. So these are all the different modules that I can run. And then for each of these modules, you can also access a help menu, which I'll show you shortly. And there's some things, for example, like windows dot mft scan dot mft scan. If you have something that looks like this, where you have two of the same word, volatility automatically tries to search for the most appropriate model. So for example, if there's only one sub module called mft scan, then all you have to do is type windows dot mft scan, but for example, windows registry has multiple modules underneath it. So in that case, you would have to actually type out windows registry hive scan. That way it doesn't get confused with windows registry user assist. So my point here is, you don't necessarily need to type out the entire thing, you can type out the unique module name, and then volatility will type the rest for you essentially. It seems a bit silly now, but it will save you time later. So one of the first things we usually do or at least one of the first things I usually do whenever I'm analyzing memory, I want to see a process list. So that is the windows dot ps list module. And then I'm going to pipe that into more. So I am in PowerShell in windows and more is usually a Linux command line tool, but PowerShell also supports the more anything yellow is a command the PowerShell understands going to print out all the processes that were in windows at the time of imaging, and I'm going to use more so that way it doesn't go by really quickly. So let's go ahead and hit enter. So now we have process, the process list coming out and you can see that I have more here with more if I hit the space bar, then it will go to the next page. If I don't use more than you're just going to have all this text flying by and you won't be able to see any of it. So from this process list, I can see, for example, first we have the process ID, that would be this number four here, we have the parent process ID, in this case, we have a zero, we have the image file name, which is the name of basically the executable, the offset where it was found in the memory image, the number of threads that are currently running the number of handles, which could be, for example, file handles, creation time, exit time and then file output. What I'm usually interested in is image file name, that way I can filter and focus on programs that I'm interested in their process ID and the parent process ID, as well as sometimes how many threads it has, but many times what handles are available. So I tend to focus on things like what files is this process accessing at the time and that's where handles would come in the most interesting. If we take this system process, we have a process ID of four, and then the parent process ID is zero. Well, why is that system is effectively one of the first processes that are started, right? And then everything else is started by system. So you can see that we have zero, meaning that it's one of the first processes, its process ID is four. And then here we have the registry was opened by process four, and the registry's process ID is one zero eight. smss.exe was also opened by process four, and its process ID is 396. So using this, we can basically reconstruct how applications were opened, who were the parents, like, where are they coming from? Okay, so this gets really interesting whenever we're trying to find out how different programs were executed. So we need to know the process ID of the process we're interested in. And then very often it's interesting to know the parent process ID as well. So again, I tend to focus on process ID, sometimes parent process ID, definitely file name, because I want to filter using that. Sometimes the threads and then many times for me, many times handles, if you're doing something like malware analysis, this might be very different. I'm usually use looking at user activities, you can see that as we go down, there's a lot of processes that we're running at the time. If we know what process we're interested in, we need to be able to filter this out. So I could just dump this entire process list and then search through it. But if I'm already interested in a specific process, then I can hit Q to get out of the more. And then instead of more, I can use PowerShell's built in string searcher, select string. Now select string is not part of volatility, it's just kind of helping me to filter. So let's say that I'm interested in anything in this memory image related to the Chrome browser. So I'm going to type Chrome. So here we still have Python volatility.py, our image file, actf.mem, that's my actual data, I'm listing all of the process list, but it's so big, I want to filter it. So I'm going to use a pipe, which is an up and down bar. For me, that's above the interkey. And then I use the PowerShell command select dash string, and it has to be capitalized. And then I'm searching for Chrome. Now what I would do in Linux is basically the same command, except select string would be grep, and I would be grepping for Chrome. Whenever we do that, I hit enter. And then you can see that we still had quite a few few processes, but all of these are related to Chrome.exe. So now we can focus in our investigation on Chrome.exe. And it looks like one of the first processes is 1328. So the parent ID of all of these processes is 1328. If I want to focus on the parent Chrome process, then 1328 is the process that I'm going to be focusing on. So using volatility with filtering tools like select string can help you focus in really quick on certain keywords that you might be interested in. What we're really interested in is the process ID, that way I can use the ID as a filter whenever I do other things. So let's go ahead and see what files Chrome is currently accessing. So instead of using windows.ps list, I'm going to use windows.handles. And then maybe I don't know how to use handles. So I'm going to type dash H to give me a help menu for windows handles. And our option here for windows.handles, we can give it a process ID. I need to do dash dash PID if I want to specify a process ID, otherwise, it will give me all of the file handles in the memory image. And again, it's going to be a lot of data. So if I just want to focus it on Chrome, now we have Chrome's process ID of 1328. So I can specify the process ID and we will just get those handles. So let's go ahead and do that dash dash PID 1328. And then I'm going to pipe this into more again, because I expect a lot of data with the PID, we have the process, the offset in memory, handle value and the type, which we'll use in a second. So let's say that we have these event types, IO completion type. Let's go ahead and scroll down a little bit. We can see that this has a full path to a file. And the type is specified as file. We also have a key type, which is related to the windows registry. So that could be interesting for me as well. But for now, I'm interested in the file type. So I'm going to use the select string keyword again. Instead of more, I'm going to type select string. And I'm looking for file. So I'm going to pipe that into more notice that the the volatility command is exactly the same. I'm printing out all the handles for PID 1328. I'm just filtering based on whether it is a file or not. So here we have our file and we can see the file that was accessed. We also have a registry key in here because the image file name matched our search query. We have a dat file, basically all the files that it was accessing, but not all of these are going to be interesting. Maybe the ones that include, for example, John Doe, our user might be interesting for us, or maybe we're only interested in databases. So let's go ahead and change our query again. Let's add another filter. I'm going to select string. And I'm going to search for history. Because I know that Chrome has a history file. So notice I'm taking the output of volatility. I haven't changed that command at all. I'm piping that into a keyword search filter for file, filtering out everything that's not a file. And then I'm piping that into another keyword for history. So I'm looking for any file that has the word history in it. And then I pipe that into more and we see what we get here. Okay, so we have a couple different files here. So we have what looks like three files were returned. One is the history journal, one is media history, and then one is the history file. So actually, this history file looks very interesting. If I want to understand John's Chrome browser history, I know that I'm interested in this file. And I want to analyze his browser history, you take the address specified for this file. And then I have my basic volatility command, this really isn't going to change ever. And I'm going to specify an output directory, I want to output the file. But before I can output the file, I need to create an output directory. So I'm going to make dir mk dir folder called dump. Okay, so now I've created a folder called dump. And that's where I'm going to save everything that I'm carving out of this memory image. You can go back to our volatility command. And I need to do dash o to specify the output directory. I'm going to say save it into the dump folder. And then I'm going to use the command windows dot dump file. And then I'm going to specify the PID of 1328, which is our Chrome process. And in that Chrome process, I have the virtual address that we just copied. Okay, so what I have here is Python volatility dot pi, our memory image that we're analyzing, I'm specifying an output directory of dump, I'm using the plug in windows dump file to extract a file from that memory image. And I wanted to search by process ID for the Chrome process. And then with the virtual address that we got from the file handle. So then this should output a history file for us into the dump folder. So let's go ahead and press enter a file was created the history dot dat. And we see the history dot that file was created here. Okay, so now we have that history file dot that I have hxt installed. So I could just do open with hxt hex editor. I recommend you get that if you're going to be analyzing any type of binary data. Let's go ahead and open it. And at the beginning of this, we see SQL light format three, which means this is an SQL light file or probably an SQL light file. If we scroll through here, we see some URLs, we see some information. So actually, this does look like a Chrome history file. I would get some sort of SQL light viewer now to view this if I instead of using the hex editor, now that I know that it is an SQL light formatted file, that's how we can find for example, an individual file inside a process, and then dump that directly from memory is using the windows dump file with our PID, give it the virtual address of the file we're interested in, and the output directory. What you can also do is dump all of the files in this memory image for a particular process ID, just don't specify the address of the file. So here we have windows dump file, I still have the output dump directory and I specify the PID, let's go ahead and press enter. This is going to give us a lot of files that we're not necessarily interested in. Okay, it's just going to dump every file related to that process ID. So I usually just dump one file at a time, as I realized that I needed, maybe I'm going to dump every file related to a process, and then do a virus scan of the files, for example. So that could be, you know, a way to automate analysis of a specific process, whether you want to dump everything or focus on a specific file, I tend to focus on files. But if you're doing a bulk scanning, then maybe it's interesting for you. Another thing that tends to be interesting is the windows cmd line command. And I want to pipe this into more because it's usually quite a bit of data. This shows command line usage, but more than that, it shows switches that were used whenever programs were started. So we have a couple of different programs here. And, and for example, we can see the switches that were used to launch these programs. So just looking at the windows registry, for example, we might see the svchost.exe was run. We might see the entire executable, but we wouldn't necessarily see the options that it was ran with. So if somebody was running something from the command line, in other places, you might just see that the command was ran, but you wouldn't see all of the options that was ran with it. This is a really quick way to see what's been run, where things were run from. And if they had any special options while they were running, for example, at the very bottom here, we have fdk imager that was ran to create this disk image, and it was run from the eDrive. Okay, so everything else pretty much was run from the C drive, as we would expect for like system options. But in this case, we had fdk imager ran from eDrive, and it looks like imager light was ran. So maybe that's an, you know, an external USB stick, like where is that drive coming from. So if we saw, you know, a malicious executable ran from an eDrive, then maybe somebody came in, plugged in a USB stick, installed a virus, and then plugged out the USB stick, that's possible. So checking command line might be interesting for that. Next, something that I pretty much always run along with a process list would be netstat. And it's going to give me a lot of stuff. So I'm going to pipe it into more. So what we get here is the offset in the memory image, the protocol that was used, the local address of the computer that this memory image was taken from. And then the local port, the foreign address or the external address that we were connecting to, and then the foreign port that was connected. So let's say that we're interested in Chrome.exe, this is our local address that Chrome was running on, and then it was connecting to the address 185704135. Well, now we can just go and do a quick search. It comes back to proton AG, so proton mail.ch. So at least from this, we very quickly find out that the user either was connected to proton mail at the time of imaging or had just closed it. So now proton mail is interesting for the case because we have a connection back to proton mail, we can go through and check all of these IP addresses and see where they're calling back to. And it might give us some really interesting information about malware that was installed, if it's calling back home, how it was calling back home, or just user activities, like for example, this address is proton mail, most of these are probably calling back to proton mail related to Chrome. So finding out network connections, we're also interested in the name of the process and the process ID. This is how we can go back and see the process list, what things are running, what is it connecting to, what files is it opening, and then also what kind of network connections is it making. So again, if I'm only interested in Chrome, then I can do the same search again, select string Chrome, and then that will filter out everything that's not related to Chrome. So that way I can focus my investigation on only addresses that Chrome was accessing, for example, use filtering often. Another thing that's useful, especially if you're trying to investigate a certain suspect and you want to know their password, and then maybe how that password is used on other systems, we want to do hash dump. What this will do is output the password hash values for this window system. So let's take a look at that. So once we have those hash values, then we can try to crack the hash values, get the password for the user. So for example, John Doe, now we have the password hash. If we can crack that password hash, then maybe that password is used on other systems or maybe it'll give us some insight into how the user is actually coming up with their passwords. So getting those passwords gives us potentially access to another local system. If the password was being used, maybe the password is used in online accounts. So doing a hash dump, getting the password hash and then trying to crack that password hash can really help us in the investigation to uncover more data. And then another thing that I tend to use a lot whenever I'm dealing with windows is windows registry analysis. One of those is the user assist. So we can do registry, registry user assist. And I'm going to use the dash H just to see if we have any options. We have the hive offset option, if I want to focus on that, or we don't have to put it and everything in user assist will be shown. So I'm just going to run this again with more and user assist tells us a lot of interesting things about user activities in the system. So for example, we have the hive offset, the hive name where we're getting all this from last right time. So this is essentially, you can almost think of it like the last time that an action took place related to that key. So if it's related to a program, then that might be the last time that the user ran that program. We also have the count, which is the number of times the program was run, the focus count. So the number of times that's the user focused on that particular window for the program. And then the time focused is the total amount of time that the user was looking at that over time, not in an individual session, you got to be a little bit careful with count focus count and time focus, don't take it as 100% accurate, but it can still establish that, for example, the user did open up this program and did focus on it for a particular period of time. Okay, let's go ahead and see what that looks like. So for example, here I have Ms paint.exe was executed and it seems like it was executed seven times, it was the focus seven times, and then I had a total focus time of like one minute. So basically it was open several times, but not really accessed. Here's another one, Microsoft Edge, the browser, it was opened three times. And then it was the focus 16 times, which means the user kind of went away from the browser and then came back to it so focused on it. And the total focus time was about an hour, 50 minutes, 56 seconds or so. So this establishes that they at least were using Microsoft Edge, they'd focused on and away from it several times, and they'd use it for a considerable amount of time. Are these 100% accurate? Maybe not. But this is already a really good place to start. User assist is really interesting for investigations, especially to establish user behaviors and whether programs were used, how long they were used, things like that. And again, you can use the same filtering technique that we've been using to focus in on, for example, Microsoft Edge, Chrome, whatever it is that you're looking for. But sometimes you might want to find and list all of the registry hives that are available in the system. And then we might want to carve them out, for example. So using that, we can use hive list. So windows.registry.hive list. Let's see if there's any options for that. We have a filter. So string to filter hive names returned, and then dump extract listed registry hives. If we just run it without any options, then we get all of the registry files that we could find. Let's say that we're interested though in John Doe. So let's try to filter by John. Okay, and then we only get back anything that looks like a registry file related to John Doe in the string. So basically, we're using volatility to do the keyword searching for us. And let's say that I'm actually interested in NT user.dat. So let's do a filter for Doe slash NT user.dat. Doe slash NT user.dat. So now we're focused on the file that we want. So let's go ahead and dump. And just like before, we need to specify an output directory. I'm going to put that into the dump folder windows registry.hive list filter Doe slash NT user.dat and then dash dash dump. And then if we go check our dump folder, we have our hive file. So I'm going to open that. And then we have our registry file header here. So I've just dumped johns NT user.dat file. So now I can use another program to actually analyze the NT user.dat registry file if I need to let's say we don't want to dump the entire registry file, I would normally prefer to dump it and then analyze it with a different program. But maybe you have a just one specific key you want to check, we can use windows registry print key. And then let's check the options for that. With print key, we can have the offset to the hive, the key that we're looking for and then recurse. So recurse through all of the keys if we're at like a top level. So what I want to do is print key. And then I'm going to give it a key value and a key that we very, very commonly use is software, Microsoft, Windows, current version. Okay, and then I'm going to pipe that into more because it's going to be a lot. Now we're listing all of the keys inside current version. We're not necessarily getting the values because we haven't gone low enough. If we actually wanted to go lower, then we could do something like dash dash recurse. And then that will actually go into each of the key directories and then look for the value pairs. So recurse, and then I'm going to pipe this into more as well, we can see the key and then inside that key, we can see the values that are associated with this. So this red binary, and then we actually have the data here. If you know exactly the key that you're looking for, and you only have one or two to search for, or if you write a script and want to print out specific keys, then you can use the print key option inside volatility. By far I use user assist the most with a search filter, or I use hive list dump the hive that I'm interested in and then process it with a different tool. But that's my workflow. If you know exactly what key you're going for, and you don't have too many keys to search for, then it totally makes sense to use print key. So with that, we've shown how to install volatility and keep it updated inside a Git repository. We've shown how to process a RAM image with volatility. We've gone through how to do things like get the memory image, we've listed processes, we've listed file handles, we were able to extract files from memory using dump files, we were able to see command line options, we were able to see the network, we could dump windows password hashes that we can later crack if we need to, we were able to query the user assist in the windows registry and then try to find programs that were accessed and how much they were accessed, we were able to both list all of the hives that are available in the memory image, as well as focus on a specific hive and dump it using the hive list function. And then we were also able to focus in on a specific registry key using the print key tool. If you can basically list processes, you understand how to dump a file, you can access the windows registry and do some searching through it or at least dump a registry hive, then you can already do a lot of things with memory. Okay, now there's a lot more we can do with this, there's really advanced stuff that volatility can do, there's a lot of extra plugins that volatility has, but if you can at least list processes, list networks, dump files, look through the windows registry, you already have a great start to using volatility, you just need to get used to the way that the commands work, and everything else will be easy from there. So that's it for this introduction to volatility three, I hope that was useful, thank you very much.