Explore the latest tactics, techniques, and procedures (TTPs) our incident response (IR) experts are actively facing in the quarterly TTP Briefing, a report built on frontline threat intelligence from our global incident response investigations across LevelBlue during Q2 2026.
Author: Guus Beckers
Back in 2022 Fox-IT decided to open source its proprietary incident response tooling known as Dissect. Since then it has been adopted by many different companies in their regular workflow. For those of you who are not yet familiar with Dissect, it is an incident response framework built with incident response engagements of any scale in mind. It allows you to extract artifacts from a variety of data formats and export them to a format of your choosing. Ever since Dissect has been open sourced a large number of individuals and institutions have contributed to the Dissect framework, culminating in the first Dissect partner day earlier in 2024.
One of the most popular requests has been the capability to use Dissect in combination with common disk encryption methods like Microsoft’s BitLocker or its Linux equivalent LUKS. Internally at Fox-IT we were able to already use these capabilities. With the release of Dissect version 3.17 these capabilities are now also available to the community at large.
Of course, a blog post is not complete without a demo. In this scenario a data acquisition has been performed against a disk protected with BitLocker. We are interested in a specific file located on the user’s desktop. During this scenario, a virtual machine was created with VMware Fusion which uses the .vmwarevm file format. Dissect can parse this format thanks to its associated loader.
First, we use Dissect to examine the disk properties:
Entrar
$ target-info "Windows 11 x64.vmwarevm" -v
2024-11-27T11:57:18.474060Z [error ] Failed to open an encrypted volume <Volume name='Basic data partition' size=67921509888 fs=None> with volume manager bitlocker: Failed to unlock BDE volume [dissect.target.volume]
2024-11-27T11:57:18.634092Z [warning ] <Target Windows 11 x64.vmwarevm>: Can't identify filesystem: <Volume name='Microsoft reserved partition' size=16776704 fs=None> [dissect.target.target]
2024-11-27T11:57:19.416120Z [warning ] <Target Windows 11 x64.vmwarevm>: Failed to find OS plugin, falling back to default [dissect.target.target]
<Target Windows 11 x64.vmwarevm>
Disks
- <Disk type="VmdkContainer" size="68719476736">
Volumes
- <Volume name="Basic data partition" size="104857088" fs="FatFilesystem">
- <Volume name="Microsoft reserved partition" size="16776704" fs="NoneType">
- <Volume name="Basic data partition" size="67921509888" fs="NoneType">
- <Volume name="part_fd7c00000" size="673185280" fs="NtfsFilesystem">
Hostname : None
Domain : None
Ips :
Os family : default
Os version : None
Architecture : None
Language :
Timezone : None
Install date : 1970-01-01T00:00:00.000000+00:00
Last activity : None It seems the disk is encrypted, now we can use the latest version of BitLocker to decrypt the information. Dissect supports three different types of decryption capabilities. An analyst can either use the user’s passphrase, the recovery key or can use a BitLocker file. Please check the updated documentation on the Dissect Docs page for more information. For now we have created a keychain CSV file with the following information:
$ cat keychain.csv
bitlocker,recovery_key,,395791-328042-677721-279895-554466-214599-232023-709148 We can use Dissect’s commands like target-info to check if the keychain works:
$ target-info "Windows 11 x64.vmwarevm" -K keychain.csv
2024-11-27T10:18:01.698079Z [warning ] <Target Windows 11 x64.vmwarevm>: Can't identify filesystem: <Volume name='Microsoft reserved partition' size=16776704 fs=None> [dissect.target.target]
2024-11-27T10:18:02.731474Z [warning ] <Target Windows 11 x64.vmwarevm>: Empty hive: sysvol/windows/SECURITY [dissect.target.target]
2024-11-27T10:18:02.737980Z [warning ] <Target Windows 11 x64.vmwarevm>: Empty hive: sysvol/windows/SYSTEM [dissect.target.target]
<Target Windows 11 x64.vmwarevm>
Disks
- <Disk type="VmdkContainer" size="68719476736">
Volumes
- <Volume name="Basic data partition" size="104857088" fs="FatFilesystem">
- <Volume name="Microsoft reserved partition" size="16776704" fs="NoneType">
- <Volume name="Basic data partition" size="67921509888" fs="NoneType">
- <Volume name="part_fd7c00000" size="673185280" fs="NtfsFilesystem">
- <Volume name="Basic data partition" size="67921509888" fs="NtfsFilesystem">
Hostname : SECRETDATAVM
Domain : None
Ips : 192.168.212.129
Os family : windows
Os version : Windows 11 Pro (NT 10.0) 26100.2314
Architecture : amd64-win64
Language : en_GB, en_NL, en_US
Timezone : Europe/Berlin
Install date : 2024-11-27T17:34:07.000000+00:00
Last activity : 2024-11-27T17:33:31.670376+00:00 Alternatively, we can pass the recovery key value directly like this:
$ target-info "Windows 11 x64.vmwarevm" -Kv 395791-328042-677721-279895-554466-214599-232023-709148 -vNow we can browse through the decrypted filesystem and view the file on the user’s desktop:
$ target-shell "Windows 11 x64.vmwarevm" -Kv 395791-328042-677721-279895-554466-214599-232023-709148 -q
SECRETDATAVM:/$ cat c:/Users/Staff/Desktop/SuperSecretFile.txt
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.As you can imagine this also works with Linux in the exact same manner. This time we use a LUKS passphrase in conjunction with Dissect:
$ target-info "Ubuntu 64-bit 24.04.1.vmwarevm" -Kv glad-design-paper-airplane
2024-11-27T11:48:07.224355Z [warning ] Failed to decode raw key as hex, ignoring: glad-design-paper-airplane [dissect.target.helpers.keychain]
2024-11-27T11:48:08.910029Z [warning ] <Target Ubuntu 64-bit 24.04.1.vmwarevm>: Can't identify filesystem: <Volume name='part_00100000' size=1048064 fs=None> [dissect.target.target]
2024-11-27T11:48:09.826056Z [warning ] <Target Ubuntu 64-bit 24.04.1.vmwarevm>: Unsupported mount device: /dev/disk/by-id/dm-uuid-LVM-YZiSLhoYFljS62k2vIjl3IcTwSkd0QguADKOf0a8t9am1jNdm9J1zerrDU7SWWFd / [dissect.target.target]
<Target Ubuntu 64-bit 24.04.1.vmwarevm>
2024-11-27T11:48:13.916382Z [warning ] No timestamp found in one of the lines in /var/log/syslog! [dissect.target.helpers.utils]
2024-11-27T11:48:13.925913Z [warning ] Timestamp '27 2024 12:40:57' does not match format '%b %d %H:%M:%S', skipping line. [dissect.target.helpers.utils]
2024-11-27T11:48:13.936096Z [warning ] Timestamp 'Nov 2024 11:40:35' does not match format '%b %d %H:%M:%S', skipping line. [dissect.target.helpers.utils]
2024-11-27T11:48:13.936416Z [warning ] Timestamp 'Nov 2024 11:40:35' does not match format '%b %d %H:%M:%S', skipping line. [dissect.target.helpers.utils]
2024-11-27T11:48:13.944841Z [warning ] Timestamp 'Nov 2024 11:40:15' does not match format '%b %d %H:%M:%S', skipping line. [dissect.target.helpers.utils]
2024-11-27T11:48:13.950083Z [warning ] Timestamp 'Nov 2024 11:40:11' does not match format '%b %d %H:%M:%S', skipping line. [dissect.target.helpers.utils]
2024-11-27T11:48:13.985809Z [warning ] Timestamp 'Nov 2024 11:40:04' does not match format '%b %d %H:%M:%S', skipping line. [dissect.target.helpers.utils]
2024-11-27T11:48:14.037897Z [warning ] <Target Ubuntu 64-bit 24.04.1.vmwarevm>: Could not match cloud-init log line in file: /var/log/cloud-init.log [dissect.target.target]
2024-11-27T11:48:14.037992Z [warning ] <Target Ubuntu 64-bit 24.04.1.vmwarevm>: Could not match cloud-init log line in file: /var/log/cloud-init.log [dissect.target.target]
2024-11-27T11:48:14.038056Z [warning ] <Target Ubuntu 64-bit 24.04.1.vmwarevm>: Could not match cloud-init log line in file: /var/log/cloud-init.log [dissect.target.target]
Disks
- <Disk type="VmdkContainer" size="21474836480">
Volumes
- <Volume name="part_00100000" size="1048064" fs="NoneType">
- <Volume name="part_00200000" size="1902116352" fs="ExtFilesystem">
- <Volume name="part_71800000" size="19569573376" fs="NoneType">
- <Volume name="part_71800000" size="19552796160" fs="NoneType">
- <Volume name="ubuntu--vg-ubuntu--lv" size="19549650944" fs="ExtFilesystem">
Hostname : personnel-VMware-Virtual-Platform
Domain : None
Ips :
Os family : linux
Os version : Ubuntu 24.04.1 LTS (Noble Numbat)
Architecture : x86_64-linux
Language : en_US, en_US
Timezone : Europe/Amsterdam
Install date : 2024-11-27T11:33:29.665213+00:00
Last activity : 2024-11-27T11:45:34.821181+00:00 We can use the same technique to extract another file from the Ubuntu desktop:
$ target-shell "Ubuntu 64-bit 24.04.1.vmwarevm" -K keychain.csv -v
2024-11-27T11:59:52.227142Z [info ] Registered key Key(key_type=<KeyType.PASSPHRASE: 'passphrase'>, value='glad-design-paper-airplane', provider='luks', identifier=None, is_wildcard=False) [dissect.target.helpers.keychain]
2024-11-27T11:59:52.227562Z [info ] Registered key Key(key_type=<KeyType.RECOVERY_KEY: 'recovery_key'>, value='395791-328042-677721-279895-554466-214599-232023-709148', provider='bitlocker', identifier=None, is_wildcard=False) [dissect.target.helpers.keychain]
2024-11-27T11:59:53.719915Z [info ] Volume <Volume name='part_71800000' size=19569573376 fs=None> unlocked with Key(key_type=<KeyType.PASSPHRASE: 'passphrase'>, value='glad-design-paper-airplane', provider='luks', identifier=None, is_wildcard=False) (keyslot: 0) [dissect.target.volumes.luks]
2024-11-27T11:59:53.922164Z [warning ] <Target Ubuntu 64-bit 24.04.1.vmwarevm>: Can't identify filesystem: <Volume name='part_00100000' size=1048064 fs=None> [dissect.target.target]
2024-11-27T11:59:54.733524Z [info ] <Target Ubuntu 64-bit 24.04.1.vmwarevm>: Found compatible OS plugin: DebianPlugin [dissect.target.target]
2024-11-27T11:59:54.770648Z [info ] <Target Ubuntu 64-bit 24.04.1.vmwarevm>: Found compatible OS plugin: LinuxPlugin [dissect.target.target]
2024-11-27T11:59:54.791479Z [info ] <Target Ubuntu 64-bit 24.04.1.vmwarevm>: Found compatible OS plugin: UnixPlugin [dissect.target.target]
2024-11-27T11:59:54.802888Z [warning ] <Target Ubuntu 64-bit 24.04.1.vmwarevm>: Unsupported mount device: /dev/disk/by-id/dm-uuid-LVM-YZiSLhoYFljS62k2vIjl3IcTwSkd0QguADKOf0a8t9am1jNdm9J1zerrDU7SWWFd / [dissect.target.target]
personnel-VMware-Virtual-Platform:/$ cat /home/personnel/Desktop/secretLinuxfile
"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."Last but not least, Dissect also contains the fve-dd utility. fve-dd can be used to decrypt an entire disk which allows a wider range of external tools to be used. fve-dd works on any supported Dissect containers. The individual VMDK files can be extracted from the .vmwarevm container:
$ ls
Virtual Disk-s001.vmdk Virtual Disk-s002.vmdk Virtual Disk-s003.vmdk Virtual Disk-s004.vmdk Virtual Disk-s005.vmdk Virtual Disk-s006.vmdk Virtual Disk.vmdkNow the disk can be decrypted using fve-dd. The decryption can take some time depending on the size of the disk:
$ fve-dd -p glad-design-paper-airplane -o decrypted.dd "Virtual Disk.vmdk" -vDissect and other tools can be used on the decrypted disk:
$ target-info decrypted.dd
[…]
Disks
- <Disk type="RawContainer" size="21458059264">
Volumes
- <Volume name="part_00100000" size="1048064" fs="NoneType">
- <Volume name="part_00200000" size="1902116352" fs="ExtFilesystem">
- <Volume name="part_71800000" size="19569573376" fs="NoneType">
- <Volume name="ubuntu--vg-ubuntu--lv" size="19549650944" fs="ExtFilesystem">
Hostname : personnel-VMware-Virtual-Platform
Domain : None
Ips :
Os family : linux
Os version : Ubuntu 24.04.1 LTS (Noble Numbat)
Architecture : x86_64-linux
Language : en_US, en_US
Timezone : Europe/Amsterdam
Install date : 2024-11-27T11:33:29.665213+00:00
Last activity : 2024-11-27T11:45:34.821181+00:00Have fun with the latest version of Dissect!
Explore the latest trends, techniques, and procedures (TTPs) our incident response (IR) experts are actively facing with the TTP Briefing Q1 2026, a report built on frontline threat intelligence from our global incident response investigations across LevelBlue.
Google Cloud Platform (GCP) has unique security challenges compared to AWS and Azure, requiring specialized strategies for incident detection, response, and forensic analysis.
Over the past quarter, the Cado team has been hard at work bringing new features and enhancements to the Cado platform. Here's an overview of what we’ve been up to:
To close out this blog series on the six phases of incident response, we will discuss the final phase: Lessons Learned. This phase takes cybersecurity incidents and turns them into opportunities for growth and improvement, and emphasizes analyzing the response, identifying successes and shortcomings, and implementing enhancements to bolster future incident handling.
In our recent blog posts, we’ve been covering the six phases of incident response. So far, we’ve already covered the preparation phase, identification phase, containment phase, and eradication phase. In this blog post, we move on to the recovery phase.
After successfully containing a cybersecurity incident, the next crucial step is eradication, the fourth phase in the incident response lifecycle. Eradication involves completely removing malicious components from the organization's systems and addressing vulnerabilities that attackers exploited. Achieving thorough eradication ensures that threats do not linger or reoccur, allowing systems to be safely restored and future incidents prevented.
Containment is the third stage in the incident response lifecycle and it directly influences how quickly and effectively an organization can mitigate the impact of a cybersecurity incident. This phase aims to halt the spread of threats, minimize damage, and maintain operational continuity. Successful containment requires rapid decision-making, careful planning, and execution of immediate and long-term actions.
Timely identification of incidents is critical. The identification phase, the second stage in the six-phase incident response lifecycle, focuses on detecting, analyzing, and verifying security incidents as quickly and accurately as possible. Early and precise identification reduces potential damage, shortens recovery time, and significantly enhances overall cybersecurity posture.
Google Cloud Platform (GCP) has unique security challenges compared to AWS and Azure, requiring specialized strategies for incident detection, response, and forensic analysis.
Threat investigations rely on context to provide security teams with a clear picture of potential risks. This context comes from various sources, including telemetry, alert data, business impact, and risk assessments. One critical aspect of risk assessment is identifying open vulnerabilities on affected systems. This can help security teams determine whether known vulnerabilities are relevant to an active incident and how best to mitigate them.
AWS remains a dominant force in cloud computing, but its complexity presents unique challenges for security teams. Incident response in AWS requires a deep understanding of log sources, service-specific strategies, and forensic techniques.
Microsoft Azure continues to be a key player in cloud computing, offering a vast array of services that organizations rely on for their operations. With this complexity comes the challenge of incident response—how do security teams efficiently detect, investigate, and remediate threats in Azure?
Security teams are facing an overwhelming volume of incidents. Manual processes can slow down response times, increasing damage and recovery costs. To counter this, organizations are adopting automation tools to:
As cloud environments grow more complex and attackers evolve their tactics, incident response strategies must continuously improve to remain effective. In a recent webinar, Cado experts Al Carchie and Shannon Lucas discussed key lessons from years of hands-on experience in incident response and shared best practices for organizations looking to strengthen their approach.
Threat actors are becoming more sophisticated, and organizations must be prepared to detect, contain, and remediate incidents swiftly. The incident response (IR) process ensures that security teams can minimize damage, recover systems, and strengthen defenses against future threats.
Digital forensics is a critical field dedicated to the identification, preservation, analysis, and presentation of digital evidence. As cyber threats evolve, so do the tools and techniques employed by forensic professionals. This blog looks into some of the top free and open-source digital forensics tools and the methodologies that are key to modern investigations.
Endpoint Detection & Response (EDR) is frequently used by organizations as the first line of defense against cyber attacks. EDR platforms monitor organizations’ endpoints (servers, employee laptops, etc) and detect and contain malicious activity running where possible. In this blog, we will be exploring a ransomware attack in a lab environment, using payloads inspired from real attacks.
As organizations increasingly migrate workloads to the cloud, cybersecurity teams must adapt their digital forensics strategies. Investigating security incidents in a cloud environment presents challenges and opportunities distinct from traditional, on-premises forensics. The ability to efficiently collect, analyze, and respond to threats depends on understanding these key differences.
