
Medusa ransomware ransom note | Image: Unit 42
Elastic Security Labs has been closely monitoring a financially motivated campaign leveraging MEDUSA ransomware, delivered through a HEARTCRYPT-packed loader. This loader deploys ABYSSWORKER, a driver signed with a revoked certificate from a Chinese vendor. Once installed on a victim’s machine, ABYSSWORKER is used to target and disable various EDR vendors.
The report highlights the initial discovery of this EDR-killer driver by ConnectWise in a separate campaign, noting its capabilities at the time. However, Elastic Security Labs provides an in-depth analysis of the driver’s features and techniques, offering Relative Virtual Addresses (RVAs) and a client example for further research.
This driver, masquerading as a legitimate CrowdStrike Falcon driver (smuol.sys), leverages revoked certificates from Chinese vendors, many of which are “widely known and shared across different malware samples.”

Notable Signed Certificates:
- Foshan Gaoming Kedeyu Insulation Materials Co., Ltd.
- Shenzhen Yundian Technology Co., Ltd.
- Changsha Hengxiang Information Technology Co., Ltd.
ABYSSWORKER employs lightweight but clever obfuscation:
- Functions that always return constants to complicate static analysis.
- Opaque predicates scattered across the code.
- Brute-force iteration over process and thread IDs to strip handles and inject protection.
“These constant-returning functions are called repeatedly throughout the binary to hinder static analysis… We can easily identify them, making this an inefficient obfuscation scheme.”
Once loaded, ABYSSWORKER registers callbacks and begins silencing EDR systems by:
Protecting Processes
- Stripping handles from other processes.
- Denying future access via ObRegisterCallbacks.
Wiping Traces
- Removing notification callbacks (e.g., PsSetCreateProcessNotifyRoutine).
- Removing mini-filter drivers like FltMgr.sys.
- Replacing other drivers’ major functions with
IopInvalidDeviceRequest
.
“Blinding EDR using these methods deserves a whole blog post of its own… but we invite the reader to explore these techniques in EDRSandblast and RealBlindingEDR.”
ABYSSWORKER accepts IOCTL commands with a hardcoded password to unlock its full potential. Among its tools:
IOCTL Command | Functionality |
---|---|
0x222080 |
Authenticate with password |
0x2220C0 |
Load kernel APIs |
0x222180 / 0x222184 |
Copy / delete files using raw IRPs |
0x222144 / 0x222140 |
Terminate process or thread by PID/TID |
0x222404 / 0x222440 |
Replace or detach driver/device components |
0x222408 |
Kill system threads tied to a module |
0x222664 |
Force system reboot from kernel mode |
“To reboot the machine, this handler uses the undocumented function HalReturnToFirmware.”
Elastic provides a sample client implementation that demonstrates how to enable ABYSSWORKER and load APIs. While not comprehensive, it’s “used to debug it,” and “motivated readers… can extend it.”
ABYSSWORKER reflects a broader trend: weaponizing kernel-level access to blind defenses. By mimicking legit drivers, hiding with revoked certificates, and directly manipulating Windows internals, it effectively slips past EDR and persists through reboot.
Organizations should:
- Block known certificates used by ABYSSWORKER.
- Monitor for suspicious driver installs (\\device\\czx9umpTReqbOOKF).
- Harden EDR tools against driver-function overwrites and callback deletions.