{
	"id": "35389a42-4bb5-4a62-806b-5675dc8e183b",
	"created_at": "2026-04-10T03:22:02.695226Z",
	"updated_at": "2026-04-10T13:12:12.012012Z",
	"deleted_at": null,
	"sha1_hash": "0b1708b5f36d209100d0d04a14eb6d4623768ac2",
	"title": "Unransomware: From Zero to Full Recovery in a Blink",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1081064,
	"plain_text": "Unransomware: From Zero to Full Recovery in a Blink\r\nBy DCSO CyTec Blog\r\nPublished: 2024-11-04 · Archived: 2026-04-10 02:57:24 UTC\r\n11 min read\r\nNov 4, 2024\r\nThis blog post discusses how we, DCSO’s Incident Response Team (DIRT), were able to help an Akira\r\nransomware victim restore their business critical data by extracting NTFS partitions from partially encrypted\r\nvirtual disks. The post outlines a generic approach based on open source tools that allows affected parties to\r\nrestore data from encrypted hypervisor systems. This approach works best for partially encrypted files and shows\r\nhow to fix a bug in a commonly used mounting tool.\r\nPress enter or click to view image in full size\r\nBlog post authored by Denis Szadkowski, Paul van Ramesdonk, Maike Orlikowski and Johann Aydinbas.\r\nHypervisor CPR\r\nhttps://medium.com/@DCSO_CyTec/unransomware-from-zero-to-full-recovery-in-a-blink-8a47dd031df3\r\nPage 1 of 10\n\nRansomware incidents tend to hit organizations with low security posture the hardest because they lack the\r\nnecessary preparedness to respond effectively. Over the past years, we have observed again and again how\r\nchallenging recovery efforts are for these organizations. They often lack basic necessities for a speedy recovery,\r\nlike spare hardware and disks.\r\nIn this particular ransomware incident, the attackers successfully obtained access to the ESXi hypervisor, allowing\r\nthem to deploy the Linux version of Akira ransomware on the system. They shut down all virtual machines to then\r\nencrypt the corresponding .vmdk files (virtual disks). To help the customer recover their business critical data with\r\nthe least amount of friction, we decided to boot a Linux OS on the ESXi host without installing it. In a second\r\nstep, a spare disk of the same size was used as the ESXi datastore for recovery purposes. As good incident\r\nresponders, we try to make the lives of our customers as easy as possible especially in hard times when their\r\ninfrastructure is on fire and their business is standing still.\r\nLocating the Datastore\r\nAfter booting into the Linux OS, we first needed to identify the ESXi datastore that uses the “VMware VMFS”\r\nfile system. This is the location where all the virtual disks (.vmdk) are stored. In the incident, these disks were\r\nencrypted by the Akira ransomware. To locate the datastore, we searched the output of the Linux command\r\nfdisk for the “VMware VMFS” file system:\r\n# fdisk -l | grep \"VMware VMFS\"\r\n/dev/sda1 2048 13120307166 13120305119 6.1T VMware VMFS\r\nYou Shall Not Access!\r\nAfter mounting dev/sda1 with the help of vmfs-fuse , we encountered an interesting (and at the time,\r\nfrustrating) bug in “vmfs-tools” that prevented us from accessing files larger than 256GB in the mounted datastore\r\nVMFS file system.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@DCSO_CyTec/unransomware-from-zero-to-full-recovery-in-a-blink-8a47dd031df3\r\nPage 2 of 10\n\nAfter trying to create a hex dump of the encrypted VDMK file SERVER_2-flat.vmdk.akira with xxd , we\r\nreceived an “Input/output error” instead of the expected output of the first 64 bytes of the file represented in both\r\nhex and ASCII. This file was the biggest virtual disk on the hypervisor and contained critical business data, so we\r\nhad to find a way to access the virtual disk for mounting purposes.\r\n# vmfs-fuse /dev/sda1 /mnt/vmdisk/\r\n# cd /mnt/vmdisk/\r\n# ls -lh\r\ntotal 811G\r\n-rw-r--r-- 1 root root 1.8K Jun 8 17:30 SERVER-6c6110af.hlog.akira\r\n-rw------- 1 root root 5.1M Jun 8 17:30 SERVER-ctk.vmdk.akira\r\n-rw------- 1 root root 81G Jun 8 17:30 SERVER-flat.vmdk.akira\r\n-rw------- 1 root root 9.0K Jun 8 17:30 SERVER.nvram.akira\r\n-rw------- 1 root root 1.1K Jun 8 17:30 SERVER.vmdk.akira\r\n-rw-r--r-- 1 root root 558 Jun 8 17:30 SERVER.vmsd.akira\r\n-rwxr-xr-x 1 root root 4.1K Jun 8 17:30 SERVER.vmx.akira\r\n-rw------- 1 root root 3.7K Jun 8 17:30 SERVER.vmxf.akira\r\n-rw------- 1 root root 5.7M Jun 8 17:30 SERVER_1-ctk.vmdk.akira\r\n-rw------- 1 root root 181G Jun 8 17:31 SERVER_1-flat.vmdk.akira\r\n-rw------- 1 root root 1.1K Jun 8 17:30 SERVER_1.vmdk.akira\r\n-rw------- 1 root root 5.5M Jun 8 17:30 SERVER_2-ctk.vmdk.akira\r\n-rw------- 1 root root 551G Jun 8 17:31 SERVER_2-flat.vmdk.akira\r\n-rw------- 1 root root 1.1K Jun 8 17:30 SERVER_2.vmdk.akira\r\n---------- 1 root root 2.7K Jun 8 17:32 akira_readme.txt\r\n-rw-r--r-- 1 root root 18M Jun 8 17:30 vmware-10.log.akira\r\n-rw-r--r-- 1 root root 2.4M Jun 8 17:30 vmware-5.log.akira\r\n-rw-r--r-- 1 root root 25M Jun 8 17:30 vmware-6.log.akira\r\n-rw-r--r-- 1 root root 19M Jun 8 17:30 vmware-7.log.akira\r\n-rw-r--r-- 1 root root 301K Jun 8 17:30 vmware-8.log.akira\r\n-rw-r--r-- 1 root root 60M Jun 8 17:30 vmware-9.log.akira\r\n-rw-r--r-- 1 root root 4.6M Jun 8 17:30 vmware.log.akira\r\n-rw------- 1 root root 111M Jun 8 17:30 vmx-SERVER-2116517489-2.vswp.akira\r\n# xxd -l 64 SERVER_2-flat.vmdk.akira\r\nInput/output error\r\nAfter some research, we discovered a Github issue in the “vmfs-tools” project that details the exact same bug. In\r\nthe same Github issue, the user Marcus Sorensen provided a patch that fixes the issue.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@DCSO_CyTec/unransomware-from-zero-to-full-recovery-in-a-blink-8a47dd031df3\r\nPage 3 of 10\n\nThank you Marcus!\r\nIt should be noted that as of today, the bug is still present in the package repositories of all major Linux\r\ndistributions out there.\r\nNext, we set up a build environment on the Linux system and then cloned the patched version of “vmfs-tools”.\r\nAfter successfully installing the patched version of “vmfs-tools”, we mounted the ESXi datastore once again. This\r\ntime, the hex dump of SERVER_2-flat.vmdk.akira successfully printed the first 64 bytes of the file to stdout .\r\n# apt remove vmfs-tools\r\n# apt install build-essential\r\n# apt install uuid-dev\r\n# apt install libfuse-dev\r\n# apt install pkg-config\r\n# wget https://github.com/mlsorensen/vmfs-tools/archive/refs/heads/double-pointer.zip\r\n# unzip double-pointer.zip\r\n# make install\r\n# vmfs-fuse /dev/sda1 /mnt/vmdisk/\r\n# cd /mnt/vmdisk/\r\n# xxd -l 64 SERVER_2-flat.vmdk.akira\r\n00000000: ccb4 630e 0e42 fb00 eb04 80df 72ef ba61 ..c..B......r..a\r\n00000010: cf44 2690 ce31 f360 cc7c cafd a8e7 a3ed .D\u0026..1.`.|......\r\n00000020: f3b6 e08d 41e7 9f7a 771f ad0b eca1 8455 ....A..zw......U\r\n00000030: d891 0cc9 71b0 63e2 86b2 1f2a b265 87e1 ....q.c....*.e..\r\nMind the Gap\r\nWith the patched version of “vmfs-tools”, we were finally able to read the contents of the Akira ransomware\r\nencrypted virtual disks. This was only a partial success — they were still encrypted after all. What now?\r\nIt is a common misconception that files encrypted with ransomware are not recoverable if the ransomware authors\r\ndid a good enough job with the encryption logic. But this really depends on the type of file that was encrypted, its\r\nsize and how exactly the encryption was performed.\r\nhttps://medium.com/@DCSO_CyTec/unransomware-from-zero-to-full-recovery-in-a-blink-8a47dd031df3\r\nPage 4 of 10\n\nGet DCSO CyTec Blog’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nThe tactic used by Akira in this ransomware attack was to first shut down the virtual machine, and then followed\r\nby partial encryption of the VM virtual disk.\r\nPartial or intermittent encryption is a technique where only parts of a file are encrypted. The specific pattern varies\r\nheavily among ransomware strains. Attackers sacrifice encryption completeness to achieve a much higher\r\nencryption speed. Faster encryption leaves defenders less time to react, and also evades typical detection logic\r\nbased on how full encryption presents itself in CPU utilization, file similarity between unencrypted and encrypted\r\nfiles and I/O rate.\r\nAkira ransomware specifically seems to apply two approaches to partially encrypting files: Reverse engineering\r\nthe Linux variant shows it applies the same logic as the Windows variant, where files are only partially encrypted\r\nwhen they exceed a certain file size and then split into three or five chunks of alternating encrypted and plaintext\r\nblocks.\r\nBut the Linux variant also uses file extensions to decide between partial and full encryption. We let the Akira\r\nransomware sample run against different 4MB files and checked whether the files were fully or partially\r\nencrypted. Some file types, like database files, were always fully encrypted, even when they exceeded the\r\nthreshold for partial encryption. But all file types relevant to virtual machines, like vhdx,vmdk,vdi were always\r\nonly partially encrypted.\r\nWhat does all this mean for defenders? With partial encryption, large parts of the file are left unencrypted. In this\r\ncase, this allowed us to attempt to recover partitions in the virtual machine disk without the need to decrypt them\r\n— because they had not been encrypted in the first place.\r\nFind Waldo, DFIR Style\r\nOur next task was to (hopefully) locate an intact NTFS partition in the unencrypted parts of the virtual machine\r\ndisk. To find NTFS partitions, we searched for the NTFS magic bytes, a sequence of bytes that identifies the\r\nbeginning of the NTFS header.\r\nNTFS Magic Bytes\r\nhttps://medium.com/@DCSO_CyTec/unransomware-from-zero-to-full-recovery-in-a-blink-8a47dd031df3\r\nPage 5 of 10\n\nInstead of manually searching, we developed the following bash script to perform the search. The script uses the\r\ntool “ripgrep” to look for the NTFS magic bytes in the virtual disk file. Then, Sleuth Kit’s “fsstat” is used to check\r\nthe file system type found at the offset of the byte sequence.\r\n#!/bin/bash\r\nvirtualdisk=$1\r\nfor offset in $(rg -obUa \"\\x4e\\x54\\x46\\x53\\x20\\x20\\x20\\x20\" $virtualdisk | awk -F\":\" '{ print $1 }')\r\ndo\r\n fsstat -o $((($offset-3)/512)) $virtualdisk 2\u003e /dev/null\r\n if fsstat -o $((($offset-3)/512)) $virtualdisk 2\u003e /dev/null | rg -o \"File System Type: NTFS\"; then\r\n printf \"Offset: $(($offset-3)) \\n\\n\\n\\n\"\r\n fi\r\ndone\r\nTo illustrate, we performed a test run against the “SERVER_2-flat.vmdk.akira”, the file from the previous\r\nexamples. A valid NTFS partition has been found at offset “368050176”:\r\n$ ./find_ntfs.sh SERVER_2-flat.vmdk.akira\r\n(...)\r\nFILE SYSTEM INFORMATION\r\n--------------------------------------------\r\nFile System Type: NTFS\r\nVolume Serial Number: 6E42D27C42D2490B\r\nOEM Name: NTFS\r\nVolume Name: System\r\nVersion: Windows XP\r\nMETADATA INFORMATION\r\n--------------------------------------------\r\nFirst Cluster of MFT: 786432\r\nFirst Cluster of MFT Mirror: 2\r\nSize of MFT Entries: 1024 bytes\r\nSize of Index Records: 4096 bytes\r\nRange: 0 - 312320\r\nRoot Directory: 5\r\nCONTENT INFORMATION\r\n--------------------------------------------\r\nSector Size: 512\r\nCluster Size: 4096\r\nTotal Cluster Range: 0 - 10395646\r\nTotal Sector Range: 0 - 83165182\r\nhttps://medium.com/@DCSO_CyTec/unransomware-from-zero-to-full-recovery-in-a-blink-8a47dd031df3\r\nPage 6 of 10\n\n$AttrDef Attribute Values:\r\n$STANDARD_INFORMATION (16) Size: 48-72 Flags: Resident\r\n$ATTRIBUTE_LIST (32) Size: No Limit Flags: Non-resident\r\n$FILE_NAME (48) Size: 68-578 Flags: Resident,Index\r\n$OBJECT_ID (64) Size: 0-256 Flags: Resident\r\n$SECURITY_DESCRIPTOR (80) Size: No Limit Flags: Non-resident\r\n$VOLUME_NAME (96) Size: 2-256 Flags: Resident\r\n$VOLUME_INFORMATION (112) Size: 12-12 Flags: Resident\r\n$DATA (128) Size: No Limit Flags:\r\n$INDEX_ROOT (144) Size: No Limit Flags: Resident\r\n$INDEX_ALLOCATION (160) Size: No Limit Flags: Non-resident\r\n$BITMAP (176) Size: No Limit Flags: Non-resident\r\n$REPARSE_POINT (192) Size: 0-16384 Flags: Non-resident\r\n$EA_INFORMATION (208) Size: 8-8 Flags: Resident\r\n$EA (224) Size: 0-65536 Flags:\r\n$LOGGED_UTILITY_STREAM (256) Size: 0-65536 Flags: Non-resident\r\nFile System Type: NTFS\r\nOffset: 368050176\r\n(...)\r\nClimbing the Top of Mount Everest\r\nAfter overcoming all the challenges with the mounting tool “vmfs-tools” and hitting the jackpot by finding a\r\nlargely unencrypted NTFS partition, we were finally ready to start recovering the business critical data. We first\r\nexecuted Sleuth Kit’s “fls” to see the files and directories present at the discovered offset. Note that “fls” expects a\r\nsector offset for the “-o” parameter. To calculate the offset, we divided the byte offset of the NTFS magic bytes\r\nsequence by the sector size of the partition, which in this case was 512.\r\nAs expected, there really was a Windows system partition at the specified offset:\r\n$ fls -o $((368050176/512)) SERVER_2-flat.vmdk.akira\r\nd/d 58-144-1: PerfLogs\r\nr/r 4-128-4: $AttrDef\r\nr/r 8-128-2: $BadClus\r\nr/r 8-128-1: $BadClus:$Bad\r\nr/r 6-128-4: $Bitmap\r\nr/r 7-128-1: $Boot\r\nd/d 11-144-4: $Extend\r\nr/r 2-128-1: $LogFile\r\nr/r 0-128-6: $MFT\r\nr/r 1-128-1: $MFTMirr\r\nd/d 57-144-1: $Recycle.Bin\r\nr/r 9-144-17: $Secure:$SDH\r\nr/r 9-144-16: $Secure:$SII\r\nr/r 9-128-18: $Secure:$SDS\r\nhttps://medium.com/@DCSO_CyTec/unransomware-from-zero-to-full-recovery-in-a-blink-8a47dd031df3\r\nPage 7 of 10\n\nr/r 10-128-1: $UpCase\r\nr/r 10-128-4: $UpCase:$Info\r\nr/r 3-128-3: $Volume\r\nr/r 19029-128-3: bootmgr\r\nr/r 19019-128-1: BOOTNXT\r\nd/d 211043-144-25: Config.Msi\r\nd/d 19026-144-1: Documents and Settings\r\nd/d 70002-144-1: Dokumente und Einstellungen\r\nd/d 176062-144-1: Drivers\r\nd/d 246515-144-1: Lexmark\r\nd/d 95077-144-1: Okidata\r\nr/r 79021-128-1: pagefile.sys\r\nd/d 263-144-5: Users\r\nr/- * 19132: WIM440A.tmp\r\nr/- * 19135: WIM441B.tmp\r\nr/- * 19136: WIM441C.tmp\r\nr/- * 19137: WIM441D.tmp\r\nr/- * 19138: WIM441E.tmp\r\nr/- * 19161: WIM441F.tmp\r\nr/- * 19162: WIM442F.tmp\r\nr/- * 19165: WIM4430.tmp\r\nr/- * 19166: WIM4431.tmp\r\nd/d 311-144-6: Windows\r\nr/- * 54: WinPEpge.sys\r\nd/d 59-144-6: Program Files\r\nd/d 152-144-6: Program Files (x86)\r\nd/d 197-144-6: ProgramData\r\nd/d 70027-144-1: Programme\r\nd/d 250012-144-1: QUARANTINE\r\nd/d 78984-144-6: System Volume Information\r\nd/d 233005-144-1: usr\r\nV/V 312320: $OrphanFiles\r\nAs a last step, we mounted the NTFS partition present at the previously identified offset in order to access the\r\nWindows system partition.\r\nFinally, we were ready to get down to business and start our recovery activities.\r\n$ sudo mount -o ro,noload,loop,noexec,offset=$((368050176)),show_sys_files,streams_interface=windows\r\n$ ls -la /mnt/vmdk/\r\ntotal 1378133\r\ndrwxrwxrwx 1 root root 8192 Jun 5 21:42 .\r\ndrwxr-xr-x 3 root root 4096 Jun 23 23:47 ..\r\n-rwxrwxrwx 1 root root 2560 Nov 24 2015 '$AttrDef'\r\n-rwxrwxrwx 1 root root 0 Nov 24 2015 '$BadClus'\r\n-rwxrwxrwx 1 root root 1299456 Nov 24 2015 '$Bitmap'\r\nhttps://medium.com/@DCSO_CyTec/unransomware-from-zero-to-full-recovery-in-a-blink-8a47dd031df3\r\nPage 8 of 10\n\n-rwxrwxrwx 1 root root 8192 Nov 24 2015 '$Boot'\r\ndrwxrwxrwx 1 root root 0 Nov 24 2015 '$Extend'\r\n-rwxrwxrwx 1 root root 67108864 Nov 24 2015 '$LogFile'\r\n-rwxrwxrwx 1 root root 4096 Nov 24 2015 '$MFTMirr'\r\ndrwxrwxrwx 1 root root 0 Nov 14 2013 '$Recycle.Bin'\r\n-rwxrwxrwx 1 root root 0 Nov 24 2015 '$Secure'\r\n-rwxrwxrwx 1 root root 131072 Nov 24 2015 '$UpCase'\r\n-rwxrwxrwx 1 root root 0 Nov 24 2015 '$Volume'\r\n-rwxrwxrwx 1 root root 398356 Nov 14 2013 bootmgr\r\n-rwxrwxrwx 1 root root 1 Jun 18 2013 BOOTNXT\r\ndrwxrwxrwx 1 root root 0 Jul 20 2020 Config.Msi\r\nlrwxrwxrwx 2 root root 15 Aug 22 2013 'Documents and Settings' -\u003e /mnt/vmdk/Users\r\nlrwxrwxrwx 2 root root 15 Nov 24 2015 'Dokumente und Einstellungen' -\u003e /mnt/vmdk/Users\r\ndrwxrwxrwx 1 root root 0 Jul 22 2019 Drivers\r\ndrwxrwxrwx 1 root root 0 Nov 21 2023 Lexmark\r\ndrwxrwxrwx 1 root root 0 Nov 4 2019 Okidata\r\n-rwxrwxrwx 1 root root 1342177280 Apr 15 08:12 pagefile.sys\r\ndrwxrwxrwx 1 root root 0 Aug 22 2013 PerfLogs\r\ndrwxrwxrwx 1 root root 8192 Jun 5 21:25 ProgramData\r\ndrwxrwxrwx 1 root root 8192 Mai 2 09:41 'Program Files'\r\ndrwxrwxrwx 1 root root 4096 Nov 21 2023 'Program Files (x86)'\r\nlrwxrwxrwx 2 root root 23 Nov 24 2015 Programme -\u003e '/mnt/vmdk/Program Files'\r\ndrwxrwxrwx 1 root root 0 Jun 5 21:42 QUARANTINE\r\ndrwxrwxrwx 1 root root 4096 Jun 8 19:01 'System Volume Information'\r\ndrwxrwxrwx 1 root root 4096 Nov 26 2015 Users\r\ndrwxrwxrwx 1 root root 0 Mai 2 09:40 usr\r\ndrwxrwxrwx 1 root root 28672 Jun 8 19:15 Windows\r\nThe remaining recovery procedure is left as an exercise to the reader ;-).\r\nConclusion\r\nBecause partial encryption is so common with different ransomware variants, we have made it a habit to search\r\nNTFS partitions in ransomware encrypted virtual disks. Partial encryption has become a commonly used tactic,\r\nleaving a gap (or many) for DFIR experts to recover large swaths of data. If you decide to use the method outlined\r\nin this post, make sure to apply the necessary patch to “vmfs-tools” if you installed the tool from your Linux\r\ndistro’s repositories.\r\nSources\r\nhttps://www.bleepingcomputer.com/news/security/linux-version-of-akira-ransomware-targets-vmware-esxi-servers/\r\nhttps://blog.talosintelligence.com/akira-ransomware-continues-to-evolve/\r\nhttps://medium.com/@DCSO_CyTec/unransomware-from-zero-to-full-recovery-in-a-blink-8a47dd031df3\r\nPage 9 of 10\n\nSource: https://medium.com/@DCSO_CyTec/unransomware-from-zero-to-full-recovery-in-a-blink-8a47dd031df3\r\nhttps://medium.com/@DCSO_CyTec/unransomware-from-zero-to-full-recovery-in-a-blink-8a47dd031df3\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://medium.com/@DCSO_CyTec/unransomware-from-zero-to-full-recovery-in-a-blink-8a47dd031df3"
	],
	"report_names": [
		"unransomware-from-zero-to-full-recovery-in-a-blink-8a47dd031df3"
	],
	"threat_actors": [],
	"ts_created_at": 1775791322,
	"ts_updated_at": 1775826732,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0b1708b5f36d209100d0d04a14eb6d4623768ac2.pdf",
		"text": "https://archive.orkl.eu/0b1708b5f36d209100d0d04a14eb6d4623768ac2.txt",
		"img": "https://archive.orkl.eu/0b1708b5f36d209100d0d04a14eb6d4623768ac2.jpg"
	}
}