{
	"id": "f4de1f7c-934a-4822-92ce-1fb4c3fef5dd",
	"created_at": "2026-04-06T00:20:51.764028Z",
	"updated_at": "2026-04-10T03:22:00.265252Z",
	"deleted_at": null,
	"sha1_hash": "6d0aa9d975b59541b2bb36a53ce4e69436edc76e",
	"title": "Part 1: Analysing MedusaLocker ransomware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 133085,
	"plain_text": "Part 1: Analysing MedusaLocker ransomware\r\nBy By Theta\r\nArchived: 2026-04-05 16:25:22 UTC\r\nRansomware is a sad fact of life in 2020. While the “big game hunting” actors (Maze, REvil et al) get the attention\r\nof the media and industry by claiming high profile scalps, far less attention is given to the victim and attacker\r\nfrom smaller origins. There are a host of actors (often under-researched or reported) engaged in ransomware\r\noperations. Most of them could be classified as opportunistic rather than persistent.\r\nIn this post, we focus on pre-impact operations as a complete intrusion. These artefacts would normally be heavily\r\ndegraded or destroyed by the ransomware, or by the need for a business to recover (often wiping evidence). You’ll\r\nsee how we found and analysed a host that failed to encrypt correctly – this host also turned out to be the initial\r\nentry point and staging post for the operators. As we go through our analysis, we’ll point out which part of the kill\r\nchain the attacker is up to and where this maps to the MITRE ATT\u0026CK framework.\r\nIt’s important to note that these adversaries weren’t particularly stealthy or advanced. They doubled up on a lot of\r\ntooling and functionality, yet they were able to completely overmatch the defenses presented to them. They\r\nachieved their goals by having enough effectiveness.\r\nThe ramifications of the attack\r\nAs a result of this attack, the organisation experienced the following:\r\nEncryption of:\r\n75% of end-user compute devices (these devices wouldn’t boot at all – we’re unsure if this was deliberate).\r\n100%* of servers (however, the server that was the point of entry and staging post failed to encrypt\r\ncompletely, leaving parts of its system drive available for analysis).\r\nMapped drives, shared drives, Dropbox, OneDrive (this organisation didn’t have enterprise licenses for its\r\ncloud file sharing solutions, making recovery more difficult).\r\nERP System (over 500 hours to rebuild and move to a SaaS application). This resulted in all purchase/sales\r\norders, inventories, ledgers, GST, shipping and financial records being lost.\r\nEDI services, which resulted in all automatic order placing and fulfilment being halted.\r\nBackups – variously encrypted or degraded. USB + network-attached storage schemes were all hit, forcing\r\nthe rebuild of critical ERP and EDI solutions from much older backups - which added additional time and\r\ncomplexity.\r\nTime from initial access to domain-wide encryption ~25hrs (16/06/2020 3:38 am to 17/06/2020 ~5 am)\r\nTime to be able to trade again: 8 working days (and hundreds of recovery and rebuild hours behind the scenes\r\nplus manual trading with incremental improvements as data structures were recovered).\r\nhttps://www.theta.co.nz/news-blogs/cyber-security-blog/part-1-analysing-medusalocker-ransomware/\r\nPage 1 of 4\n\nAs we go through each stage of the attack, it's worth role playing this scenario in your own organisation to see\r\nhow you would recover the loss of such data types. You can use the MITRE ATT\u0026CK mapping to overlay your\r\norganisation’s controls and your ability to detect and stop a similar attack.\r\nThis dataset comes from one intrusion without good instrumentation, and thus may not represent a total picture of\r\nthe actor’s TTP’s. In the forensic analysis, bits were missing, and the pieces we found often made little sense. Still,\r\nby piecing together a timeline, we could be reasonably confident about the adversary activity that had happened.\r\nIntrusion Analysis\r\nBackground\r\nWe received a phone call from the client on the morning of June 17th 2020. We’d supported their ERP and EDI\r\nsystems in the past, but were not currently their IT outsource partner. They reported that all computers in their\r\nenvironment were not booting and that they thought they’d been attacked.\r\nA search on Shodan showed one of their servers had RDP exposed, giving a possible source of entry (we were\r\nsadly correct). When our team arrived on site, we found their environment was completely shutdown; all of their\r\nworkstations wouldn’t boot, and all servers were powered off.\r\nOn the particular server that this analysis is from, we found its RAID array reporting it was in a degraded state\r\n(we’re not sure if the ransomware did this) leaving us with some difficult choices when it came to triage and\r\nimaging. To our surprise, the ransomware failed to completely execute on this host. While all of the non-system\r\ndrives (10+ TB of them) were completely encrypted, and its system drive was partially encrypted, we later saw\r\nthat the task executing it had failed. Most of this analysis comes from imaging of the file system on that host.\r\nInitial Access:\r\nInitial Access was via RDP brute-forcing (T1110) to a Domain Controller that had RDP open to the internet\r\n(T1133 – External Remote Services). This (obviously dangerous) configuration was set up to enable remote access\r\nby the clients’ main IT provider.\r\nThe initial logon via an admin account was recorded at 16/06/2020 3:38 am NZT from 185.202.1[.]19. Landing on\r\nan account with DA on a DC certainly made the job of the ransomware operator’s life somewhat easier and\r\nshortened the kill chain. However, the assessment shows they would have been able to carry out their objectives\r\ngiven the low-security posture of the environment regardless. Logons were also observed from 213.7.208[.]69 \u0026\r\n5.2.224[.]56.\r\nExecution:\r\nFragments of several interesting tool chains were recovered from the Server.\r\nAs the vector of entry was RDP, graphical tools were used (T1061) and recovered shellbags support this.\r\nThe intruder staged their tooling in a pre-existing folder - C:\\SQLDB\\.\r\nhttps://www.theta.co.nz/news-blogs/cyber-security-blog/part-1-analysing-medusalocker-ransomware/\r\nPage 2 of 4\n\nEvent logs record large amounts of PowerShell (T1086) activity being executed, although the system had\r\nPowerShell 2.0 installed, so no useful information was logged as to what was run specifically. Timestamps also\r\nshow the Powershell_ise.exe binary was also accessed.\r\nRecovered Certutil Logs reference the PowerShell modules Connect-Mstsc.ps1, PSnmap.psd1 (both of which are\r\nthe names of pre-made modules widely available online) and a more enigmatic 2sys.ps1 (“Command Line:\r\nCertUtil -decode file.b64 2sys.ps1”) which shares a name to script referenced in a Carbon Black report on another\r\nransomware group from 2018 (Dharma).\r\nThis usage of CertUtil is evidence of Remote File Copies (T1105).\r\nMACB timestamps also suggest WMIC was used, although given the utility of this software its purpose cannot be\r\nconfirmed. It may have been caused by some of the intruders tooling rather than directly invoked.\r\nIn addition to other precompiled binaries and tools (7za, via certutil: CertUtil -decode za 7za.exe),\r\nthe Certutil.log file once again offers some evidence of staging tooling; with the following commands executed\r\n(via script):\r\n\u003c trimmed for brevity\u003e\r\nWith a total of 48 numbered arch\u003c$number\u003e.b64 files decoded in sequence.\r\nhttps://www.theta.co.nz/news-blogs/cyber-security-blog/part-1-analysing-medusalocker-ransomware/\r\nPage 3 of 4\n\nBased on the prior collection of 7za.exe (a command-line version of 7zip) and the fact the first of these files ended\r\nwas decoded to have a .zip extension, it’s a reasonably safe assertion that this was a multipart archive file.\r\nAdditional file structures beneath the C:\\SQLDB\\ folder were visible via shellbags, in particular folders called\r\n`kamikadze new` (as referenced here) `_local` and `77`.\r\nThe intruder installed a C++ Runtime library (Microsoft Visual C++ 2015 x86 Runtime 14.0.23026) to the system.\r\nIt appears as though this or some of other parts of the software deployed prompted the system to collect a large\r\nnumber of Windows updates (such as KB2999226). These artefacts are inconclusive but were not exhaustively\r\nsearched, as are the subsequent .msi’s the system installed (their names variously available as deleted registry\r\nitems) not long before executing the ransomware.\r\nSource: https://www.theta.co.nz/news-blogs/cyber-security-blog/part-1-analysing-medusalocker-ransomware/\r\nhttps://www.theta.co.nz/news-blogs/cyber-security-blog/part-1-analysing-medusalocker-ransomware/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.theta.co.nz/news-blogs/cyber-security-blog/part-1-analysing-medusalocker-ransomware/"
	],
	"report_names": [
		"part-1-analysing-medusalocker-ransomware"
	],
	"threat_actors": [],
	"ts_created_at": 1775434851,
	"ts_updated_at": 1775791320,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6d0aa9d975b59541b2bb36a53ce4e69436edc76e.pdf",
		"text": "https://archive.orkl.eu/6d0aa9d975b59541b2bb36a53ce4e69436edc76e.txt",
		"img": "https://archive.orkl.eu/6d0aa9d975b59541b2bb36a53ce4e69436edc76e.jpg"
	}
}