PatchDay Alert
Analysis · 4 min read · 802 words By operations-desk

Scattered Spider didn't need a zero-day. They brought a decade-old driver Windows still loads.

CVE-2015-2291 is a vulnerable Intel Ethernet driver. Scattered Spider loaded it to reach the kernel and patch out Defender, CrowdStrike, SentinelOne, and Palo Alto in memory. It's the classic bring-your-own-vulnerable-driver attack, and the defenses are switches you can flip today.

Scattered Spider didn't need a zero-day. They brought a decade-old driver Windows still loads.

To get into the Windows kernel and switch off the security tools, an attacker has two options: find a vulnerability in a driver Windows already trusts, or bring along an old, vulnerable, but still-validly-signed driver and load it themselves. The second approach is bring-your-own-vulnerable-driver (BYOVD), and CVE-2015-2291 is one of its workhorses. It’s a flaw in the Intel Ethernet diagnostics driver (iqvw64e.sys / iqvw32.sys) that allows kernel-level code execution through crafted IOCTLs. CrowdStrike documented Scattered Spider loading this driver to reach the kernel and then patch the in-memory components of several endpoint products, Microsoft, CrowdStrike, SentinelOne, and Palo Alto among them, to blind them. No zero-day required. A ten-year-old driver Windows still happily loads.

This is the companion to the built-in-driver case in CVE-2024-21338: there, the vulnerable driver was a Windows component you can’t blocklist. Here, it’s a foreign driver you can.

What the bug is

CVE-2015-2291 is rated by CISA as a denial-of-service issue in the Intel Ethernet diagnostics driver (CWE-20), covered by Intel advisory SA-00051, but in attacker hands the driver provides a path to arbitrary kernel code execution. CISA added it to the Known Exploited Vulnerabilities catalog on February 10, 2023, with the ransomware flag. Scattered Spider used it through 2022 and 2023 against telecom and business-process-outsourcing firms, the same crew behind a string of high-profile help-desk-social-engineering intrusions, and the malicious driver they loaded would iterate the loaded kernel modules for security software and patch them out so their activity went unseen.

The driver itself is legitimately signed by Intel, which is the entire trick: Windows will load a properly-signed driver even if it’s ancient and known-vulnerable, so the attacker doesn’t need to forge a signature or find a new bug. They just need administrative rights, which they already have by this stage, and a copy of the old driver, which is freely available.

The defenses are switches you can flip

Unlike the built-in-driver case, classic BYOVD has concrete, available countermeasures, and they’re the controls worth turning on proactively:

  • Microsoft Vulnerable Driver Blocklist. Microsoft maintains a blocklist of known-bad drivers, including the ones used for BYOVD, and modern Windows can refuse to load them. On current Windows it’s increasingly on by default, but verify it’s enabled and updated on your fleet. This directly stops loading of cataloged vulnerable drivers like iqvw64e.sys.
  • Memory Integrity (HVCI / hypervisor-protected code integrity). Part of core isolation, HVCI uses virtualization to enforce that only validated code runs in the kernel, which raises the bar for BYOVD substantially. Driver-compatibility issues have historically kept some shops from enabling it; if that’s you, it’s worth revisiting, because the security payoff against kernel attacks is large.
  • Windows Defender Application Control (WDAC) with driver rules. For high-assurance environments, WDAC can enforce an allowlist of permitted drivers, which is the strongest answer: a driver not on your allowlist doesn’t load, vulnerable or not.

These are configuration, not patches, and that’s the point. You can’t patch every old signed driver out of existence, but you can stop Windows from loading the known-bad ones.

What to do

  • Enable and update the Microsoft Vulnerable Driver Blocklist across the fleet, and confirm it’s actually on (it’s been shipped in inconsistent states across Windows versions). This is the single highest-value action against commodity BYOVD.
  • Turn on Memory Integrity / HVCI where hardware and driver compatibility allow. Pilot it, resolve driver conflicts, and roll it out; it’s a structural defense against exactly this attack class.
  • Treat EDR going blind as an incident. The whole purpose of BYOVD is to silence your telemetry. Agents that stop reporting, get tampered with, or whose kernel components are modified are a high-fidelity sign of an active kernel-level intrusion, not a glitch.
  • Watch for new driver loads. Alert on unexpected kernel driver installs, especially old or unusual signed drivers appearing on a host. A diagnostics driver from a decade ago showing up on a server has no benign explanation.

The reframe ties the two BYOVD cases together. Attackers reach the kernel either through a driver Windows ships (which you can’t blocklist, so patch fast) or one they bring (which you can block, so turn the controls on). CVE-2015-2291 is the bring-it case, and the defenses, the driver blocklist and HVCI, are sitting in Windows waiting to be enabled. The crews using this technique are betting you left them off. We track the BYOVD entries because they’re the bugs that turn admin access into a blinded environment, and the countermeasures are too cheap to skip.

Sources

Share

Related field notes

One email, every weekday morning.

You're in. Check your inbox.

Get the digest

Free. Weekday mornings. Plain English CVE triage.

Check your inbox to confirm.