{
	"id": "e73ff80f-ff22-4625-a300-93d8e85dd5c9",
	"created_at": "2026-04-06T01:31:30.645959Z",
	"updated_at": "2026-04-10T03:27:57.413237Z",
	"deleted_at": null,
	"sha1_hash": "34ddc297c2c477bab195978dcf44d7cd01c538ec",
	"title": "Weaponising VMs to bypass EDR – Akira ransomware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1865694,
	"plain_text": "Weaponising VMs to bypass EDR – Akira ransomware\r\nBy Lee Davis\r\nPublished: 2023-09-15 · Archived: 2026-04-06 00:43:04 UTC\r\nPublished by Digital Forensics and Incident Response on 15 September 2023\r\nThe CyberCX DFIR team has been engaged to assist in multiple investigations related to the Akira ransomware\r\ngroup, which has been seen affecting victims since April 2023. One novel technique that we’ve observed leverages\r\ndeployment of ransomware onto Windows Hyper-V hypervisor systems, causing major damage to attached virtual\r\nmachines (VMs). Even when Windows-based hypervisor and target virtual machines are running prominent\r\nEndpoint Detection \u0026 Response (EDR) tooling, the threat actor has been observed circumventing this by creating\r\nnew, unmonitored, VMs on the hypervisor, from which they can navigate directories on the hypervisor and execute\r\ntheir ransomware.\r\nWhile Akira leverages many known attack techniques, this article focuses on some standout methods that we’ve\r\nobserved.\r\nhttps://cybercx.com.au/blog/akira-ransomware/\r\nPage 1 of 7\n\nInitial Access \r\nis aware of several Akira ransomware attacks which leveraged VPN accessmulti-factor authentication (MFA)\r\napplied on the initial access point. This was emphasised by Cisco in a recent blog post. In our experience, when\r\nconducting a thorough review to ascertain where compromised credentials have been obtained, no obvious\r\nlocations have been identified. [1] in previous ransomware cases by other threat actors, we believe that Akira\r\ntypically obtains access through info stealers and credential marketplaces.  \r\nIntrusion Activities  \r\nCyberCX has observed Akira conducting typical cyber-extortion activity post-initial access which includes but is\r\nnot limited to: \r\nScanning the network using SoftPerfect Network Scanner (netscan.exe) \r\nEnumeration of data available in the Active Directory through AdFind (AdFind.exe) \r\nIdentifying sensitive information on file shares and servers to exfiltrate by uploading it over SFTP using\r\nFileZilla \r\nInstalling SystemBC and creating a scheduled task to remain persistent. \r\nDefence Evasion \u0026 Impact  \r\nWe have observed this threat actor maintain access to compromised environments for several weeks before they\r\nachieve their objectives of deploying ransomware. While we expect they intend to encrypt an entire network,\r\nwe’ve also observed EDR tooling slowing down their progress to their final objectives. One of our more\r\ninteresting observations has been the threat actor initially attempting to disable EDR using a vulnerable driver.\r\nTerminator \r\nIt was reported by CrowdStrike that in May 2023, a user on a dark web forum, Spyboy, promoted a tool they\r\ncalled Terminator, that was used to stop actively running EDR tools in an effort to circumvent detection. This tool\r\nwas for sale for US$3,000 at the time and reverse engineers confirmed that it utilised a signed kernel driver file\r\ntaken from the Zemana Anti-Malware program to perform privileged operations, which is commonly referred to as\r\na Bring Your Own Vulnerable Driver (BYOVD) attack. \r\nhttps://cybercx.com.au/blog/akira-ransomware/\r\nPage 2 of 7\n\nIn early June, a GitHub user ZeroMemoryEx created a tool also named Terminator with the same functionality and\r\npublished their source code on GitHub.  \r\nWithin 3-5 days of the open-source release of Terminator, we observed Akira attempt to use this tool (as\r\nconfirmed with a hash match to the tool on GitHub) to evade detection. We have also seen one prominent EDR\r\nagent and Windows Defender detect this program execution as malicious, with no apparent impact to the operation\r\nof the EDR agent. \r\nAttacking the Hypervisor Layer   \r\nDuring other investigations we have typically seen threat actors execute their ransomware directly on the\r\nhypervisor, which will encrypt all of the files including virtual disk images stored in the various datastores.\r\nHowever, in other situations we believe the threat actor has seen an EDR tool in place, that is clearly capable of\r\npreventing their malicious program executions and even their EDR evasion has been successfully stopped. As a\r\nresult, we’ve observed them deviating from their standard playbook and using a privileged account to launch a\r\nnew, clean VM within the hypervisor.  \r\nFrom the threat actor’s perspective, the benefit is that the VM they created has all the access needed to the\r\nnetwork, and none of the security controls of another typical host on the same network. \r\nAfter accessing the VM, the threat actor would disable Windows Defender, mount the data storage drives on the\r\nhypervisor, stop (shut down) VMs to release locked disk image files, and then execute the ransomware. While\r\nEDR tooling can detect that encryption has commenced, it is generally unable to block it as the process is\r\nexecuting on the VM, which would impact VMs in a shutdown state. As the attacker VMs are still running, they\r\nare not encrypted, which allowed forensic analysis to piece together the investigation.  \r\nThe technique of using custom VMs is not new, and CyberCX has seen multiple investigations where a threat\r\nactor has built their own VM to conduct their malicious activities. Discussed at the end of this blog, you can find\r\nforensic artefacts and detection opportunities that may arise if you are running hypervisors in your environment or\r\ninvestigating a breach across hypervisors. \r\nAnalysts across the cybersecurity community have recently confirmed that a vulnerability existed within the Akira\r\nransomware implementation. The decryption vulnerability relates to the use of a stream cipher (ChaCha20) that\r\nproduces a fixed keystream per execution, which is then used for all files to be encrypted. This allows for the\r\npossibility of decryption without paying the ransom, however there are a few limitations. CyberCX confirmed the\r\nvulnerability and developed a working capability to decrypt encrypted data under certain circumstances shortly\r\nbefore the public release of the flaw by Avast.  \r\nExploiting the vulnerability requires a file pair before and after encryption (plaintext and ciphertext), however you\r\ncould only decrypt files smaller than the file pair. The first issue is identifying a valid pair, which can be difficult\r\nin cases where all backup data has also been encrypted.  \r\nOne way to partially navigate this challenge is by identifying a file pair that could be sourced independently. In\r\none case, we used several encrypted ISO files containing default installations of operating systems which were\r\nstored on a hypervisor (which is reasonably common in hypervisor datastores). Unencrypted versions of these are\r\nhttps://cybercx.com.au/blog/akira-ransomware/\r\nPage 3 of 7\n\noften available from their official sources on the internet and can be used to generate the data needed. This\r\nsolution has proven adequate for successfully decrypting small files on encrypted servers (specifically smaller\r\nthan the ISO files). Unfortunately though, it may not be helpful in recovering what is often the most critical files\r\non a hypervisor; large virtual hard disks. \r\nHowever, as is common in ransomware encryption routines, threat actors rarely encrypt entire disks, each of\r\nwhich could be several hundred gigabytes in size, as this would be too slow. Instead, they often rely on\r\nintermittent encryption which only encrypts portions of large files, rendering them unreadable by tools, unable to\r\nbe mounted cleanly, difficult to recover data from, and practically unusable. Another technique is to target file\r\nheaders, being metadata stored at the beginning of most files. In these cases, we’ve seen ransomware actors only\r\nencrypting the first few MB of files targeting these file headers, but usually they also intermittently encrypt other\r\nportions of the file as well, to make recovery difficult to impossible, depending on the format of the file.\r\nSentinelOne produced an excellent article listing intermittent encryption options used by several ransomware\r\nvariants.  \r\nIn such cases, relying on available backups is the primary method of data restoration, and carving files and\r\nforensic artefacts from the non-encrypted portions of the affected virtual hard disks is the last resort. \r\n“Just because files are encrypted doesn’t mean that they’re completely unrecoverable!“\r\nCyberCX has significant experience investigating partially encrypted virtual hard disks – in some cases\r\ncompletely recovering the underlying data. Phill Moore recently presented a case study at the on an investigation\r\ninvolving recovering data from an encrypted virtual disk that allowed CyberCX to confirm the initial infection\r\nvector during a ransomware attack. Yogesh Khatri wrote an open-source tool – JARP that allows recovery of data\r\nfrom partially encrypted registry hives. \r\nOn 29 June 2023, Avast published a decryptor for Akira which utilised the same vulnerability identified above. By\r\nreleasing the decryptor to the public, it also informed the owners of the ransomware.  \r\nAn Akira ransomware sample that did not contain the vulnerability was uploaded to VirusTotal on 7 July 2023.\r\nThe PE metadata recorded that it was compiled on 2 July 2023. This confirmed that within three days, Akira had\r\npatched the vulnerability and newer samples did not have the vulnerable code.[2] \r\nAs such, we anticipate that any new or recent Akira ransomware attack should be expected to use a newer\r\nransomware variant which is not vulnerable to this weakness. However, any organisation who suffered an Akira\r\nransomware attack prior to around 7 July 2023 and still has their encrypted data, may be able to use this weakness\r\nto decrypt their data. \r\nCyberCX has also observed vSphere/ESXi environments being affected by ransomware in a way that would\r\nimpact recovery. In some cases, threat actors apply different approaches to different ESXi hosts, even within the\r\nsame network, including encryption through ransomware, changing the root password, or in some cases doing\r\nnothing to the hypervisor. \r\nIn cases where the threat actor did not (or perhaps could not) shut down the virtual machines, their disks were\r\nlocked and would not be encrypted, however binaries on the ESXi host would still be encrypted. In these cases,\r\nhttps://cybercx.com.au/blog/akira-ransomware/\r\nPage 4 of 7\n\nthe remediation team has the opportunity to save the underlying VMs, but forensic analysis of the hypervisor\r\nwould be impacted.  \r\nWe also note that public reporting on a Linux variant of the Akira ransomware has recently been published. \r\n1. Hyper-V Hypervisor Logging and Activities\r\nCyberCX has compiled the following table of hypervisor event logs based on some validation testing that was\r\nperformed on Windows Server 2022. It’s worth noting that no logs are generated after creating a “checkpoint\r\n(snapshot)” for a VM and when attempting to “connect” to a VM.\r\nAction Performed\r\nEvent\r\nID\r\nChannel Provider\r\nCreated VM (Creation started) 18304\r\nMicrosoft-Windows-Hyper-V-VMMS-AdminMicrosoft-Windows-Hyper-V-VMMS\r\nCreated VM (Successfully Created) 13002\r\nMicrosoft-Windows-Hyper-V-VMMS-AdminMicrosoft-Windows-Hyper-V-VMMS\r\nStarted VM 12148\r\nMicrosoft-Windows-Hyper-V-Worker-AdminMicrosoft-Windows-Hyper-V-SynthStor\r\nStarted VM 18500\r\nMicrosoft-Windows-Hyper-V-Worker-AdminMicrosoft-Windows-Hyper-V-Worker\r\nSaved VM 18510\r\nMicrosoft-Windows-Hyper-V-Worker-AdminMicrosoft-Windows-Hyper-V-Worker\r\nRestoring VM 18596\r\nMicrosoft-Windows-Hyper-V-Worker-AdminMicrosoft-Windows-Hyper-V-Worker\r\nExporting VM 18303\r\nMicrosoft-Windows-Hyper-V-VMMS-AdminMicrosoft-Windows-Hyper-V-VMMS\r\nPause VM 18516\r\nMicrosoft-Windows-Hyper-V-Worker-AdminMicrosoft-Windows-Hyper-V-Worker\r\nResume VM 18518\r\nMicrosoft-Windows-Hyper-V-Worker-AdminMicrosoft-Windows-Hyper-V-Worker\r\nTurn Off VM 18502\r\nMicrosoft-Windows-Hyper-V-Worker-AdminMicrosoft-Windows-Hyper-V-Worker\r\nReset VM (Using Hyper-V Manager) 18512\r\nMicrosoft-Windows-Hyper-V-Worker-AdminMicrosoft-Windows-Hyper-V-Worker\r\nhttps://cybercx.com.au/blog/akira-ransomware/\r\nPage 5 of 7\n\nReset VM (Using Guest Operating System) 18514\r\nMicrosoft-Windows-Hyper-V-Worker-AdminMicrosoft-Windows-Hyper-V-Worker\r\nShut Down VM (Using The Shutdown\r\nIntegration Component)\r\n18504\r\nMicrosoft-Windows-Hyper-V-Worker-AdminMicrosoft-Windows-Hyper-V-Worker\r\nShut Down VM (Using Guest Operating\r\nSystem)\r\n18508\r\nMicrosoft-Windows-Hyper-V-Worker-AdminMicrosoft-Windows-Hyper-V-Worker\r\nMoved VM’s Storage Location 20927\r\nMicrosoft-Windows-Hyper-V-VMMS-AdminMicrosoft-Windows-Hyper-V-VMMS\r\nDeleted VM 13003\r\nMicrosoft-Windows-Hyper-V-VMMS-AdminMicrosoft-Windows-Hyper-V-VMMS\r\n2. VMware ESXi / vSphere Logging and Activities \r\nVirtual Machine Audit activity can be reviewed by logging onto the ESXi host utilising an administrator/root\r\naccount. Activity is recorded in the “hostd.log” file found here: \r\n/var/log/hostd.log  \r\n/var/run/log/hostd.log \r\nBelow is an extract from our test instance demonstrating the creation of a new virtual machine.  \r\n2023-07-25T07:29:57.870Z info hostd[2098947] [Originator@6876 sub=Vmsvc opID=esxui-46f0-93b4 user=Evi\r\n /vmfs/volumes/\u003cVOLUME_ID\u003e/MySecretVM/MySecretVM.vmx\r\n2023-07-25T07:29:57.871Z info hostd[2098947] [Originator@6876 sub=Vimsvc.ha-eventmgr opID=esxui-46f0-\r\nOnce the VM was created there was a state change from VM_STATE_INITIALIZING to VM_STATE_OFF. \r\n2023-07-25T07:30:00.126Z info hostd[2098947] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/\u003cVOLUME_ID\u003e/\r\nopID=esxui-46f0-93b4 user=EvilUser] State Transition (VM_STATE_INITIALIZING -\u003e VM_STATE_OFF)\r\n2023-07-25T07:30:00.127Z info hostd[2098947] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/\u003cVOLUME_ID\u003e/\r\n/vmfs/volumes/\u003cVOLUME_ID\u003e/MySecretVM MySecretVM.vmx\r\nWhen conducting forensics or incident response, you can collect these logs either through direct SSH access to the\r\nhost or through generating a “support bundle” which includes the necessary logs from /var/log on the host.  \r\nBlue teams should also consider enabling syslog to automatically forward these events to a SIEM or log\r\naggregation platform.  \r\nAdditional log locations can be found here. \r\nhttps://cybercx.com.au/blog/akira-ransomware/\r\nPage 6 of 7\n\n3. Standard or Default Windows Workstation names leaked in Windows authentication logs \r\nWhen a new Windows endpoint is setup, the hostname, if not manually assigned by the organisation will start with\r\n“WIN-“ or “DESKTOP-“ or “PC-“ or “WORKSTATION-“. Most ransomware actors we’ve seen use these\r\ndefaults, which subsequently end up in event logs. A review of the Security authentication logs on Windows\r\n(Event ID 4624/4625) may show attempted or successful accesses. Furthermore, if these authentication attempts\r\nhave an IP address from your VPN address pool, it may indicate that an unmanaged device is connected.  \r\nThis may also be observed in Remote Desktop and SMB File share related event logs as well. \r\n4. Audit infrastructure and ensure you have coverage of your security tooling \r\nThe CyberCX DFIR team commonly identifies initial access vectors or hives of threat actor activity around\r\nunmanaged hosts. Whether it is a test VM in Azure left open to the Internet, or an old “decommissioned” host that\r\nis left unpatched, ensuring you have proper visibility of these hosts will enable you to assess your risk.   \r\nAuthors: Phill Moore and Zach Stanford with contributions from Suyash Tripathi and Yogesh Khatri \r\nCyberCX Security, Testing and Assurance and Managed Security Services\r\n[1] CyberCX assesses with medium confidence these credentials were obtained outside of the affected network. \r\n[2] Akira has also made recent changes to their binary again, now going by “Megazord” – VirusTotal – File –\r\nc9c94ac5e1991a7db42c7973e328fceeb6f163d9f644031bdfd4123c7b3898b0 \r\nSource: https://cybercx.com.au/blog/akira-ransomware/\r\nhttps://cybercx.com.au/blog/akira-ransomware/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"MITRE"
	],
	"references": [
		"https://cybercx.com.au/blog/akira-ransomware/"
	],
	"report_names": [
		"akira-ransomware"
	],
	"threat_actors": [
		{
			"id": "8c8fea8c-c957-4618-99ee-1e188f073a0e",
			"created_at": "2024-02-02T02:00:04.086766Z",
			"updated_at": "2026-04-10T02:00:03.563647Z",
			"deleted_at": null,
			"main_name": "Storm-1567",
			"aliases": [
				"Akira",
				"PUNK SPIDER",
				"GOLD SAHARA"
			],
			"source_name": "MISPGALAXY:Storm-1567",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "910b38e9-07fe-4b47-9cf4-e190a07b1b84",
			"created_at": "2024-04-24T02:00:49.516358Z",
			"updated_at": "2026-04-10T02:00:05.309426Z",
			"deleted_at": null,
			"main_name": "Akira",
			"aliases": [
				"Akira",
				"GOLD SAHARA",
				"PUNK SPIDER",
				"Howling Scorpius"
			],
			"source_name": "MITRE:Akira",
			"tools": [
				"Mimikatz",
				"PsExec",
				"AdFind",
				"Akira _v2",
				"Akira",
				"Megazord",
				"LaZagne",
				"Rclone"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775439090,
	"ts_updated_at": 1775791677,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/34ddc297c2c477bab195978dcf44d7cd01c538ec.pdf",
		"text": "https://archive.orkl.eu/34ddc297c2c477bab195978dcf44d7cd01c538ec.txt",
		"img": "https://archive.orkl.eu/34ddc297c2c477bab195978dcf44d7cd01c538ec.jpg"
	}
}