Windows Drivers Kill AV and EDR Before Ransomware

Windows Drivers Are Being Used to Kill AV and EDR Before Ransomware Deployment

Attackers are increasingly abusing signed but vulnerable Windows drivers to disable antivirus and endpoint detection and response tools before launching ransomware.

This technique is known as Bring Your Own Vulnerable Driver, or BYOVD.

The tactic is dangerous because it turns legitimate driver trust into an attacker advantage.

Windows drivers operate at a privileged level close to the kernel. If attackers can load a signed but vulnerable driver, they may gain the ability to terminate protected security processes, interfere with telemetry, disable endpoint defenses, and blind defenders before the final payload runs.

Recent ransomware operations have shown how serious this has become.

GentleKiller, Qilin, Warlock, Akira, and other threat groups have used vulnerable or abused Windows drivers to weaken endpoint security and prepare systems for encryption, data theft, or further compromise.

For enterprises, this is a critical warning.

An EDR agent is only useful if it remains running, protected, and visible when the attack begins.

What Happened:

Security researchers and incident responders have observed multiple ransomware and malware operations using Windows drivers to kill AV and EDR processes.

In these attacks, threat actors deploy signed drivers that Windows may trust because they were issued by legitimate vendors.

The problem is that some of these drivers contain vulnerabilities or unsafe functionality that attackers can abuse.

Once loaded, the driver can operate at kernel level.

That gives attackers more power than ordinary user mode malware.

They can terminate processes that are normally protected.

They can target security services.

They can interfere with sensors.

They can reduce visibility before deploying ransomware.

Recent reporting on GentleKiller shows a dedicated EDR killing framework used by a ransomware operation to disable more than 400 security related processes.

Other ransomware groups, including Qilin, Warlock, Akira, Reynolds, BlackByte, RansomHub, and Scattered Spider related activity, have also been linked to BYOVD style tactics in public reporting.

The trend is clear.

EDR killing is no longer a niche technique.

It is becoming a standard part of modern ransomware preparation.

Why This Issue Is Critical:

This issue is critical because endpoint security tools are often the last line of defense before ransomware runs.

EDR and AV tools monitor processes, detect malicious behavior, collect forensic telemetry, block payloads, isolate hosts, and alert security teams.

If attackers can disable those tools first, the rest of the intrusion becomes easier.

Ransomware operators want quiet execution.

They want to delete backups, steal data, spread laterally, disable protections, and encrypt systems before defenders respond.

BYOVD helps them do that.

Because the abused driver may be signed, Windows may allow it to load unless the organization has strong driver controls in place.

This creates a difficult security problem.

The driver may be legitimate.

The signature may be valid.

The behavior may still be malicious.

How BYOVD Works:

BYOVD attacks abuse the trust model around Windows drivers.

A driver is software that allows Windows and applications to interact with hardware or low level system functions.

Drivers often require high privileges because they operate close to the kernel.

Attackers take advantage of older drivers that were legitimately signed but later found to contain dangerous capabilities or vulnerabilities.

The attacker brings the vulnerable driver into the environment.

The driver is installed or loaded as a service.

Because it is signed, Windows may permit it to run.

The attacker then uses the driver’s vulnerable functionality to interact with kernel level objects, terminate processes, disable services, tamper with security tools, or support additional malicious activity.

This allows attackers to bypass some user mode protections.

The attack does not always require a new zero day.

In many cases, attackers reuse known vulnerable drivers that defenders have not blocked.

How the Attack Chain Could Work:

A realistic attack may begin after an attacker has already gained initial access through phishing, stolen credentials, VPN compromise, remote desktop exposure, software exploitation, or malware delivery.

The attacker performs reconnaissance and identifies the endpoint security stack.

The attacker drops a signed but vulnerable Windows driver onto the system.

The driver is installed as a service or loaded through a malicious loader.

The attacker sends commands to the driver.

The driver terminates AV and EDR processes.

Security telemetry is reduced or interrupted.

The attacker disables additional protections, clears logs, or prepares ransomware execution.

The ransomware payload runs with reduced interference.

Files are encrypted.

Data may already have been stolen before encryption begins.

By the time defenders receive alerts, the endpoint security stack may already be damaged or offline.

Why Kernel Level Access Matters:

Kernel level access matters because it sits below ordinary application security.

Most endpoint security tools include both user mode and kernel mode components.

User mode components handle interfaces, services, telemetry, cloud communication, and management functions.

Kernel mode components monitor lower level activity such as process creation, memory, file operations, registry access, driver loading, and system calls.

If attackers gain kernel level capability through a vulnerable driver, they can attack security tools from a powerful position.

They may terminate processes that normal malware cannot kill.

They may interfere with callbacks.

They may manipulate kernel objects.

They may reduce visibility before user mode tools can respond.

That is why BYOVD is so dangerous.

It gives attackers a way to fight defenders from inside the operating system’s most trusted layer.

Why Signed Drivers Are Abused:

Attackers abuse signed drivers because Windows uses driver signing as a trust control.

Unsigned drivers are harder to load on modern Windows systems.

A signed driver, especially one from a legitimate vendor, may be allowed to run.

This creates an opportunity.

If an old signed driver has a vulnerability or dangerous capability, attackers can bring that driver with them and use it as a weapon.

The signature does not mean the driver is safe forever.

It only means the driver was signed.

If vulnerable drivers remain allowed, attackers can exploit that trust gap.

That is why driver blocklists, HVCI, WDAC, and continuous driver monitoring are so important.

Organizations must treat vulnerable signed drivers as active threats.

Why This Incident Matters for Cybersecurity:

This trend matters because ransomware operators are professionalizing their defense evasion.

They are no longer relying only on simple process killing, PowerShell commands, or disabling services through ordinary administrative tools.

They are using kernel level techniques.

They are building dedicated EDR killer frameworks.

They are testing multiple drivers until one works.

They are targeting long lists of security products.

They are integrating EDR killing before ransomware deployment.

That changes the defensive requirement.

Organizations cannot assume that having EDR installed is enough.

They must verify that EDR cannot be disabled easily, that vulnerable drivers cannot load, and that driver load events are monitored in real time.

Endpoint protection must be resilient under attack.

Common Risks Highlighted:

This BYOVD trend highlights several common enterprise weaknesses.

Vulnerable driver blocklists may not be enabled.

Hypervisor protected code integrity may be disabled.

Windows Defender Application Control may not be deployed.

Users or attackers may be able to load drivers.

Security teams may not monitor driver installation events.

EDR tamper protection may be misconfigured.

Local administrator access may be too broad.

Ransomware operators may have enough privileges to install services.

Legacy hardware or software may require risky drivers.

Security tools may not alert quickly when their own processes terminate.

These weaknesses allow a vulnerable driver to become a direct path to blinding the security stack.

Potential Impact:

The potential impact can be severe.

Antivirus processes may be terminated.

EDR sensors may stop reporting.

Security telemetry may be interrupted.

Ransomware may execute without being blocked.

Incident responders may lose visibility.

Attackers may delete backups.

Data theft may continue unnoticed.

Lateral movement may become harder to detect.

Endpoint isolation may fail.

Forensic evidence may be incomplete.

The organization may discover the compromise only after encryption or extortion begins.

The greatest risk is not only that security tools are disabled.

The greatest risk is that defenders may not know they were disabled until it is too late.

What Organisations Should Do Now:

Organizations should treat vulnerable driver abuse as a ransomware readiness issue.

Enable Microsoft’s Vulnerable Driver Blocklist.

Use Hypervisor Protected Code Integrity where hardware and compatibility allow.

Deploy Windows Defender Application Control to restrict driver and executable loading.

Enable EDR tamper protection.

Monitor driver load events.

Alert on new kernel driver installation.

Review Sysmon Event ID 6 where Sysmon is deployed.

Monitor service creation events linked to driver loading.

Restrict local administrator privileges.

Audit systems for known vulnerable drivers.

Remove unnecessary legacy drivers.

Review endpoint security health continuously.

Test whether EDR agents remain protected during simulated tampering.

The goal is to prevent vulnerable drivers from loading and to detect attempts immediately.

Driver Security Controls to Prioritize:

Organizations should strengthen driver governance.

Maintain an inventory of loaded drivers.

Block known vulnerable drivers.

Restrict who can install kernel drivers.

Review driver signing and certificate trust.

Use WDAC policies to control driver execution.

Enable memory integrity where possible.

Keep Windows systems updated.

Remove unsupported hardware utilities.

Audit endpoint management tools that install drivers.

Review security vendor guidance for tamper protection.

Monitor for driver names associated with known EDR killer tooling.

Driver control should not be treated as a niche hardening task.

It is now a ransomware defense requirement.

Detection and Monitoring Strategies:

Security teams should monitor for behavioral indicators of BYOVD.

Alert on unusual driver loads.

Monitor service creation events where the service type indicates a kernel driver.

Detect suspicious drivers written to temporary directories, user profiles, program data, or unusual paths.

Watch for security process termination after a driver load.

Alert when EDR or AV services stop unexpectedly.

Monitor for attempts to disable tamper protection.

Detect command line activity involving service creation, driver installation, or kernel service manipulation.

Review Windows event logs, Sysmon logs, EDR telemetry, and security product health signals.

Correlate driver load activity with ransomware staging behavior.

The most important signal is sequence.

A suspicious driver load followed by security process termination is a high risk pattern.

Incident Response Guidance:

If BYOVD activity is suspected, responders should act immediately.

Isolate affected endpoints.

Preserve memory and disk evidence where possible.

Collect driver files, hashes, service names, command lines, event logs, EDR health data, and process termination records.

Identify when the driver was loaded.

Determine which security tools were terminated.

Review whether ransomware, credential theft, lateral movement, or data exfiltration followed.

Hunt for the same driver across the environment.

Block the driver through policy.

Remove persistence mechanisms.

Rotate credentials if the attacker had administrative access.

Review backups and recovery readiness.

Do not assume that one endpoint is the only affected system.

BYOVD tools are often deployed during broader ransomware operations.

Penetration Testing Insight:

From a penetration testing perspective, BYOVD highlights why defensive validation must go beyond malware execution.

A strong assessment should test whether vulnerable drivers can be loaded.

It should validate whether driver blocklists are active.

It should assess whether EDR tamper protection works.

It should determine whether local administrator rights are excessive.

It should test whether security teams detect suspicious driver load events.

It should simulate security process termination attempts in a controlled way.

It should verify whether alerts fire when endpoint protection stops reporting.

Modern penetration testing should answer one practical question.

If an attacker tries to kill EDR before deploying ransomware, will the organization block it, detect it, or only discover it after encryption starts?

Expert Insight:

James Knight, Senior Principal at Digital Warfare, said:

“BYOVD turns legitimate Windows trust into an attacker weapon. A signed driver can still be dangerous if it gives attackers kernel level control. Organizations must block vulnerable drivers, monitor driver load events, and prove that EDR cannot be silently killed before ransomware runs.”

What Security Leaders Should Prioritize:

Security leaders should treat Windows driver abuse as a high priority ransomware defense issue.

The immediate priority is blocking known vulnerable drivers and monitoring driver loads.

The broader priority is proving that endpoint protection remains resilient during active tampering.

Leaders should ask clear questions.

Is Microsoft’s Vulnerable Driver Blocklist enabled?

Is HVCI enabled on compatible endpoints?

Do we use WDAC or equivalent application control?

Can users or attackers install kernel drivers?

Can we detect new driver loads in real time?

Can we alert when AV or EDR processes stop?

Can we identify security product health failures quickly?

Have we tested EDR tamper protection?

Can we hunt for known BYOVD drivers across the environment?

If teams cannot answer these questions quickly, the organization has an endpoint resilience gap.

Call to Action:

Organizations should not assume that EDR alone will stop ransomware.

Attackers are now using signed but vulnerable Windows drivers to kill AV and EDR tools before encryption begins.

Block vulnerable drivers, enforce driver control, monitor kernel driver loads, restrict administrator privileges, and validate that endpoint security remains alive under attack.