Reynolds ransomware shows how BYOVD breaks endpoint defenses

At a glance

What this is: Reynolds ransomware abuses a signed vulnerable driver to reach kernel mode, disable endpoint defenses, and accelerate encryption across local and network storage.

Why it matters: This matters because it shows how privilege, driver trust, and detection assumptions fail when malware can operate below normal endpoint controls, which affects NHI, PAM, and broader containment design.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Gurucul's analysis of Reynolds ransomware and BYOVD abuse

Context

BYOVD, or Bring Your Own Vulnerable Driver, is a defence-evasion technique where malware loads a legitimately signed but vulnerable driver to operate with kernel privileges. In this case, Reynolds ransomware uses NSecKrnl.sys to bypass normal user-mode restrictions and interfere directly with endpoint protection processes. The primary issue is not encryption alone, but the collapse of trust in driver handling and local control enforcement.

For identity and access teams, this is a machine-identity problem as much as a ransomware problem. Signed drivers, service execution, privileged process control, and endpoint protection dependencies all sit inside the same access boundary, so once kernel trust is abused, ordinary monitoring and response windows shrink sharply.

The starting position is typical of modern ransomware tradecraft, not exceptional. Attackers increasingly chain legitimate components, hidden privilege paths, and defensive blind spots to create a pre-encryption window where controls are present in theory but ineffective in practice.

Key questions

Q: What breaks when ransomware can load a vulnerable signed driver?

A: Endpoint trust breaks down because the malware can move from user mode into kernel mode while still appearing to use a legitimate driver. At that point, ordinary AV and EDR controls are easier to disable than to defend. The practical result is a much smaller response window before encryption starts.

Q: Why do vulnerable drivers make ransomware more dangerous than file encryption alone?

A: Vulnerable drivers let attackers disable the very tools meant to detect them, so the ransomware can operate with reduced interference. That increases dwell time, speeds up encryption, and makes containment harder. In practice, the driver abuse is what turns a manageable event into a high-impact outage.

Q: How can security teams tell driver abuse from ordinary software activity?

A: Look for a new driver load followed by process termination, security service stoppage, unusual API resolution, and rapid file modifications from the same host. Legitimate software rarely chains those behaviours together. The most useful signal is the sequence, not any one event on its own.

Q: Who is accountable when a trusted driver is abused to disable defenses?

A: Accountability usually spans endpoint engineering, vulnerability management, and security operations because the failure sits at the boundary between code trust and runtime control. The governance issue is not only who patched the driver, but who maintained visibility into what privileged components were allowed to load and run.

Technical breakdown

How BYOVD abuse turns a signed driver into kernel access

Bring Your Own Vulnerable Driver works because Windows still trusts many signed drivers at load time, even when the driver contains known flaws. Reynolds drops NSecKrnl.sys, loads it locally, and uses crafted IOCTL calls to make the driver perform privileged actions on its behalf. That shifts the malware from user mode, where endpoint tools can observe and block more easily, into kernel mode, where it can issue termination and control operations with far fewer constraints. The key technical problem is not just code execution, but the abuse of a trusted kernel interface as an enforcement bypass.

Practical implication: block known-bad and vulnerable drivers before load, not after process creation.

Why kernel-mode process termination defeats AV and EDR visibility

Once kernel access is achieved, the ransomware targets security processes directly, including AV and EDR services. It does this through device object communication and driver-assisted termination rather than ordinary task management, which means the defensive tooling is attacked from beneath its own privilege boundary. That matters because endpoint controls are usually designed to detect suspicious user-space behaviour, not a trusted driver removing them. The result is a sharply reduced response surface just before encryption begins, which is why defence evasion is the central operational objective here.

Practical implication: monitor for driver loads and service stoppage together, because either event alone can miss the real attack stage.

How multi-threaded encryption and network share discovery raise blast radius

Reynolds does not stop at local files. It enumerates drives, resolves network shares, and creates multiple worker threads based on CPU count so encryption happens quickly across both local and remote storage. It also uses Restart Manager to unlock files that are in use, which reduces friction around active documents and databases. The architectural point is that ransomware now behaves like a storage workflow engine as much as a payload, optimising throughput, file lock handling, and shared-drive targeting to maximise impact before defenders recover control.

Practical implication: segment network shares and watch for sudden drive enumeration plus rapid rename-and-write bursts.

Threat narrative

Attacker objective: The attacker wants to disable endpoint resistance long enough to encrypt as much accessible data as possible and increase ransom leverage.

1. Entry begins with the ransomware package dropping an embedded vulnerable signed driver and loading it on the host as a trusted kernel component.
2. Escalation occurs when crafted IOCTL requests abuse CVE-2025-68947 to gain kernel-level execution and terminate AV and EDR processes.
3. Impact follows as the malware enumerates local and network drives, unlocks files, and performs multi-threaded encryption while defenses are impaired.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Kernel trust is the real attack surface here: Reynolds succeeds because endpoint trust models still assume that a signed driver is safe enough to load. That assumption fails when the driver is vulnerable and the payload is designed to command it directly. The implication is that driver trust must be treated as an access decision, not a binary allow or deny on signature alone.

Defense evasion is now an identity problem, not just a malware problem: The ransomware does not merely evade detection, it uses privileged execution to terminate the processes that provide detection. In NHI terms, the malware is abusing a high-trust machine identity path to neutralise control planes that were never designed to defend themselves from kernel-originated actions. Practitioners should read this as a privilege boundary failure.

Blast radius control matters more than endpoint perfection: Reynolds deliberately enumerates network shares and accelerates encryption across connected storage, so a single compromised host can produce shared-data impact. This is why storage segmentation, share isolation, and privilege scoping across service access paths matter as much as endpoint prevention. The practitioners’ lesson is to reduce what a single trusted execution path can reach.

Legitimate components become malicious when governance is absent: Restart Manager, driver loading, process enumeration, and API resolution are all normal system capabilities, but the malware chains them into a destructive workflow. That is the pattern defenders must govern: trusted components, when left without usage constraints and anomaly detection, can be repurposed faster than signature-based controls can respond. The implication is stronger behavioural governance around privileged machine activity.

Targeted encryption exposes a speed-over-stealth trade-off: Reynolds skips files that would break the system, encrypts selectively, and uses multithreading to maximise damage before intervention. That combination shows why ransomware operators optimise for operational continuity on the victim side, not just payload success. Security teams should treat rapid file churn plus selective exclusion as a signal of deliberate impact engineering.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to NHI Mgmt Group research.
• That remediation gap is explored further in Ultimate Guide to NHIs , Key Challenges and Risks, which helps teams understand why exposure persists after discovery.

What this signals

Kernel abuse is a governance signal, not just an endpoint threat: once attackers can command a signed driver, standard response assumptions about process control, logging, and isolation degrade quickly. Teams should assume that privileged machine activity needs separate monitoring from user-facing detections, especially where endpoint protection products share the same trust boundary.

Identity blast radius now extends into the storage layer: if a compromised endpoint can enumerate network shares and encrypt remote data, the relevant control is not only endpoint hardening but storage reach limitation. In practice, that means reviewing where privileged endpoints can write, what service identities can touch shared volumes, and how quickly those permissions can be revoked.

Because 71% of NHIs are not rotated within recommended time frames, according to the Ultimate Guide to NHIs, defenders should expect stale machine trust to persist longer than they assume. That makes driver governance, service account scoping, and access path review part of the same containment strategy.

For practitioners

• Block vulnerable signed drivers before load Maintain a denylist of known-abused drivers and enforce vulnerable driver block controls at the endpoint and via policy. Include driver inventory checks during hardening so a signed binary cannot become a kernel escalation path.
• Correlate driver load events with security service stoppage Alert when a new driver load is followed by AV or EDR process termination, service disablement, or Windows Security reporting that protection has stopped. That sequence is a stronger signal than any single indicator in isolation.
• Monitor for abnormal drive enumeration and share resolution Detect rapid GetLogicalDrives-style enumeration patterns, network share resolution, and sudden access to multiple mounted paths from a single host. Pair that with file rename bursts and high-volume writes to catch encryption before it spreads.
• Constrain access to shared storage from privileged endpoints Separate workstation and server share permissions, remove unnecessary write access, and limit how far a single endpoint can reach across network-mounted storage. Reduced lateral storage reach directly limits ransomware blast radius.

Key takeaways

• Reynolds ransomware shows that a signed but vulnerable driver can become the shortest path to kernel-level defense evasion.
• The operational damage comes from the full chain, driver abuse, security-tool termination, and fast encryption across local and network storage.
• Teams need to treat driver trust, storage reach, and privileged machine activity as a single governance problem, not separate controls.

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.
• IOCTL abuse: The misuse of device control requests sent to a driver through a legitimate Windows interface. Attackers use it to instruct a driver to perform actions it was never intended to support in a hostile context, turning trusted kernel communication into a control channel.
• Blast radius: The maximum downstream damage a compromised identity, host, or service can cause before containment. For ransomware, blast radius is shaped by reach into shared storage, privileged service paths, and how much of the environment one execution context can touch.

What's in the full article

Gurucul's full blog covers the operational detail this post intentionally leaves for the source:

• IOCTL-level driver abuse details showing how NSecKrnl.sys is used to terminate security processes
• IOC lists including file hashes and named process targets for detection engineering work
• MITRE ATT&CK mappings for execution, privilege escalation, defense evasion, discovery, and impact
• Behavioural detection patterns across endpoint telemetry, file activity, and network communication

👉 Gurucul's full post covers the driver workflow, MITRE mapping, and indicator details

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 or security programme, it is worth exploring.