ProtonMail Artifacts from 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.

Last year I covered how to pull Word documents out of Windows memory using a remote Kali Linux shell.  Using the same techniques and tools covered in that article you can do the same to recover ProtonMail artifacts.

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:

Bobba Fett Test 1

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:

Bobba Fett Test 2Comparing 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.

If you enjoyed this article, check out my book, “Intermediate Security Testing with Kali Linux 2” which has an entire section on performing Forensics with Kali Linux.

 

 

Advertisements

Memory Forensics: Analyzing a Stuxnet Memory Dump (And you can too!)

In the previous article, we learned how to Pull Process & Network Connections from a Memory Dump. It been kind of fun playing around with a memory dump from our own system, but it would be cool to take a look at some memory dumps that are from infected machines.

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.

So why don’t we take a look at a memory dump from a system with Stuxnet? Simply download the malfind.py plugin, and the Stuxnet memory sample.

First, let’s grab the imageinfo information for the Stuxnet memory dump:

volatility imageinfo -f stuxnet.vmem

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:

volatility pstree –profile=WinSP3x86 -f stuxnet.vmem (two dashes in front of profile)

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:

volatility –plugins=PluginDirectory malfind –profile=WinSP3x86 -f stuxnet.vmem -D OutputFolder (two dashes in front of profile and plugins)

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.

If you want to see a complete dismantling of Stuxnet with Volatility by an expert analyst. Check out Michael Hale Ligh’s post “Stuxnet’s Footprint in Memory with Volatility 2.0“.

Want to learn a lot more about analyzing malware? Then look no further than the “Malware Analyst’s Cookbook“, written by Michael Hale Ligh, Steven Adair, Blake Hartstein, and Matthew Richard.