Driver loaded from a user-writable path or a known-abused driver

Siemphony@siemphonymediumT1068unverified

Takes the driver-load leg of MITRE's AN1419 rather than its process-creation leg: a kernel driver whose image sits in a user-writable directory instead of System32\drivers, or whose filename is one of the signed but vulnerable drivers repeatedly staged for privilege escalation. Choosing this leg is what keeps the rule from collapsing into another "service spawns a shell" analytic — the published T1210 and T1190 rules both match process_creation on a parent-child pair, and this one shares no log source, no field and no event with either. Signature status is deliberately not used as a filter, because the defining property of a bring-your-own-vulnerable-driver load is that the driver is validly signed, so SignatureStatus is Valid in exactly the case worth catching; the name list is authored here from public reporting rather than supplied by MITRE, which names only the DriverNamePattern knob, and it is defeated by renaming the .sys file, which is why the path arm carries the general case. Sysmon EventID 6 also carries no loading process, so the parent lineage in MITRE's ParentProcessPath knob and the 4672 privilege-use follow-on cannot be expressed here at all. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0514, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 3 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Splunk · SPL

Run this as a search.

index=* ((ImageLoaded="*\\Users\\*" OR ImageLoaded="*\\Windows\\Temp\\*" OR ImageLoaded="*\\ProgramData\\*" OR ImageLoaded="*\\PerfLogs\\*" OR ImageLoaded="*\\$Recycle.Bin\\*") OR (ImageLoaded="*\\dbutil_2_3.sys" OR ImageLoaded="*\\DBUtilDrv2.sys" OR ImageLoaded="*\\RTCore64.sys" OR ImageLoaded="*\\gdrv.sys" OR ImageLoaded="*\\iqvw64e.sys" OR ImageLoaded="*\\mhyprot2.sys" OR ImageLoaded="*\\procexp152.sys" OR ImageLoaded="*\\WinRing0x64.sys" OR ImageLoaded="*\\AsrDrv101.sys" OR ImageLoaded="*\\AsrDrv103.sys" OR ImageLoaded="*\\aswArPot.sys" OR ImageLoaded="*\\zam64.sys" OR ImageLoaded="*\\viragt64.sys" OR ImageLoaded="*\\truesight.sys"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(file.path) LIKE "*\\\\users\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\windows\\\\temp\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\programdata\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\perflogs\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\$recycle.bin\\\\*") OR (TO_LOWER(file.path) LIKE "*\\\\dbutil_2_3.sys" OR TO_LOWER(file.path) LIKE "*\\\\dbutildrv2.sys" OR TO_LOWER(file.path) LIKE "*\\\\rtcore64.sys" OR TO_LOWER(file.path) LIKE "*\\\\gdrv.sys" OR TO_LOWER(file.path) LIKE "*\\\\iqvw64e.sys" OR TO_LOWER(file.path) LIKE "*\\\\mhyprot2.sys" OR TO_LOWER(file.path) LIKE "*\\\\procexp152.sys" OR TO_LOWER(file.path) LIKE "*\\\\winring0x64.sys" OR TO_LOWER(file.path) LIKE "*\\\\asrdrv101.sys" OR TO_LOWER(file.path) LIKE "*\\\\asrdrv103.sys" OR TO_LOWER(file.path) LIKE "*\\\\aswarpot.sys" OR TO_LOWER(file.path) LIKE "*\\\\zam64.sys" OR TO_LOWER(file.path) LIKE "*\\\\viragt64.sys" OR TO_LOWER(file.path) LIKE "*\\\\truesight.sys"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,driver_load,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="ImageLoaded" type="pcre2">(?i)((\\Users\\|\\Windows\\Temp\\|\\ProgramData\\|\\PerfLogs\\|\\\$Recycle\.Bin\\)|(\\dbutil_2_3\.sys$|\\DBUtilDrv2\.sys$|\\RTCore64\.sys$|\\gdrv\.sys$|\\iqvw64e\.sys$|\\mhyprot2\.sys$|\\procexp152\.sys$|\\WinRing0x64\.sys$|\\AsrDrv101\.sys$|\\AsrDrv103\.sys$|\\aswArPot\.sys$|\\zam64\.sys$|\\viragt64\.sys$|\\truesight\.sys$))</field>    <description>Driver loaded from a user-writable path or a known-abused driver</description>    <mitre>      <id>T1068</id>    </mitre>  </rule></group>

Sentinel · KQL

Run this as a search.

Sentinel cannot express this construct. No Sentinel table is modelled for this logsource ({"category":"driver_load","product":"windows"}), so there is nothing honest to query. Pick a logsource this translator maps, or write the KQL by hand. The Sigma source is on the first tab, unchanged.

At a glance

Logsource: driver_load / windows
Level: medium
Category: privilege_escalation_abuse
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 8988e8fa-945a-41ce-a863-1fe0a7b49e9d

ATT&CKT1068

T1068Exploitation for Privilege Escalation

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonprivilege escalation abuse

privilege escalation abuseAI draft — unreviewed

01 · What this rule detects

AN1419 correlates a driver load with unusual process spawn and privilege-use behaviour on the same host. This rule takes only the driver-load leg: a Sysmon driver_load event that matches either selection_user_writable_path (ImageLoaded|contains one of \Users\, \Windows\Temp\, \ProgramData\, \PerfLogs\, \$Recycle.Bin\) or selection_known_abused_driver (ImageLoaded|endswith one of fourteen named .sys files), joined by condition: 1 of selection*. It catches the delivery mechanism for bring-your-own-vulnerable-driver privilege escalation specifically, not T1068 generally — the rest of the technique (win32k/kernel LPEs, token or UAC abuse, container escape, the Linux and macOS analytics in the same brief) produces no driver_load event at all.

02 · Telemetry you need

Sysmon EventID 6, category: driver_load / product: windows, copied verbatim from AN1419. Sentinel has no table modelled for this logsource; Wazuh refuses the OR across the two selections. Splunk and Elastic render both arms.

03 · How the logic works

The path arm treats any driver image loaded from a user-writable location as suspicious, since System32\drivers is where legitimate drivers live and none of the five listed paths are. The name arm lists specific .sys files repeatedly staged for privilege escalation in public reporting — dbutil_2_3.sys, RTCore64.sys, gdrv.sys, iqvw64e.sys, mhyprot2.sys, procexp152.sys, WinRing0x64.sys, and others. That list is authored here, not supplied by MITRE — the brief's DriverNamePattern knob names only the tuning point, no values. Signature status is deliberately not used as a filter: the defining property of a BYOVD load is that the driver is validly signed, so gating on SignatureStatus: Valid would exclude exactly the case worth catching.

04 · Common false positives

The reviewer's sharpest finding is structural: loading a kernel driver already requires administrator rights, and an adversary at that level defeats both arms with one action — copying the .sys into System32\drivers under a random name. The rule's own description claims the path arm "carries the general case" once the name is defeated by renaming, but the reviewer points out the path arm dies to that same copy operation, so the stated fallback is not actually one.
On volume, the path arm dominates by a wide margin: hardware-monitoring and overclocking utilities, and Process Explorer started elevated, are the rule's normal case on engineering and IT workstations, which is why level is medium rather than high. The reviewer's missed false positive is bigger still and universal rather than role-specific: Microsoft Defender's platform-update model runs WdFilter.sys and WdNisDrv.sys out of C:\ProgramData\Microsoft\Windows Defender\Platform\<version>\, so the \ProgramData\ arm matches on essentially every Windows host after every platform update. The reviewer also flagged \$Recycle.Bin\ as list padding — no reported campaign stages a driver there — and noted the name list omits several widely reported abused drivers (Capcom.sys, elrawdsk.sys, dbk64.sys, AsIO.sys, speedfan.sys).

05 · Detection maturity

tier_1: . UNVERIFIED, derived from a MITRE scaffold with no query logic, never run against a log line.
tier_2: run read-only, rank hits by `ImageLoaded`, and expect `WdFilter.sys`/`WdNisDrv.sys` and elevated Process Explorer sessions near the top — turn that ranking into the exclusion block the rule currently lacks.
tier_3: ** add the Hashes arm to survive rename-and-relocate, and build the process-creation and 4672 legs of AN1419 as a companion correlation so an alert means exploitation followed the load, not just that a driver appeared somewhere unusual.

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Split the rule conceptually before deploying: keep medium for the
Exclude C:\ProgramData\Microsoft\Windows Defender\Platform\ explicitly;
Drop \$Recycle.Bin\ or mark it speculative rather than reported.
Add a Hashes arm keyed on known vulnerable-driver hashes — EventID 6
MITRE's TimeWindow and ParentProcessPath knobs are not implemented at

Declared by the author

Hardware monitoring, overclocking and system-inspection utilities loading their own drivers as designed — RTCore64.sys under a GPU tuning tool, WinRing0x64.sys under a sensor utility, procexp152.sys whenever Process Explorer is started elevated. On engineering and IT workstations this is the normal case and the rule's dominant volume by a wide margin, which is why the level is medium rather than high.
Anti-malware and anti-rootkit products whose own driver names appear in the list, such as aswArPot.sys, which load at boot on every protected host in an estate that runs them.
Software installers, virtualisation guest tooling and driver update utilities that stage a .sys file under %ProgramData% or %TEMP% and load it there before moving it into System32\drivers.
Portable diagnostic and benchmarking tools run from a user profile or a USB path by support staff, which load their driver straight out of \Users\ and match the path arm on every run.

Noise checknot tested

No baseline event covers this rule’s log type (driver_load / windows), so the rule was never evaluated. This is missing data, not a clean result — nothing was checked either way.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verificationnone

Never run

The lab has not evaluated this composition. A run needs a dataset of its log type — a capture of the technique it claims, or the benign baseline — and not every rule has one. Some are also held back by the evaluator’s own safety limits.

Other compositions here have been run and some carry the badge — this one has not, so nothing about it has been shown either way. Read the rule and its noise check on their own terms; silence here is the absence of evidence, not evidence of a problem.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1068, evaluated against their driver_load events.

Share this rule

/u/siemphony/8988e8fa-945a-41ce-a863-1fe0a7b49e9d

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Driver loaded from a user-writable path or a known-abused driver

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it