When Trusted Windows Drivers Become Weapons Against Your Security

Have you ever considered that the software your business trusts could be used to disable the very security tools protecting it?

That is what investigators at Beazley Security uncovered in an INC ransomware intrusion reported on September 23, 2026. Attackers deployed four different vulnerable-driver toolkits to interfere with endpoint security and concealed a malicious backdoor inside a modified security software library.

The business concern is straightforward: A trusted Windows component can become an attacker’s tool, and having EDR installed does not guarantee it will remain effective during an intrusion.

Key Takeaway: Attackers can exploit legitimate but vulnerable Windows drivers and familiar software components to undermine endpoint defenses. Organizations need vulnerable-driver protection, hardened Windows configurations, and prevention controls that restrict damaging behavior even when an attack avoids detection.

So what exactly happened in this ransomware attack?

An INC ransomware affiliate gained access through a deceptive ClickFix infection, stole credentials, moved between systems, and attempted to disable endpoint security using multiple vulnerable drivers.

According to Beazley Security’s September 23 investigation, the intrusion began when a user encountered malicious website content and was tricked into executing a PowerShell command. The attackers then attempted to expand access using stolen credentials, remote desktop connections, and other Windows capabilities.

Beazley identified four distinct Bring Your Own Vulnerable Driver (BYOVD) toolkits deployed during the same intrusion. They included vulnerable drivers associated with anti-cheat and antivirus software, a Huawei audio driver, and an EDR-disabling toolkit Beazley described as apparently novel.

Investigators also found a backdoor inside a modified SentinelOne software library. The attackers preserved recognizable characteristics of the original file while removing its valid digital signature. The incident illustrates how criminals can repurpose legitimate technology to undermine defenses.

What does Bring Your Own Vulnerable Driver actually mean?

Bring Your Own Vulnerable Driver, or BYOVD, is an attack technique in which criminals introduce or exploit a legitimate but vulnerable device driver to gain powerful access inside Windows.

A driver acts as an intermediary between Windows and hardware or other low-level system functions. Drivers can run with privileges ordinary applications do not have. If a driver has an exploitable weakness, attackers may abuse those privileges to perform actions Windows would normally restrict.

A driver can be legitimately signed and still be vulnerable. A digital signature helps establish origin and integrity; it does not prove that software is free of security flaws.

In this intrusion, attackers used vulnerable drivers to interfere with endpoint security components. Rather than merely evading every detection rule, they were trying to impair the detection system itself.

Why is this especially dangerous for businesses relying on EDR?

Endpoint Detection and Response (EDR) remains important, but its effectiveness depends on the integrity and continued operation of the software performing detection and response.

Beazley described an EDR-disabling utility targeting security products including Microsoft Defender, SentinelOne, Bitdefender, Kaspersky, and others. It was designed to interfere with important functions inside security drivers.

If an attacker can impair security software, an organization may lose visibility precisely when responders need it most. That creates opportunities for further credential theft, persistence, lateral movement, data theft, or ransomware deployment.

For business leaders, the potential impact is interrupted operations, inaccessible files, recovery expenses, and prolonged downtime. The lesson is not that EDR is ineffective. It is that detection tools themselves can be attacked and should not be the only endpoint defense.

How did attackers hide a backdoor inside familiar security software?

Investigators found malicious code in a modified SentinelOne DLL, a software library normally associated with legitimate security functionality. The altered file retained recognizable attributes but was no longer validly signed.

Beazley reported that Windows Defender did not identify the implant as malicious in this incident. Investigators associated the backdoor with activity including downloading file utilities, changing firewall rules, and using cloud storage infrastructure for data exfiltration.

The important distinction is that a familiar filename or vendor association should not automatically confer unrestricted trust. Businesses need to consider what software is allowed to do, not only whether its appearance seems legitimate.

Can these attacks be stopped without identifying every malicious file?

Some damaging actions can be prevented without first naming the malware, provided appropriate preventive controls are configured and enforced.

This intrusion required actions such as executing commands, establishing persistence, accessing credentials, moving between systems, loading drivers, interfering with EDR, and reaching sensitive data. Attackers can change their drivers, scripts, or delivery methods, but many of the endpoint actions needed to succeed remain recognizable.

What if you did not have to detect the attack in order to stop it?

Isolation and Containment establish boundaries around applications and sensitive Windows resources. Properly configured controls can constrain unexpected process behavior, restrict access to protected resources, and reduce opportunities for persistence, unauthorized file modification, or ransomware encryption.

AppGuard is an endpoint protection solution with more than a decade of production history focused on prevention through Isolation and Containment. Its approach restricts out-of-bounds endpoint behavior without requiring every attack to be identified by name or signature.

No containment technology can guarantee prevention of every BYOVD exploit or kernel-level compromise. Driver-blocking policies, platform protections, privileged-access restrictions, and system hardening remain essential. Detection and response still matter, but they should work alongside prevention.

What Should Businesses Do Next?

• Verify vulnerable-driver protection. Confirm Microsoft’s vulnerable driver blocklist is enabled and maintained on supported workstations and servers.
• Harden Windows. Evaluate Memory Integrity (HVCI) and Microsoft App Control for Business, testing compatibility before enforcement.
• Layer driver defenses. Consider Microsoft’s Attack Surface Reduction rule for vulnerable signed drivers, alongside policies that prevent blocked drivers from loading.
• Protect security tools. Use available tamper protection, limit administrative privileges, and investigate unexpected EDR service or driver changes.
• Reduce endpoint execution freedom. Apply application guardrails and Isolation and Containment where appropriate.
• Address ClickFix risks. Train staff to recognize fake verification prompts and unexpected instructions to run commands.
• Plan for security-tool failure. Test endpoint isolation, evidence preservation, backups, recovery, and operations when EDR telemetry is unavailable.

MSPs should validate these protections across customer environments rather than assume that every device in a standardized EDR deployment has identical resilience.

What is the bigger lesson from this attack?

The INC ransomware investigation shows that attackers do not always need entirely new malware to undermine defenses. They may exploit weaknesses in software Windows already recognizes as legitimate.

Four vulnerable-driver toolkits appearing in one intrusion demonstrate why organizations should prepare for multiple methods of impairing endpoint security. The question is not just whether security software is installed. It is whether essential controls can withstand tampering, and what limits damaging activity when a control fails.

Unknown does not automatically mean unstoppable. The objective is not to predict every attack. It is to restrict the actions an attacker needs in order to succeed.

For additional perspective, read ClickFix: When a Browser Fix Puts Business Access at Risk, which explores the social-engineering technique seen early in this intrusion.

Sources and further reading: Beazley Security investigation and Microsoft recommended driver block rules.