Firmware flashing utility executed on an endpoint

Siemphony@siemphonymediumT1495unverifiedPlaybook · Destructive impact

Matches process creation of the native Windows utilities that write to system or peripheral flash — the AMI and Intel BIOS programmers, vendor BIOS update executables, the open-source flashrom port, and the GPU VBIOS flashers — which is the first clause of the analytic and the only clause that is a single event. The list spans vendors and bitness variants rather than one name because it is authored here from the utilities that are redistributed as standalone binaries. It is not MITRE's: the `ToolName` knob belongs to the Linux analytic AN0475, while the Windows analytic this rule follows (AN0474) names `ParentImage` and `CommandLine`, and both are left for the reader to add as a filter — the first is what separates a vendor update chain from a hand-run flash, the second is MITRE's note that silent or forced flash flags vary by tool. A renamed or newly signed flasher defeats it, and Python-launched tooling such as chipsec is invisible on process creation because the recorded image is the interpreter. The analytic's second clause — raw access to the firmware device path, or a boot-configuration change in the same window — is a correlation Sigma cannot express, and the elevation test it also describes is omitted because the two feeds disagree on how to express it. The rule is written in the Sysmon EventID 1 process-creation vocabulary (`Image`); the Security EventID 4688 feed the analytic names calls the same path `NewProcessName` and needs a field mapping first, plus *Audit Process Creation*, which is not enabled in a default install or in the MS and CIS baselines. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0167, 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

1title: Firmware flashing utility executed on an endpoint2id: 6014f108-64b1-41b7-ac74-384e2d53d2e23status: experimental4description: |5  Matches process creation of the native Windows utilities that write to system6  or peripheral flash — the AMI and Intel BIOS programmers, vendor BIOS update7  executables, the open-source flashrom port, and the GPU VBIOS flashers — which8  is the first clause of the analytic and the only clause that is a single event.9  The list spans vendors and bitness variants rather than one name because it is10  authored here from the utilities that are redistributed as standalone binaries.11  It is not MITRE's: the `ToolName` knob belongs to the Linux analytic AN0475,12  while the Windows analytic this rule follows (AN0474) names `ParentImage` and13  `CommandLine`, and both are left for the reader to add as a filter — the first14  is what separates a vendor update chain from a hand-run flash, the second is15  MITRE's note that silent or forced flash flags vary by tool. A renamed or newly signed flasher defeats16  it, and Python-launched tooling such as chipsec is invisible on process17  creation because the recorded image is the interpreter. The analytic's second18  clause — raw access to the firmware device path, or a boot-configuration change19  in the same window — is a correlation Sigma cannot express, and the elevation20  test it also describes is omitted because the two feeds disagree on how to21  express it. The rule is written in the Sysmon EventID 1 process-creation22  vocabulary (`Image`); the Security EventID 4688 feed the23  analytic names calls the same path `NewProcessName` and needs a field mapping24  first, plus *Audit Process Creation*, which is not enabled in a default25  install or in the MS and CIS baselines.26  UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0167, not hand-written and not tested by its author. Any lab result is on this rule's own page.27references:28  - https://attack.mitre.org/techniques/T149529  - https://attack.mitre.org/detectionstrategies/DET016730author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)31date: 2026-08-1632tags:33  - attack.impact34  - attack.t149535logsource:36  category: process_creation37  product: windows38detection:39  selection:40    Image|endswith:41      - '\flashrom.exe'42      - '\afuwin.exe'43      - '\afuwinx64.exe'44      - '\afuwingui.exe'45      - '\fpt.exe'46      - '\fptw.exe'47      - '\fptw64.exe'48      - '\flash64w.exe'49      - '\winflash.exe'50      - '\winflash64.exe'51      - '\nvflash.exe'52      - '\nvflash64.exe'53      - '\amdvbflash.exe'54      - '\atiflash.exe'55  condition: selection56falsepositives:57  - "Fleet BIOS and firmware update campaigns. Vendor update packages and their management agents invoke these exact binaries under SYSTEM during a maintenance window, so a scheduled BIOS rollout matches on every host it touches — the loudest source by volume, and the reason this rule is not rated higher. Separate it by parent process and by whether the run falls inside a change window rather than by the tool name."58  - "Hardware validation, repair and imaging benches, where technicians reflash boards and GPUs as routine work, so the same binaries run daily on a small set of known workstations."59  - "Engineering and firmware-development workstations, where flashrom is run against an external programmer or a development board many times a day, and the target is not the host's own system flash at all."60  - "Enthusiast GPU VBIOS flashing on developer, CAD and lab machines, where amdvbflash or nvflash is run by the logged-on user to change fan or power tables."61level: medium

Sentinel · KQL

Run this as a search.

DeviceProcessEvents| where (FolderPath endswith "\\flashrom.exe" or FolderPath endswith "\\afuwin.exe" or FolderPath endswith "\\afuwinx64.exe" or FolderPath endswith "\\afuwingui.exe" or FolderPath endswith "\\fpt.exe" or FolderPath endswith "\\fptw.exe" or FolderPath endswith "\\fptw64.exe" or FolderPath endswith "\\flash64w.exe" or FolderPath endswith "\\winflash.exe" or FolderPath endswith "\\winflash64.exe" or FolderPath endswith "\\nvflash.exe" or FolderPath endswith "\\nvflash64.exe" or FolderPath endswith "\\amdvbflash.exe" or FolderPath endswith "\\atiflash.exe")

Splunk · SPL

Run this as a search.

index=* (Image="*\\flashrom.exe" OR Image="*\\afuwin.exe" OR Image="*\\afuwinx64.exe" OR Image="*\\afuwingui.exe" OR Image="*\\fpt.exe" OR Image="*\\fptw.exe" OR Image="*\\fptw64.exe" OR Image="*\\flash64w.exe" OR Image="*\\winflash.exe" OR Image="*\\winflash64.exe" OR Image="*\\nvflash.exe" OR Image="*\\nvflash64.exe" OR Image="*\\amdvbflash.exe" OR Image="*\\atiflash.exe")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(process.executable) LIKE "*\\\\flashrom.exe" OR TO_LOWER(process.executable) LIKE "*\\\\afuwin.exe" OR TO_LOWER(process.executable) LIKE "*\\\\afuwinx64.exe" OR TO_LOWER(process.executable) LIKE "*\\\\afuwingui.exe" OR TO_LOWER(process.executable) LIKE "*\\\\fpt.exe" OR TO_LOWER(process.executable) LIKE "*\\\\fptw.exe" OR TO_LOWER(process.executable) LIKE "*\\\\fptw64.exe" OR TO_LOWER(process.executable) LIKE "*\\\\flash64w.exe" OR TO_LOWER(process.executable) LIKE "*\\\\winflash.exe" OR TO_LOWER(process.executable) LIKE "*\\\\winflash64.exe" OR TO_LOWER(process.executable) LIKE "*\\\\nvflash.exe" OR TO_LOWER(process.executable) LIKE "*\\\\nvflash64.exe" OR TO_LOWER(process.executable) LIKE "*\\\\amdvbflash.exe" OR TO_LOWER(process.executable) LIKE "*\\\\atiflash.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)(\\flashrom\.exe$|\\afuwin\.exe$|\\afuwinx64\.exe$|\\afuwingui\.exe$|\\fpt\.exe$|\\fptw\.exe$|\\fptw64\.exe$|\\flash64w\.exe$|\\winflash\.exe$|\\winflash64\.exe$|\\nvflash\.exe$|\\nvflash64\.exe$|\\amdvbflash\.exe$|\\atiflash\.exe$)</field>    <description>Firmware flashing utility executed on an endpoint</description>    <mitre>      <id>T1495</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: medium
Category: impact_destruction
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 6014f108-64b1-41b7-ac74-384e2d53d2e2

ATT&CKT1495

T1495Firmware Corruption

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.

Evidence

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

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.

Test it yourselfin your browser

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

Recordings of T1495, evaluated against their process_creation events.

Using it

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

MITRE gives AN0474 two knobs: ParentImage, with the note that legitimate flash tool chains can be allowlisted, and CommandLine, with the note that silent or forced flash flags vary by tool. The rule uses neither, which is its main weakness — every false positive above is separated by parent or by host, and none of that is reachable without editing the detection. Add a filter block on ParentImage naming your update agent and switch the condition to selection and not filter, then scope the benches by hostname upstream. The fourteen image names are the pipeline's own, not MITRE's; the ToolName knob often cited here belongs to AN0475, the Linux analytic.

Declared by the author

Fleet BIOS and firmware update campaigns. Vendor update packages and their management agents invoke these exact binaries under SYSTEM during a maintenance window, so a scheduled BIOS rollout matches on every host it touches — the loudest source by volume, and the reason this rule is not rated higher. Separate it by parent process and by whether the run falls inside a change window rather than by the tool name.
Hardware validation, repair and imaging benches, where technicians reflash boards and GPUs as routine work, so the same binaries run daily on a small set of known workstations.
Engineering and firmware-development workstations, where flashrom is run against an external programmer or a development board many times a day, and the target is not the host's own system flash at all.
Enthusiast GPU VBIOS flashing on developer, CAD and lab machines, where amdvbflash or nvflash is run by the logged-on user to change fan or power tables.

Lessonimpact destruction

impact destructionAI draft — unreviewed

01 · What this rule detects

The rule matches process creation of a firmware-flashing utility on a Windows endpoint — the AMI and Intel programmers, vendor BIOS updaters, the flashrom port and the GPU VBIOS flashers. That is the first clause of MITRE's Windows analytic AN0474 and the only clause that is a single event. Be clear about what it does not see. It sees a flashing tool starting, never a flash happening, and never a flash that corrupts. The same event is equally the observable for T1542.001 (System Firmware, persistence) — only the image written distinguishes destruction from implantation, and process creation cannot see the image.

02 · Telemetry you need

The logsource is process_creation / windows, and the rule is written in the Sysmon EventID 1 vocabulary: it selects on Image. This matters more than usual here. AN0474's only process-creation source is Security EventID 4688, which calls that path NewProcessName, so on an estate audited exactly as MITRE describes the rendered queries return zero rows — and zero rows reads as quiet when it means blind. To run this you need Sysmon deployed with EventID 1 unfiltered; a 4688-only estate needs the Image-to-NewProcessName mapping added to the pipeline first, plus Audit Process Creation, which is off in a default install and in the MS and CIS baselines. AN0474's second source, Sysmon EventID 6 (driver_load), is untouched by this rule.

03 · How the logic works

One selection block, one field. Image|endswith carries fourteen entries, each prefixed with a backslash so it anchors to the filename rather than matching anywhere in the path: flashrom.exe; the AMI family afuwin, afuwinx64, afuwingui; Intel's fpt, fptw, fptw64; vendor updaters flash64w, winflash, winflash64; and the GPU flashers nvflash, nvflash64, amdvbflash, atiflash. condition: selection. No filter block ships. Two clauses of the analytic are absent. The correlation half — raw write to the firmware device path or a boot-configuration change in the same window — needs a join and a timeframe that Sigma as modelled here does not express. The elevation half is dropped because it would not discriminate: fleet BIOS rollouts run as SYSTEM and pass any elevation gate the attacker's run passes. The list is brittle by construction. A renamed or freshly signed flasher walks past it, AFUWINGUIx64.exe is missed by the afuwingui entry, and Python-launched tooling such as chipsec is invisible because the recorded image is the interpreter. OEM update wrappers under per-model names (Lenovo WINUPTP, HP HPBIOSUPDREC) are out of scope by design.

04 · Common false positives

The loudest source by a wide margin is the legitimate one: a fleet BIOS campaign, where a management agent invokes these exact binaries under SYSTEM on every host it touches. That is why the rule is medium and not higher. Behind it sit repair and imaging benches, where technicians reflash boards daily on a known set of workstations; firmware-development machines running flashrom against an external programmer many times a day, not against the host's own flash; and enthusiast GPU VBIOS flashing on CAD and lab machines.

05 · Detection maturity

tier_1: Lowest tier. This rule has never been executed against a log line: no true positive, no measured false-positive rate, no field validation. Treat it as a scaffold to instrument and test, not as coverage for T1495.

Related detections2 nearby

Ranked by how alike the detection logic reads, computed offline. Proximity is not evidence — each of these carries its own verification state on its own page.

Share this rule

/u/siemphony/6014f108-64b1-41b7-ac74-384e2d53d2e2

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.

Firmware flashing utility executed on an endpoint

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it