This blogpost is part of the Thanatology blogpost series. If you haven’t check it out, I recommend reading the following first:
In this blogpost, we will dive into the concepts of GPT and MBR partition schemes and explore them using Exhume Partitions.
This blogpost is part of the Thanatology blogpost series. If you haven’t check it out, I recommend reading the following first:
In this blogpost, we will dive into the concepts of disk images and how digital forensics examiners can use the Exhume toolkit to read data transparently from different formats. First, we will give an overview of what is a disk image and describe some of the existing formats one may encounter during a digital investigation. Next, we will explore how Exhume Body is providing an abstraction layer to those formats to read data agnostically.
After attending a conference for incident response teams, I joined a project aiming to create a forensic framework allowing acquisition and visualization of evidence from various sources: the Exhume toolkit.
In this quest of retrieving data from various base formats, I got involved in the understanding and implementation of a parser for the VMDK format.
The Virtual Machine Disk format has been created by VMware and is used by all kinds of virtual machines from all types of hypervisors. It is also used in exchange formats used to share virtual machines from one hypervisor to another.
Most IT experts, from cybersecurity to system administrators have heard of VMDK files. And I am no exception. But I never really understood what was behind this format. Sure, I did encounter some difficulties to access data from a VMDK file sourced from and ESXi server but I always found tools allowing to convert the file to a better suited format... Including VMDK itself.
At that moment I wondered why converting a VMDK file to another one could help me get access to the data for forensic purposes. And I've found the answer now I did some serious research on the matter.
In digital forensics, tools are only as valuable as the investigator’s ability to understand and explain their output, especially when presenting evidence in court. Beyond simply extracting data, the methodology behind how artifacts are collected and interpreted plays a critical role in admissibility, reliability and credibility.
This blog post series introduces the Thanatology Project, an open-source, cross-platform digital forensics framework currently under development. Built on top of the Exhume ToolKit (a modular set of Rust-based forensic tools), Thanatology combines performance, transparency, and modern design via a Tauri-based desktop interface. Designed for law enforcement and digital forensic professionals, the project emphasizes not only artifact collection and presentation but will also try to provide help for interpretation.
For example, when analyzing EXTFS file systems, Thanatology will try to offers guidance on timestamp meanings and includes complete extraction details suitable for annexing to formal reports.
The blog series will cover:
While Thanatology is not intended to replace established tools, it will attempt to offers a modular and modern alternative ideal for cross-verifying findings or integrating into custom workflows. This blogpost series is mainly here to provide the community with updates, technical knowledge and any interesting subjects we found along the way.
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.
Video games have become an integral part of our culture, providing entertainment and social opportunities. Unfortunately, criminals have also begun to take advantage of modern video games and their ever-growing capabilities to conduct illegal activities. Organized crime, hate spread, and pedophilia have been documented occurring within games, opening up the potential to a world of cybercrime.
Digital forensics on the Steam application can be especially useful for law enforcement in tracking down and prosecuting these cybercriminals. By investigating video game applications like Steam, digital footprints that can be used to link individuals to games, transactions, and even other players. Once these links are established, they can then used to build a case against the perpetrators. In this article, the reader will learn about some artifacts that can give releavant information left on a disk during a post-mortem analysis.
Note : All of the information about the investigated user displayed in the following findings are redacted.
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.