Unsigned kernel driver loaded

Siemphony@siemphonymediumT1014unverified

AN1061's own `DriverSignatureStatus` knob — "signed vs unsigned drivers; many environments restrict unsigned drivers, but some legacy systems allow them" — maps onto a single real field on Sysmon EventID 6: `Signed`, a boolean set from the result of the load-time signature check. An adversary loading a custom rootkit driver is loading one that was never submitted for attestation signing, so `Signed: false` is the direct, single-field expression of the knob, deliberately narrower than the service-creation and file-drop legs of the same analytic (System 7045, Sysmon 11) which this rule does not attempt, since neither carries a signature verdict at all. This is the complement of the corpus's T1068 driver rule, which explicitly does not filter on signature because a bring-your-own-vulnerable-driver load is validly signed by definition — the two rules cover opposite ends of the same `DriverLoad` event and neither substitutes for the other. Sysmon is not installed by default, and on a fleet without it this rule returns nothing, which reads as quiet rather than as the blind spot it actually is. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0377, 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=* Signed="false"

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE TO_LOWER(file.code_signature.signed) == "false"

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="Signed" type="pcre2">(?i)^false$</field>    <description>Unsigned kernel driver loaded</description>    <mitre>      <id>T1014</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: kernel_and_firmware_tampering
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: eab17826-1beb-4126-9184-c5d171c28220

ATT&CKT1014

T1014Rootkit

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.

Lessonkernel and firmware tampering

kernel and firmware tamperingAI draft — unreviewed

01 · What this rule detects

A kernel driver load event where the signature-check verdict is false. AN1061's own DriverSignatureStatus knob — "signed vs unsigned drivers; many environments restrict unsigned drivers, but some legacy systems allow them" — maps onto a single real field on Sysmon EventID 6: Signed, set from the result of the load-time signature check. A rootkit driver was never submitted for attestation signing, so Signed: false is a direct, single-field expression of the knob rather than a proxy for it.

02 · Telemetry you need

category: driver_load, product: windows — Sysmon EventID 6. Sysmon is not installed by default; on a fleet without it, this rule returns nothing, and the description is explicit that this reads as quiet rather than as the blind spot it actually is. There is no fallback log source for this leg: Windows doesn't natively log a per-driver signature verdict outside Sysmon, so unlike some rules in this corpus there's no alternate EventID to point to if Sysmon isn't an option.

03 · How the logic works

The whole rule is one field:

There's no Image gate, no path filter, no allowlist of expected driver publishers — just the boolean. That's a deliberate scope decision, not an oversight: AN1061 also covers the service-creation and file-drop legs of the same technique (System 7045, Sysmon 11), and this rule doesn't attempt either, since neither event carries a signature verdict at all to filter on. The rule is also explicitly the mirror image of the corpus's T1068 driver rule, which does not filter on signature, because a bring-your- own-vulnerable-driver load is validly signed by definition. The two rules cover opposite ends of the same DriverLoad event stream, and neither one substitutes for the other — a signed-but-vulnerable driver load will not trip this rule, and that's correct, not a gap.

04 · Common false positives

The falsepositives block names three real sources, and the first is described as "the dominant source on any fleet with an engineering population": driver development and test-signing workstations, where engineers routinely load self-signed or wholly unsigned drivers with test signing mode enabled as a normal part of their job. Second, a Sysmon- specific caveat rather than anything about the driver itself: a legitimately signed driver can still be reported unsigned if the load-time WinVerifyTrust catalog check couldn't complete — most commonly a host with no internet access for the certificate-revocation check at boot. Third, older or specialised hardware drivers — industrial equipment, legacy printers and scanners — from vendors that never adopted modern kernel-mode signing requirements, still loading on hosts kept on an older servicing branch that permits them.

05 · Detection maturity

tier_1: .** UNVERIFIED — derived from DET0377, never run against a log line. Review found no findings against this rule, but "no findings" means the logic is internally consistent, not that it has been checked against real driver-load volume on an engineering-heavy fleet.
tier_2: needs that volume check and a first pass at the test-signing and legacy-hardware allowlists before this moves past scaffold status.

Tuning & false positivesexperimental · 3 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

Start by separating engineering and test-signing hosts from the rest of the fleet — by host group or by checking whether test signing mode is enabled — since that population alone will otherwise dominate every alert. The revocation-check caveat is harder to filter directly from this one event; cross-reference repeat unsigned verdicts for the same driver hash across hosts with working internet access, which argues against it being a transient CRL failure. For the legacy-hardware source, an allowlist of known vendor driver names or hashes on the affected device classes will cut the remainder without touching the core Signed: false gate. level: medium is a reasonable starting point given how concentrated the noise is in a small number of known populations, but it assumes those populations get filtered rather than ignored.

Declared by the author

Driver development and test-signing workstations, where engineers routinely load self-signed or entirely unsigned drivers with test signing mode enabled — the dominant source on any fleet with an engineering population.
Legitimately signed drivers that Sysmon still reports as unsigned because the load-time WinVerifyTrust catalog check could not complete — most commonly a host with no internet access for the certificate-revocation check at boot, which is a known Sysmon signing-verdict caveat rather than anything about the driver itself.
Older or specialised hardware drivers (industrial equipment, legacy printers and scanners) from vendors that never adopted modern kernel-mode signing requirements, still loaded on hosts kept on an older Windows servicing branch that permits them.

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.

Verification1 run

Not verified

Security Datasets — Rootkit driver activity
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

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

Recordings of T1014, evaluated against their driver_load events.

Share this rule

/u/siemphony/eab17826-1beb-4126-9184-c5d171c28220

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.

Unsigned kernel driver loaded

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it