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

Volatility Memory Analysis Article Featured in eForensics Magazine

eForensics April 2013

Check out this month’s issue of eForenics Magazine for my article on Memory Analysis using Volatility 2.2 and DumpIt!

“Analyzing system memory for artifacts is a technique used by forensic analysts, security specialists and those that analyze malware.

In this article we will cover how to obtain a complete copy of system memory from a computer using the easy to use program “DumpIt”. We will then take this memory dump and analyze it with the popular memory analysis tool “Volatility”.

With Volatility, you can pull a list of what software was installed on a system, what processes were running, what network connections were active, and a whole lot more.

We will look at all of this and even see how to pull password hashes from a memory dump. Lastly we will try our hand at analyzing a memory image infected with a sample of Stuxnet.”

The magazine also includes:

  • Cold Boot Memory Forensics by Alexander Sverdlov
  • MALWARE FORENSICS & ZEUS by Mikel Gastesi ,  Jozef Zsolnai & Nahim Fazal
  • Establishing a Center for Digital Forensics Investigative Services on the Cloud by Dr. Rocky Termanini
  • Digital Continuity of Government Records by Dr. Stilianos Vidalis
  • And more!

Check it out! (Subscription Required)

Windows 8 Open Source Memory Analysis Fail

Wow, spent a lot of time yesterday trying to do some memory analysis on Windows 8 with a couple open source tools…

And completely failed.

I wanted to analyze a suspended Win8 virtual machine’s memory and see what information could be pulled from it. I know VMWare has a “vmss2core” utility that will do the trick. Of course I had Windows 8 in a Virtualbox VM. No problem, I exported and imported to VMWare Workstation with no problems. Okay, it hung up on first boot in VMWare, but a hard reset and everything was right as rain on the next boot.

Next I suspended the VM, grabbed the .vmem and the .vmss suspension files and tried to run it through vmss2core:

C:\VM>vmss2core.exe -W windows8.vmem windows8.vmss
vmss2core version 812388 Copyright (C) 1998-2012 VMware, Inc. All rights reserved.

Unrecognized .vmss file (magic f000ff53).

Unrecognized .vmss file… Okay, not to be deterred, I rebooted the Windows 8 VM and took a snapshot. Vmss2core also works with snapshots!

Same error.

I actually read the help features for Vmss2core and realized that it has a “-W8” command for Windows 8! Doh!

Used that… Same error…

Okay, bothered now, but still undeterred, I figured I would just boot the system up and run MoonSols DumpIt command to get a copy of the active RAM. Then I can use the memory dump output and feed it into Volatility!

Or so I thought…

DumpIt works great for grabbing a full copy of your active RAM so you can analyze it for artifacts. Simply Download the file, and place it where you want it – USB drive, hard drive etc. Then just run the command, and the full active memory of the system will be saved in the same directory.

I ran DumpIt in Windows 8 and it worked flawlessly:

Yeah! Now all I need to do is take the .raw memory dump file and feed it into the memory analysis program Volatility. And I should be able to see tons of information and artifacts including network connections, users, services and other goodies!  🙂

I started out by using the imageinfo command. This command returns the exact operating system level to Volatility so that it correctly maps memory locations with services when you use the more advanced commands.

(I created a whole series on using volatility to perform analysis on Windows 7 last year)

When I ran Volatility, it was unable to determine the OS level. I was using the latest version that just came out this month. A quick search on their website and it looks like Wind0ws 8 functionality will not be out for several more months…

Well, that was the final brick wall for me. I had other things to do and had to walk away from it at that point.

Anyone have any ideas or know of any other open source memory analysis tools like Volatility that will work with Windows 8?

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.