Process opens the whole-disk raw device object bypassing partitions

Siemphony@siemphonymediumT1542.003unverified

AN0428 asks for "raw access to physical drives, modification of boot records (MBR/VBR), and suspicious file creation ... within the EFI System Partition (ESP)" across two Sysmon feeds. This rule is written against the first, EventID 9 (`raw_access_thread`) and matches `Device` on whichever of the two real whole-disk device objects the caller opened. The Windows disk class driver exposes the entire physical disk two ways: `\Device\HarddiskN\DRN`, reached through the `\\.\PhysicalDriveN` symbolic link that essentially every raw-disk tool actually calls — including the malware this technique is named for; NotPetya's MBR overwrite and `dd for Windows` both open `\\.\PhysicalDrive0`, which resolves to `\Device\Harddisk0\DR0` — and the legacy `\Device\HarddiskN\Partition0` alias, the reserved logical unit representing the same unpartitioned whole disk under the older per-disk partition naming. An earlier draft of this rule matched only the Partition0 alias, which a source review found is not the path real raw-disk-access tools take — that selector would validate clean and never fire on the primary case. Both are now matched; either one bypasses every filesystem and partition boundary a normal application respects, and sector 0 of that block is the MBR, so a process opening either device object is asking for exactly the access an MBR/VBR overwrite requires. Almost nothing on a running system has a legitimate reason to address a disk that way instead of through a drive letter or a specific partition, which is what makes this a reasonably tight single-event proxy for "about to touch the boot sectors" even though it cannot see whether a write actually followed. Two honesty points follow directly from what EventID 9 records. First, its own name is RawAccessRead — Sysmon emits it for raw *read* operations issued through the `\\.\` device path, not for writes, so this rule is watching the read that precedes or accompanies a sector edit (most MBR-writing tools open the device and read the existing sectors before patching them, or share one handle for both), not the write itself; a tool that opens the device write-only and never reads is invisible here. Second, this is a Sysmon feed and needs the event enabled in whatever configuration the host is running — a bare `sysmon -i` with no config captures everything, but several widely used community configs restrict EventID 9 to a short device or process allowlist to cut noise, and a bootkit dropper outside that allowlist produces silence that reads as "clean" rather than "not being watched." This rule does not attempt AN0428's second leg (Sysmon EventID 11, ESP file creation) — a different logsource category, so it cannot share this rule — or MITRE's `KnownGoodMBRHashes` and `ESPFileWhitelist` knobs, both hash/ allowlist comparisons lib/sigma has no operator for, or the Linux leg (AN0429, `auditd`/`syslog` writes to `/dev/sda`, `/dev/nvme0n1` or EFI mounts), a separate product and therefore a separate rule. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0150, 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=* (Device="*\\Partition0" OR Device="*\\DR*")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(Device) LIKE "*\\\\partition0" OR TO_LOWER(Device) LIKE "*\\\\dr*")

Wazuh · XML rule

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

<group name="sigma,windows,raw_access_thread,">  <!-- 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="Device" type="pcre2">(?i)(\\Partition0$|\\DR)</field>    <description>Process opens the whole-disk raw device object bypassing partitions</description>    <mitre>      <id>T1542.003</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":"raw_access_thread","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: raw_access_thread / windows
Level: medium
Category: kernel_and_firmware_tampering
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 1af80580-4105-4ee4-9af3-f14cee1cdbbd

ATT&CKT1542.003

T1542.003Bootkit

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

This rule watches for a process opening a whole-disk device object directly — the raw path that bypasses every filesystem and partition boundary and lands you at sector 0, where the MBR lives. AN0428 (MITRE's analytic) describes raw disk access plus boot-record modification plus suspicious ESP file creation. This rule covers only the first leg: it fires on the open, not on a confirmed write to the boot sectors, because that's all Sysmon EventID 9 records.

02 · Telemetry you need

Sysmon EventID 9, raw_access_thread, on Windows. This is not on by default under most community Sysmon configs — several restrict EventID 9 to a short device/process allowlist specifically to cut noise, so a bootkit dropper outside that allowlist produces silence that looks like "clean" rather than "not being watched." Confirm EventID 9 is actually enabled and unrestricted before trusting a quiet result.

03 · How the logic works

Two selections, OR'ed together (1 of selection*): - selection_partition0: Device ends with \Partition0 — the legacy per-disk alias for the whole unpartitioned disk. - selection_physicaldrive: Device contains \DR — matches \Device\HarddiskN\DRN, reached in practice through the \\.\PhysicalDriveN symbolic link. The rule originally shipped with only the Partition0 selector. Adversarial review caught that this was the wrong branch to lean on: NotPetya's MBR overwrite and dd for Windows both open \\.\PhysicalDrive0, which resolves to the DR path, not Partition0. A rule matching only the legacy alias would validate cleanly, render in three backends, and never fire on the primary, documented way this technique's namesake malware and real raw-disk tools actually request access. The fix adds the DR selector alongside the original so either path trips the rule. Note also what EventID 9 actually is: despite the generic-sounding raw_access_thread category name, Sysmon's own event name is RawAccessRead — it fires on raw reads through the \\.\ device path, not writes. Most MBR-patching tools open the device and read existing sectors before or while writing (or share one handle for both), so this rule usually catches the read that precedes or accompanies the sector edit. A tool that opens the device write-only and never reads is invisible to this rule.

04 · Common false positives

The two documented false positives both open the identical device object for entirely legitimate reasons: disk-imaging and backup tools (FTK Imager, dd for Windows, Macrium Reflect, Acronis) opening \\.\PhysicalDriveN to capture or restore full images including the boot sectors, and anti-rootkit scanners (GMER, TDSSKiller, vendor UEFI/MBR modules) reading raw MBR/VBR sectors specifically to detect this exact technique — a security sweep produces the identical event as the attack. Partition managers and disk cloners (MiniTool, EaseUS, Paragon) round out the Partition0 side during routine IT maintenance. level: medium reflects that the top false positive (routine backup software) is a wide, recurring volume source, not a rare edge case.

05 · Detection maturity

tier_1: Lowest tier. This is a machine-derived scaffold, authored from MITRE's prose description and never run against a single log line — treat every claim above as a hypothesis until it has fired against real Sysmon EventID 9 data.

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

Build an allowlist of known-good backup, imaging and partition-management processes on your fleet and exclude them by Image — this is the single highest-leverage change, since backup software runs on a schedule and will otherwise dominate every match. MITRE names KnownGoodMBRHashes and ESPFileWhitelist as tuning knobs for the sibling analytic (AN0428's second leg, ESP file creation on EventID 11), but this rule doesn't implement either — lib/sigma has no hash-comparison operator, and that leg is a different logsource category entirely, so it would need a separate rule.

Declared by the author

Disk-imaging and full-disk backup tools such as FTK Imager, dd for Windows, Macrium Reflect and Acronis True Image, which open a whole-disk device object (typically \.\PhysicalDriveN, i.e. \Device\HarddiskN\DRN) to capture or restore an image that includes the boot sectors, as routine, scheduled backup activity.
Anti-rootkit and bootkit scanners themselves, including GMER, TDSSKiller and vendor UEFI/MBR scan modules, which read raw MBR and VBR sectors specifically to detect the technique this rule targets, so a security sweep produces the identical event.
Third-party partition managers and disk-cloning utilities such as MiniTool Partition Wizard, EaseUS Partition Master and Paragon Hard Disk Manager, which open Partition0 during routine resize, clone or partition-table-repair operations run by IT staff.

Noise checknot tested

No baseline event covers this rule’s log type (raw_access_thread / 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 T1542.003, evaluated against their raw_access_thread events.

Share this rule

/u/siemphony/1af80580-4105-4ee4-9af3-f14cee1cdbbd

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.

Process opens the whole-disk raw device object bypassing partitions

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it