Exploitation for Privilege Escalation
Adversaries may exploit software vulnerabilities in an attempt to elevate privileges. Exploitation of a software vulnerability occurs when an adversary takes advantage of a programming error in a program, service, or within the operating system software or kernel itself to execute adversary-controlled code. Security constructs such as permission levels will often hinder access to information and use of certain techniques, so adversaries will likely need to perform privilege escalation to include use of software exploitation to circumvent those restrictions. When initially gaining access to a system, an adversary may be operating within a lower privileged process which will prevent them from accessing certain resources on the system. Vulnerabilities may exist, usually in operating system components and software commonly running at higher permissions, that can be exploited to gain higher levels of access on the system. A key sub-technique is Bring Your Own Vulnerable Driver (BYOVD), where adversaries drop a legitimately signed but vulnerable kernel driver onto a compromised machine and then exploit it to execute code in kernel mode, bypassing Driver Signature Enforcement. Real-world examples include Embargo ransomware using MS4Killer, ZeroCleare using VBoxDrv.sys, APT29 exploiting CVE-2021-36934, and Turla exploiting VBoxDrv.sys vulnerabilities.
What is T1068 Exploitation for Privilege Escalation?
Exploitation for Privilege Escalation (T1068) maps to the Privilege Escalation tactic — the adversary is trying to gain higher-level permissions in MITRE ATT&CK.
This page provides production-ready detection logic for Exploitation for Privilege Escalation, covering the data sources and telemetry it touches: Driver: Driver Load, Process: Process Creation, Windows Registry: Windows Registry Key Modification, Microsoft Defender for Endpoint, Windows Security Event Log. The queries below are rated critical severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Privilege Escalation
- Canonical reference
- https://attack.mitre.org/techniques/T1068/
let SuspiciousDriverPaths = dynamic([
"\\temp\\", "\\tmp\\", "\\downloads\\", "\\appdata\\local\\",
"\\appdata\\roaming\\", "\\users\\public\\", "\\programdata\\",
"\\$recycle.bin\\", "\\windows\\tasks\\", "\\perflogs\\"
]);
let KnownVulnerableDriverNames = dynamic([
"rtcore64.sys", "rtcore32.sys", "gdrv.sys", "gdrv2.sys",
"asrdrv10.sys", "asrdrv101.sys", "asrdrv102.sys",
"aswarpot.sys", "vboxdrv.sys",
"dbutil_2_3.sys", "dbutildrv2.sys",
"mhyprot2.sys", "mhyprot3.sys",
"iqvw64e.sys", "iqvw32e.sys",
"winring0x64.sys", "winring0.sys",
"capcom.sys", "msio64.sys", "msio32.sys",
"ms4killer.sys", "glckio2.sys",
"physmem.sys", "nvflash.sys",
"nicm.sys", "nscm.sys",
"spwizeng.sys", "bs_rcio64.sys"
]);
// Signal 1: Known vulnerable driver loaded (BYOVD)
let BYOVDDriverLoad = DeviceImageLoadEvents
| where Timestamp > ago(24h)
| where tolower(FileName) in (KnownVulnerableDriverNames)
| extend DetectionSignal = "KnownVulnerableDriverLoaded"
| project Timestamp, DeviceName, AccountName, DetectionSignal,
DriverFile=FileName, DriverPath=FolderPath,
SHA256, InitiatingProcessFileName, InitiatingProcessCommandLine,
InitiatingProcessAccountName;
// Signal 2: Driver (.sys) loaded from user-writable or suspicious path
let SuspiciousPathDriverLoad = DeviceImageLoadEvents
| where Timestamp > ago(24h)
| where FileName endswith ".sys"
| where tolower(FolderPath) has_any (SuspiciousDriverPaths)
| extend DetectionSignal = "DriverLoadedFromSuspiciousPath"
| project Timestamp, DeviceName, AccountName, DetectionSignal,
DriverFile=FileName, DriverPath=FolderPath,
SHA256, InitiatingProcessFileName, InitiatingProcessCommandLine,
InitiatingProcessAccountName;
// Signal 3: New driver service registered pointing to suspicious path (pre-load step)
let SuspiciousDriverService = DeviceRegistryEvents
| where Timestamp > ago(24h)
| where ActionType == "RegistryValueSet"
| where RegistryKey has "\\SYSTEM\\CurrentControlSet\\Services\\"
| where RegistryValueName == "ImagePath"
| where tolower(RegistryValueData) endswith ".sys"
| where tolower(RegistryValueData) has_any (SuspiciousDriverPaths)
or tolower(RegistryValueData) has_any (KnownVulnerableDriverNames)
| extend DetectionSignal = "SuspiciousDriverServiceRegistered"
| project Timestamp, DeviceName, AccountName=InitiatingProcessAccountName,
DetectionSignal, DriverFile=tostring(split(RegistryValueData, "\\")[-1]),
DriverPath=RegistryValueData, SHA256="",
InitiatingProcessFileName, InitiatingProcessCommandLine,
InitiatingProcessAccountName;
// Signal 4: Security Event 4697 — new kernel driver service installed
let NewDriverServiceInstalled = SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4697
| where ServiceType == "0x1" // Kernel driver
| where tolower(ServiceFileName) has_any (SuspiciousDriverPaths)
or tolower(ServiceFileName) has_any (KnownVulnerableDriverNames)
| extend DetectionSignal = "KernelDriverServiceInstalled_4697"
| project Timestamp=TimeGenerated, DeviceName=Computer,
AccountName=SubjectUserName, DetectionSignal,
DriverFile=ServiceName, DriverPath=ServiceFileName, SHA256="",
InitiatingProcessFileName="", InitiatingProcessCommandLine="",
InitiatingProcessAccountName=SubjectUserName;
// Union all signals
BYOVDDriverLoad
| union SuspiciousPathDriverLoad
| union SuspiciousDriverService
| union NewDriverServiceInstalled
| sort by Timestamp descMulti-signal detection for T1068 Exploitation for Privilege Escalation, focused on the Bring Your Own Vulnerable Driver (BYOVD) sub-pattern. Covers four detection signals: (1) known vulnerable drivers loaded by name (RTCore64, DBUtil_2_3, MHyprot2, WinRing0, Capcom, etc. sourced from the LOLDrivers project), (2) any .sys driver loaded from user-writable or suspicious filesystem paths, (3) registry service key creation pointing to a .sys in a suspicious path (the pre-load registration step), and (4) Security Event 4697 (new kernel driver service installed) for drivers matching suspicious paths or known vulnerable names. Uses DeviceImageLoadEvents, DeviceRegistryEvents, and SecurityEvent tables.
Data Sources
Required Tables
False Positives
- Legitimate use of virtualization software (VMware, VirtualBox) loading VBoxDrv.sys or vmware*.sys during installation or normal operation
- Security research or penetration testing tools that use signed vulnerable drivers in controlled environments
- Overclocking or hardware monitoring utilities (MSI Afterburner loading RTCore64.sys, ASUS GPU Tweak loading AsrDrv) on gaming or engineering workstations
- Dell BIOS update utilities legitimately loading dbutil_2_3.sys or dbutildrv2.sys as part of authorized firmware updates
- Kernel debugging sessions by authorized developers loading unsigned or test-signed drivers via WinDbg or similar
- Software deployment tools (SCCM, PDQ Deploy) installing legitimate hardware vendor drivers that happen to match path patterns
Sigma rule & cross-platform mapping
The detection logic for Exploitation for Privilege Escalation (T1068) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: process_creation
product: windowsBrowse the community-maintained Sigma rules for this technique:
Platform-specific guides for T1068
References (9)
- https://attack.mitre.org/techniques/T1068/
- https://www.loldrivers.io/
- https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules
- https://www.welivesecurity.com/wp-content/uploads/2020/06/ESET_InvisiMole.pdf
- https://unit42.paloaltonetworks.com/acidbox-rare-malware/
- https://github.com/wavestone-cdt/EDRSandblast
- https://github.com/Idov31/Nidhogg
- https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
- https://github.com/SigmaHQ/sigma/tree/master/rules/windows/driver_load
Testing Methodology
Validate this detection against 5 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 1BYOVD — Drop and Register Known Vulnerable Driver (RTCore64.sys Simulation)
Expected signal: Windows Security Event ID 4697 (New Service Installed): ServiceName=RTCore64, ServiceFileName=C:\Windows\Temp\RTCore64.sys, ServiceType=0x1 (Kernel Driver). Sysmon Event ID 1 (Process Create): Image=sc.exe, CommandLine containing 'create RTCore64 type= kernel'. DeviceRegistryEvents: RegistryKey containing \Services\RTCore64, RegistryValueName=ImagePath, RegistryValueData=C:\Windows\Temp\RTCore64.sys.
- Test 2Suspicious Driver Load Path — Copy System Driver to Temp and Reload
Expected signal: Sysmon Event ID 11 (File Create): TargetFilename=C:\Users\Public\null_test.sys. Security Event ID 4697: ServiceFileName=C:\Users\Public\null_test.sys, ServiceType=0x1. DeviceRegistryEvents: RegistryKey containing \Services\TestPathDriver, ImagePath=C:\Users\Public\null_test.sys.
- Test 3SeLoadDriverPrivilege Assignment via sc.exe (Privilege Telemetry)
Expected signal: Security Event ID 4697: ServiceName=FakePrivTest, ServiceType=0x1. Security Event ID 4672: PrivilegeList containing SeLoadDriverPrivilege assigned to the calling session's SubjectLogonId. System Event ID 7045 (New Service Installed) in System event log. sc.exe Process Create in Sysmon Event ID 1.
- Test 4Linux Kernel Module Load from Non-Standard Path (Container/Linux)
Expected signal: Auditd SYSCALL record with syscall=finit_module or init_module, uid/euid of calling process. Syslog/kern.log message: 'df00tech_test: disagrees about version of symbol module_layout' or 'insmod: ERROR: could not insert module'. Auditd WATCH record for file access to /tmp/df00tech_test.ko. /var/log/audit/audit.log entries with key=t1068_test.
- Test 5BYOVD — Enumerate Loaded Drivers for Vulnerable Candidates
Expected signal: Sysmon Event ID 1 (Process Create): driverquery.exe, sc.exe, powershell.exe executions with respective command lines. Security Event ID 4688 (if command-line auditing enabled) for same processes. WMI Activity log entries for Win32_SystemDriver query in Microsoft-Windows-WMI-Activity/Operational.
Response Playbook
Triage
- Identify the driver file: capture the full path, filename, and SHA256 hash. Check the hash against VirusTotal and the LOLDrivers project database (loldrivers.io) to confirm whether it is a known vulnerable driver
- Check the driver signature: a legitimately signed but vulnerable driver (e.g., RTCore64.sys signed by MSI) is the classic BYOVD pattern — the signature alone does not indicate legitimacy in context
- Identify who loaded the driver: examine the InitiatingProcessFileName and InitiatingProcessCommandLine fields. Was this a known software installer, or an unexpected binary (cmd.exe, powershell.exe, a staged payload)?
- Determine the user context: which account registered or loaded the driver? A standard user account loading a kernel driver is extremely anomalous. Service accounts or SYSTEM doing so via an unexpected process warrants immediate escalation
- Check for temporal proximity of privilege escalation: within minutes of the driver load, did any process transition from low/medium integrity to high/SYSTEM integrity? Look for Security Event ID 4672 (Special Logon / SeDebugPrivilege assigned) near the driver load timestamp
- Examine the filesystem origin: where did the driver file come from? Check file creation events (Sysmon Event ID 11 or DeviceFileEvents) for the .sys file to identify the dropper. Look for the file in temp directories, user profile directories, or paths outside System32/drivers
- Assess scope: was this isolated to one endpoint or seen across multiple machines? Check for the same driver SHA256 across your fleet — widespread distribution indicates an automated tool or lateral movement phase
Containment
- Isolate the endpoint immediately from the network using EDR network isolation or VLAN segmentation — kernel-level exploits may grant full system control and enable credential extraction or rootkit installation
- Stop and disable the newly registered driver service: sc stop <ServiceName> followed by sc delete <ServiceName>, then remove the .sys file from disk. Document the service name, binary path, and file hash before deletion
- If the driver is still loaded in kernel memory, a system reboot may be required to fully unload it — coordinate with the asset owner as this will cause downtime
- Revoke the credentials of any accounts active on the system at the time of the exploit, especially if SeDebugPrivilege or SeTcbPrivilege was assigned to a non-administrative account
- Block the driver hash at the endpoint security layer (EDR hash block, Windows Defender Application Control policy update) to prevent re-deployment across the fleet
- Search the entire environment for the driver SHA256 hash and for creation of the driver file path pattern — treat any other host with the same indicator as potentially compromised
Evidence Collection
- Driver file: preserve a copy of the .sys file from disk with SHA256 hash for forensic analysis and threat intelligence submission
- Sysmon Event ID 6 (Driver Loaded): contains ImageLoaded path, Hashes (MD5/SHA1/SHA256), Signed (true/false), Signature, and SignatureStatus fields — the primary forensic artifact for BYOVD
- Sysmon Event ID 1 (Process Create): the process that registered the driver service and the process that triggered the exploit — capture full command lines and parent-child chain
- Windows Security Event ID 4697 (Service Installed): contains ServiceFileName, ServiceType, ServiceStartType, and SubjectUserName — captures the service registration step
- Windows Security Event ID 4672 (Special Logon): records assignment of sensitive privileges (SeDebugPrivilege, SeLoadDriverPrivilege, SeTcbPrivilege) — correlate timestamps with driver load events
- Windows Security Event ID 4688 (Process Create with command line): if Sysmon is unavailable, use this with command-line auditing enabled
- Kernel memory dump: if post-exploitation activity is suspected, a full kernel memory dump via WinPmem or similar tool can reveal loaded kernel modules and in-memory shellcode
- Prefetch files: C:\Windows\Prefetch\ for the dropper binary and any exploit tool executables — provides first and last execution timestamps
- MFT (Master File Table) entry for the .sys file: use tools like MFTECmd to extract precise file creation timestamps and determine if the file was written before or after initial access
Escalation Criteria
- ! Known BYOVD driver confirmed via LOLDrivers SHA256 match — this indicates deliberate, pre-planned kernel exploitation, not accidental software vulnerability
- ! Driver loaded from a path consistent with a dropper (temp directory, user profile) rather than a vendor installation path — indicates active adversary use rather than a misconfigured application
- ! Security Event 4672 with SeDebugPrivilege or SeTcbPrivilege assigned to a standard user or unexpected service account within 60 seconds of the driver load
- ! Post-load process creation showing LSASS access (Sysmon Event ID 10, SourceImage != system security tools), credential dumping tools, or EDR/AV process termination — indicates the exploit achieved kernel-level control
- ! Driver load observed on multiple endpoints with the same SHA256 hash — indicates automated lateral propagation or a worm-like deployment mechanism
- ! The exploit tool or dropper was delivered via a recently opened document, email attachment, or download — indicates a full kill chain from phishing/initial access through privilege escalation
Investigation Guide
Forensic Artifacts
- >
Registry: HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName> — driver service key created during BYOVD setup; examine ImagePath, Start type (0x0 = boot, 0x1 = system, 0x3 = demand), Type (0x1 = kernel driver) - >
File System: The dropped .sys file, typically in %TEMP%, %APPDATA%, %ProgramData%, or directly in C:\Windows\System32\drivers\ if the attacker had sufficient access - >
Event Log: System Event ID 7045 (New Service Was Installed) — contains ServiceName, ServiceFileName, ServiceType, and AccountName; lower fidelity than 4697 but available without advanced audit policy - >
Event Log: Security Event ID 4697 — requires 'Audit Security System Extension' to be enabled; provides SubjectUserSid and SubjectLogonId for session correlation - >
Event Log: Security Event ID 4672 — Special Logon events showing SeLoadDriverPrivilege, SeDebugPrivilege, or SeTcbPrivilege assigned; correlate with driver load timestamp - >
Sysmon Event ID 6 (DriverLoad): the most forensically complete artifact — records exact ImageLoaded path, file hashes, Signed status, and Signature field. Stored in Microsoft-Windows-Sysmon/Operational - >
WMI: Win32_SystemDriver query — lists currently registered kernel drivers including State (Running/Stopped), PathName, and ServiceType; can be queried remotely for live response - >
UEFI/Boot log: for Secure Boot violations caused by loading unsigned or revoked drivers — check System event log for Event ID 1796 (Code Integrity) and 3001 from Microsoft-Windows-CodeIntegrity
Tuning Guidance
BYOVD detection requires careful baselining to avoid alert fatigue from legitimate hardware vendor software. Start by inventorying all kernel drivers present in your environment using a one-time query across your fleet: collect all SHA256 hashes of loaded .sys files and cross-reference against the LOLDrivers database (loldrivers.io provides a machine-readable JSON feed). Build an allowlist of hashes confirmed to be from legitimate, patched vendor software. For path-based detections, the most reliable signal is a .sys file appearing in a user-writable directory rather than C:\Windows\System32\drivers\ or a vendor program directory — this path pattern has very few legitimate explanations. For the privilege correlation hunting queries, start with a 5-minute window and expand or contract based on noise. Key exclusions: exclude driver loads initiated by msiexec.exe, setup.exe, install.exe, and update.exe binaries in vendor subdirectories of C:\Program Files\ as these are almost always legitimate installations. Do NOT exclude based on driver Signed=true alone — BYOVD specifically uses legitimately signed drivers. Ensure Sysmon Event ID 6 (Driver Loaded) is enabled in your Sysmon configuration; without it, the SPL query will miss driver load events entirely. Enable Security Event 4697 via Group Policy: Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies > System > Audit Security System Extension (Success).
Hunting Queries
Hunt for rare kernel drivers loaded on only a single device. Legitimate enterprise drivers appear across many endpoints; a .sys file seen on exactly one machine with low load count is a strong BYOVD indicator. Review the initiating process and file path for each result.
DeviceImageLoadEvents
| where Timestamp > ago(7d)
| where FileName endswith ".sys"
| summarize LoadCount=count(), Devices=make_set(DeviceName),
Paths=make_set(FolderPath), Hashes=make_set(SHA256),
Initiators=make_set(InitiatingProcessFileName)
by FileName
| where LoadCount < 5 and array_length(Devices) == 1
| extend RareDriver = true
| order by LoadCount ascindex=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=6
| eval driver_name=lower(mvindex(split(ImageLoaded, "\\"), -1))
| stats count as LoadCount, dc(host) as DeviceCount,
values(host) as Devices, values(ImageLoaded) as Paths,
values(Hashes) as Hashes, values(Signed) as SignedValues
by driver_name
| where LoadCount < 5 AND DeviceCount == 1
| sort LoadCountHunt for driver loads temporally correlated with sensitive privilege assignment (SeDebugPrivilege, SeTcbPrivilege, SeLoadDriverPrivilege within a 10-minute window). This correlation is a strong indicator that a driver exploit succeeded in elevating the process token. A driver load immediately followed by debug privilege assignment on the same host is a high-fidelity BYOVD exploitation signal.
let DriverLoads = DeviceImageLoadEvents
| where Timestamp > ago(7d)
| where FileName endswith ".sys"
| project DriverLoadTime=Timestamp, DeviceName, DriverFile=FileName,
DriverPath=FolderPath, DriverHash=SHA256, LoadInitiator=InitiatingProcessFileName;
let PrivEscEvents = SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4672
| where PrivilegeList has_any ("SeDebugPrivilege", "SeTcbPrivilege", "SeLoadDriverPrivilege")
| project PrivEscTime=TimeGenerated, DeviceName=Computer,
AccountName=SubjectUserName, LogonId=SubjectLogonId, PrivilegeList;
DriverLoads
| join kind=inner PrivEscEvents on DeviceName
| where abs(datetime_diff('minute', PrivEscTime, DriverLoadTime)) < 10
| project DriverLoadTime, PrivEscTime, DeviceName, DriverFile, DriverPath,
AccountName, PrivilegeList, LoadInitiator
| sort by DriverLoadTime descindex=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=6
| eval driver_load_time=_time, driver_path=ImageLoaded
| join type=inner host
[search index=wineventlog sourcetype="WinEventLog:Security" EventCode=4672
(PrivilegeList="*SeDebugPrivilege*" OR PrivilegeList="*SeTcbPrivilege*" OR PrivilegeList="*SeLoadDriverPrivilege*")
| eval priv_esc_time=_time
| table host, priv_esc_time, SubjectUserName, PrivilegeList]
| eval time_delta_minutes=abs(driver_load_time - priv_esc_time) / 60
| where time_delta_minutes < 10
| table driver_load_time, priv_esc_time, time_delta_minutes, host, driver_path, SubjectUserName, PrivilegeList
| sort driver_load_timeHunt for processes running at SYSTEM integrity level spawned from a parent process running at Low, Medium, or High integrity. A legitimate system service will be spawned by services.exe or svchost.exe (both at SYSTEM level). A process achieving SYSTEM integrity from a Medium-level parent is a classic exploitation indicator — the parent exploited a vulnerability to elevate its child token to SYSTEM.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessIntegrityLevel == "System"
| where InitiatingProcessIntegrityLevel in ("Low", "Medium", "High")
| where AccountName != "SYSTEM" and AccountName != "LOCAL SERVICE" and AccountName != "NETWORK SERVICE"
| where FileName !in~ (
"TrustedInstaller.exe", "MsMpEng.exe", "svchost.exe",
"wininit.exe", "services.exe", "lsass.exe", "csrss.exe"
)
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
ProcessIntegrityLevel, InitiatingProcessFileName,
InitiatingProcessIntegrityLevel, InitiatingProcessCommandLine
| sort by Timestamp descindex=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| eval integrity_level=lower(IntegrityLevel)
| eval parent_integrity=lower(ParentIntegrityLevel)
| where integrity_level="system"
| where parent_integrity IN ("low", "medium", "high")
| eval image_name=lower(mvindex(split(Image, "\\"), -1))
| where NOT (image_name IN ("trustedinstaller.exe", "msmpeng.exe", "svchost.exe", "wininit.exe", "services.exe", "lsass.exe", "csrss.exe"))
| table _time, host, User, Image, CommandLine, IntegrityLevel, ParentImage, ParentIntegrityLevel, ParentCommandLine
| sort - _timeAtomic Red Team Tests
Simulates the BYOVD preparation phase by downloading the known vulnerable Micro-Star MSI Afterburner kernel driver (RTCore64.sys) and registering it as a kernel service. This driver is well-documented in the LOLDrivers project and has been abused by ransomware groups. This test only registers the service — it does NOT exploit the driver. Run in a test environment only. Requires administrator privileges to register a kernel service.
Command
sc create RTCore64 type= kernel start= demand binPath= C:\Windows\Temp\RTCore64.sys displayname= "MSI Afterburner Test Driver"
sc query RTCore64Cleanup
sc delete RTCore64
del C:\Windows\Temp\RTCore64.sys 2>nulExpected Telemetry
Windows Security Event ID 4697 (New Service Installed): ServiceName=RTCore64, ServiceFileName=C:\Windows\Temp\RTCore64.sys, ServiceType=0x1 (Kernel Driver). Sysmon Event ID 1 (Process Create): Image=sc.exe, CommandLine containing 'create RTCore64 type= kernel'. DeviceRegistryEvents: RegistryKey containing \Services\RTCore64, RegistryValueName=ImagePath, RegistryValueData=C:\Windows\Temp\RTCore64.sys.
Expected Detection
KQL Signal 3 (SuspiciousDriverServiceRegistered) fires on RegistryValueData containing \windows\temp\ for a .sys file. KQL Signal 4 (KernelDriverServiceInstalled_4697) fires on SecurityEvent 4697 matching both KnownVulnerableDriverNames (rtcore64.sys) and SuspiciousDriverPaths (\temp\). SPL IsKnownVulnDriver=1, IsSuspiciousPath=1, DetectionSignal=KnownVulnerableDriverLoaded.
Copies a benign system driver to a temp directory to simulate the filesystem path anomaly generated by BYOVD droppers that write their vulnerable driver to user-writable locations before loading. Uses the legitimate null.sys driver which has no functional impact. This generates path-anomaly telemetry without any actual exploitation.
Command
copy C:\Windows\System32\drivers\null.sys C:\Users\Public\null_test.sys
sc create TestPathDriver type= kernel start= demand binPath= C:\Users\Public\null_test.sys displayname= "Path Test Driver"
sc query TestPathDriverCleanup
sc delete TestPathDriver
del C:\Users\Public\null_test.sys 2>nulExpected Telemetry
Sysmon Event ID 11 (File Create): TargetFilename=C:\Users\Public\null_test.sys. Security Event ID 4697: ServiceFileName=C:\Users\Public\null_test.sys, ServiceType=0x1. DeviceRegistryEvents: RegistryKey containing \Services\TestPathDriver, ImagePath=C:\Users\Public\null_test.sys.
Expected Detection
KQL Signal 3 fires on RegistryValueData containing \users\public\ for a .sys file matching SuspiciousDriverPaths. SPL IsSuspiciousPath=1, DetectionSignal=DriverLoadedFromSuspiciousPath. Hunting Query 1 (rare driver) may also trigger if null_test.sys has not been seen before in the fleet.
Uses sc.exe to attempt loading a driver binary, which causes Windows to assign SeLoadDriverPrivilege to the calling process token. This generates Event ID 4672 telemetry for the privilege correlation hunting queries without requiring a real exploit or driver. The load will fail gracefully (STATUS_DRIVER_UNABLE_TO_LOAD or access denied on non-admin), but the privilege assignment event fires during the attempt if run as admin.
Command
sc create FakePrivTest type= kernel start= demand binPath= C:\Windows\Temp\nonexistent_driver.sys
net start FakePrivTestCleanup
sc delete FakePrivTest 2>nulExpected Telemetry
Security Event ID 4697: ServiceName=FakePrivTest, ServiceType=0x1. Security Event ID 4672: PrivilegeList containing SeLoadDriverPrivilege assigned to the calling session's SubjectLogonId. System Event ID 7045 (New Service Installed) in System event log. sc.exe Process Create in Sysmon Event ID 1.
Expected Detection
Hunting Query 2 (driver load correlated with privilege assignment) will fire if this test is run on the same host as a driver load within the 10-minute window. Security Event 4697 in the SPL query fires on the service registration. The SeLoadDriverPrivilege in Event 4672 is a standalone indicator to monitor.
On Linux, simulates the kernel module exploitation preparation phase by creating a dummy .ko (kernel object) file in /tmp and attempting to load it with insmod. The module load will fail (invalid module format), but the attempt generates auditd and syslog telemetry consistent with T1068 exploitation preparation. Requires root or CAP_SYS_MODULE capability.
Command
echo 'This simulates a kernel module drop' > /tmp/df00tech_test.ko
insmod /tmp/df00tech_test.ko 2>&1 || echo 'Expected failure: invalid module format — telemetry generated'
auditctl -w /tmp -p rwxa -k t1068_test
ls -la /tmp/df00tech_test.koCleanup
rm -f /tmp/df00tech_test.ko
auditctl -W /tmp -p rwxa -k t1068_test 2>/dev/null || trueExpected Telemetry
Auditd SYSCALL record with syscall=finit_module or init_module, uid/euid of calling process. Syslog/kern.log message: 'df00tech_test: disagrees about version of symbol module_layout' or 'insmod: ERROR: could not insert module'. Auditd WATCH record for file access to /tmp/df00tech_test.ko. /var/log/audit/audit.log entries with key=t1068_test.
Expected Detection
Linux-focused detection using auditd sourcetype in Splunk: search index=linux_secure (sourcetype=linux_secure OR sourcetype=auditd) for insmod or init_module syscall from /tmp or /dev/shm paths. The file creation in /tmp followed by a kernel module load attempt from that path is the key pattern. KQL equivalent using Syslog table: Syslog | where SyslogMessage contains 'insmod' and SyslogMessage contains '/tmp/'.
Enumerates all currently loaded kernel drivers on the system and cross-references against common vulnerable driver filenames. Adversaries perform this reconnaissance step to identify if a vulnerable driver is already loaded (meaning no drop step is needed). This test is purely read-only and generates process creation telemetry for the enumeration commands.
Command
driverquery /FO LIST /SI
sc query type= driver state= all
powershell -Command "Get-WmiObject Win32_SystemDriver | Select-Object Name, PathName, State, Started | Format-Table -AutoSize"
powershell -Command "[System.IO.DriveInfo]::GetDrives() | ForEach-Object { Get-ChildItem ($_.RootDirectory.FullName + 'Windows\System32\drivers') -Filter '*.sys' -ErrorAction SilentlyContinue } | Select-Object Name, FullName | Format-Table"Expected Telemetry
Sysmon Event ID 1 (Process Create): driverquery.exe, sc.exe, powershell.exe executions with respective command lines. Security Event ID 4688 (if command-line auditing enabled) for same processes. WMI Activity log entries for Win32_SystemDriver query in Microsoft-Windows-WMI-Activity/Operational.
Expected Detection
While this specific test does not directly trigger the main detection query, it generates context for hunting: DeviceProcessEvents showing driverquery.exe and sc.exe used for driver enumeration. The WMI query against Win32_SystemDriver is a pre-exploitation reconnaissance step that can be hunted via DeviceEvents table (ActionType=WmiActivity) or Windows-WMI-Activity event log.