Threat Intelligence Spotlight
Executive Summary
VMRay Labs has analyzed a family of malicious WinRAR self-extracting archives that act as droppers. Each one unpacks several helper tools and a password protected archive into a temporary folder, then executes a batch script. The script identifies Windows security components on the host, disables Windows Update to prevent their repair, and deletes them from disk by abusing the kernel driver of IObit Unlocker, a legitimate signed file-unlocking utility. In the sample we examined most closely, a single command targeted 281 distinct files and directories for deletion. We also observed the kernel driver forcibly delete all three Microsoft Defender directories.
We assess with high confidence that this is a commodity tool used across the Russian-speaking cybercrime ecosystem, not the work of a single actor. Across the six archives, the same helper kit and the same deletion command appear every time: four deliver the same .NET payload and two carry different payloads. Their shared import hash also appears in open-source records for a large set of otherwise unrelated samples spanning numerous commodity malware families over several years.
This family stays out of public malware repositories for two reasons. The first is that its damage is only visible at runtime. The malicious logic sits inside a password protected archive and unfolds only when the batch script runs, so a security product that scans the self-extracting archive as a file sees only a benign-looking wrapper and labels it generically; the scale of what happens underneath, with the host’s antivirus, backups, recovery data, and Windows Update all removed together, is never recorded. The deletion itself is split in two: a .NET payload we track as Saked (it runs on disk as mika.exe) removes the files it can reach on its own, then hands the protected ones to the kernel driver of IObit Unlocker. The second reason is fragmented delivery. Saked is packaged in at least four separately built archives, so counting by file hash treats them as unrelated samples and undercounts the family, and static, file-level clustering lumps these archives in with unrelated self-extractors that share only the same WinRAR stub. This spotlight should give defenders the behavioral signatures that identify the routine at runtime, and explain why static, file-level identification gets it wrong.
Key Judgments
Saked’s defining behavior is removing endpoint security completely. It detects Microsoft Defender and Windows Security components and disables the Windows Update services that would otherwise repair or replace them once they are gone. A single IObitUnlocker.exe /Delete /Advanced command then deletes 281 distinct files and directories spanning Microsoft Defender, at least nine third-party antivirus vendors, backups, Windows Update, OneDrive, and recovery and forensic logs.
The deletion abuses a legitimate signed driver, a Bring-Your-Own-Vulnerable-Driver (BYOVD) technique. Saked carries the IObit Unlocker 1.6.0.16 utility embedded and unpacks it at runtime, then drives its kernel driver. The driver terminates and force-deletes each target, even Microsoft Defender components that are still running, by sending the device control code 0x222124 to \\.\IObitUnlockerDevice. The driver and control code are documented in CVE-2020-14974 and CVE-2020-14975 [2].
One shared routine carries the payloads. The same deletion kit and the same /Delete /Advanced command recur across all six archives: four deliver Saked, one an Amadey loader, and one an NSudo-elevated equivalent. Open-source records tie the shared import hash to other families, but those share only the WinRAR stub, not the deletion kit.
Saked, the .NET payload in four of the six archives, is a deletion tool, not an information stealer. Our dynamic analysis shows it launching IObit Unlocker with the target list and deleting the accessible files itself; across the runs we cross-checked, it accessed no credential stores, browser data, or DPAPI-protected material. Public scanners label it a process killer (MSIL/KillProc). It was compiled on 2025-10-17.
The self-extracting archive carries no file-level fingerprint unique to this malware. Its import hash (12e12319…), Rich-header hash (5a0b7a24…), and timestamp (2022-03-03 13:15:57 UTC) all come from the generic WinRAR self-extractor stub and are identical across unrelated families, so any tool that identifies malware by these static values cannot tell this family apart from any other WinRAR archive.
Endpoint products detect the outer layer, not the payload. Public labels name the delivery behavior (BAT/KillAV, DefenderKiller, NirCmd, RarDrp), which flags that the sample tampers with security software but never conveys the scale of what Saked deletes beneath it: Microsoft Defender, third-party antivirus, backups, recovery data, and Windows Update.
Endpoint security software is built to be hard to switch off, and harder still to remove: Windows protects its own Microsoft Defender files, and third-party vendors guard their processes and services. Clearing that protection away is often an attacker’s first move in a serious intrusion. Most malware is content to turn it off; a smaller, more aggressive group deletes it from disk so it cannot simply be turned back on.
This report examines a family of WinRAR self-extracting archives whose shared purpose is exactly that: to strip a Windows host of its defenses before another payload runs. The family surfaced through VMRay’s UniqueSignal Threat Feed, which flags samples on unusual runtime behavior rather than on whether their files match a known signature. One such sample led us to a cluster of closely related archives. Because those archives are nearly identical as files and carry no distinguishing static signature, we analyzed them dynamically, reconstructing what each one does after it extracts and runs, and we cross-checked the primary sample across multiple independent executions.
A comprehensive investigation of the second-stage payloads retrieved during execution, as well as an assessment of the operators’ ultimate objectives, falls outside the scope of this spotlight.
Self-extracting archives and defense-disabling scripts are each well known on their own, so the contribution here is not a new technique but an execution-level finding: several payloads that public feeds track as separate threats are delivered by one and the same destruction routine. Throughout, we separate what we observed directly in execution from what open-source records only associate, and we rate confidence for each.
That distinction matters most to the people who have to stop it. A security product that inspects only the outer layer can produce only a generic label before it moves on, and the routine underneath, which deletes the antivirus, backups, recovery data, and Windows Update together, stays hidden behind that label. We wrote this spotlight for the defenders, threat hunters, and detection engineers who need to recognize that routine while it runs, and its wider point is a straightforward one: watching a sample execute identifies and links these archives correctly, while static, file-level comparison, misled by a shared WinRAR stub, splits them apart and overlooks the damage beneath.
02
The Self-Extracting Archive
The sample is a WinRAR self-extracting archive. On execution it writes a randomly named batch script under %TEMP% and a small utility set into a subfolder: 7z.exe, cecho.exe, nircmd.exe, and a password protected archive (same.zip). The batch script decrypts same.zip with 7z using the hardcoded password stucha, which yields the Saked payload, as shown in the VMRay function log in Figure 1. IObit Unlocker is not inside same.zip; Saked carries it embedded and unpacks it at runtime into %TEMP%\IObitUnlocker. The archive’s dialog strings are Cyrillic, and the password stucha is the Russian slang word штука (shtuka), literally “a piece” but colloquially “a grand,” a thousand units of money. Together these point, with high confidence, to a Russian-speaking developer. From here on, the logic lives in the batch script and the Saked payload it launches.
VMRay Platform · function log
CreateProcessW
[0083.603] CreateProcessW
lpApplicationName=C:\Users\RDHJ0C~1\AppData\Local\Temp\saked\7z.exe
lpCommandLine=7z x -aoa -bso0 -bsp1 “same.zip” -p”stucha” “mika.exe”
lpCurrentDirectory=C:\Users\RDHJ0C~1\AppData\Local\Temp\saked
lpDesktop=WinSta0\Default
returned 1
lpProcessInformation=0x4fe79c · dwProcessId=0xcc4 · returned 1
Figure 1: Unpacking the payload. 7z.exe extracts Saked (mika.exe) from the encrypted same.zip using the password stucha. Captured by the VMRay Platform function log.The batch script uses a random name for every sample (seen as 0x0rUvmjn.bat, KY81D8m.bat, CGZ6SaUIK.bat, 8Iy4vvg10.bat, and 1Dbw5oJHw.bat), which defeats file-name signatures while the logic underneath stays the same, and it carries an internal version and date tag (version 15.0, dated 2025-03-28) consistent with a maintained, reused tool. Before it acts, the script minimizes its own console window with NirCmd, checks for administrator rights by reading the LocalSystem registry hive, elevates through nircmd elevate if needed, and uses a lock file under %TEMP% to avoid running twice, all of which fits a design meant to finish its work quietly and only once.
The deletion engine is a legitimately signed IObit utility the operators abuse rather than code they wrote. The IObitUnlocker.exe staged on disk is the genuine, IObit-signed IObit Unlocker 1.6.0.16 (SHA-256 eaa9dc1c… [3], a signed product that is itself widely bundled inside unrelated malware), and the kernel driver it loads (IObitUnlocker.sys, SHA-256 1845fe85…) is the matching genuine IObit component. The operators use both unmodified, which is exactly what Bring-Your-Own-Vulnerable-Driver means: a real, signed but vulnerable driver that Windows trusts and loads. Saked unpacks the genuine IObit Unlocker, instructs its driver to do the deletion, and brands itself at runtime with the mutex Unlocker by Eject NotOfficial (“Eject” being the malware author’s handle). This driver is a known, abused tool, not a new discovery: the LOLDrivers project catalogs it [4], and Acronis reported it in Makop ransomware intrusions [5]. We attribute none of IObit’s code to the malware author; the operators’ own work is everything around it, namely the batch script, the Saked payload that unpacks and runs the tool, and the list of files to delete.
The four archives that deliver Saked each have a different SHA-256, yet all stage the same kit and issue the same /Delete /Advanced command. Because the payload is identical while the file hashes differ, we assess that the operators repackage the archive for each distribution, which is why tracking by file hash alone undercounts the family.
03
The Defense Destruction Routine
The script removes endpoint security in three layers: detect, disable, then delete.
First it finds which security components are present. It takes a snapshot of all running processes and checks it for named Microsoft Defender and Windows Security components (for example SmartScreen.exe, MsSense.exe, and SecurityHealthSystray.exe), and it queries the registry for the matching services (for example MsSecCore), recording each result in a status flag, as the VMRay function log in Figure 2 shows. The set it checks is the full Microsoft Defender and Windows Security stack: WinDefend, MsMpEng, MsSense, NisSrv, WdNisSvc, WdNisDrv, MpCmdRun, MDCoreService, MPSigStub, MsSecCore, MsSecFlt, MsSecWfp, WdBoot, WdFilter, SmartScreen, SgrmAgent and SgrmBroker (System Guard Runtime Monitor), wscsvc (Security Center), and webthreat. The deletion that follows is not limited to Microsoft Defender; it reaches every installed antivirus product it can find, along with backup, recovery, and update components.
VMRay Platform · function log
Monitored processes — discovery
PID
Reason
Integrity
Image
Command line
0xcd0
Child Process
High (Elevated)
find.exe
find /i “0x0”
0x5e0
Child Process
High (Elevated)
cmd.exe
C:\Windows\system32\cmd.exe /c tasklist
0xfd8
Child Process
High (Elevated)
tasklist.exe
tasklist
0x358
RPC Server
System (Elevated)
svchost.exe
C:\Windows\system32\svchost.exe -k netsvcs
0xb94
Child Process
High (Elevated)
reg.exe
reg query “HKLM\System\CurrentControlSet\Services\WinDefend”
0x49c
Child Process
High (Elevated)
reg.exe
reg query “HKLM\System\CurrentControlSet\Services\MDCoreSvc”
0xc18
Child Process
High (Elevated)
reg.exe
reg query “HKLM\System\CurrentControlSet\Services\WdNisSvc”
0x148
Child Process
High (Elevated)
reg.exe
reg query “HKLM\System\CurrentControlSet\Services\Sense”
0x730
Child Process
High (Elevated)
reg.exe
reg query “HKLM\System\CurrentControlSet\Services\MsSecCore”
0xb20
Child Process
High (Elevated)
7z.exe
7z x -aoa -bso0 -bsp1 “same.zip” -p stucha “mika.exe”
0xcf4
Child Process
High (Elevated)
mika.exe
mika.exe /CurrentDiskSize
The registry queries walk the full Defender and Windows Security service list; representative rows are shown.
Figure 2: The discovery queries the malware issues to detect the installed Microsoft Defender and Windows Security components, from the VMRay Platform function log.Next it disables the Windows Update services that would otherwise repair the system, running sc.exe stop and sc.exe config <service> start= disabled against wuauserv, dosvc, bits, UsoSvc, and WaaSMedicSvc (Figure 3). The Microsoft Defender components themselves are not disabled this way; they are deleted, which the final step covers.
Then the components are deleted from disk. The batch launches the Saked payload, which deletes the accessible files itself (Windows Update logs, CBS.log, the update DataStore) and then unpacks and launches IObit Unlocker to remove the protected ones, passing it one long list of targets. In the run we examined in full, a single IObitUnlocker.exe /Delete /Advanced command named 281 distinct files and directories and deleted its entire target list in one call. Those 281 targets fall into the categories below, with representative paths shown:
THE 281 DELETION TARGETS, BY CATEGORY
| Target Category |
Representative Targets |
| Microsoft Defender / Windows Security |
Program Files\Windows Defender, ProgramData\Microsoft\Windows Defender, Windows Defender Advanced Threat Protection, SecurityHealthService.exe, smartscreen.dll, drivers\wd, Microsoft Defender ETW loggers |
| Third-party antivirus |
ESET, McAfee, AVG, Avast, FortiClient, Dr.Web, Malwarebytes, Bitdefender, and Comodo product directories |
| Backup and recovery software |
Acronis, Macrium, EaseUS, AOMEI, Paragon, Active@, CloneApp |
| Windows Update |
SoftwareDistribution, update-orchestrator and delivery paths |
| System recovery and forensic logs |
WinSxS\Backup, wbem\Repository, config\RegBack, System Restore, OneDrive, Defender / CBS / WindowsUpdate logs |
Figure 3: Disabling the Windows Update services and launching the mass-delete function, from the VMRay Platform analysis report.
VMRay Platform · analysis report
Monitored processes — disable and delete
PID
Reason
Integrity
Image
Command line
0xf34
Child Process
High (Elevated)
sc.exe
sc stop wuauserv
0x2d0
Child Process
High (Elevated)
sc.exe
sc config wuauserv start= disabled
0xa68
Child Process
High (Elevated)
sc.exe
sc stop dosvc
0xfa8
Child Process
High (Elevated)
sc.exe
sc stop bits
0x898
Child Process
High (Elevated)
sc.exe
sc stop UsoSvc
0xcc8
Child Process
High (Elevated)
sc.exe
sc stop WaaSMedicSvc
0xae0
Child Process
High (Elevated)
sc.exe
sc config WaaSMedicSvc start= disabled
0xff8
Child Process
High (Elevated)
taskkill.exe
taskkill /f /im mika.exe
0x2f8
Child Process
High (Elevated)
mika.exe
mika.exe /DelWD
0xc48
Child Process
High (Elevated)
iobitunlocker.exe
IObitUnlocker.exe /Delete /Advanced “C:\ProgramData\Microsoft\Windows Defender”,”…”
The target list reaches well beyond Microsoft Defender. It covers at least nine commodity antivirus vendors, local backup tools, Windows Update, and recovery and forensic data, and it removes the host’s OneDrive cloud backup completely across 24 distinct paths, including the sync client, its scheduled tasks, and its updater. It does not touch enterprise EDR agents such as CrowdStrike or SentinelOne, which fits a commodity threat aimed at ordinary users rather than enterprises.
The protected targets are deleted through the kernel driver. Saked launches IObitUnlocker.exe, which opens the device \\.\IObitUnlockerDevice and passes each target to the driver with a DeviceIoControl call carrying control code 0x222124. For each target, the driver enumerates running processes and, for any process outside a hardcoded safe-list of core Windows processes (System, smss.exe, csrss.exe, wininit.exe, winlogon.exe, lsass.exe, lsm.exe, userinit.exe, explorer.exe, and IObitUnlocker.exe itself) that holds the file open, terminates it via ZwTerminateProcess and then force-deletes the file. Because this happens in the kernel, the driver can terminate even a protected, still-running process, such as a live Microsoft Defender service, that an ordinary user-mode program could not, and then delete the file it was holding open.
The BYOVD deletion path
Figure B. Saked drives the genuine, signed IObit driver through control code 0x222124. The driver terminates the locking process and force-deletes the target from kernel mode.
What remains is a host that cannot detect a later payload, repair itself through Windows Update, or restore from local backups or system-restore data. This degree of destruction has two readings that our telemetry does not let us separate: it is consistent with clearing the way for a serious follow-on intrusion, and it is equally the aggressive antivirus removal that ordinary commodity loaders perform to keep themselves alive. In the Saked droppers we saw no network communication, data encryption, data theft, ransomware module, or autostart persistence beyond the driver’s own service. The Amadey variant is the exception, with its own command-and-control server and persistence, covered in Section 4.
One variant adds NSudo before the deletion: the batch script of the archive 926ba1f8… runs through NSudo (NSudoLG -U:T -P:E -UseCurrentConsole), executing as TrustedInstaller with every privilege enabled. The others run without it, which points to small build-time differences around the same core.
The family’s main payload, in four of the six confirmed samples, is Saked, a .NET executable that runs the deletion. It is not an information stealer but a defense-removal tool; public scanners label it MSIL/KillProc. Four archives stage and run it, three of them launching it minimized with the /DelWD switch. It was compiled on 2025-10-17 and first submitted to public scanning on 2026-02-08. The batch runs it twice. The first run, in /CurrentDiskSize mode, is reconnaissance: it reads the running processes and queries host information through WMI (select * from Win32_ComputerSystem). The second run performs the deletion, in /DelWD mode, in three of the four samples; in one sample the first run deletes directly.
In that deletion run, Saked unpacks the IObit Unlocker tool it carries into %TEMP%\IObitUnlocker and launches IObitUnlocker.exe /Delete /Advanced with the full target list, so the deletion processes are its own children, as the VMRay function log in Figure 4 shows. It deletes the unprotected files itself with DeleteFileW (Windows Update logs, CBS.log, the update DataStore) and leaves the protected targets to the driver. It does not call the kernel terminate or the device I/O control directly; those belong to the IObit Unlocker driver, which Saked drives. Across all runs we cross-checked, it accessed no browser credential databases, DPAPI master keys, or other credential stores, which is why we class it as a deletion tool rather than a stealer.
VMRay Platform · function log
Figure 4: The mass deletion carried out by IObitUnlocker.exe /Delete /Advanced, listing hundreds of Microsoft Defender, antivirus, backup, and recovery paths, from the VMRay Platform function log.The Saked droppers showed no ransomware, data theft, or network activity of their own, so we did not observe the operators’ end objective. Wiping a host’s antivirus, backups, and recovery is the kind of groundwork that can precede several different goals: deploying ransomware, enrolling the machine into a botnet or loader network, dropping a cryptominer or an information stealer, or selling the cleared access on to another actor. We offer these as possibilities, not findings.
The same destruction kit also appears beneath payloads other than Saked, with only the packaging changed. The four Saked droppers wrap the payload in an archive named same.zip (password stucha). One sample, 926ba1f8…, instead wraps a near-identical deletion tool, Unlocker.exe, in DKTolz.zip (password DDK), and first elevates the batch script to TrustedInstaller using NSudo. Another, 23bedf93…, places an Amadey loader (game.exe) in front of the same kit. The pattern is consistent: the detect-disable-delete routine is a reusable layer that the operators slot under whichever payload they are distributing, most often Saked.
The Amadey variant is the one exception to the family’s otherwise quiet, local behavior. It carries an Amadey 5.55 loader configured to reach the command-and-control server 94.154.35[.]25/di9ku38f/index.php, to pull further executables from 130.12.180[.]43, 185.241.208[.]90, and 91.92.243[.]47, and to persist through a scheduled task. The Saked and NSudo droppers, by contrast, make no network connection and set up no persistence.
Beyond the confirmed set, the same import hash also appears on unrelated commodity families such as DCRat, Vidar, RedLineStealer, and LaplasClipper [1]. These are not related deliveries: the import hash comes from the shared WinRAR stub, so it cannot link samples. They only show how widely the same packaging is reused.
05
Why Public Feeds Miss the Link
Static identifiers group the archive with a large set of unrelated self-extractors instead of with its own family, because the file-level values that clustering relies on all come from the WinRAR stub.
Every sample carries the same import hash (12e12319…), Rich-header hash (5a0b7a24…), and compilation timestamp (2022-03-03 13:15:57 UTC). These come from the WinRAR self-extractor stub, not the actor’s code, and stay identical across every self-extractor built with this WinRAR version. A match on any of them only tells you the file is a WinRAR SFX of that version; it cannot link these samples to one another or tell them apart from any other WinRAR SFX. Open-source identification tools bear this out, classifying every sample identically as a WinRAR self-extractor built with the same compiler, and the 2022-03-03 stamp is the stub module’s own, consistent with the WinRAR 6.11 release of March 2022.
Pivoting on these shared identifiers in open-source records therefore just returns the whole commodity SFX population, unrelated families included, and inside that population the archives cannot be told apart by static features. The over-grouping is easy to demonstrate: the same fingerprint even appears on an unrelated downloader (SHA-256 7ba51d483de3af4beb94f4e1dc2ac2a24bcf3f1a8c921278645a0ba92c922565) that is not a self-extractor at all, carries a 1970-01-01 timestamp, and shares none of this family’s behavior. We treat it as a coincidental collision and exclude it.
The compilation timestamp also does not date the malware: because 2022-03-03 is the stub’s build date, it appears on samples first seen anywhere from 2023 to the present day. The payload’s own timestamp (2025-10-17) and first submission (2026-02-08) are the only reliable dates for it.
Public detections, finally, name the outer archive rather than the payload. A defender triaging on the family label alone sees a generic antivirus killer. That label signals that security software is being tampered with, but not the true scope: that the host’s Microsoft Defender, third-party antivirus, backups, and recovery data are all deleted outright. The destruction routine and the payload it carries are visible only when the sample runs.
Self-extracting archives carrying the shared stub appear in open-source records from April 2023 to the present day, so the packaging has been reused for years across commodity malware. The Saked payload itself is recent, compiled 2025-10-17 and first seen publicly 2026-02-08, with the archives that deliver it observed between February and May 2026.
We examined 10 unique samples drawn from 25 sandbox executions and confirmed the destruction template in six; the rest shared only the self-extractor stub. The open-source matches show the stub is widespread, but not how widespread the destruction template itself is.
07
Detection and Hunting Guidance
Hunt the behavior, not the static identity; matching on the import hash, Rich-header hash, or timestamp produces a high volume of false positives. The following behavioral indicators are specific to the destruction routine:
▪DeviceIoControl calls carrying I/O control code 0x222124 to the device \\.\IObitUnlockerDevice from a process that is not an interactive IObit Unlocker session.
▪IObitUnlocker.exe run with /Delete /Advanced and a command line listing Microsoft Defender, antivirus, backup, and Windows Update directories.
▪Extraction of 7z.exe, cecho.exe, nircmd.exe, and a password protected archive into one %TEMP% subfolder, launched by a randomly named batch script that also runs sc.exe config <service> start= disabled against the Windows Update services.
▪Bulk deletion of Microsoft Defender directories and ETW logger files (EtwRTDefenderApiLogger.etl, EtwRTDefenderAuditLogger.etl), followed by the payload launched minimized with the /DelWD switch (start "" /min <payload>.exe /DelWD).
▪Optional precursor: NSudo (NSudoLG -U:T -P:E) running the batch as TrustedInstaller just before the kit.
A YARA rule keyed to the self-extractor stub will match every commodity self-extractor, so it is a poor way to identify this family; a behavioral rule is far more reliable, keyed to the \\.\IObitUnlockerDevice device plus an IObitUnlocker.exe /Delete /Advanced command line that lists Microsoft Defender paths.
Blocking the driver is the strongest control, but make sure the block covers this build. The deletion relies on a signed but vulnerable kernel driver, which signature checks alone will not stop, so the control is a driver blocklist. Microsoft’s recommended vulnerable-driver blocklist already lists IObitUnlocker.sys [6] in two ways: by file name for versions up to 1.3.0.0, and by a set of specific file hashes. The build seen here reports version 1.6.0.16, above that file-name threshold, so the file-name rule alone may not catch it, and the blocklist’s hash entries or an updated rule need to cover the build in use. The list is enforced automatically when memory integrity (HVCI), Smart App Control, or App Control for Business is turned on; organizations should turn one on with the Microsoft recommended block rules, keep the list current, verify that any loaded IObit Unlocker driver matches a blocked hash, and alert on kernel driver loads from user-writable paths. A blocklist is necessary but not sufficient: it has to be paired with behavioral detection of the abuse itself.
08
Indicators of Compromise
We mark these shared file-level values as an over-clustering artifact, not an attribution indicator.
Shared static identity:
| Attribute |
Value |
| Import hash (imphash, MD5) |
12e12319f1029ec4f8fcbed7e82df162 (WinRAR SFX stub, build date 2022-03-03) |
| Rich-header hash (MD5) |
5a0b7a24cfc45ac734b73051b5669bf5 |
| Compilation timestamp |
2022-03-03 13:15:57 UTC (stub, not build date) |
| Self-extractor icon hash (dhash) |
9494b494d4aeaeac |
Self-extracting archives (confirmed by VMRay dynamic analysis, destruction template):
| SHA-256 |
Carried Payload |
VirusTotal First Submission |
| 2ff2c511b26796bdfa6befc3e8e155276b552e0c6844cbcd97f81e36ba0fe059 |
Saked (.NET; VT: MSIL/KillProc) |
2026-04-29 |
| 0c0a390d402a9abe37f738d83140bcc7683d4c2f6f23f55e359e6c72c5c6afba |
Saked (.NET; VT: MSIL/KillProc) |
not on VirusTotal |
| a6bbb6272992e3f72e3cde768353bfd4a0aa9f15bbc3dee33b43816683e08791 |
Saked (.NET; VT: MSIL/KillProc) |
not on VirusTotal |
| 32f4959794c2db90e50e8a1ab9710e4d172a943555c9e8d70ac63b533c28519f |
Saked (.NET; VT: MSIL/KillProc) |
2025-10-22 |
| 23bedf93a6f4c8a100c436f0f4acc0da311de886c08e15ec441f2cf60dc3b610 |
Amadey loader (VMRay / VirusTotal; C2 and persistence below) |
2025-08-10 |
| 926ba1f8efd8bba4ff2ab9d1aa0b0e6d112c66ddbe58feb2b4756c57e7433ed3 |
NSudo-elevated; delivers Unlocker.exe (works like mika) |
2025-05-15 |
Payload (Saked):
| Attribute |
Value |
| Saked (SHA-256) |
9163d41300fda804823a0032a205f1e4e38b90daf00fbfcff99161af80a6cedc |
| Function |
.NET tool that runs the deletion (unpacks and launches IObit Unlocker; deletes unprotected files via DeleteFileW; enumerates processes; queries host info via WMI; modes /CurrentDiskSize and /DelWD; no credential or data theft observed; public scanners label it MSIL/KillProc) |
| Compiled / First Submitted |
2025-10-17 / 2026-02-08 |
| Command-line Switch |
/DelWD |
Bundled driver (IObit Unlocker):
| Attribute |
Value |
| User Mode Component |
Genuine, IObit-signed IObit Unlocker 1.6.0.16, used unmodified (IObitUnlocker.exe, SHA-256 eaa9dc1c9dc8620549fee54d81399488292349d2c8767b58b7d0396564fb43e7) |
| Kernel Driver |
Genuine signed IObit driver it loads (IObitUnlocker.sys, SHA-256 1845fe8545b6708e64250b8807f26d095f1875cc1f6159b24c2d0589feb74f0c) |
| Device / Control Code |
\\.\IObitUnlockerDevice / 0x222124 |
| Watermark Mutex |
Unlocker by Eject NotOfficial, created at runtime by the Saked payload (not by the genuine IObitUnlocker.exe); “Eject” = malware author handle |
| Blocklist |
IObitUnlocker.sys is on Microsoft’s recommended vulnerable-driver blocklist |
| Prior Abuse |
Catalogued by LOLDrivers; reported in Makop ransomware intrusions (Acronis) |
| Reference |
CVE-2020-14974, CVE-2020-14975 (published against IObit Unlocker 1.1.2) |
Behavioral Indicators
| Behavioral Indicators |
|
| Device |
\\.\IObitUnlockerDevice |
| IOCTL |
0x222124 |
| Mutex |
Unlocker by Eject NotOfficial (created by Saked, not by the genuine IObitUnlocker.exe) |
| kernel-mode |
ZwTerminateProcess of processes locking the delete targets |
| The kit |
7z.exe / cecho.exe / nircmd.exe plus a password protected archive extracted to a %TEMP%\saked folder (Saked samples) |
|
Saked (modes /CurrentDiskSize and /DelWD) unpacking IObit Unlocker to %TEMP%\IObitUnlocker and launching IObitUnlocker.exe /Delete /Advanced |
|
sc.exe config <service> start= disabled against the Windows Update services wuauserv, dosvc, bits, UsoSvc, WaaSMedicSvc |
|
The payload launched minimized via start “” /min with the /DelWD switch. |
Amadey-loader variant 23bedf93… (additional indicators, this variant only):
| Attribute |
Value |
| Amadey C2 |
hxxp://94.154.35[.]25/di9ku38f/index.php (POST; Amadey v5.55) |
| Payload Download Servers |
130.12.180[.]43 (/files/<id>/<rand>.exe), 185.241.208[.]90/system.exe, 91.92.243[.]47/v3441.exe |
| Persistence |
Scheduled tasks HVqJBbEyt and ZmgfUQAQ.exe (time-triggered) |
| AV |
Antivirus |
| BYOVD |
Bring Your Own Vulnerable Driver |
| CVE |
Common Vulnerabilities and Exposures |
| ETW |
Event Tracing for Windows |
| HVCI |
Hypervisor-protected Code Integrity (memory integrity) |
| IOCTL |
Input/Output Control (code) |
| PE |
Portable Executable |
| SFX |
Self-Extracting Archive |
| VTI |
VMRay Threat Identifier (behavioral detection) |
| WMI |
Windows Management Instrumentation |
- MalwareBazaar records for import hash
12e12319f1029ec4f8fcbed7e82df162 (partial sample set reviewed), abuse.ch – Figthing malware and botnets.
- CVE-2020-14974 and CVE-2020-14975, IObit Unlocker 1.1.2 driver (
IObitUnlocker.sys), IOCTL 0x222124: low-privileged file unlock, delete, move, copy and termination of SYSTEM-owned processes. NVD: NVD – CVE-2020-14974. Original disclosure: theevilbit, CVE-2020-14974 & CVE-2020-14975 – IOBit Unlocker 1.1.2 – Local Privilege Escalation
- VirusTotal file record for SHA-256
eaa9dc1c9dc8620549fee54d81399488292349d2c8767b58b7d0396564fb43e7 (IObit Unlocker 1.6.0.16).
- LOLDrivers project, community catalog of vulnerable and malicious drivers (lists IObit Unlocker), LOLDrivers
- Acronis Threat Research Unit, “Makop ransomware, GuLoader, and privilege escalation in attacks against Indian businesses” (IObit Unlocker driver abused for defense evasion), Makop ransomware: GuLoader and privilege escalation in attacks against Indian businesses
- Microsoft recommended driver block rules, App Control for Business (the blocklist includes IObit Unlocker), Microsoft recommended driver block rules
