Tag: Memory Dump

“Physical Access = Total Access”. In this post we will take a quick look at pulling ProtonMail artifacts from a Windows 10 process memory dump.

It’s been a very long time since I have posted on my blog. I have been very busy with a couple new book writing projects, but I have missed doing regular blog posts. Ran into this today and thought it would be a good post to hopefully get back on the blogging horse. Let me say before we get started that I am a big ProtonMail fan, and highly recommend it. I am not breaking their encryption or anything fancy like that, just simply pulling artifacts that belong to a ProtonMail session out of the computer’s memory.

As a test I crafted an e-mail using text from the Boba Fett Wikipedia entry. I figured the word “Boba” would make a good canary, a word that would be easily found in the memory dump.

The test e-mail looked like this in ProtonMail:

I then performed a memory dump on the Firefox process:

The “tasklist” command returned the Firefox process ID

Then, “procdump64 -ma [Process ID or you can just use ‘firefox.exe’] mem_dump_filename“

And then, “strings64 mem_dump_filename.dmp > Protonmail.txt“

The procdump command copies memory in use by the Firefox process to a file. The resultant file is very large, so the strings command is used to pull text strings out of the dump and save them to a much smaller file called “Protonmail.txt”.

I then manually searched through the resultant .txt file for artifacts.

I found the source e-mail address, and the e-mail subject. A little farther down I found the entire e-mail text as seen below:

Comparing the two images you can see that the entire e-mail text was recovered from the memory dump. I was also able to view the contents of every e-mail that was opened during the session (not shown) and most, if not all e-mail contacts that I have in ProtonMail.

This shows that if you have physical access to a system, you could recover ProtonMail artifacts including entire messages from a memory dump. The moral of this story, as a Linux guru once told me – “physical access equals total access”. If you have physical access (including remote access) to a system, you can recover many interesting things from system memory. That is why it is important to secure physical access to your systems.

Well, you can! The Malware Analyst’s Cookbook (exceptional book by the way) has been kind enough to post several memory dumps that you can play with and also additional plug-ins to increase the functionality of Volatility.

Okay, it is a Windows XP SP3 image, so we use that information with the profile switch.

Next, let’s take a look at what processes were running on the Stuxnet infected machine:

volatility pslist –profile=WinSP3x86 -f stuxnet.vmem (two dashes in front of profile, for some reason only one is showing)

Looking at this list you can see one of the signs of a stuxnet infection. There are three copies of lsass.exe running, there should only be one. The lsass process authenticates users for the Winlogon service. Let’s do a process tree list and see if all three instances of lsass correspond to Winlogon:

Looking at the PPID column, you can see that two of the processes connect to PPID 668 and on connects to 624. Looking at the PID you can see that the third instance does in fact tie to Winlogon (624). But the two other instances connect to Services.exe (628). Something is not right.

Let’s run the plugin command “malfind” and see what it detects. According to the Volatility Wiki Command Reference, malfind can find hidden or injected code or DLLs in user mode memory. We will run malfind against the whole memory dump and see if it can find any suspicious code. To do so, because we are using the standalone exe version of Volatility, we need to tell volatility where to find the malfind.py file. We do so by using the –plugin switch:

It finds something it didn’t like in explorer.exe right away, but continued to run for quite a while and kicked out two more. Something suspicious in the two copies of lsass.exe – suprise, suprise!

Going to the output directory you see all three suspicious files stored as .dmp files. You can take these files and upload them to VirusTotal to see if it detects anything suspicious.

The first explorer.exe file when run against Virus Total did not return anything malicious. But uploading the two lsass files to virus total returns some interesting results:

Two virus scanners detected something they don’t like in the files. Comodo detects it as a Packed.Win32.MUPX. Gen and VirusBuster detects a Trojan. And indeed there is something fishy there. The real lsass.exe does not have an executable section in its data region, but both of these files do. In the Malfind return above you can see that both copies of the malicious lsass have Page_Execute_ReadWrite permissions. This means exactly what it says, this code has execute and read write permissions.

We could go on and find Stuxnet registry key settings, hidden Dll’s, file objects and numerous other artifacts in this memory sample all with using Volatility. But I will end this simple overview of analyzing stuxnet here.