First, a little story.
I was doing the penetration test in a medical company. I was talking with the administrator there to make sure I know where I am and how the infrastructure looks like.
The discussion was already 2 hours gone and he asked if I wanted a cup of coffee or tea and went away to get it. Obviously, I didn’t want any coffee or tea.
All I wanted was an opportunity where he leaves his desktop unlocked to come up. He didn’t lock his computer and I quickly inserted my Pendrive into his computer. I performed a memory dump out of which I was able to extract all the interesting and juicy data on his computer.
One of the many things I was able to get was his passwords.
So, my penetration test started without really touching the infrastructure just because of the little incident that just happened.
Lesson learned.
However, what is really important to understand is that whatever works is always in the memory and whatever happens is always in the memory.
It is, therefore, fantastic to learn how to perform memory dumps in order to follow the incident response activities and also how to extract the information from the memory, so that we are able to get a little bit more insight about what was, or is, working in the operating system at that moment.
How to perform a memory dump
The image above is of my screen right now. We are going to first learn how to perform a memory dump of the whole operating system’s memory. Then, we are going to learn how to perform memory dumps of the system process and how to analyze both ways.
Let’s first perform the memory dump of the full operating system. For that, I am going to use the tool Dumpit. It is a tool developed by Matthieu Suiche.
It comes in many versions, so please be sure to check it out. To be sincere, the reason I am using this tool is that it’s the best and simplest way to perform a memory dump of the whole operating system, especially if you do not have experience in memory analysis.
I think it is very convenient as the only thing you need to do is to launch it.
You need to be running the console as an administrator or you just double-click on the tool and then elevate it. Then, it will ask you if you would like to continue performing the memory dump of the whole operating system.
In my case, I am going to select “No” because there is no fun in writing that big file into our disk. In your case, you can say “Yes” and then analyze that memory dump. I have already made a dump for the purpose of this post, so I will just say “No”.
That’s how we are able to do it using one of the tools. There is a very good website, Forensics Wiki, which has a list of tools that you can use for memory imaging. You can always check this out if you are looking for some alternatives. You can also get more tools and details from our Online 1 Day Forensic Mastery Course,
Now that we’ve done got that, the second thing to learn is how to perform the memory dump of the process. To be sincere there are many ways to do it. Starting from ProcDump, which is a very good tool that you can download from sysinternals.com, and even with Task Manager that I have opened here.
>> Link to the the ProcDump <<
I want to show you this because I want it to be as easy as possible for now, so that we are able to jump into memory analysis. Of course, you can use any version of Process Explorer, so you just right-click on the particular process and there is an option to “Create Dump”.
There is another tool from sysinternals.com called Process Hacker, which can be used as an alternative. Right-click on the process, create the dump file, and then you have got it.
>> Link to the the Process Hacker <<
I will perform the lsass dump from task manager. Let’s do it. Create a dump file, and copy the path that you see. I’ll copy the dump (lsass.DMP) to my Mimikatz folder.
This is a great tool by Benjamin Delpy that I already mentioned here before. Basically, we have our own version made in cooperation with Benjamin. This is the one that may not be recognized by antivirus, and in this case, I will use it for memory analysis. We were working with this tool in the operating system, hence performing the different activities online on the active processes, and right now I will just connect to the dump.
Analyzing memory dumps
As you can see, we don’t necessarily need to use debuggers to analyze memories. Sometimes, it might be a dedicated tool just to extract a certain type of information from the dump and that’s it. Memory analysis can be endless, as we know, and it can be super short. One thing, which is sure, is that whatever works is always in the memory. In the memory dumps, we can find a big amount of different kinds of data and information. In this case, we use mimikatz. We can do sekurlsa::minidump, in order to connect to the memory dump, Lsass.dmp, because I got it in the same folder. Here we go.
The next step is to do something that you may already know, which is sekurlsa::logonPasswords. This information comes directly from the dump. Of course, we are able to spot over here different usernames, passwords, and things like that. So end users’ passwords hashes or NThash or NTLM hash. There are different ways this can be named.
This is a little extraction of the data from the process. Of course, whenever we are thinking about memory analysis of the whole operating system, I have here a Python script called Volatility. We can use this tool in order to jump into the subject.
It’s very convenient when configured properly because it can give you a lot of information related to what kind of processes we’re running, what types of handles we have, what kind of handles for each process, and so on. It can also tell us which type of process is running and list his DLLs. There’s a lot of information that we can grab.
Putting this in a technical frame, in order to set it up correctly, you will need to download Python.
I’ll recommend version 2.7x which is the newest version. The reason we are going for 32-bit is that there are a lot of different extensions that we will be using for memory analysis, and all of them are available only in the 32-bits edition. Of course, ActivePython, which we need to just be comfortable when we work and Volatility itself is in 32-bit. You just want to make sure that you’ve got the full functionalities here. Of course, you can use it for an analysis of a 64-bit operating system. It’s all good.
Let’s do it. We’ve got the vol.py -f to specify the file. My file with the dumps is in the “d:\Tools”, and then I got here “dumps”, and then I got “ANALYZE.dmp”. This is a dump that I made previously.
We have to specify here “profile”. Within this profile, we specify what kind of operating system this is. Sometimes we may not know. Then, there is a way to check, using an imageinfo module which we can use to verify. In this case, we know it’s a Windows 7, SP1 x64. In order to get some information from the dump, let’s say we want to list processes, so pslist. Very simple, right? Very quickly, we’re going to get information about what kind of processes were running when we were performing this dump.
I want to show you something interesting here. This is the beauty about memory, because of whatever works, as you remember, is in the memory. We can spot a list of processes here, but this is not a complete list. I don’t like the word “hidden”, but because they are not showing up, we could say that they are hidden. They are not just in front of our eyes. These processes can be found by our analysis here. To bring out these “hidden” processes, we will do “psscan” instead of “pslist”. That takes a little bit longer, but at least we have here a new process that wasn’t on the list before. It’s called malware.exe. We can verify to check it wasn’t there before.
Let me show you. This is this list over here and as you see malware.exe doesn’t exist, but in the second tab of command it comes out.
Why is this so? The answer is maybe not very simple but is something that we call active process links. It is an LIST_ENTRY structure that is part of the EPROCESS structure. In simple words, it means that in order for processes to exist in Windows, they need to be designed in a certain way. One of the things that it needs to have is the indication of where it is on the process list. For example, this is how Process Explorer, Process Hacker, Task Manager, and other tools list processes in Windows.
This is like dual existence, so one process indicates a previous one and the next one. What I did in this operating system is that I have modified that particular structure so that malware.exe is gone from the list. In this particular case, the only way to show it is, for example, is to get access to the handles of csrss.exe (Client/Server Runtime Subsystem). This means that if the guy that manages processes knows where that particular process is going to be, he will able to spot it. This is because once it works, it is in memory.
The last thing that I want to show you is how we are able to extract files from memory. Let me clear this screen over here.
In this particular case, we will use a dll list option. I’m just going to do psscan, and run these commands dlllist and dlllist.txt. In a second we are going to have a full list of different dll’s loaded within our processes. We can check what is inside. I will be interested in, let’s say, extraction of the event logs from memory.
With the Task Manager, we can go to Services and Description. What is the point is that we will be able to find out the service? This is a Windows Event Log or for short, EventLog. We can go to details, as you see and what is selected here, highlighted, is the svchost.
We’ve got many SVCHOSTs over here, so how do I know from the memory dump which svchost is responsible for hosting event log? That is actually very easy to track since we know that wevtsvc is a DLL that is representing this service so we can jump over here.
We can spot that this is indeed the process ID 848. At this stage, the next thing that we are going to do is to dumpfiles. Within the dump files, we will specify that we would like to extract data from the process 848 which was our svchost. I will save everything in the directory FileHandles that I have over here.
There is a data extraction that’s going to happen right now. It’s case sensitive so you’ll need to use capital D. What you see that it’s happening right now it’s the extraction of the logs.
It takes a little while, so you always need to be patient with memory analysis. What is important to understand here is that with these files, there’s a high probability that they will not be consistent. Sometimes you’ll need to work a little bit more in order to get the data extracted.
I can go to our file handles where we have a list of what is happening over here and we can take one of these files to try to open it. Let’s choose Diagnostics Performance Operational evtx.
We’re going to rename it to the same one but we will specify this evtx file extension. Let’s try to open it.
It’s going to take a little while because it tries to interpret it. Sometimes we manage to have it and that’s okay. Sometimes this file opens and this is all good, but if we choose for example some other type of log, our Event Viewer may fail.
Recovering corrupted records in a memory dump
Let’s find something that is not working correctly. We were very lucky here. Let me find a file that might not be that super cool to open because it has a lot of different events. It could be the Application Event Log.
Let’s take another example and rename it. So we’ve got an evtx and a vacb. We’re going to rename it to evtx. Let’s try to open it.
Here we go. That’s what I needed to show you. Sometimes we see that the file event log might be corrupted. Let’s say “OK”. It doesn’t open as we see. In that stage, I’m just going to copy it into my toolkit to recover it.
We are copying it into d:\tools\tools_te\Mem_EVTXRecovery\in. In the second console over here, I am already in this folder so let’s go to “in”. As you see this is the only file that I got.
I’m going to go to “out” folder which is empty.
We’re going to use our tool CQEVTXRecovery.exe where we specify the point of entry, so “–in in” a folder, “–out out” and we are recovering the file. As you see, I’ve successfully recovered 17 records.
Download the CQEVTXRecovery tool:
We can go in here and to “out”. We’ve got our file. Let’s open it and let’s see what happens. For now, fingers crossed because when the file is recovered it should be possible to open it.
This is an Application.evtx, that it is right now recovered. So, sometimes we need to work a little bit harder to be able to extract what we want from memory.
What you have learned in this post is how to perform memory dumps. Also, we have analyzed them from the system perspective and also from the process perspective. We could be talking about this for hours. Stay tuned because I’m super happy to write more articles where I’ll be talking about analysis from the different perspectives.
Join us LIVE from 6PM CET on Nov. 23, 2021 for our biggest ever annual cybersecurity webinar feat. Sami Laiho, Michael Grafnetter & Paula Januszkiewicz.
Take this chance to grow your skills in Azure AD security, digital forensics, shadow credential injection attacks, and Privileged Access Workstations.
