Most teams still treat the vulnerable-driver blocklist like a finished control. A known-bad .sys tries to load, Windows denies it, the ticket closes, and someone updates a slide about kernel protection. That reaction is already late. This week’s reporting on bring-your-own-vulnerable-driver tradecraft, ransomware crews exploiting PAN-OS, and a genuine Siemens updater dropping malicious DLLs all land on the same cybersecurity failure: you are hunting names attackers can swap, while the asset you actually lose is visibility.

EDR did not fail because you missed a hash. It failed because the environment still honors signed load paths, then keeps trusting the sensor after those paths go quiet.

Cybersecurity Teams Keep Scoring a Catalog

The Microsoft vulnerable driver blocklist is useful. Treating it as coverage is the mistake. BYOVD operators pick a signed driver with a known write primitive or privilege bug, drop it from a path your allowlist already likes, and disable or blind the EDR. After that, the rest of the intrusion runs with the lights off. You can patch, you can block yesterday’s .sys names, and you can still lose the only process that would have told you the next stage started.

SentinelOne’s latest guidance for detection teams is blunt about what actually works. Split EDR-killer activity into four behavior hunts so you catch BYOVD and driverless variants before ransomware fires. Driverless is the part too many programs still skip. Plenty of crews never bring a custom kernel module. They abuse built-in admin surfaces, stolen tokens, service control, or legitimate kernel interfaces your hash list will never see. If the query that makes your dashboard green is “known vulnerable driver filename,” you have a library. You do not have a hunt.

You already know the celebrity drivers from every after-action: motherboard utilities, GPU helpers, anti-cheat leftovers, the usual “legit vendor, ancient bug” set. Attackers know you know. They rename the file, they sideload it from a user-writable directory, or they pick a driver your quarterly review has not added yet. Catalog maintenance is security hardening. It keeps the easy stuff out. It does not tell you when SeLoadDriverPrivilege flipped on a helpdesk admin account, or when the EDR service entered a stop-pending state at 2:14 a.m. Those are the events that precede the note.

Defense in depth only holds if the next layer still reports after the first one dies. Most cyber security programs still grade kernel defense on prevent counts. Prevent counts look great until the host that mattered never sent the alert.

Trusted Boxes Keep Loading Untrusted Code

While endpoint teams argue over driver IOCs, ransomware operators including Spikey Scorpius (Qilin) and Tarnished Scorpius (Inc) are exploiting PAN-OS CVE-2026-0257. Unit 42 refreshed that threat brief on October 19. This is an internet-facing security appliance, the box you bought so threat-protection would happen before a payload reached a laptop. If they hold that box, they hold part of the story your SOC believes.

Policy objects, decryption exceptions, management-plane accounts, VPN users: those are incident-response artifacts, not “network team” leftovers. A quiet change that stops forwarding telemetry, or carves a hole for C2, will look like a sensor-health problem if you start every investigation at the workstation. Patch the CVE. Pull PAN-OS management off the public internet. Treat unexplained policy edits with the same severity as a domain admin login at 3 a.m.

The Siemens Software Center case should finish the last argument that a valid signature closes the ticket. Attackers paired a genuine, signed copy of that updater with malicious DLLs and infected Windows PCs. The binary looked like a vendor tool because it was a vendor tool. Your allowlist nodded. The DLLs did the work. That is the same trust bug as BYOVD, one ring up the stack. Signed driver, signed updater, signed security appliance. Each one is a load instruction your environment already agreed to honor.

Trust is a write, not a badge

Code signing tells you who shipped the file. It does not tell you the file is being used the way the vendor intended, or that adjacent DLLs are clean, or that the process should be allowed to load a driver. If Siemens Software Center, or any other vendor helper, is not a required business binary on a given subnet, it should not run there. Jump boxes and engineering workstations keep becoming staging hosts because the installer looked official.

You do not need another awareness slide about “don’t run random tools.” You need path rules, publisher constraints that still inspect loaded modules, and a written “no vendor helpers on privileged hosts” standard that survives a plant manager asking for an exception.

Hunt the Mute Host, Then Cut Remaining Paths

If you only have time for one change this week, stop scoring kernel defense on blocked driver names and start paging people when the sensor disappears. The four hunts below are tool-agnostic. Use whatever telemetry you already have: Sysmon, EDR process events, Windows service logs, firewall change logs. The point is the behavior, not a product SKU.

1. Hunt driver loads from user-writable paths, browser download caches, email attachments, temp directories, and renamed copies sitting outside the DriverStore. Include service creation that points ImagePath at those locations.
2. Hunt security-product tamper: EDR service stops, process kills, minifilter unloads, ETW session disruption, and local firewall rules that appear in the same window as those stops.
3. Hunt the privilege setup that makes tamper cheap. SeLoadDriverPrivilege or SeDebugPrivilege enabled on accounts that should never load drivers, token impersonation to SYSTEM, and new services created as SYSTEM in the minutes before a sensor dies.
4. Hunt silence. Agent heartbeat loss, a sudden drop in host telemetry, PAN-OS or other firewall policy churn, then admin logons originating from the mute host. Silence is the signal. Wait for ransomware and you are reading a receipt.

Do these immediately, on production hosts, not in a lab slide:

• Export currently loaded drivers from a sample of workstations, jump boxes, and servers. Diff them against public known-vulnerable lists tonight, then again after you enable the Microsoft blocklist and HVCI where the hardware can take it.
• Page on EDR process exit and security service stop as Sev-1. If you can auto-isolate a mute host, do it. A sensor-health ticket that sits until morning is how lateral movement buys hours.
• Patch PAN-OS for CVE-2026-0257. Restrict management to a jump segment you actually watch. Review policy diffs for the last 30 days as if an attacker already had a session.
• Block Siemens Software Center and similar updaters where they are not a required plant or engineering binary. Inventory which privileged hosts already have them.
• Assume brute-force against whatever admin path still answers after EDR dies. RDP, WinRM, and SSH on leftover jump hosts need lockouts, not hope. Host-level controls in the ipban family still earn their keep on those services; IPBan Pro is one option on Windows if you want automated source bans instead of a spreadsheet of failed logons.

Keep a weekly query for drivers loaded outside %SystemRoot%\System32\drivers and the DriverStore. Run a monthly tabletop that starts with a mute host and no ransom note. Name the person who isolates the box, the person who pulls firewall change logs, and the person who can revoke the service account that just spawned a SYSTEM service. Incident response that waits for encryptors is a communications plan.

Ongoing defense is dull on purpose. Recertify who can load drivers. Recertify which vendor updaters are allowed on which VLANs. Keep appliance configs under the same change control you use for domain admins. When a host goes mute, isolate first and debug second. That is how you stop paying for threat-protection theater while the actual kill happens one layer below the dashboard.

Frequently Asked Questions

Is the Microsoft vulnerable driver blocklist enough on its own?

No. Enable it, and enable HVCI where hardware allows, because it removes a pile of lazy BYOVD loads. Driverless tamper, renamed helpers, and signed updaters with hostile DLLs still get through a list that only knows yesterday’s .sys files. Pair the blocklist with hunts for privilege enables, service stops, and mute hosts.

What should we do first if EDR goes silent on one host?

Isolate that host at the network, then treat it as compromised until you prove otherwise. Pull local service and driver load events, check PAN-OS or other firewall policy diffs from the same window, and look for admin logons originating from the mute box. A sensor-health ticket is the wrong queue.

How does a firewall CVE change endpoint hunting?

If ransomware crews can edit PAN-OS policy, they can hide C2, drop inspection, or starve your SOC of the telemetry the endpoint hunt needs. Endpoint queries still matter, but you have to correlate them with appliance change logs or you will investigate a laptop while the path in and out is already theirs.

Sources

• Bring Your Own Vulnerable Driver: What Detection Teams Should Actually Hunt
• Threat Brief: Active Exploitation of PAN-OS CVE-2026-0257 (Updated October 19)
• Siemens Software Center Vulnerability Exploited in ClickFix Malware Attacks