Known BIOS/UEFI firmware flash utility launched

Siemphony@siemphonymediumT1542.001unverified

AN0275 names `fwupdate.exe` and "vendor flash tools" as the process-creation signal for a firmware write; this rule matches that binary plus the closely related AMI, Insyde and ASUS flash utilities (`afuwin.exe`/`afudos.exe`, `h2offt.exe`/`h2offtwin64.exe`, `winflash.exe`) added here to widen coverage beyond MITRE's single named example — those five are this rule's own addition, not MITRE's. The brief offers Security EventID 4688 for this leg but maps it onto the Sysmon-shaped `process_creation` category, and the rule is written in that vocabulary (`Image`, `CommandLine`); a native 4688 feed needs `NewProcessName` mapped onto `Image` and `ProcessCommandLine` onto `CommandLine` before it can match at all, and 4688 itself requires *Audit Process Creation* plus the separate *Include command line in process creation events* policy, neither on by default or in the MS/CIS baselines. AN0275's other two sources, Sysmon EventID 9 (raw disk sector writes) and EventID 11 (file creation in the EFI GUID partition), are not used here — they would need a byte-range or path baseline this rule does not attempt, so a raw `DeviceIoControl` write from a tool not on this binary list is invisible to it. The account-privilege half of the analytic ("executed from non-administrative or non-IT management accounts") is also not implemented: `process_creation` carries no reliable account-role field, so the rule flags every launch of these binaries regardless of who ran them. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0099, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 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

Sentinel · KQL

Run this as a search.

DeviceProcessEvents| where (FolderPath endswith "\\fwupdate.exe" or FolderPath endswith "\\afuwin.exe" or FolderPath endswith "\\afudos.exe" or FolderPath endswith "\\h2offt.exe" or FolderPath endswith "\\h2offtwin64.exe" or FolderPath endswith "\\winflash.exe")

Splunk · SPL

Run this as a search.

index=* (Image="*\\fwupdate.exe" OR Image="*\\afuwin.exe" OR Image="*\\afudos.exe" OR Image="*\\h2offt.exe" OR Image="*\\h2offtwin64.exe" OR Image="*\\winflash.exe")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(process.executable) LIKE "*\\\\fwupdate.exe" OR TO_LOWER(process.executable) LIKE "*\\\\afuwin.exe" OR TO_LOWER(process.executable) LIKE "*\\\\afudos.exe" OR TO_LOWER(process.executable) LIKE "*\\\\h2offt.exe" OR TO_LOWER(process.executable) LIKE "*\\\\h2offtwin64.exe" OR TO_LOWER(process.executable) LIKE "*\\\\winflash.exe")

Wazuh · XML rule

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

<group name="sigma,windows,process_creation,">  <!-- 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="Image" type="pcre2">(?i)(\\fwupdate\.exe$|\\afuwin\.exe$|\\afudos\.exe$|\\h2offt\.exe$|\\h2offtwin64\.exe$|\\winflash\.exe$)</field>    <description>Known BIOS/UEFI firmware flash utility launched</description>    <mitre>      <id>T1542.001</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: medium
Category: kernel_and_firmware_tampering
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: bfd84137-b562-43d7-b6e3-2a42b05793a5

ATT&CKT1542.001

T1542.001System Firmware

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

The launch of a named BIOS/UEFI firmware-flashing utility — the tool an attacker (or a legitimate technician) uses to write new firmware onto the board. It is a process-launch signal, not a firmware-integrity check: it tells you a flashing tool ran, not whether the flash it performed was malicious or whether it succeeded.

02 · Telemetry you need

Sysmon EventID 1 (process creation) with CommandLine/Image populated. The brief also offers Security EventID 4688 for this leg, but the rule is written in the Sysmon-shaped process_creation vocabulary (Image, CommandLine). A native 4688 feed does not slot in directly — it needs NewProcessName mapped onto Image and ProcessCommandLine onto CommandLine before this rule can match anything. And 4688 itself requires Audit Process Creation plus the separate Include command line in process creation events policy, neither on by default or in the MS/CIS baselines — without both, this rule against a native Security-log feed returns zero rows that look like "quiet" but mean "blind."

03 · How the logic works

A single selection, condition: selection, matching Image ending in any of six binaries: fwupdate.exe, afuwin.exe, afudos.exe, h2offt.exe, h2offtwin64.exe, winflash.exe. AN0275 names only fwupdate.exe and "vendor flash tools" generically as the process-creation signal; the other five — the AMI (afuwin/afudos), Insyde (h2offt/h2offtwin64), and ASUS (winflash) utilities — are this rule's own addition to widen coverage beyond MITRE's single named example, not MITRE's list. Two parts of AN0275 are deliberately not implemented. First, the other two telemetry sources it names — Sysmon EventID 9 (raw disk sector writes) and EventID 11 (file creation in the EFI GUID partition) — are unused, because matching them meaningfully needs a byte-range or path baseline this rule does not attempt. A raw DeviceIoControl firmware write performed by any tool not on the six-binary list is invisible to this rule. Second, AN0275's account-privilege condition ("executed from non-administrative or non-IT management accounts") is not implemented either: process_creation carries no reliable account-role field, so the rule fires on every launch of these binaries regardless of who ran them.

04 · Common false positives

The primary source is exactly the legitimate use case: vendor-managed firmware campaigns. Dell Command | Update, Lenovo System Update, and HP Image Assistant silently invoke these same AMI/Insyde/ASUS flash utilities during scheduled patch windows across a fleet, and each such rollout can produce a wave of matches. The second source is IT staff manually re-flashing BIOS firmware during a break-fix or hardware-refresh cycle, using the exact same OEM binary this rule matches on — there is no way from process launch alone to distinguish a technician's deliberate flash from an attacker's.

05 · Detection maturity

tier_1: Unverified — this rule has never been run against real logs and sits at the lowest DeBMM tier. It is a starting scaffold to validate against your own firmware-management tooling before it can be trusted to distinguish sanctioned patch campaigns from unauthorized flashing.

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

Suppress matches during known maintenance windows or when the parent process is a recognized vendor update agent (e.g. DellCommandUpdate.exe, HPImageAssistant.exe). If your fleet standardizes on one OEM, drop the other vendors' binaries to cut noise rather than leaving all six active. Because the account-privilege check MITRE describes isn't implemented, pair this rule downstream with an allowlist of accounts authorized to run firmware tools, and treat matches from other accounts as higher priority.

Declared by the author

Vendor-managed firmware update campaigns pushed through Dell Command | Update, Lenovo System Update or HP Image Assistant, which silently invoke these same AMI/Insyde/ASUS flash utilities during a scheduled patch window.
IT staff manually re-flashing BIOS firmware during a break-fix or hardware-refresh cycle using the OEM's own flash tool, which is legitimate use of the identical binary this rule matches on.

Noise check0 of 30 fired

Fires on none of the 30 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 30 behaviours, and the next ordinary behaviour nobody wrote down may still match.

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

Siemphony benign baseline
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 T1542.001, evaluated against their process_creation events.

Share this rule

/u/siemphony/bfd84137-b562-43d7-b6e3-2a42b05793a5

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.

Known BIOS/UEFI firmware flash utility launched

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it