The Australian Cyber Security Centre released a "simulated cyber security challenge" which was first used at a security conference called BSides Canberra2021. It is an awesome challenge to have a go at and provides questions and answers so you can test your knowledge. The challenge can be found here.
We will examine the memory file provided in the challenge using Volatility. In doing so, we will explore the functionality and features of Volatility that can be used when examining memory files in an incident response engagement.
What is RAM?
Random Access Memory, or RAM, is the memory that a computer uses to temporarily write information it has read from the hard disk so that it can use it quickly when required, resulting in a faster user experience as RAM is very quick compared to the read/write speeds of a hard disk.
For example, you may have noticed when running Google Chrome that if you look at the task manager, Chrome tends to use a lot of RAM. This is because Chrome uses the RAM to store information related to running the program. The specifics of why it uses so much? I'm not sure but many a joke has been had as a result.
As mentioned above RAM is only temporary storage, or what we refer to as volatile, meaning that when the computer is turned off, the RAM is erased too.
Why is RAM important to investigate?
When responding to an incident, RAM can be extremely useful in identifying artifacts relating to the attack and the actor involved.
It is important to consider if you are able to do a RAM dump (copy the contents of RAM) when dealing with a live system (hasn't been turned off).
Memory Analysis with Volatility
One of the commonly used tools for examining RAM is called Volatilitycreated by The Volatility Foundation. It can be run on Windows, Linux or Mac operating systems adding to its usefulness and ease of use.
Let's take a look at how we would examine a RAM dump using Volatility. I will be using REMnux, a Linux distro created by Lenny Zeltserfor malware analysis but includes tools such as volatility and doesn't require much setup.
Note: Some of the output from volatility in this article is lengthy but I believe it is a good habit to view what the output will look like if you were to be conducting memory analysis yourself and adjust to the output produced.
Volatility Overview in the terminal
When first looking at volatility, we can use the command "vol.py -h" shown in the snip below to identify what its features, arguments and plugins are.
All Volatility commands are based on the same command and only vary depending on the plugin you use which will determine if you are required to provide other arguments.
vol.py -f [image] profile=[profile] [plugin]
Volatility Profiles
Our first question is what version of Windows was in use when the RAM was captured? We need to know this to apply the correct 'profile' in Volatility for it to correctly parse the memory dump.
The below command can be used to identify what profiles are supported in the version of Volatility you are using.
vol.py --info | more
The output of this command for Volatility 2.6.1 at the time of writing this article are outlined below and as we can see there is good support from Windows XP through to Windows 10.
VistaSP0x64 - A Profile for Windows Vista SP0 x64
VistaSP0x86 - A Profile for Windows Vista SP0 x86
VistaSP1x64 - A Profile for Windows Vista SP1 x64
VistaSP1x86 - A Profile for Windows Vista SP1 x86
VistaSP2x64 - A Profile for Windows Vista SP2 x64
VistaSP2x86 - A Profile for Windows Vista SP2 x86
Win10x64 - A Profile for Windows 10 x64
Win10x64_10240_17770 - A Profile for Windows 10 x64 (10.0.10240.17770 / 2018-02-10)
Win10x64_10586 - A Profile for Windows 10 x64 (10.0.10586.306 / 2016-04-23)
Win10x64_14393 - A Profile for Windows 10 x64 (10.0.14393.0 / 2016-07-16)
Win10x64_15063 - A Profile for Windows 10 x64 (10.0.15063.0 / 2017-04-04)
Win10x64_16299 - A Profile for Windows 10 x64 (10.0.16299.0 / 2017-09-22)
Win10x64_17134 - A Profile for Windows 10 x64 (10.0.17134.1 / 2018-04-11)
Win10x64_17763 - A Profile for Windows 10 x64 (10.0.17763.0 / 2018-10-12)
Win10x64_18362 - A Profile for Windows 10 x64 (10.0.18362.0 / 2019-04-23)
Win10x64_19041 - A Profile for Windows 10 x64 (10.0.19041.0 / 2020-04-17)
Win10x86 - A Profile for Windows 10 x86
Win10x86_10240_17770 - A Profile for Windows 10 x86 (10.0.10240.17770 / 2018-02-10)
Win10x86_10586 - A Profile for Windows 10 x86 (10.0.10586.420 / 2016-05-28)
Win10x86_14393 - A Profile for Windows 10 x86 (10.0.14393.0 / 2016-07-16)
Win10x86_15063 - A Profile for Windows 10 x86 (10.0.15063.0 / 2017-04-04)
Win10x86_16299 - A Profile for Windows 10 x86 (10.0.16299.15 / 2017-09-29)
Win10x86_17134 - A Profile for Windows 10 x86 (10.0.17134.1 / 2018-04-11)
Win10x86_17763 - A Profile for Windows 10 x86 (10.0.17763.0 / 2018-10-12)
Win10x86_18362 - A Profile for Windows 10 x86 (10.0.18362.0 / 2019-04-23)
Win10x86_19041 - A Profile for Windows 10 x86 (10.0.19041.0 / 2020-04-17)
Win2003SP0x86 - A Profile for Windows 2003 SP0 x86
Win2003SP1x64 - A Profile for Windows 2003 SP1 x64
Win2003SP1x86 - A Profile for Windows 2003 SP1 x86
Win2003SP2x64 - A Profile for Windows 2003 SP2 x64
Win2003SP2x86 - A Profile for Windows 2003 SP2 x86
Win2008R2SP0x64 - A Profile for Windows 2008 R2 SP0 x64
Win2008R2SP1x64 - A Profile for Windows 2008 R2 SP1 x64
Win2008R2SP1x64_23418 - A Profile for Windows 2008 R2 SP1 x64 (6.1.7601.23418 / 2016-04-09)
Win2008R2SP1x64_24000 - A Profile for Windows 2008 R2 SP1 x64 (6.1.7601.24000 / 2016-04-09)
Win2008SP1x64 - A Profile for Windows 2008 SP1 x64
Win2008SP1x86 - A Profile for Windows 2008 SP1 x86
Win2008SP2x64 - A Profile for Windows 2008 SP2 x64
Win2008SP2x86 - A Profile for Windows 2008 SP2 x86
Win2012R2x64 - A Profile for Windows Server 2012 R2 x64
Win2012R2x64_18340 - A Profile for Windows Server 2012 R2 x64 (6.3.9600.18340 / 2016-05-13)
Win2012x64 - A Profile for Windows Server 2012 x64
Win2016x64_14393 - A Profile for Windows Server 2016 x64 (10.0.14393.0 / 2016-07-16)
Win7SP0x64 - A Profile for Windows 7 SP0 x64
Win7SP0x86 - A Profile for Windows 7 SP0 x86
Win7SP1x64 - A Profile for Windows 7 SP1 x64
Win7SP1x64_23418 - A Profile for Windows 7 SP1 x64 (6.1.7601.23418 / 2016-04-09)
Win7SP1x64_24000 - A Profile for Windows 7 SP1 x64 (6.1.7601.24000 / 2018-01-09)
Win7SP1x86 - A Profile for Windows 7 SP1 x86
Win7SP1x86_23418 - A Profile for Windows 7 SP1 x86 (6.1.7601.23418 / 2016-04-09)
Win7SP1x86_24000 - A Profile for Windows 7 SP1 x86 (6.1.7601.24000 / 2018-01-09)
Win81U1x64 - A Profile for Windows 8.1 Update 1 x64
Win81U1x86 - A Profile for Windows 8.1 Update 1 x86
Win8SP0x64 - A Profile for Windows 8 x64
Win8SP0x86 - A Profile for Windows 8 x86
Win8SP1x64 - A Profile for Windows 8.1 x64
Win8SP1x64_18340 - A Profile for Windows 8.1 x64 (6.3.9600.18340 / 2016-05-13)
Win8SP1x86 - A Profile for Windows 8.1 x86
WinXPSP1x64 - A Profile for Windows XP SP1 x64
WinXPSP2x64 - A Profile for Windows XP SP2 x64
WinXPSP2x86 - A Profile for Windows XP SP2 x86
WinXPSP3x86 - A Profile for Windows XP SP3 x86
In our case, as we haven't created the RAM dump and as such we do not know what version of Windows the computer was using, the challenge provides us with the profile 'Win10x64_17134'.
Fortunately, if for some reason or other we didn't know what version of Windows the RAM dump came from then we can use the below command to ask Volatility to attempt to identify the version.
vol.py -f <path to image> imageinfo
This can take time in some cases but below is the snipped output from the terminal. As we can see the first suggested profile is 'Win10x64_17134'. Therefore a good bet is to try that profile first and work your way through the other suggestions if the first doesn't work.
One of the process plugins I find most useful to start analysing is 'pstree'. This plugin allows you to view the processes running on the device at the time of capture in a tree format showing the parent-child relationships between processes, their Process ID (PID) and time of execution. The output of this command can be lengthy depending on how many processes are running. So, let's have a look and see if anything piques our interest.
What are the items of interest here? Below are some of the processes I find interesting and would be looking to explore further around them.
amazon-ssm-age
This is a virtual machine running on Amazon Web Services (AWS)
powershell.exe
PowerShell was running.
winpmem_mini_x
A memory acquisition tool used in Velociraptor by Velocidex
Several mstsc.exe processes
Used by Windows Remote Desktop Protocol (RDP)
Based on what we have seen in the process tree and identifying items of interest we can start to follow the trail of information to our next port of call.
Networking Plugins
Let's have a look at what sort of network connections have been captured using the 'netscan' plugin.
Looking through the information provided to us we can identify what was the IP address of the device by looking at the 'Local Address' column. 127.0.0.1 is the loopback address, 0.0.0.0 is a non-routable address but we see that the address 10.1.1.182 is the unique local address and signifies the IPv4 address of the device another key piece of information.
Next, looking at the "Remote Address' column we notice two addresses with established connections. I will leave any further analysis so as not to spoil the challenge.
Registry Plugins
UserAssist
The UserAssist artifact tracks executed GUI programs and it is an incredibly useful piece in building a picture of what has occurred on a system. It is found in Windows systems at the location below if you are completing disk forensics.
WF.msc is used to view 'Windows Defender Firewall with Advanced Security' and PowerShell is used for executing commands or scripts on a Windows device. This could be normal but seeing as it is an incident response case, I'd be curious to explore further.
Conclusion
We have looked at how we can identify the correct profile of the RAM dump you would like to examine. A plugin to view running processes in memory, a networking plugin to view what connections were present and a registry plugin using the UserAssist artifact to identify what programs have been executed on the device.
Hopefully, you can now have a go at doing some memory analysis testing using Volatility or start to make use of it in your incident response engagements. Volatility is very powerful as we have seen, and I plan to do a couple more posts regarding other plugins and what information we can gather using them.
Finally, a reminder that memory analysis and disk forensics should complement each other and not be used on their own. Although circumstances will dictate that but hopefully, you have the opportunity to capture both on your next engagement.