DEV Community: nithiya-rajesh

Neutralizing the Shield: The Escalation of BYOVD Attacks in Kernel-Level Evasion

nithiya-rajesh — Wed, 29 Jul 2026 05:00:00 +0000

The contemporary threat landscape is characterized by a strategic shift toward the subversion of endpoint security primitives. As Endpoint Detection and Response (EDR) solutions have become more resilient, sophisticated threat actors have pivoted from user-mode obfuscation to kernel-mode neutralization.

The primary mechanism for this escalation is the "Bring Your Own Vulnerable Driver" (BYOVD) attack. This technique leverages the inherent trust placed in digitally signed drivers to execute arbitrary code with kernel privileges, effectively "blinding" security telemetry at its source.

The Mechanism: From Ring 3 to Ring 0

In modern Windows environments, Driver Signature Enforcement (DSE) prevents the loading of unsigned code into the kernel (Ring 0). However, DSE does not verify the security of the code, only its provenance.

Attack Vector and Exploitation

A BYOVD attack occurs when an adversary, having already gained administrative privileges (Ring 3), installs a legitimate, digitally signed driver known to contain a security vulnerability—typically an insufficient access control on I/O Control (IOCTL) codes.

The attacker then interacts with the vulnerable driver to achieve an out-of-bounds write or an arbitrary memory write in kernel space. This capability is used to:

Modify EDR Callbacks: Locate and nullify the kernel callbacks (e.g., PsSetCreateProcessNotifyRoutine) that EDRs use to monitor process creation, thread injection, and file system activity.
Unload Security Minifilters: Detach file system minifilter drivers that provide visibility into ransomware-like encryption activity.
Direct Kernel Object Manipulation (DKOM): Modify kernel structures to hide processes, files, or network connections from the operating system’s reporting tools.

Real-World Incidents: BlackByte and Lazarus Group

The operationalization of BYOVD is no longer confined to academic research; it is a staple of high-impact intrusion sets.

Scenario A: BlackByte Ransomware:

In late 2022 and throughout 2023, the BlackByte ransomware group was observed utilizing a vulnerable driver associated with the Micro-Star MSI Afterburner utility (RTCore64.sys).

Vulnerability: CVE-2019-16098.
Action: Attackers targeted the callback routines of various EDR products, zeroing them out to ensure their encryption payload remained undetected.

Scenario B: Lazarus Group (APT38):

This North Korean-nexus actor pioneered BYOVD for espionage.

Vulnerability: They utilized a vulnerable Dell hardware driver (dbutil_2_3.sys, CVE-2021-21551).
Action: Once in Ring 0, they successfully disabled Windows Defender and established persistence that survived standard security scans.

Impact Analysis: The Visibility Gap

The impact of a successful BYOVD attack is catastrophic for the defensive posture of an organization.

Total Loss of Telemetry: Once the EDR’s kernel callbacks are disabled, the security console may show the agent as "Healthy," yet the agent is effectively deaf and blind. It will no longer report suspicious process execution, lateral movement, or data exfiltration.
Irreparable Trust Erosion: When the underlying operating system kernel is compromised, no higher-level security software can be trusted. This complicates incident response, as the tools used to investigate the breach are themselves subject to manipulation by the attacker.
Ecosystem Risk: The vast ecosystem of third-party drivers (printers, GPUs, peripheral controllers) provides a nearly inexhaustible supply of vulnerable, signed targets for adversaries.

Detection and Defense Strategies

Defending against BYOVD requires a shift from reactive signature scanning to proactive configuration hardening and behavioral monitoring.

1. Implementation of HVCI and WDAC

The most effective defense is preventing the vulnerable driver from loading.

a. Hypervisor-Protected Code Integrity (HVCI): Enable Memory Integrity in Windows Security. HVCI uses hardware virtualization to ensure that only signed, compliant code can run in the kernel, significantly raising the bar for memory manipulation.
b. Windows Defender Application Control (WDAC): Implement strict WDAC policies to permit only a known-good list of drivers. Use Microsoft’s "Vulnerable Driver Blocklist," which is frequently updated to prevent the loading of known exploitable drivers.

Actionable Tip: Use the Microsoft Vulnerable Driver Blocklist, which is frequently updated to prevent loading known exploitable drivers

2. Behavioral Monitoring of Driver Load Events
Blue Teams should monitor for the following telemetry markers:

a. Unusual Driver Loads: Audit System Event ID 6 (Driver Loaded) in Sysmon. Alert on drivers being loaded from temporary directories or by non-system processes.
b. Service Creation: Monitor for the creation of new kernel services by accounts that do not typically perform administrative maintenance.
c. EDR Heartbeat Gaps: Configure alerts for when an EDR agent stops sending specific telemetry types (e.g., Process Creation events) while still reporting a "Connected" status.

3. Red Team Methodology
Red Teams should move beyond simple EDR bypasses and simulate kernel-level threats. Utilizing tools like EDRSilencer in controlled environments helps Blue Teams understand the specific telemetry "silence" that occurs during a BYOVD event, allowing for the development of custom detection logic based on missing expected events.

Conclusion

The BYOVD crisis represents a fundamental challenge to the security of the Windows kernel. As attackers continue to automate the discovery and exploitation of vulnerable drivers, organizations must move away from the assumption that a digital signature equals security. Hardening the kernel interface via HVCI and maintaining aggressive driver blocklists are now mandatory components of a mature cybersecurity strategy.

I Built a Runtime Immune System for Multi-Agent AI — Here’s What Broke First 🛡️

nithiya-rajesh — Tue, 14 Jul 2026 15:54:17 +0000

The blind spot in current AI guardrails

Guardrail middleware for AI agents is maturing fast. LangChain ships native guardrails. NeMo Guardrails and Guardrails AI are established. Between input filtering, output moderation, tool sandboxing, and audit logging, there’s a real defense-in-depth stack available today.

All four of those layers check one agent, one message, at one point in time. None of them ask a different question: is this same payload echoing across three different agents in my system right now?

That question — propagation across a mesh, not content within a single message — is exactly the mechanism a self-replicating prompt attack (the “Morris-II” class) exploits. An adversarial input tricks Agent A into mirroring that input into its own output. Any downstream agent that consumes A’s output re-triggers the same behavior. No file dropped, no code executed — the conversation itself is the propagation mechanism.

I built ImmuneMesh — a sandboxed research prototype — to test one idea: give a multi-agent mesh a shared memory, the way biological adaptive immunity works, so once one agent is fooled, the rest aren’t. 🧠

How it works ⚙️
ImmuneMesh runs as LangGraph middleware, attached at wrap_model_call. Two independent detection signals feed a shared “antibody store”:

Mirroring score 🪞 — cosine similarity between an agent’s input and its own output embeddings.
Canary token 🐤 — a random per-call token silently injected into the system prompt. A legitimate agent never reproduces it.

Once any agent confirms a threat, every other agent checks new input against that shared memory first — before even calling its own model. A match means instant quarantine of that message, mesh-wide.

def wrap_model_call(self, request, handler):
    input_embedding = embed(input_text)
    # Check the shared antibody store BEFORE calling the model at all 🛑
    matched_antibody, scor``e = self.store.check(input_embedding)
    if matched_antibody:
        return ModelResponse(result=[AIMessage(
            content="[BLOCKED BY IMMUNEMESH — known threat pattern]"
        )])
    ...

What broke: the false-positive problem ⚠️

Every early demo proved the detector catches attacks. The harder question is: how often does it wrongly flag normal work?

Download the Medium app

I ran it against eight realistic benign task categories — summarization, translation, Q&A, proofreading — at a fixed mirroring threshold. Three false-positive:

CaseScoreFlagged?Off-topic summarization0.804

✅ Yes Instruction confirmation 0.920

✅ Yes Verbatim proofreading 0.902

✅ Yes Confirmed Attack0.549❌ No (Caught by Canary)

The fix, and the bootstrap bug 🐛

The fix is a per-agent adaptive baseline. Instead of one global number, each agent learns its own normal. Building this surfaced a real bootstrap deadlock: the first version gated “is this safe to learn from” on the same threshold it was replacing. An agent whose true normal was high could never accumulate enough history to graduate out of cold start.

The Fix: Canary detection now gates learning. Mirroring becomes purely advisory until an agent has enough history. Canary detection stays absolute — a baseline can learn “this agent mirrors 90%,” but it must never learn “leaking my system prompt is normal.”

Research Limitations & Honest Scope 🧐

This is a research prototype. It is not adversarially hardened, and “baseline poisoning” — where an attacker slowly shifts an agent’s “normal” definition — remains an open research problem. This project is my attempt to map the “cross-agent propagation” blind spot. I’d genuinely welcome pushback, alternative approaches, or pointers to prior work I’ve missed.

Explore the Research: ImmuneMesh on GitHub

The First Ransomware Attack With No Humans in the Loop Just Happened — and Your Playbook Isn’t Ready

nithiya-rajesh — Sun, 12 Jul 2026 07:34:28 +0000

Three weeks ago, security researchers watched something they’ve been warning about for a year actually happen: an AI agent ran a complete ransomware attack by itself. No human attacker typing commands. No delays waiting for approval. Start to finish — reconnaissance, exploitation, lateral movement, data exfiltration, and the extortion demand — all orchestrated by software.

The attack is called JADEPUFFER. It’s the first confirmed case of end-to-end autonomous ransomware. And it means your incident response playbook, which is built around the assumption that humans are doing the attacking, is already obsolete.

What JADEPUFFER actually did
On July 7, 2026, Sysdig (a container security firm) published the technical details. JADEPUFFER isn’t a new piece of malware — it’s a proof of concept showing how an agentic AI can automate every stage of a ransomware intrusion without a human operator stopping to check in, approve, or adjust course.

The kill chain it executed:

Reconnaissance — the agent mapped the target network, identified high-value systems, and located backup infrastructure
Initial access — exploited a known vulnerability to get a foothold
Privilege escalation — moved from user-level to admin access
Lateral movement — spread across the network to reach other systems
Data exfiltration — identified and copied sensitive files to staging areas
Encryption — deployed ransomware to lock files across the environment
Extortion — crafted and delivered the ransom demand with proof of stolen data
Every step. No operator. No waiting for a human to decide what to do next.

If you’ve been in security long enough, you know what makes this different from ransomware as it’s existed for the past five years. Ransomware attacks have always been authored by humans — a team of specialists sitting at keyboards, making decisions, checking in on progress. An intrusion that takes hours or days to unfold is slow enough for a skilled defender to spot, interrupt, or at least slow down. The human operators’ need to sleep, coordinate, and think things through created natural choke points.

JADEPUFFER removes that. An AI doesn’t sleep. It doesn’t second-guess. It doesn’t need to wait for approval to move to the next step. It moves at CPU speed.

Why this is the story of the month
The cybersecurity industry has spent the last year talking about agentic AI as a threat. Researchers have published white papers. Conferences have panels. Security vendors have released products claiming to defend against it.

But JADEPUFFER is different. It’s not a theory anymore. It’s not a “we ran a simulation and here’s how bad it could be.” It’s a real attack, against a real target, documented and analyzed.

That pivot from “this might happen” to “this is happening” changes everything about how you should think about your defenses. And most organizations haven’t caught up yet.

Why your current playbook doesn’t work against this
Every incident response plan ever written assumes something that’s no longer true: that the attacker is human and is therefore subject to human constraints.

Your playbook probably says things like:

“Monitor for unusual administrative login patterns”
“Alert if someone accesses the backup infrastructure outside normal hours”
“Catch lateral movement by tracking network traffic spikes”
Those work great when an attacker has to be awake, has to coordinate with team members, and has to fit their attack into hours of elapsed time. An AI doesn’t care about “normal hours.” It doesn’t get tired and make mistakes. It doesn’t need to wait for a partner to respond on Slack.

A machine-speed attack can cross your entire network and encrypt your most critical systems in minutes — faster than a human operator can even detect something’s wrong, let alone respond. Your SIEM is still indexing the first log when the attack is already over.

The uncomfortable truth: detection now requires a different model
Here’s what keeps security leaders up at night about JADEPUFFER: traditional threat detection is built around finding patterns of human behavior. An attacker who’s unusual or slow or hesitant triggers alarms. But an AI that’s perfectly normal, fast, and methodical might not.

Think about it. What does an AI-driven reconnaissance look like? It looks like thorough documentation of network architecture. What does lateral movement look like? It looks like legitimate network administration. The AI isn’t trying to be sneaky in the way a human would be — it’s just executing the most efficient path to its goal, which happens to look like normal business operations if you’re only looking at individual events.

The countermove isn’t to get smarter at detecting humans who pretend to be machines — it’s to shift your entire defensive model.

What your organization should do starting today
I know that’s a terrifying framing. Here’s the practical side: you don’t need to rebuild your entire security infrastructure overnight. But you do need to change how you think about detection and response.

Assume breach, accept speed. Your old playbook said “detect, contain, eradicate.” That takes days or weeks. Against JADEPUFFER-class attacks, the timeline is minutes. You need to shift from “detect and investigate” to “assume it’s happening and verify containment.” That means:

Your backups aren’t just backed up — they’re tested to restore quickly. Can you recover your most critical systems in under an hour?
Your disaster recovery plan isn’t a theoretical document — it’s exercised monthly.
You know exactly which data is most critical and where it lives.

Network segmentation isn’t optional anymore. If an AI can move laterally at machine speed, the only real defense is making it impossible to reach crown jewels from infected systems. Segment your network so that a breach in one area doesn’t automatically grant access to everywhere else. Backup infrastructure especially: it should be on a separate network, with separate credentials, and never reachable from user-facing systems.
Continuous verification of access. Your current access controls probably work on an annual cycle — hire someone, they get access, leave the company, access gets revoked eventually. A machine-speed attack exploits the gaps: stale credentials, over-privileged service accounts, unused admin rights that never got cleaned up. You need:

Monthly review of who has what access (not annual)
Zero-trust principles: don’t assume a logged-in session is legitimate just because it has valid credentials MFA on everything, especially backup access and sensitive systems

Immutable backups. If your backups can be deleted or encrypted, they’re not backups — they’re targets. JADEPUFFER’s attack chain specifically includes identifying and compromising backup infrastructure. Your backups need to be:

Stored offline or in immutable storage that can’t be modified, even by a system administrator Tested regularly (not just assumed to work)
Kept separate from your production systems and network

Rethink your incident response timeline. Your playbook probably says “Alert → Investigate → Contain → Eradicate.” That assumes hours. For AI-driven attacks, you need a different sequence:

Alert (seconds): Automated response triggers
Contain (minutes): Isolate affected systems before the attack spreads
Verify (minutes): Confirm what happened
Recover (hours): Restore from backups
Investigate (days): Figure out how it happened after you’re back online
The hard conversation with your leadership
Here’s what you need to say to your board or executive team: the ransomware threat changed on July 7, 2026. Not in degree, but in kind. An attacker that moves at machine speed doesn’t just need better defenses — it needs a different strategy.

Enterprise security used to be built on prevention and detection. “Stop the bad thing from happening, and if it does, catch it before it causes damage.” That model relied on the attacker being slower than your response. JADEPUFFER proves that assumption is broken.

The new model is: recovery by design. You assume the attack will succeed. You focus on making sure that when it does, you can get back online faster than the attacker can extract value or destroy systems. That changes where your security budget goes. It’s less “fancy detection tools” and more “immutable backups, network segmentation, and recovery drills.”

It’s also less comfortable. Nobody likes admitting that the attacker might win the initial engagement. But it’s the only model that works when the attacker doesn’t need a human to coordinate the attack.

What happens next
JADEPUFFER was a proof of concept, not a widespread campaign — yet. But the playbook is published. Other threat actors will study it. The techniques will spread. Within months, expect to see AI-driven ransomware attempts against real targets from real adversaries, not just security researchers.

The organizations that survive those attacks will be the ones that started planning now, not the ones that wait for the first breach to rewrite their playbook.

Here’s my question for you: If an AI agent could cross your entire network in 10 minutes, could you restore from backups and be back online in an hour? If the answer is “I’m not sure,” that’s your starting point. What’s the first step you’d take this week?

Drop it in the comments — or better yet, talk to your team about it this week.

Publisher’s note: JADEPUFFER was disclosed by Sysdig on July 7, 2026. At time of writing, there was no evidence of widespread exploitation — this is a warning signal, not an active campaign.

Stop Running GitHub PoCs on Your Workstation. You’re Being Hunted.

nithiya-rajesh — Sat, 04 Jul 2026 14:30:30 +0000

When a new critical CVE drops, we race to be the first to verify it. Fueled by caffeine and the pressure of a ticking clock, we scour GitHub for a Proof of Concept (PoC) to see how the exploit works. We find a repo with a few stars, skim the Python script, see nothing "obvious," and hit run.

In 2026, that speed is exactly what is going to get your entire enterprise compromised.

The recent "ChocoPoC" campaign isn't just another malware report; it is a professional wake-up call. It proves that attackers have stopped targeting the software—they are now targeting the defender’s process.

The Death of the "Quick Code Review"

The old-school way of staying safe was to "read the code before you run it." But the ChocoPoC campaign has officially made the "eye-ball test" obsolete.

Researchers from YesWeHack and Sekoia recently deconstructed a series of repositories claiming to exploit fresh CVEs. To the naked eye, the exploit script looked perfectly legitimate.

The malware wasn't in the script. It was in the dependencies.
By hiding malicious code (nicknamed ChocoPoC) inside a Python package listed in the requirements.txt, the attackers bypassed the human reviewer. The moment you ran the script, the dependency executed quietly in the background, exfiltrating your saved passwords, browser cookies, and session tokens before handing the attacker a shell on your machine.

If you are only reviewing the .py file and not the entire supply chain of the repository, you aren't doing a security review. You’re just gambling.

Why Researchers are the "Golden Ticket"

Why would an attacker spend time building fake exploits instead of just phishing a CEO? Because a security researcher's laptop is a Golden Ticket.

A single infected workstation in a SOC or DevSecOps team provides:

Privileged Access: You likely have active session cookies for cloud consoles (AWS/Azure) or internal GitLab instances.
Source Code: Access to the "crown jewels" of your organization.
The Ultimate Cloak: Traffic coming from a security pro’s machine is rarely questioned by automated alerts.

Attackers aren't looking for random victims anymore. They are looking for the keys to the castle, and we are handing them over in our rush to be "first."

The Professional Standard: Building a "Zero-Trust" Workflow

If you are still running untrusted code on your bare-metal workstation because you "don't have time" to spin up a VM, you are a liability to your team.

Here is the 2026 baseline for running any community PoC:

Containment is the only Control: Assume "eyeballing" code will fail. Use a disposable, air-gapped Virtual Machine or a strictly isolated sandbox (like Tenzir or a dedicated lab VPC).
Audit the Supply Chain: Before running pip install -r requirements.txt, verify every package on PyPI. Look for typosquatted names (e.g., requests-auth-lib vs request-auth-lib).
The 72-Hour Rule: The window immediately following a CVE disclosure is the "Danger Zone." This is when fake PoCs are seeded. If a repo is less than 3 days old and has 100+ stars, it’s a red flag. Stars are cheap; reputation is earned.

The Hard Truth

This campaign is a neat illustration of a trend that will define this decade: attackers weaponizing the "defender's rush."

We need to stop rewarding "fast and loud" research and start rewarding "contained and verified" research. The fix isn't paranoia—it’s building a workflow where running malicious code is cheap and inconsequential because it’s trapped in a sandbox.

The Question for the Community:

How many of you can honestly say you haven't run a PoC on your host machine in the last 30 days? Are we actually sandboxing our research, or are we just hoping the "Star" count on GitHub means the code is safe?

Let’s be honest in the comments—how does your team handle the "rush" of a new CVE?