Windows executable analysis is a key aspect of Digital Forensics and Reverse Malware Engineering. Identifying the capabilities of a program can help to target potential malicious code and orient the later reverse code analysis phase. In this blogpost, we will dive into the structure of the Windows Portable Executable (PE) and how we can extract the imported functions in the context of memory analysis.
Windows executable analysis is a key aspect of Digital Forensics and Reverse Malware Engineering. Identifying the capabilities of a program can help to target potential malicious code and orient the later reverse code analysis phase. In this blogpost, we will dive into the structure of the Windows Portable Executable (PE) and how we can extract the imported functions in the context of memory analysis.
In the Digital Forensics ecosystem, the field of memory forensics can help uncover artifacts that can’t be found anywhere else. That can include deleted files, network connections, running processes, rootkits, code injection, fileless malware and many more.
Microsoft introduced the hibernation feature in Windows 2000, allowing systems to be powered down while preserving their volatile state. This is achieved by saving RAM contents and processor context to a file called hiberfil.sys before shutting down inside the root folder of the filesystem drive. When the computer is turned on again, the system restores the volatile state from the saved file. Hibernation files are valuable for digital forensic professionals as they store temporary data from RAM to non-volatile storage, eliminating the requirement for specialized tools on the target device.
The Hibernation file structure has evolved in time. In this blog post, we will dive into the structure of the modern Windows hibernation file and propose a new translation layer for the volatility3 framework to create a raw memory image from a hibernation file.
Memory forensics is a huge help when performing an investigation and during incident response. Collecting memory images and analyzing them at scale is a challenge.
It is crucial to have the capability of examining memory images on storage platforms other than traditional file systems. With the emergence of cloud technologies, new forms of storage known as object storage have emerged. Enabling memory analysis on object storage provides exciting opportunities for innovation and advancement.
In this article, we will go through the journey of making the volatility3 framework compatible with s3 object-storage to perform memory analysis over the network. Also, the reader will discover how this new capability can and will be applied to the VolWeb 2.0 project which is still in developpement.
Disclaimer : All of the information about the volatility3 framework given in this blogpost are from my own understanding of the framework and of the project documentation1. Feel free to contact me at felix.guyard@forensicxlab.com to correct any mistake made in the explanations.
On May 1st, 2023, vdhoney1 raised concerns about a flaw he found impacting KeePass 2.X.2. Vdhoney claimed to be able to reconstruct the master password from memory. A POC 3 was later released by the researcher not only in dotnet but also in python34.
Today in this blog post we will describe the vulnerability and see how we can create a volatility3 plugin to help forensics investigators to retrieve passwords from memory.
When performing incident response, the adversary often uses legitimate remote access software as an interactive command and control channel. AnyDesk1 is one of those software being extensively used as a sublayer of persistence by threat actors or access other servers in the environment via RDP2. The latter has been often encountered in the wild in the past years as a preferred tool leveraged by known threat actors.
As such, Anydesk should be closely monitored as threat actors could easily alter or delete data after a successful attack; sometimes it is not possible to restore those altered logs. Defending against malicious actions with such remote software can be even more intricate for organizations having approved its legitimate usage. Here we propose to leverage memory forensics to retrieve and analyze artefacts thanks to a custom Volatility plugin that I made available as a free open-source tool for improving digital investigations.
The filesystem is one of the most basic and important concepts in UNIX/Linux. This concept is working around the idea that “everything is a file”, meaning that the hardware, regular files, directories, sockets, kernel data structures, process communications etc are represented as files with their own types. On a filesystem, a file (whatever its type) is assigned with a number called an "inode". An inode is an interface between the blocks on the filesystem and the file.
When a process is running, it is interacting with the hardware, the kernel, the user’s resources etc, therefore opening the required files. Linux is keeping track of the opened files inodes in memory by using the Virtual File System (VFS) and more precisely the directory entry cache (dentry). In this article, I will present how you can extract inode metadata from a modern Linux memory image using the volatility3 framework.
Windows prefetch files are temporary files stored in the %SystemRoot%\System\Prefetch folder. This memory management feature is keeping track of the frequently running applications on a given system. We can extract some data from those files in order to get useful information for a digital forensic investigation. In this blog article, I will explain how we can use memory forensic to extract prefetch files, parse them and create in the end a volatility3 plugin.
This writeup is covering the cyberdefenders.org challenge named "Brave". Today we are going to solve this challenge using the VolWeb memory analysis platform.