SEPTEMBER 27, 2020 GUIDANCE, LABS, THE HUNT

20,967 views
Reading Time: 23 minutes
This memory analysis lab will walk you through the entire process, start to finish, for investigating malware in
a system’s memory.

Case 001 Memory Analysis [photo courtesy of https://pxhere.com]

Case 001 Brief and Materials.
Get the materials and follow along!
Have you built your DFIR Fort Kickass, yet? How to build a DFIR Analyst Workstation found here.
Make sure you understand the basic rundown of forensic artifacts.
This post assumes you have a DFIR Analyst Station ready to analyze the Memory Images from the Case of the
Stolen Szechuan Sauce.

LEARNING OBJECTIVES OF MEMORY ANALYSIS

 Understand the advantages and goals of Memory Analysis
 Be capable of using common Memory Forensics tools
  Quickly identify network connections
 Quickly find rogue and malicious processes
 Extract plaintext malware samples from memory

SEMI-REQUIRED KNOWLEDGE
 Computer Processes and threads
 Computer memory (the RAM) basic knowledge
 Basic Linux Command Line Fu
 Basic Virtual Machine Operation

COMMON TOOLS
 Volatility
 Rekall
 Redline
 Cyber Triage

TOOLS COVERED HERE

 Volatility
o netscan
o malfind
o pstree (-v)
 Clam Scan
 FLOSS
 Strings
 GREP

OTHER LEARNING RESOURCES ON THIS TOPIC

 Book: “The Art of Memory Forensics“
 Book: “The Little Handbook of Windows Memory Analysis“
 Videos:
o 13Cubed – Intro to Memory Forensics
o 13Cubed – Intro to Windows Memory Analysis
 SANS Poster for Hunting Evil
 SANS Course: FOR526 – Advanced Memory Forensics and Threat Detection

MUSIC
 Robot Music
 Metal Forensics

NOTES
  Keep solid notes on your thinking around evidence and data that you find
o This is for teammates to understand your thinking
o Understand your own thinking later… or after sleep.
 Notes should be accompanied by screenshots that tell a story
o Examples: Highlights, Boxes, Arrows Text. The reader should quickly
understand what they’re looking at
 A great note-keeping App that teams can use to coordinate is OneNote.
o Each host gets a tab etc.
 A great piece of software to take Screen Shots is Greenshot

WALK-THROUGH TO GET YOU STARTED WITH

MEMORY ANALYSIS
SCREENSHOTS
As you go through an investigation you should be taking screenshots of key items and saving those with good
notes as to why it seemed important at the time. Additionally, screenshots should ‘Stand Alone’. This means
they should have good labels, arrows, and highlights explaining exactly what you have found. This will help
teammates, customers, and you understand your findings at the time you took the screenshot. Example
screenshots will be provided – but not all screenshots here are examples of what would be in a
report. GreenShot is amazing for taking screenshots. OneNote works great for keeping and sharing notes with
your team.

PIVOT POINTS
 From PCAP: Malicious filenames, IP Addresses, and Malicious Activity times.
 To PCAP: Malicious IP Addresses, Processes and file names.
 From Disk: Malicious filenames and paths, IP Addresses, and Malicious Activity times.
 To Disk: Malicious file names and paths, DLL’s, IP Addresses, Exfiltration filenames
 From Timeline: Malicious filenames and paths, IP Addresses, processes, DLL’s.
 To Timeline: Malicious filenames and paths, IP Addresses, processes, DLL’s.

TIMELINE ARTIFACTS IN MEMORY

When it comes time to do the Super Timeline of the disk image we will run a Volatility module called
Timeliner against the memory image. Timeliner analysis of the memory image is a huge win here. Certain
artifacts that investigators use to determine things like evidence of execution live in memory before being
written to disk. One example is the ShimCache. The ShimCache is an artifact produced when Windows tries to
determine if an executable needs some compatibility assistance (overly simplified explanation). They also
record a timeline of when executables are run! ShimCache entries are not written to the registry until
shutdown. However, they are in memory! Investigators can pull these entries from memory and place these
entries into the Super Timeline. Link to Supertimline Analysis (Coming soon).

ACQUIRING MEMORY
The Memory Image for this walk-through is provided at the link in the beginning of this post. A quick lesson
memory acquisition follows.
You want to acquire memory first. It is what is known as ‘Volatile’. This means it is highly prone to changes.
Investigators want the best possible view into the state of the machine at the time of the incident; or as close to
it as they can. The more activity on the machine between the incident and the time of collection can mean less
fidelity of the samples collected.
In this ‘case’ the incident responder had a thumb drive with incident handling tools prepared on it and inserted
it into the victim machine. FTK Imager Lite was then run on the machine from the thumb drive. FTK Imager is
a free tool from Access Data that makes quick work of forensic collection of the disk images, memory images,
and ‘protected files’. Andrea Fortuna has a great walk-through on the collection of artifacts from a
machine. As company networks begin to spread out physically, the collection techniques are shifting to remote
solutions and lighter ‘triage’ collections. Understanding memory forensics will still be key for digital forensics
for many years to come.

 Collect Memory first

 Remote collection is the new hot dance move
 Memory Analysis is key in DFIR

ANALYSIS STATION SET-UP

If you haven’t built your nest yet, head over to building a DFIR Fort and get up to speed!

WHICH IMAGE TO START WITH

As a personal choice, the Memory for the Domain Controller (DC) is a good place to start. It is the heart of a
Windows Enterprise. DC’s are key terrain for both defenders and attackers. Starting efforts at the DC is not a
bad idea, especially when it is suspected to be infected. It is suspected here because the victim indicated that
data was stolen from it. This alone doesn’t mean it’s infected, it only means it was accessed. However,
common attacker techniques tell us they typically want to compromise it in some way. This could be through
the installation of malware or simply adding a new account for the attacker to use to login with later.

 Start with key terrain and systems the attacker interacted with.

TRANSFER THE IMAGE TO THE VM

An easy option is to ensure the VM is network-connected (have you tried ‘sudo dhclient’?). If it’s connected
and ready, simply download the Memory Images from the Case 001 Brief. Other options would be to drag and
drop the file, or cut and paste the file, from the host to the VM Desktop. You also could simply put it on a
USB, and insert the USB into the host and tell the Hypervisor to pass it to the VM. In any case, you will need
the image inside the VM.
Place the image in the /cases folder once you have it loaded into the VM. Each case being investigated
should get a unique case folder in the /cases directory. Each host should get a directory in that directory.
Example layout below.
 Making a Case Dir for this Case
From here it is recommended a memory directory also be created to keep all of the outputs we will be creating
separate from everything else.
Place the memory image in the memory folder and unzip the files.
$ unzip memory.zip)

 Load forensic artifacts into the cases directory.

 Each host gets a folder
 Each effort on that host gets a folder

FOUR MEMORY ANALYSIS TOOLS

As of this writing, there are four tools that dominate the DFIR World. There is Volatility 2 and 3, Rekall and
Redline. A lot of commercial tools exist but are actually nice GUI’s wrapped around Volatility. Volatility and
Rekall have the same origins. Rekall is a fork of Volatility 2 and brings speed and many other features with it.
Volatility 3 is working to replace Volatility 2, but it hasn’t yet as of this writing. Remember to learn the
methodology and not Click-ology. If you get the concept of what is shown here you will be able to apply it to
nearly any Memory Analysis tool.

VOLATILITY 2
IMAGE INFO
Hopefully, the person who retrieved the image took great notes on the affected system. This is often not the
case. This knowledge will be key in analyzing the image. Memory analysis revolves around essentially finding
answers in the memory to questions the investigator has. As you work you should start to build a hypothesis
based on evidence you find. Do not get married to a hypothesis. Go where the data takes you. Finally, test the
hypothesis in a lab if possible.
To find the answers the framework being used needs to know where to find the data structures that have these
answers. The map to finding these specific structures in the billions of bytes is known as a profile. There are
efforts underway to remove the need for telling the framework which profile to use. For now, we will practice
‘asking’ the image what profile to use. The framework does this by searching the bytes for known signatures of
operating systems in the Kernel Debugger Block (KDGB).
In this scenario, you ask around and sure enough, the incident handler took a screenshot of the System Info
page and provided in on request.

SYSTEM INFO PAGE FOR THE DC

To verify the images weren’t mixed up we will still confirm with the image info plugin of Volatility. A good
practice is to pipe many of the Volatility Plugins into a text file. Some plugins take a LONG time to run.
Rather than run the same plugin twice you can simply re-read the text output – as long as you saved it to text.
When using the tee command the system will no longer output text in color. To preserve color simply
install expect in sift with sudo apt install expect. Then lead the commands with unbuffer. Note:
none of the modules demonstrated here have important color coding.
 1. The pattern to Volatility Commands here are: vol.py -f imagename pluginname |tee
pluginname.out
2. Vol is aging out. This is a warning from Py2 stating it is End of Life
3. Vol is scanning the Kernel Debugger Block for Signatures of data structures that match
known Operating Systems
4. Vol is providing the guesses of the Operating system based on the KDBG Scan to the
Analyst. In our case we know it to be Win2012R2x64.
5. Times relevant to the case. In this case it incorrect! The image taken LOCAL time is correct
but with the wrong UTC time! That is an interesting note. This could be due to something
with the VM in the Lab and where it thinks it was… maybe. We will have to keep an eye on
this during Super Timeline creation. Another reason a log is very important during an
investigation.

FROM HERE ON FOR THE DC01 WE WILL BE USING A

COMMAND LINE PATTERN LIKE THIS:

Running subsequent commands is now as easy as hitting the up arrow and changing the latter part of the
command rather than re-typing it. One could also set an alias for the first portions of the command if desired.

 Tee all commands into output files. Any extention works but .out is a safe bet
 Use the up arrow to simply modify previous run commands rather than retype them all.
 CTRL+R will also allow you to search your history for previous commands

NETWORK CONNECTIONS
Understanding which processes have, or recently had, connections to remote systems is key. Most modern
Malware has network functionality. This can quickly help an investigator narrow their search for which
process(es) in memory is (are) malicious.
This will produce A LOT of data on a DC. A good practice here is to do some Linux Fu against the output file
after scrolling through it with the less command. What to look for:

 Known bad IP Addresses (If pivoting from other data and findings)
 Known Malicious Processes (If pivoting from other data and findings)
 Processes that don’t normally connect to the internet

Looking through the output we immediately notice that dns.exe is loud! Very loud. We can reduce the noise by
removing dns.exe from the data. However, we should make a mental note here that dns.exe could in fact be the
malicious process. We will come back to that if we need to. For now, let’s look at connections not related to
dns.exe with: grep -v dns.exe netscan.out|less.
That’s better.

WHAT ON EARTH AM I LOOKING AT?

1. Memory offset of where this connection data structure begins in the connection pool.
2. Protocol of the connection.
3. Which local interface the connection is coming from. Useful for Servers with multiple
Interfaces. Was this in the DMZ? The Management LAN?
4. Remote System this connection is connected to.
5. State of the connection at the time of collection.
6. Process ID
7. The Process is allegedly responsible for this connection.
8. Timestamp of when this connection started.

Do any processes stand out as odd?

Take some time. Look at the names of processes. Google the names. Especially ones with connections to
remote systems.

Try it out before scrolling further.

MEMORY ANALYSIS SPOILERS FOLLOW.

Did you find a process associated with a name that isn’t well known to Captain Google as being a normal
windows process? Was it connected to the internet?
Great job if you found it on your own! If not, do not worry. It takes practice. Note the IP Address, Owner
Name, and PID. Take a screenshot. If you haven’t found it yet, let’s walk through it together.
We find a single process connected over IPv4 at the time of the memory collection. Note: this VM really was
connected to the actual internet and the Lab net at the same time. It’s a bit of luck this was the only connection.

Notice the language. It is not immediately malicious because it is interesting to us. If this was for a report we
may change the language once this information is confirmed and supported with forensics and adequate
screenshots.

THE GOOGLE SEARCH SHOWING THIS IS NOT A COMMON

WINDOWS PROCESS.
While there are some references to past malware this looks fairly unknown to the Windows World. It is
“interesting” to us at this time. Next, we turn to VirusTotal to see if anyone else is tracking this IP Address as
malicious.

This is interesting. There aren’t any detections yet. This company doesn’t do a lot of business in Thailand, and
there aren’t a lot of Content Distribution Nodes out that way either. Checking the Relations tabs might help us
out. We see that around the time of the incident there was reference to happydoghappycat-th.com. Lets pivot
off of that and look into some Threat Streams.
 1. It’s currently TLP: White. This means it’s not known as an indicator of compromise.
2. This is interesting. It’s a baby domain. That is often a sign of trouble. How would any user
on this network know anything about this website… especially in Thailand. These facts will
shift over time. In other words, if anyone is looking at this exercise after November 2020
this site will no longer be a ‘Baby Domain’. The IP Address will likely no longer match, and
the site might be completely gone. For this exercise use the information above.
3. The first time of domain observation. A decent indicator of the ‘born on date’.

Note: No detections or warnings about an indicator does not mean its benign (good). It just means it
is not yet known to be bad.
This IP and Domain was briefly an IOC for an APT. Between the time of this writeup and when the
research was done for the lab, it was no longer considered an IOC. It worked out well since there are
many cases where there is lag time between detection and knowledge of an IOC reaching the
Community.

MALFIND
Malfind is a Volatility program that frankly does some magic for the investigator. It examines many aspects of
every process in memory and does a great job of determining which ones smell of evil. As stated from the
Malfind GitHub page:
The malfind command helps find hidden or injected code/DLLs in user mode memory, based on characteristics
such as VAD tag and page permissions.
Malfind is great at its job. It will get Analysts close to the mark. To do this, simply run the plugin and tee the
output as normal.