{
	"id": "daf8d820-c6c7-4f04-b118-8586e6735fc3",
	"created_at": "2026-04-06T01:30:41.569718Z",
	"updated_at": "2026-04-10T03:19:58.817588Z",
	"deleted_at": null,
	"sha1_hash": "31e10d2c6b6e6cae67b2b230a8af6c2d76f4e9bf",
	"title": "Part 2: Analysing MedusaLocker ransomware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 347248,
	"plain_text": "Part 2: Analysing MedusaLocker ransomware\r\nBy By Theta\r\nArchived: 2026-04-06 00:51:37 UTC\r\nPersistence\r\nNo specific persistence events were observed; it assessed that these intruders likely rely on tempo of operations\r\nand low-security posture of the victim to complete their objectives before being evicted.\r\nInterestingly the earliest reference to the SVHOST task that executed the ransomware was at 16/06/2020 4:58:11\r\npm; even though most of the adversary activity was conducted later at 17/06/2020 3:00 to 4:00 am. This\r\npotentially represented a minimum viable (aka local) ransomware deployment in case the actors were detected and\r\nlost access to the host. Given the ~10hr time offset this may also represent a geographically distributed set of\r\nintrusion operators involved.\r\nPrivilege Escalation\r\nThe admin account compromised already had Domain Administer rights (T1110), so no privilege escalation was\r\nstrictly necessary. Nonetheless, Theta observed the Domain\\Administrator (S-1-5-21domain-500) account utilised\r\nby the intruder for lateral movement and reconnaissance. However, the exact mechanism these credentials were\r\nobtained with was not observed (other reporting suggests mimikatz staged in the `kamikadze` folder). Theta also\r\nobserved the use of NT\\SYSTEM (with C:\\Windows\\syswow64\\config\\systemprofile storing some useful\r\nartefacts).\r\nDefense Evasion\r\nEvent logs and registry hives show artefacts related to the removal of ESET, the installed AV product on the server\r\n(T1089) before starting the encryption, some duplication of which may represent automated removal rather than\r\nby hand.\r\nThe previously mentioned arch.z$ sequence of files in the certutil log represents evidence of obfuscation of files\r\nor information (T1027), which is another technique to avoid detection.\r\nCredential Access          \r\nGiven the limited telemetry available, no evidence of Credential Access TTPs was observed (such as accessing\r\nsystem hives, the ntdis.dit file, or the ever-ubiquitous and suspected mimikatz).\r\nWhile this was not necessary for the actors to carry out their objectives as referenced in the Privilege Escalation\r\nsection, ultimately other accounts were obtained; however their mechanism for access remains unknown.\r\nRecovered registry hives show the HKLM\\SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\WDigest key\r\nwas set to 1; although given the age of the machine in question it was possible that the legitimate system\r\nhttps://www.theta.co.nz/news-blogs/cyber-security-blog/part-2-analysing-medusalocker-ransomware/\r\nPage 1 of 4\n\nadministers never applied the fix to disable this. During the period the intruders were on the system there appeared\r\nto be a legitimate login from the Domain\\Administrator account (S-1-5-21domain-500), which would have given\r\nan additional opportunity for the intruders to hijack these credentials, although this remains an open question.\r\nDiscovery\r\nSeveral network discovery tools were used by the actor (T1018). Famatech’s Advanced Port Scanner was\r\ndeployed to the host, with evidence suggesting interaction and use. The aforementioned PSnmap.psd1 PowerShell\r\ndatafile (likely an implementation of the well-known nmap) is another network discovery/reconnaissance tool, and\r\n2sys.ps1 script (if the same as referenced by Carbon Black) contains RDP scanning functionality.\r\nThe deployed binary NetworkShare_pre2.exe detected variously as NetTool has a diverse set of capabilities\r\nfocused around network discovery. This was not removed from the staging directory unlike most of the other\r\ntooling across this intrusion.\r\nWinPCAP 4.1.3 (rpcapd.exe) was also installed as a service onto the host by the actor, but its exact purpose cannot\r\nbe inferred as it may be a dependency of other tooling used.\r\nLateral Movement      \r\nThere is evidence from Security Event Logs of the Domain\\Administrator account logging onto other hosts in the\r\nenvironment (via Event ID 4648). The connect-mstsc (Connect-Mstsc.ps1) likely provides RDP functionality in\r\nPowerShell.\r\nAll the other impacted hosts in the environment would not boot, so minimal forensic analysis was conducted into\r\nthem as to the actions on them before encrypting. Other reporting details Medusa Locker spreading via PSexec\r\nand SMB - although with Domain Admin access a raft of lateral movement techniques is available.\r\nUltimately, the actors were able to spread their payload to effectively every host in the domain (bar a few off-site\r\nlaptops).\r\nCollection\r\nThere was no firm evidence of collection observed by the actor. Circumstantial evidence shows interaction with a\r\nSQL database present on the system.\r\nCommand and Control\r\nAs mentioned; the intruders logged in via RDP (External Remote Services - T1133) from 185.202.1[.]19,\r\n213.7.208[.]69 \u0026 5.2.224[.]56.\r\nAdditional information, such as keyboard language or screen size was not available.\r\nExfiltration\r\nThe ransom note referenced potential data exfiltration and release, however no direct evidence of this was found\r\nand no effort was made to reach out and engage with the actor. Of the limited telemetry observed, there was a\r\nhttps://www.theta.co.nz/news-blogs/cyber-security-blog/part-2-analysing-medusalocker-ransomware/\r\nPage 2 of 4\n\nspike of 200Gb+ uploaded which did not match the pattern of life around the incident. If it was carried out, it may\r\nhave been via RDPclip (Exfiltration Over Command and Control Channel - T1041) which would have left little\r\nevidence.\r\nThe actor has not followed up by engaging with the client. Access to this environment with Domain Admin would\r\nhave given them enough access to harvest emails, and contact details for the business had they wished.\r\nImpact\r\nGiven the nature of this intrusion, Data Encrypted For Impact (T1486) was the end goal. This was incredibly\r\nsuccessful in this environment (see: Headline Stats).\r\nThe actor created a hidden scheduled task “svhost” (similarly named to the legitimate svchost process used by\r\nwindows) and stored the binary in the %AppData%\\Roaming\\ folder for the compromised admin user. The binary\r\nitself was also named svhost.exe. The binaries contain a unique key per-campaign, so to preserve the\r\nconfidentially of the client, this file won’t be made available in full.\r\nEvent logs show its execution every 15 minutes (this behaviour is consistent with other reported activity on\r\nMedusa Locker) as well as failure notices later on.\r\nThere remains some ambiguity around the exact timing of their operations. There’s evidence of the scheduled task\r\nrunning while the operators were still engaged on the host – unfortunately prefetch data was not available for\r\nanalysis. Given the cryptographic overhead involved in sequentially encrypting each file on the file system, they\r\nmay have been confident in the knowledge that the system would take some time to become fully degraded.\r\nEspecially if the non-system drives were targeted first. There is some evidence (via event logs and shellbags) of\r\ngraphical interaction with the Windows task scheduler to manipulate the scheduled task after it’s deployment – in\r\nwhat looks troubleshooting efforts.\r\nIt remains unclear if the operators intended to prevent the other hosts on the network from booting at all via\r\nencrypting the master boot record or if this was unintended - however, the result was that some of the machines\r\nwere rendered inoperable - T1487 (Disk Structure Wipe).\r\nA simple script named _backup.bat was used to delete Volume Shadow Copies – evidence of Inhibiting System\r\nRecovery (T1490) and this was executed on the system before encryption:\r\nOther examples of MedusaLocker have shown vssadmin.exe to be spawned to further complicate recovery\r\nattempts (T1490):\r\nhttps://www.theta.co.nz/news-blogs/cyber-security-blog/part-2-analysing-medusalocker-ransomware/\r\nPage 3 of 4\n\nThe ransom demand pointed to a TOR address with a unique string for this campaign. While we did not interact\r\nwith the attackers, others had, which in turn revealed a modestly successful return, at least for this campaign and\r\nfurther indirect evidence of this adversary successfully monetising their operation through Data Encrypted For\r\nImpact (T1486).\r\nSource: https://www.theta.co.nz/news-blogs/cyber-security-blog/part-2-analysing-medusalocker-ransomware/\r\nhttps://www.theta.co.nz/news-blogs/cyber-security-blog/part-2-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-2-analysing-medusalocker-ransomware/"
	],
	"report_names": [
		"part-2-analysing-medusalocker-ransomware"
	],
	"threat_actors": [],
	"ts_created_at": 1775439041,
	"ts_updated_at": 1775791198,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/31e10d2c6b6e6cae67b2b230a8af6c2d76f4e9bf.pdf",
		"text": "https://archive.orkl.eu/31e10d2c6b6e6cae67b2b230a8af6c2d76f4e9bf.txt",
		"img": "https://archive.orkl.eu/31e10d2c6b6e6cae67b2b230a8af6c2d76f4e9bf.jpg"
	}
}