Linux firmware flashing tool executed

Siemphony@siemphonylowT1542.002unverifiedPlaybook · Destructive impact

AN0917 names three signals on Linux: raw ioctl/write syscalls that write firmware or controller memory, "unexpected flashing tools execution", and anomalous SMART/kernel-audit firmware checksums. This rule takes only the middle one. The raw syscall leg cannot be scoped honestly with the fields this corpus has established for {product: linux, service: auditd}: a SYSCALL record for ioctl or write carries no file path (that lives on a separate PATH record auditd does not always emit for ioctl, and Sigma cannot join the two), so a bare `syscall: ioctl` or `syscall: write` selector would match nearly every process on the host — the same over-matching failure this corpus treats as equivalent to a selector that never fires. The flashing-tools leg has no such problem: it is a process-identity match with `type: SYSCALL`, `syscall: execve`, and `exe`, the same auditd EXECVE vocabulary already used for T1547.006. `flashrom`, `fwupdmgr` and `fwupdtool` are this rule's own addition, not MITRE's, chosen because unlike diagnostic tools such as `nvme` or `ethtool` — which spend most invocations on read-only inventory subcommands this ruleset has no field to distinguish from a firmware-write subcommand, since raw auditd EXECVE carries no argv this corpus has an established field for — a `flashrom` or `fwupd*` invocation has no comparably common benign read-only mode; running the binary at all is itself the observable MITRE's analytic asks for. AN0916, the Windows leg, is not attempted: its only logsource, {category: driver_load, product: windows}, carries just `ImageLoaded`, `Signed` and `Hashes`, and both ways of using them are already claimed by published siblings — `Signed: false` is T1014's rule verbatim, and a named-driver list is T1068's — so nothing distinct from either sibling remains on that logsource. AN0918, the macOS leg, is not attempted either: its only logsource, {product: macos, service: unifiedlog}, has no established Sigma field vocabulary anywhere in this corpus, the same blocker already recorded against that exact source for T1037.002, T1036.004, T1036.006, T1053.003 and others. The Linux driver-load/syslog source in AN0917 ({product: linux, service: syslog}) is also unattempted for the same reason. MITRE's `AlertThresholds` knob (SMART error tolerance) has no field to bind to here at all; `FirmwareImageBaseline` would require a checksum comparison lib/sigma cannot express. Prerequisite: raw auditd does not record execve by default; this returns nothing until a rule such as `-a always,exit -F arch=b64 -S execve -k exec` is loaded, and zero rows reads as quiet when it actually means blind. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0323, 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

1title: Linux firmware flashing tool executed2id: 76e797f2-b52e-4743-b47e-ae03b0bdbd453status: experimental4description: |5  AN0917 names three signals on Linux: raw ioctl/write syscalls that write6  firmware or controller memory, "unexpected flashing tools execution", and7  anomalous SMART/kernel-audit firmware checksums. This rule takes only the8  middle one. The raw syscall leg cannot be scoped honestly with the fields9  this corpus has established for {product: linux, service: auditd}: a10  SYSCALL record for ioctl or write carries no file path (that lives on a11  separate PATH record auditd does not always emit for ioctl, and Sigma12  cannot join the two), so a bare `syscall: ioctl` or `syscall: write`13  selector would match nearly every process on the host — the same14  over-matching failure this corpus treats as equivalent to a selector that15  never fires. The flashing-tools leg has no such problem: it is a16  process-identity match with `type: SYSCALL`, `syscall: execve`, and `exe`,17  the same auditd EXECVE vocabulary already used for T1547.006. `flashrom`,18  `fwupdmgr` and `fwupdtool` are this rule's own addition, not MITRE's, chosen19  because unlike diagnostic tools such as `nvme` or `ethtool` — which spend20  most invocations on read-only inventory subcommands this ruleset has no21  field to distinguish from a firmware-write subcommand, since raw auditd22  EXECVE carries no argv this corpus has an established field for — a23  `flashrom` or `fwupd*` invocation has no comparably common benign24  read-only mode; running the binary at all is itself the observable MITRE's25  analytic asks for. AN0916, the Windows leg, is not attempted: its only26  logsource, {category: driver_load, product: windows}, carries just27  `ImageLoaded`, `Signed` and `Hashes`, and both ways of using them are28  already claimed by published siblings — `Signed: false` is T1014's rule29  verbatim, and a named-driver list is T1068's — so nothing distinct from30  either sibling remains on that logsource. AN0918, the macOS leg, is not31  attempted either: its only logsource, {product: macos, service:32  unifiedlog}, has no established Sigma field vocabulary anywhere in this33  corpus, the same blocker already recorded against that exact source for34  T1037.002, T1036.004, T1036.006, T1053.003 and others. The Linux35  driver-load/syslog source in AN0917 ({product: linux, service: syslog}) is36  also unattempted for the same reason. MITRE's `AlertThresholds` knob (SMART37  error tolerance) has no field to bind to here at all; `FirmwareImageBaseline`38  would require a checksum comparison lib/sigma cannot express.39  Prerequisite: raw auditd does not record execve by default; this returns40  nothing until a rule such as `-a always,exit -F arch=b64 -S execve -k exec`41  is loaded, and zero rows reads as quiet when it actually means blind.42  UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0323, not hand-written and not tested by its author. Any lab result is on this rule's own page.43references:44  - https://attack.mitre.org/techniques/T1542/00245  - https://attack.mitre.org/detectionstrategies/DET032346author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)47date: 2026-08-1848tags:49  - attack.defense-evasion50  - attack.persistence51  - attack.t1542.00252logsource:53  product: linux54  service: auditd55detection:56  selection:57    type: 'SYSCALL'58    syscall: 'execve'59    exe|endswith:60      - '/flashrom'61      - '/fwupdmgr'62      - '/fwupdtool'63  condition: selection64falsepositives:65  - "Fleet firmware-management tooling: GNOME Software / KDE Discover and the systemd-managed fwupd background service invoke fwupdmgr or fwupdtool on a timer to check for and apply Linux Vendor Firmware Service updates, which is the routine, intended way most desktop distributions patch NIC, SSD, TPM and UEFI firmware."66  - "IT staff or a configuration-management run (Ansible, Puppet, cloud-init) deliberately re-flashing BIOS, EC or peripheral-controller firmware with flashrom during a break-fix, hardware-refresh or coreboot/firmware-security hardening project — this is legitimate use of the identical binary this rule matches on."67level: low

Splunk · SPL

Run this as a search.

index=* (type="SYSCALL" AND syscall="execve" AND (exe="*/flashrom" OR exe="*/fwupdmgr" OR exe="*/fwupdtool"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(type) == "syscall" AND TO_LOWER(syscall) == "execve" AND (TO_LOWER(exe) LIKE "*/flashrom" OR TO_LOWER(exe) LIKE "*/fwupdmgr" OR TO_LOWER(exe) LIKE "*/fwupdtool"))

Wazuh · XML rule

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

<group name="sigma,linux,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^SYSCALL$</field>    <field name="syscall" type="pcre2">(?i)^execve$</field>    <field name="exe" type="pcre2">(?i)(/flashrom$|/fwupdmgr$|/fwupdtool$)</field>    <description>Linux firmware flashing tool executed</description>    <mitre>      <id>T1542.002</id>    </mitre>  </rule></group>

Sentinel · KQL

Run this as a search.

Sentinel cannot express this construct. No Sentinel table is modelled for this logsource ({"product":"linux","service":"auditd"}), 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: auditd / linux
Level: low
Category: kernel_and_firmware_tampering
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 76e797f2-b52e-4743-b47e-ae03b0bdbd45

ATT&CKT1542.002

T1542.002Component 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.

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 5 fired

Fires on none of the 5 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 5 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 T1542.002, evaluated against their — events.

Using it

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

The fix the review didn't attempt but the description sets up: if the auditd pipeline captures EXECVE argument records (a0, a1, ...) in addition to the bare SYSCALL line, distinguish fwupdmgr refresh/get-updates from fwupdmgr install/update at the argument level, and exclude the read-only verbs. Without that, correlate hits against fwupd-refresh.service's schedule and suppress the predictable timer-driven ones, watching what's left. For flashrom, pair with a change-window or ticket reference rather than trying to distinguish legitimate from malicious invocation by argv alone.

Declared by the author

Fleet firmware-management tooling: GNOME Software / KDE Discover and the systemd-managed fwupd background service invoke fwupdmgr or fwupdtool on a timer to check for and apply Linux Vendor Firmware Service updates, which is the routine, intended way most desktop distributions patch NIC, SSD, TPM and UEFI firmware.
IT staff or a configuration-management run (Ansible, Puppet, cloud-init) deliberately re-flashing BIOS, EC or peripheral-controller firmware with flashrom during a break-fix, hardware-refresh or coreboot/firmware-security hardening project — this is legitimate use of the identical binary this rule matches on.

Lessonkernel and firmware tampering

kernel and firmware tamperingAI draft — unreviewed

01 · What this rule detects

AN0917 gives three Linux signals for component firmware flashing: raw ioctl/write syscalls touching firmware or controller memory, "unexpected flashing tools execution," and anomalous SMART/kernel-audit checksums. This rule implements only the middle one — execution of a known Linux firmware-flashing binary via auditd's EXECVE record. The other two Linux signals, the Windows leg (AN0916), and the macOS leg (AN0918) are all declined in the rule's description, not silently dropped: the raw-syscall leg has no path field to scope it with in this corpus's auditd vocabulary, the Windows driver-load fields are already claimed by two published siblings (T1014, T1068), and macOS unifiedlog has no established Sigma field vocabulary anywhere in the corpus yet.

02 · Telemetry you need

{product: linux, service: auditd}, the same EXECVE vocabulary this corpus already uses for T1547.006: type, syscall, and exe. Raw auditd does not record execve by default — this rule returns nothing until a rule such as -a always,exit -F arch=b64 -S execve -k exec is loaded. Zero rows here reads as quiet; it means blind.

03 · How the logic works

One selection block, three fields, implicitly ANDed: type: 'SYSCALL', syscall: 'execve', and exe|endswith against /flashrom, /fwupdmgr, /fwupdtool. Condition is just selection. Unlike the Java/Ruby-wrapper trap this pipeline watches for, exe on a SYSCALL/execve record is a straight process-identity match — these are compiled binaries invoked directly, not interpreter-launched scripts, so the endswith gate is sound as written. The three-binary list is the rule's own addition, not MITRE's. The reasoning given: diagnostic tools like nvme or ethtool spend most invocations on read-only inventory subcommands this corpus's auditd vocabulary cannot distinguish from a firmware-write subcommand, since bare EXECVE carries no argv field here. flashrom, fwupdmgr and fwupdtool were chosen instead because, in the rule's own words, none has "a comparably common benign read-only mode" — running the binary at all is treated as the observable MITRE's analytic asks for.

04 · Common false positives

The adversarial review caught a direct contradiction between that claim and the rule's own top false positive, and downgraded level from medium to low to match it. That top entry: the systemd-managed fwupd-refresh.service invokes fwupdmgr refresh on a timer — daily on Fedora, similarly elsewhere — across every managed desktop as the routine Linux Vendor Firmware Service patching mechanism. That is exactly the common, non-writing invocation the description says doesn't exist. Expect this to fire fleet-wide, on a schedule, dwarfing genuine flashing activity by volume alone.
The second listed false positive is narrower but real: IT staff or config-management runs (Ansible, Puppet, cloud-init) deliberately re-flashing BIOS, EC, or peripheral firmware with flashrom during a break-fix or hardening project — legitimate use of the identical binary.

05 · Detection maturity

tier_1: .** Machine-derived from a MITRE scaffold with no query logic behind it, and never run against a single log line — the low level is analysis of the rule's own stated false positive, not field evidence.
tier_2: means running it read-only long enough to confirm the fwupd-refresh volume and build the argv-based exclusion; only after that does raising the level back above low become defensible.

Related detections4 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/76e797f2-b52e-4743-b47e-ae03b0bdbd45

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.

Linux firmware flashing tool executed

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it