Reynolds ransomware shows how BYOVD breaks endpoint defenses

At a glance

What this is: This is a threat research post on Reynolds ransomware and its Bring Your Own Vulnerable Driver pattern, which uses NSecKrnl.sys to disable endpoint defenses before encryption.

Why it matters: It matters because kernel-level defense evasion can make standard endpoint controls, detection timing, and incident containment much less effective for both security teams and identity-led control validation.

Context

Reynolds ransomware shows how Bring Your Own Vulnerable Driver abuse can turn a signed driver into a defense-evasion path. The practical issue is not just encryption, but the ability to reach kernel-level execution before endpoint controls can respond.

For identity and access teams, the governance question is whether high-trust execution paths, driver loading, and privileged process termination are being treated as part of the control surface. If those paths are invisible or unvalidated, an attacker can reshape the endpoint before detection has value.

This is a ransomware case, but the lesson extends beyond malware families. Any programme that assumes endpoint protection can be relied on after a privileged driver loads is starting from an unsafe premise.

Key questions

Q: What breaks when a vulnerable signed driver is loaded on an endpoint?

A: The normal trust boundary breaks because the attacker gains a kernel-level path that can bypass user-mode restrictions and interfere with endpoint protections. In practice, that means process termination, control tampering, and stealthier execution become possible before conventional alerts can react.

Q: Why does BYOVD abuse increase ransomware impact so quickly?

A: BYOVD abuse moves the attacker into a privileged layer that can disable monitoring and accelerate encryption before defenders have a chance to intervene. Once AV and EDR are terminated, the environment loses much of the visibility it needs for timely containment.

Q: What are the signs that Conti ransomware activity is progressing from initial access to impact?

A: The warning signs include suspicious authentication activity, brute-force attempts against RDP, unusual use of remote monitoring tools, malware staging on hosts, unexpected network scans of routers or storage devices, and abnormal outbound transfer activity. If those signals appear together, the environment may already be in the pre-exfiltration or pre-encryption phase and needs immediate containment.

Q: How should incident teams respond when ransomware kills AV or EDR processes?

A: Isolate the host immediately, preserve volatile evidence, and treat the endpoint as potentially untrustworthy at kernel level. The priority is containment and triage before the encryption routine finishes spreading to local and network storage.

Technical breakdown

How BYOVD turns a signed driver into kernel execution

Bring Your Own Vulnerable Driver, or BYOVD, means an attacker loads a legitimate but flawed kernel driver to execute privileged operations. In this case, Reynolds embeds NSecKrnl.sys, drops it to disk, and uses crafted IOCTL requests to reach code paths that normal user-mode processes cannot touch. Once the driver is loaded, the malware no longer depends on pre-existing vulnerable software on the host. That matters because kernel-mode access changes the control boundary: user-mode detections, standard process restrictions, and ordinary application telemetry all become weaker signals.

Practical implication: validate driver-loading controls and block known vulnerable kernel drivers before they can be used as an execution bridge.

Why endpoint protections fail after kernel-level access is obtained

Once the malware has kernel access, it can terminate targeted AV and EDR processes directly. The article describes process enumeration, dynamic API resolution, and driver-assisted termination as part of that sequence, which reduces the chance that endpoint tools can observe or interrupt the encryption phase. This is a classic defense-evasion problem: the protective stack is present, but the attacker has reached a layer that can interfere with its execution. In that state, the issue is not detection tuning alone, but whether the security stack can still trust its own runtime environment.

Practical implication: treat kernel-level process termination as a detection and containment event, not just a malware symptom.

How the encryption phase maximises operational impact

After defenses are neutralized, Reynolds enumerates local and network drives, uses multithreading to speed up file processing, and applies selective encryption to maximise corruption while preserving system stability. It also abuses Restart Manager to unlock files that are in use, which increases the chance that shared data and active documents are encrypted quickly. The combination of drive discovery, file unlocking, and hybrid encryption turns a single compromised endpoint into a broader storage-impact event. That is why time-to-encryption, not just infection time, becomes the decisive metric.

Practical implication: monitor for rapid drive enumeration, file unlock behaviour, and burst encryption patterns as pre-impact signals.

Threat narrative

Attacker objective: The attacker seeks to neutralize endpoint defenses long enough to encrypt local and network data and force ransom-driven recovery.

1. Entry begins when the ransomware drops an embedded vulnerable driver and loads NSecKrnl.sys onto the host.
2. Privilege escalation follows when crafted IOCTL requests exploit CVE-2025-68947 to obtain kernel-level access.
3. Escalation continues as the malware terminates AV and EDR processes and suppresses the normal detection surface.
4. Impact occurs when the ransomware encrypts files across local and network drives and drops ransom instructions.

Breaches seen in the wild

• JADEPUFFER agentic ransomware 2026: The first documented agentic ransomware used harvested keys, default MinIO credentials and a default Nacos signing key to wipe a database.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

BYOVD is a governance failure of trust in kernel provenance: organisations often treat a signed driver as a trusted runtime component, even when that driver can be weaponised. Reynolds shows that the trust decision cannot stop at signature validation if the binary can still be abused for privileged operations. The implication is that driver provenance and driver allowlisting are not niche hardening tasks but core endpoint governance requirements.

Defense evasion becomes the primary risk once execution reaches kernel mode: the article shows that AV and EDR termination is not a side effect, but the enabling step that makes encryption viable. Once the malware can interfere with its own monitors, the endpoint no longer presents a reliable control environment. Practitioners should treat kernel-mediated process killing as a control boundary breach, not just an alert-worthy event.

High-speed ransomware changes the meaning of response time: Reynolds combines multithreaded encryption, network-share discovery, and file unlocking to compress the window between compromise and impact. That means containment logic built around slower user-mode malware assumptions will underperform. Security teams need to evaluate whether their alerting, isolation, and response workflows still work when the attacker can move from driver load to encryption in one short chain.

Signed-driver abuse creates an identity-adjacent trust problem, not just a malware problem: kernel execution depends on a privileged software identity that the operating system is willing to honour. When that trust is reused for malicious purpose, the programme must question which runtime identities are still implicitly trusted after load. The practical conclusion is to govern driver trust as part of endpoint identity and privilege control, not as a separate platform concern.

What this signals

Kernel-level defense evasion is the real inflection point: once a ransomware family can load a vulnerable driver, the usual endpoint controls no longer govern the runtime environment in the same way. That shifts the programme question from malware detection alone to whether privileged software trust is actually being enforced.

Control validation has to happen before the first encryption burst: this pattern shows why timing matters as much as control coverage. If detection arrives after AV termination and drive enumeration, the response path is already behind the attacker.

Signed driver trust should be treated as part of endpoint identity governance: the runtime is only as safe as the privileged binaries it is willing to execute. Practitioners should expect more ransomware to target that trust layer because it shortens the path to impact.

For practitioners

• Harden vulnerable-driver governance Inventory signed drivers that can be loaded on managed endpoints and block known vulnerable kernel drivers from execution paths wherever the platform supports it.
• Watch for kernel-level defense evasion Alert on sudden termination of AV and EDR processes, especially when it follows driver loading, IOCTL activity, or unusual device handle access.
• Correlate pre-encryption behaviours Tie together driver events, process enumeration, rapid file rename activity, and network-share enumeration so the first-stage symptoms are visible before mass encryption starts.
• Validate containment against fast encryption Test whether host isolation, endpoint kill switches, and SOC triage still work when the attacker can encrypt local and remote drives at high speed.

Key takeaways

• Reynolds ransomware demonstrates that a vulnerable signed driver can be enough to collapse endpoint defenses before encryption begins.
• The article shows a full pre-impact chain, from driver loading to AV and EDR termination to multi-drive encryption.
• Defenders need visibility and control at the driver trust layer, because once kernel access is obtained, ordinary response assumptions weaken quickly.

Key terms

• Bring Your Own Vulnerable Driver (BYOVD): A technique where an attacker loads a legitimate but vulnerable signed driver to gain capabilities that normal user-mode malware does not have. The driver becomes an enforcement bypass, letting the attacker perform privileged actions such as process termination, memory manipulation, or defense evasion from kernel space.
• Kernel-level defense evasion: A defensive blind spot created when malware operates with kernel privileges and can interfere directly with security tooling. In practice, it means detection, blocking, and response components can be disabled or blinded before they can finish their own work.
• Device Trust Boundary: The device trust boundary is the point where an endpoint is considered sufficiently verified to access systems, data, or services. It defines the security line between trusted and untrusted device states, based on posture, identity, integrity, and policy. In practice, it governs whether a device can authenticate, connect, or receive sensitive access.
• DeviceIoControl abuse: Misuse of a Windows interface that sends control codes to a driver. When malware uses it with crafted requests, it can instruct kernel components to perform privileged actions such as process termination or system manipulation without using ordinary application APIs.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.