FOR532: Enterprise Memory Forensics In-Depth

Overview

For many incident responders, the inner workings of memory are still terra incognita. Yet, many cases can be solved faster by looking into memory.

The first step towards successful memory forensics is understanding how memory works. Even with the variety of different operating systems, how memory exists is more similar than many would think.

On day 1 we will start looking into the inner workings of memory. We then move on to explore different ways of extracting memory from various operating systems (Windows and Linux, 64 and 32 bit). This includes virtual machines and techniques supporting cloud workloads.

To work with memory, we will leverage volatility 2 and volatility 3 in the labs. There are differences in these versions that will clarify when its best to use one vs the other. We then deep-dive into memory objects using volshell to display that dereferencing memory objects is not as complicated as it might seem.

Once you understand the major memory objects and their use in forensics investigations, we will investigate memory management and how that affects our investigations.

Finally, we work on a 5-step process to rapidly identify malware in memory. We differentiate between malware that runs as its own process and malware code that runs in the realm of another process.

Exercises

• SIFT Workstation orientation
• Memory Extrcation (Windows & Linux)
• Volshell understand Memory layouts
• Find the malware
• Find the hidden malware (network)

Topics

• Fundamentals of Memory
• What is the role of Memory
• Quick wins in Memory forensics
• Kernel Memory vs. Process Memory
• Which Memory artifacts survive a reboot
• History of Memory forensics
• Order of volatility in Memory
• Memory acquisition challenges
• Memory acquisition in practice
• Targeted memory acquisition
• Introduction to Analysis Tools
• MemProcFS
• MemProcFS Analyzer
• Volatility
• Understanding Memory Structures
• Understanding byte order
• Basics of Memory objects
• Memory forensics vs. debugging
• Key Memory objects
• Overlays
• Doubly-linked lists in memory
• Object headers
• VAD
• Memory Management
• Page layout and addressing
• Virtual Memory
• Pooling
• Memory scrambling
• Finding Malware
• Preliminary steps
• Understand the 5-step process
• Locate hidden processes
• 6 process factors
• Network-object based malware detection

Overview

During an intrusion, using memory analysis sometimes feels like cheating. Finding active malware should not be this easy.

Malware authors spend a lot of time to hide their malware better. They have one major disadvantage. Malware can hide, but it must run. That means, that the malicious code must eventually hit the CPU in plain sight. Even well-written malware is most vulnerable in memory. On day two we start focusing on well-hidden malware that runs in the memory space of legitimate processes or even interacts directly with the kernel. You will get the chance to manually mimic malware by altering the process list using Direct Kernel Object Manipulation (DKOM). This allows you to better understand how simple hiding techniques can be and that the inner workings of an operating system are nothing monolithic where you cannot change things.

We will also look at windbg which is a free Microsoft tool that supports live memory analysis and even alteration in a running operating system. You can even use it remotely over the network.

A large part of the day focuses on memory-based artifacts that allow you to tell the story of an attack. Often attackers do not install malware on every endpoint they access. Instead, they jump there using legitimate tools like Remote Desktop or psexec. We, as defenders, must remain vigilant to understand what they did on these systems. Memory can give you a quick shot at their actions.

Finally, sometimes it is the legitimate user of a machine who misuses IT assets for criminal actions. There are several artifacts in memory that allow investigators to get a better idea about what users have done most recently on computers. It includes the extraction of encryption keys and even Facebook chat messages. This can be valuable for internal and criminal investigations. We will also focus on how the corresponding volatility plugins work so you will be able to write your own later in the class.

Exercises

• Memory Injection
• Hooks
• Manual DKOM
• WinDBG
• Memory Artifact extraction

Topics

• Finding Malware - Injection
• How does Memory injection work
• Import Address Table (IAT)
• Load Order Hijacking
• Sideloading
• Process Hollowing
• Reflective Loading
• Atom Bombing
• MemProcFS injection detection
• Finding Malware - Hooks
• What are hooks
• How to write a hook (simplified)
• SSDT Hooks
• IRP Hooks
• IDT Hooks
• IAT Hooks
• Volatility plugins to analyze hooks
• DKOM (Direct Kernel Object Manipulation)
• What is DKOM
• Userland vs. Kernel
• DKOM in Malware
• Frequently modified structures
• Countermeasures against DKOM
• Userland Object manipulation
• WinDBG
• Fundamentals of Windbg
• Using Windbg to identify and understand malware
• Limitations of Windbg
• Artifact extraction
• Process Artifacts
• Extraction strategies
• Limits of process extraction
• Drivers
• User Artifacts
• Types of user artifacts (Red Poster)
• Registry hives in memory vs. on hard drive
• Limits of EDRs
• Case samples

Overview

Many responders think that Memory forensics is something for single host investigations. They could not be more wrong.

This part of the course focuses on scaling memory forensics. Current tools allow incident responders to scale core memory forensics techniques to thousands of machines all at once. This drastically reduces survivability of an attacker. We will introduce the memory capabilities of a tool called velociraptor which is the incident response swiss army knife that we also use in the FOR508 and FOR608 classes to demonstrate large-scale repones. Modern incident response comes with a lot of challenges. One of them is resource management. We will also shed light on when memory forensics is the right approach in an investigation and how it can be built into an IR process efficiently.

For thisreason we also dive into memory forensics automation. If you do something the same way more than twice, you should think about automating it to save time in the future. Another important point for large scale response is collaboration and knowledge transfer. We will focus on how to establish that in memory forensics.

As enterprise networks are rarely ever Windows-only, we will discuss Linux memory forensics. That is particularly important as often attackers enter the network via external facing machines and appliances. Memory might give you a quick shot to identify what is actually going on.

Sometimes it is better and faster to leverage unstructured memory analysis rather than a structured analysis. We will focus on the major techniques to apply unstructured analysis techniques locally and in scale.

Exercises

• DWARF & /proc
• Configure Velociraptor for Memory forensics
• Write your own velociraptor artifact
• Node-red automation
• Unstructured Memory analysis

Topics

• Linux memory forensics
• Linux Kernel
• Linux Symbols
• DWARF
• The /proc filesystem
• Scaling memory forensics
• Possible solutions
• Integrating into enterprise IR tactics
• Remote Memory acquisition
• Velociraptor
• Scaling techniques in IR
• Velociraptor artifacts
• Automated Processing
• MemProcFS Automation considerations
• MemProcFS Analyzer
• Requirements for automation
• Node-Red for IR automation
• Collaborative investigations
• Resource management in IR
• Jupyter Notebooks
• Orochi
• Unstructured memory analys is
• Structured vs. unstructured analysis
• Tools and techniques
• Large-scale unstructured analysis

Overview

Memory forensics is a cutting-edge field. That means that many possibilities have not been explored yet. So it makes sense to be able to push the current borders of memory forensics further.

Today's enterprise infrastructures heavily rely on containerization. The main representative of that is docker. In this section we will have a shot at docker memory forensics. You will experience how attackers gain access to docker containers firsthand and then you will investigate the breach yourself.

Volatility used to be the number one memory forensics tool. With volatility 3, the support for modules that used to be there in volatility two Is lacking. Additionally, volatility 3 has lost the capability to do live memory analysis which makes it harder to use in large scale live investigations. While we cant do anything about the lacking live forensics capabilities, its pretty straight forward to write volatility 3 plugins. Well write our own version of the psxview plugin.

Memory is short-lived is what we hear a lot. This is not quite true. First of all, servers keep running for long stretches of time and even than they are rarely switched off but rebooted. Secondly most people do not fully shutdown their machines which also preserves a number of memory artifacts. Finally, there are a few portions of memory that are preserved on the hard drive for indefinite amounts of time. These might make the difference between success and failure in critical investigations.

We will investigate page files, hibernation files, and crash dumps.

Finally, you can test your knowledge in a scoreboard-style capstone.

Exercises

• Docker Memory forensics
• Write your own volatility plugin
• CAPSTONE

Topics

• Docker Memory forensics
• Docker basics
• Useful docker commands
• Find and extract container process Memory
• Docker in enterprise setups
• Custom volatility plugins
• How do plugins work in volatility 3
• Layers
• Our plugin idea
• Pagefiles & Hibernation
• Page files and challenges
• Hibernation in modern OS
• Crashdumps
• CAPSTONE