{
	"id": "11da98bb-24b4-42d8-b107-181875c5070a",
	"created_at": "2026-04-06T01:30:03.111296Z",
	"updated_at": "2026-04-10T03:20:58.865189Z",
	"deleted_at": null,
	"sha1_hash": "43a01f160ec3e327adc93d6b3140705cb0a0f5d7",
	"title": "Ransomware: Growing Number of Attackers Using Virtual Machines",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 78898,
	"plain_text": "Ransomware: Growing Number of Attackers Using Virtual\r\nMachines\r\nBy About the Author\r\nArchived: 2026-04-06 01:00:47 UTC\r\nSymantec has found evidence that an increasing number of ransomware attackers are using virtual machines\r\n(VMs) in order to run their ransomware payloads on compromised computers. The motivation behind the tactic is\r\nstealth. In order to avoid raising suspicions or triggering antivirus software, the ransomware payload will “hide”\r\nwithin a VM while encrypting files on the host computer.\r\nThe tactic is a recent development, having been documented by Sophos in connection with RagnarLocker last\r\nyear. In that case, ransomware was run from inside an Oracle VirtualBox Windows XP VM.\r\nVirtualBox usage\r\nDuring a recent investigation into an attempted ransomware attack, Symantec discovered that the attackers had\r\ninstalled a VirtualBox VM on some compromised computers. Unlike the previously documented RagnarLocker\r\nattacks, which involved Windows XP, the VM in this case appeared to be running Windows 7.\r\nThe VM was delivered to the target via a malicious installer file that used various file names, including:\r\nfuckyou.msi\r\nfuck.msi\r\naa51978f.msi\r\ns3c.msi\r\nThe installer created a file called runner.exe, which was a Golang (Go) executable compiled from the following\r\nsource file:\r\nC:/builder/runner/main.go\r\nApart from standard Go libraries, it used the go-ps library for process enumeration. Embedded strings used by the\r\nexecutable, such as file names, process names, and commands, were obfuscated using four-byte XOR keys. Each\r\nstring was encrypted using a unique key.\r\nThis executable depended on multiple other files that were expected to be present in the same directory. Its main\r\npurpose was to install a VirtualBox VM in a headless mode.\r\nWhen executed, runner.exe performed following actions:\r\nIt checked if it was running on Active Directory (AD) controller based on whether the\r\nC:\\Windows\\SYSVOL directory was present. It exited if the check proved true.\r\nhttps://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/ransomware-virtual-machines\r\nPage 1 of 4\n\nIt used a function named russianDetect to check if it was running on a system using a Russian keyboard\r\nlayout (0x0419). It exited if the check proved true. Checks such as this are a common feature of targeted\r\nransomware attacks.\r\nIt enumerated running processes and services and terminated any that were present on blacklists\r\n(procBlacklist, servicesBlacklist) using taskkill.exe and sc.exe.\r\nThe executable then dropped, executed, and deleted a file called starter.bat with the following content in order to\r\nmount a recovery partition:\r\nmountvol E:\\ \\\\?\\Volume{\u003cID\u003e}\\\r\nIt then decrypted and dropped VirtualBox.xml, a VirtualBox configuration file, and micro.xml, a VM\r\nconfiguration file (see appendix). It created an SDRSMLINK directory and linked system files to that directory,\r\ne.g:\r\ncmd /C mklink /j \"%SYSTEMROOT%\\SDRSMLINK\\Program Files\" \"%SYSTEMROOT%\\Program Files\"\r\nIt also adjusted the \"\u003cSharedFolders\u003e\" section in micro.xml to reflect files and directories linked in\r\nCSIDL_WINDOWS\\SDRSMLINK. It then initialized VirtualBox components:\r\ncmd /C sc create VBoxDRV binpath= %SYSTEMROOT%\\\\app64\\drivers\\VBoxDrv.sys type= kernel start= auto\r\nerror= normal displayname= PortableVBoxDRV regsvr32 /S %SYSTEMROOT%\\\\app64\\VBoxC.dll cmd /C\r\n%SYSTEMROOT%\\\\app64\\VBoxSVC.exe /reregserver rundll32 %SYSTEMROOT%\\\\app64\\VBoxRT.dll ,RTR3Init\r\nIt enumerated and cleared Windows system logs using WEvtUtil.exe:\r\nwevtutil.exe enum-logs wevtutil.exe clear-log \u003cLOG_NAME\u003e\r\nSymantec did not obtain a VM image, but what likely occurred next was that the ransomware payload was located\r\non the VM's disk and auto started once the operating system was fully booted. The VM likely had access to the\r\nhost computer’s files and directories (via \"SharedFolders\" set up by runner.exe), allowing it to encrypt files on the\r\nhost computer.\r\nConti or Mount Locker?\r\nWhile the payload running in the VM was not identified, there were reasonably strong indicators that it was Conti.\r\nA username and password combination (nuuser/7HeC00l3stP@ssw0rd) used in these attacks was previously\r\nassociated with older Conti activity, dating from April 2021.\r\nHowever, on the same computer that the VM was deployed on, Symantec also observed Mount Locker being\r\ndeployed, raising the question as to whether the payload was actually Mount Locker. Since the main purpose of\r\nrunning a payload on a VM is to avoid detection, it doesn’t make much sense for the attacker to also deploy the\r\npayload on the host computer.\r\nOne possible explanation is that the attacker is an affiliate operator with access to both Conti and Mount Locker.\r\nThey may have attempted to run a payload (either Conti or Mount Locker) on a virtual machine and, when that\r\ndidn’t work, opted to run Mount Locker on the host computer instead.\r\nhttps://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/ransomware-virtual-machines\r\nPage 2 of 4\n\nObfuscating malicious activity\nRansomware operators are continually refining their tactics in a bid to stay one step ahead of detection. Many are\nnow heavily relying on legitimate and dual-use tools in order to stage attacks on targeted networks. The\nransomware payload itself is often the stage of the attack most likely to raise red flags and, by hiding it in a virtual\nmachine, there is an expectation that it may not be discovered. Organizations should exercise increased vigilance\nin relation to the unauthorized installation of virtual machines on their networks.\nProtection/Mitigation\nFor the latest protection updates, please visit the Symantec Protection Bulletin.\nIndicators of Compromise\n2eae8e1c2e59527b8b4bb454a51b65f0ea1b0b7476e1c80b385f579328752836 - Installer\n9f801a8d6b4801b8f120be9e5a157b0d1fc3bbf6ba11a7d202a9060e60b707d8 - runner.exe\ne5291bae18b0fa3239503ab676cacb12f58a69eb2ec1fd3d0c0702b5a29246cb - VirtualBox\nd89bd47fb457908e8d65f705f091372251bae3603f5ff59afb2436abfcf976d8 - Mountlocker\n8f247e4149742532b8a0258afd31466f968af7b5ac01fdb7960ac8c0643d2499 - Mountlocker\nAppendix\nVirtualBox.xml - VirtualBox configuration file\n         Micro.xml - virtual machine configuration file\n\nname=\"GUI/ShowMiniToolBar\" value=\"yes\"/\u003e                               Ransomware: Growing Number of Attackers Using Virtual Machines\nThreat Hunter Team\nThreat Hunter Team\nSymantec and Carbon Black\nSource: https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/ransomware-virtual-machines\nhttps://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/ransomware-virtual-machines\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/ransomware-virtual-machines"
	],
	"report_names": [
		"ransomware-virtual-machines"
	],
	"threat_actors": [],
	"ts_created_at": 1775439003,
	"ts_updated_at": 1775791258,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/43a01f160ec3e327adc93d6b3140705cb0a0f5d7.pdf",
		"text": "https://archive.orkl.eu/43a01f160ec3e327adc93d6b3140705cb0a0f5d7.txt",
		"img": "https://archive.orkl.eu/43a01f160ec3e327adc93d6b3140705cb0a0f5d7.jpg"
	}
}