They stole… what? Identifying exfiltrated data: Part 3

Memory forensics is often an overlooked capability. However,  with the right skills and following a timely capture of the memory contents, it can provide a treasure trove of information.

In this third and final part of the series, we will dive deeper into memory artifacts to address one of the most challenging questions in many investigations: we know exfiltration took place, but which files were exfiltrated?

One of the main challenges with memory forensics is timing. Forensic analysis of memory contents is not always fruitful because it is often too late to obtain a useful memory dump. Memory contents are volatile, meaning the contents are gone forever when the device is switched off. In practice, everyday device users who encounter a suspicious system often shut it down immediately. This action unintentionally eliminates the opportunity to collect valuable memory evidence.

Another challenge centers around how long artifacts remain in memory. While a device is switched on, a system will reuse parts of its limited memory. This means that the longer it takes to obtain a memory dump, the more likely it is that important artifacts are overwritten.

Despite these challenges, memory remains an exceptionally valuable source of information. Many artifacts exist in memory that cannot be recovered from disk. For example, some malware is nearly impossible to identify when it is found on disk. This is due to the use of encryption, but in order to run, it will likely need to decrypt itself at some point. That means the decrypted malware could often be extracted from memory. In addition, command histories, clipboard entries and even passwords may persist in memory after a threat actor has used a device. For all of these reasons, the key is to acquire the memory dump as soon as possible.

Memory forensics does not always require complex analysis. In some cases, a quick string search across the entire memory dump file can provide the answers you need. The screenshot below shows some of the output from a regular expression-based (regex based) string search for relevant file names. In our simulated exfiltration scenario, only 5,000 files were copied by the threat actor, but our search in memory returns over 80,000 results. This is an indication of how much data remains in memory after the file operations are completed and after files are removed from disk. Some file names are mentioned more than 10 times throughout the memory dump file. In some cases, full file paths are recovered, something we could not see in the disk-based forensics covered in Part 2 of this series.

With some smart searches and a few pivots, it is often possible to reconstruct the commands used by the threat actor to stage data for exfiltration. In the screenshot below, we can see that the password used by the threat actor is “findme111”. If this Zip file is still recoverable, through disk forensics, the password can be used to decrypt and identify all files contained within. When available, this is the most accurate method for determining exactly which files were staged for exfiltration.

Some files, or snippets of files, remain in memory after the system has opened, moved or processed them in any other manner. Software such as MemProcFS or the Volatility framework can identify these files and attempt to recover them. This includes the $MFT file, discussed in Part 2 of this series, which talks about disk forensics. An operating system loads this Master File Table, containing references to all current files and some deleted files, into memory so it can work with the files on a hard disk.

The screenshot below shows file names recovered from an in-memory $MFT file, using MemProcFS analysis. Although a full reconstruction of the files is not possible, since the actual data did not exist in the memory space, this metadata provides valuable insight. It can determine which files existed on the system and, based on the timestamps, which files were likely staged to prepare for their exfiltration.

Memory forensics can extend far beyond the techniques discussed here and quickly become extremely technical. It can be used to link files to processes, reconstruct deleted log files, find decryption keys and uncover many other valuable artifacts, most of which are far out of scope of this article.

While in-depth analysis can be rather time consuming, a quick triage approach often provides most answers. In many cases, the initial analysis surfaces information that can’t be recovered through any other means. The key here is to acquire the memory dump as soon as possible and before the device is switched off.

Given all the required tools are open source and well documented, it is worth designing, documenting and testing a process for memory acquisition and analysis. This process should be incorporated within playbooks, table-top exercises and the organization’s broader incident response plan. One day, this often overlooked capability can have a significant impact and potentially prevent substantial financial and operational loss.