MEDUSA Ransomware Evolves: How the ABYSSWORKER Driver Disables Your Security

Three beliefs that ABYSSWORKER was built to exploit, next to what is actually true.

The gap between what a Houston business assumes its endpoint security does and what MEDUSA's ABYSSWORKER driver actually does to it is where this attack lives. Close that belief gap first, and the technical defenses follow.

Here is the contrast. On the left is the comfortable version most owners carry: the security stack is bought, installed, and therefore handled. On the right is what Elastic Security Labs documented actually happening once MEDUSA is on the machine.

The myth that endpoint protection is a finish line, and the driver that walks past it.

EDR does not stop MEDUSA ransomware on its own, because MEDUSA's ABYSSWORKER driver is designed to disable EDR before encryption starts. An endpoint tool that has been switched off at the kernel level cannot detect, block, or alert on the attack it was bought to stop.

The belief goes like this: we invested in endpoint detection and response, the agent is green on every machine, so ransomware gets caught the moment it runs. That was a reasonable assumption a few years ago. MEDUSA's operators built ABYSSWORKER specifically to break it. Elastic Security Labs documented the driver being deployed to blind security products, then the ransomware runs against a machine that is no longer watching.

ABYSSWORKER does this at the kernel, the most privileged layer of Windows, where a driver can reach in and disable the tools running above it. According to the Elastic analysis, it removes the notification callbacks that EDR products register to watch process and file activity, replaces the working parts of targeted security drivers with empty placeholder functions, detaches the minifilter that many tools rely on, and terminates security threads outright. By the time encryption begins, the EDR is a green icon reporting nothing.

• The tool is neutralized, not evaded. ABYSSWORKER does not sneak past detection. It reaches down and switches detection off, so there is nothing left to sneak past.
• Kernel access beats user-level defenses. A driver loaded into the kernel operates below the security software, which is exactly why disabling it from there works.
• Green does not mean protected. An agent can show as healthy while its callbacks have been stripped, so the dashboard lies right up until the ransom note.

Why a valid signature is not proof of a safe driver, and how ABYSSWORKER abuses one.

A signed driver is not automatically a safe driver. ABYSSWORKER is signed with likely stolen, revoked certificates from Chinese companies, which lets it load into the Windows kernel and pose as a legitimate CrowdStrike Falcon driver while doing the opposite of what a security driver should.

Windows heavily favors signed drivers, and for good reason: a signature is supposed to prove the driver came from a known publisher. Attackers learned to turn that trust into a weapon. Elastic Security Labs found that every ABYSSWORKER sample was signed using revoked certificates traced to Chinese companies, and the malicious file, named smuol.sys, was dressed up to imitate CrowdStrike's legitimate Falcon driver, complete with convincing metadata.

This is the signed-driver twist on a technique the industry calls "bring your own vulnerable driver," or BYOVD. In a classic BYOVD attack, the criminal loads a genuine but flawed driver and abuses its bug. ABYSSWORKER skips that step: it is a purpose-built malicious driver that carries its own signature, so it does not need a vulnerable third-party driver to get into the kernel. The lesson for a Houston business is that "it is signed" and "it is safe" are two different claims, and MEDUSA proved it.

• A signature proves origin, not intent. Even a valid signature only tells you who signed a driver, not whether the driver is going to protect you or attack you.
• Stolen and revoked certificates still load. Unless certificate revocation and a driver blocklist are actively enforced, a driver signed with a bad certificate can still reach the kernel.
• Impersonation is part of the play. Naming the file to look like a CrowdStrike component is designed to make an analyst glance past it, which is why behavior matters more than the label.

The myth of the loud alarm, and why ABYSSWORKER makes the attack quiet.

Most small businesses would not see a MEDUSA attack coming, because the whole point of ABYSSWORKER is to remove the signals that would warn you. When the driver strips EDR callbacks and terminates security processes, the alerts that were supposed to fire never do.

The comforting version says an attack this serious would be obvious, that something would light up and give you time to react. ABYSSWORKER is engineered to make that false. Once it is active, it does not just hide the ransomware; it dismantles the reporting. There is no flood of alerts because the thing that generates alerts has been taken apart.

In practice, the businesses we see get hurt most by this in the Houston area are the ones running a single endpoint product with nobody watching the results. A tool with no human or managed service behind it can be silenced without anyone noticing until the files are encrypted. Detection that survives this attack looks at behavior from outside the endpoint: the driver install itself, the security agent suddenly going quiet, a device object appearing where none should be. That kind of monitoring, and the CISA-recommended step of enforcing a vulnerable-driver blocklist, is what turns a silent attack back into a loud one.

• No alerts is not the same as no attack. Silence after ABYSSWORKER runs is the symptom, not the all-clear, and a quiet dashboard deserves suspicion.
• Watch the security tool itself. An EDR agent that stops reporting, or a driver load that precedes it, is the tell that outside monitoring catches.
• Block the driver before it loads. Enforcing the Microsoft vulnerable-driver blocklist and application control, as CISA advises, stops the loader at the door.