Firmware Corruption
Adversaries may overwrite or corrupt the flash memory contents of system BIOS or other firmware in devices attached to a system in order to render them inoperable or unable to boot, thus denying the availability to use the devices and/or the system. Firmware is software that is loaded and executed from non-volatile memory on hardware devices in order to initialize and manage device functionality. These devices may include the motherboard, hard drive, or video cards. Real-world examples include TrickBot's 'Trickboot' module (2020), which can write or erase UEFI/BIOS firmware of a compromised device, and Bad Rabbit ransomware, which installed a modified bootloader to prevent normal boot-up. Firmware corruption often results in permanent hardware denial-of-availability and may be combined with data destruction for maximum impact.
What is T1495 Firmware Corruption?
Firmware Corruption (T1495) maps to the Impact tactic — the adversary is trying to manipulate, interrupt, or destroy your systems and data in MITRE ATT&CK.
This page provides production-ready detection logic for Firmware Corruption, covering the data sources and telemetry it touches: Process: Process Creation, Command: Command Execution, Microsoft Defender for Endpoint. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Impact
- Technique
- T1495 Firmware Corruption
- Canonical reference
- https://attack.mitre.org/techniques/T1495/
let FirmwareToolNames = dynamic([
"rw.exe", "rw64.exe", "rweverything.exe",
"chipsec.exe", "chipsec_main.exe",
"flashrom.exe",
"fpt.exe", "fptw.exe", "fptw64.exe",
"afuwin.exe", "afuwin64.exe", "afudos.exe",
"meinfo.exe", "meinfowin.exe", "meinfowin64.exe",
"amidewin.exe", "amidewin64.exe",
"h2offt.exe", "h2offt-w.exe",
"winphlash.exe", "winphlash64.exe",
"ubuild.exe", "ubu.exe"
]);
let FirmwareWritePatterns = dynamic([
"--write", "--erase", "--flash",
"spi write", "spi.write", "spi_write",
"bios write", "uefi write", "flash write",
"nvram write", "WRITESPI", "/WRITESPI",
"chipsec_util spi write",
"flashrom -w", "flashrom --write"
]);
let SuspiciousParents = dynamic([
"cmd.exe", "powershell.exe", "pwsh.exe",
"wscript.exe", "cscript.exe", "mshta.exe",
"explorer.exe"
]);
// Signal 1: Execution of known firmware manipulation tools
let FirmwareToolExec = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName has_any (FirmwareToolNames)
| extend Signal = "KnownFirmwareTool"
| extend RiskDetail = strcat("Firmware tool executed: ", FileName);
// Signal 2: Command-line patterns indicating firmware write or erase operations
let FirmwareWriteCmd = DeviceProcessEvents
| where Timestamp > ago(24h)
| where ProcessCommandLine has_any (FirmwareWritePatterns)
| extend Signal = "FirmwareWriteOperation"
| extend RiskDetail = strcat("Write/erase flag in command: ", ProcessCommandLine);
// Signal 3: PowerShell-based UEFI variable modification or BCD tampering
let UEFITamper = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any (
"Set-SecureBootUEFI", "Set-UEFIVariable",
"bcdedit /set", "bcdedit /delete", "bcdedit /deletevalue"
)
| extend Signal = "UEFIOrBCDTamper"
| extend RiskDetail = "PowerShell UEFI variable or BCD modification";
// Combine all signals and enrich with context
union FirmwareToolExec, FirmwareWriteCmd, UEFITamper
| extend SuspiciousParent = InitiatingProcessFileName has_any (SuspiciousParents)
| extend IsSystemAccount = AccountName =~ "SYSTEM"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine,
Signal, RiskDetail, SuspiciousParent, IsSystemAccount
| sort by Timestamp desc Detects execution of known firmware manipulation tools and command-line patterns indicating BIOS/UEFI firmware write or erase operations. Three signals are combined: (1) process creation of named firmware tools including RW-Everything, CHIPSEC, flashrom, and vendor utilities (Intel FPT, AMI AfuWin, Insyde H2OFFT, WinPhlash); (2) command-line arguments containing firmware write or erase operations against SPI/BIOS/UEFI/NVRAM targets; (3) PowerShell-based UEFI variable modification (Set-SecureBootUEFI, Set-UEFIVariable) or Boot Configuration Data tampering via bcdedit. Results include parent process and account context to help analysts distinguish legitimate vendor updates from malicious activity.
Data Sources
Required Tables
False Positives
- Legitimate firmware updates performed by IT or hardware teams using vendor tools (Dell Command Update, HP BIOSConfigUtility, Lenovo Vantage, Intel ME FW Recovery Tool) during approved maintenance windows
- Security research or firmware auditing environments where CHIPSEC or RW-Everything are deployed for authorized vulnerability assessment or UEFI security analysis
- OEM factory imaging or provisioning systems that perform BIOS flashing as part of hardware configuration pipelines, typically under a service account from a management process
- Automated asset management tools that invoke bcdedit to configure boot options during operating system deployment or repair workflows (e.g., WDS, MDT, SCCM OSD)
Sigma rule & cross-platform mapping
The detection logic for Firmware Corruption (T1495) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: process_creation
product: windows Browse the community-maintained Sigma rules for this technique:
Platform-specific guides for T1495
References (8)
- https://attack.mitre.org/techniques/T1495/
- https://securelist.com/bad-rabbit-ransomware/82851/
- https://eclypsium.com/research/trickbot-now-offers-trickboot-persist-brick-profit/
- https://www.cisa.gov/uscert/ncas/alerts/aa22-057a
- https://cyber.dhs.gov/assets/report/ar-16-20173.pdf
- https://chipsec.github.io/
- https://www.flashrom.org/
- https://web.archive.org/web/20190508170055/https://www.symantec.com/security-center/writeup/2000-122010-2655-99
Testing Methodology
Validate this detection against 5 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1CHIPSEC UEFI Variable Enumeration — Read-Only Firmware Reconnaissance
Expected signal: Sysmon Event ID 1: Process Create with Image=python.exe, CommandLine containing 'chipsec_util.py uefi var-list'. Sysmon Event ID 6: Driver load for chipsec.sys (or chipsec_hlpr.sys) from a temp or install directory. Security Event ID 7045: New service installed for the CHIPSEC kernel driver. Windows may prompt for UAC on driver installation.
- Test 2RW-Everything Hardware Access Tool Execution with Ring-0 Driver Load
Expected signal: Sysmon Event ID 1: Process Create with Image=Rw.exe and CommandLine containing '/Command="PCI 0 0 0 0 10"'. Sysmon Event ID 6: Driver load for rw.sys from tool directory or System32\drivers\. Security Event ID 7045: New service named 'RW' registered pointing to rw.sys. Service exits after tool completes but driver load telemetry persists.
- Test 3PowerShell BCD Store Modification — Bad Rabbit Bootloader Tamper Simulation
Expected signal: Sysmon Event ID 1: Process Create for powershell.exe with CommandLine containing 'bcdedit /set' and ExecutionPolicy Bypass. Two additional Sysmon EventCode=1 events for bcdedit.exe child processes. Security Event ID 4688 (if command-line auditing enabled) for both bcdedit invocations. PowerShell ScriptBlock Log Event ID 4104 capturing the full command.
- Test 4Linux flashrom SPI Flash Probe — Non-Destructive Hardware Reconnaissance
Expected signal: Linux auditd EXECVE record with a=flashrom, argv containing '-p', 'internal', '--no-action', '-V'. Syslog entry capturing sudo invocation and flashrom execution. On systems with Sysmon for Linux (EventID 1): Process Create event for flashrom. /var/log/auth.log entry recording sudo authentication for the flashrom command.
- Test 5Intel Flash Programming Tool (FPT) Flash Descriptor Read
Expected signal: Sysmon Event ID 1: Process Create with Image=fptw64.exe, CommandLine containing '-DESC -d'. Sysmon Event ID 11: File Create event for df00tech_flashdesc.bin in %TEMP%. Security Event ID 7045 may appear if FPT installs a kernel service for hardware access. The .bin file size will reflect the flash descriptor region size (typically 4KB).
Response Playbook
Triage
- Identify the specific firmware tool detected — determine if it is a vendor-supplied update utility (Dell Command Update, HP BIOSConfigUtility, Lenovo Vantage) indicating legitimate maintenance, a generic hardware access tool like RW-Everything or CHIPSEC indicating high risk, or a known threat actor module component indicating critical severity
- Examine the full command-line arguments — read-only operations (e.g., 'chipsec_util spi read', RW-Everything in read mode, flashrom --read) are lower severity; any --write, --erase, --flash, or equivalent write-flag arguments indicate active firmware modification and should be escalated immediately
- Trace the parent process chain — firmware tools spawned by cmd.exe, powershell.exe, mshta.exe, or unknown binaries from user-writable paths are highly suspicious; tools launched by vendor update services (DellClientManagementService, HPSoftwareFramework, LenovoService) with a service account are likely legitimate
- Verify against change management records — was this device scheduled for firmware maintenance? Contact the device owner and IT asset management to confirm whether an authorized update was in progress; any unscheduled firmware tool execution should be treated as suspicious
- Review recent process history on the device for the 24 hours prior — look for preceding credential access (LSASS access, credential dumping), privilege escalation, or lateral movement that may indicate the firmware tool was deployed as a late-stage destructive payload in a multi-stage attack
- Check for network activity from the firmware tool process — TrickBot's Trickboot module retrieved firmware write functionality from C2; any outbound network connection from a firmware utility is anomalous and indicates remote-controlled firmware tampering
Containment
- Immediately isolate the endpoint from the network via EDR network isolation or emergency VLAN quarantine to prevent further C2 communication, additional payload retrieval, and potential lateral spread to other devices
- Do NOT reboot the device — if a firmware write is in progress or has completed, rebooting may render the device permanently unbootable; preserve current power state for forensic imaging and evidence collection before any recovery attempt
- Terminate the firmware tool process via EDR kill process capability to halt any in-progress write operation — document the exact process ID, parent chain, and command line before termination
- If the firmware tool was deployed by a remote execution mechanism (scheduled task, lateral movement service, WMI subscription), disable the originating account in Active Directory and revoke all active Kerberos tickets and OAuth tokens immediately
- Identify all devices that had network connections with the affected host in the 24–72 hours preceding detection; assess whether the same firmware tool or payload was deployed laterally across multiple endpoints as part of an automated destructive campaign
- If firmware corruption is confirmed after a reboot (device fails to POST or boot), quarantine the physical device, initiate hardware recovery procedures, and contact the vendor for firmware recovery via hardware SPI programmer, recovery USB, or chassis intrusion-based flash recovery
Evidence Collection
- Capture full process memory of the firmware tool process via EDR live response or a memory acquisition tool (WinPmem, RAMMap) before killing the process — memory may contain decrypted C2 addresses, firmware image buffers, or embedded configuration identifying the attacker's targeting criteria
- Collect all files in the same directory as the firmware tool executable — look for firmware image files (.bin, .rom, .fd, .cap, .img) which may contain the malicious payload intended for flashing; hash all files and submit .bin/.rom files to firmware security researchers (Binarly, Eclypsium) for analysis
- Retrieve current UEFI variable state using CHIPSEC (chipsec_util uefi var-list) or OS-native tools (Linux: efivar -l; Windows: Confirm-SecureBootUEFI, Get-SecureBootUEFI) and compare against a known-good baseline to identify tampered UEFI variables
- Collect Sysmon Event ID 1 (Process Create), Event ID 6 (Driver Load), and Event ID 11 (File Create) logs for the 24 hours prior to detection to reconstruct the full execution chain and identify all tool components dropped to disk
- Retrieve Windows Security Event ID 7045 (new service installed) and Event ID 4697 logs — firmware tools typically register a kernel driver as a short-lived service for ring-0 access; the service registration event captures the driver binary path
- Collect prefetch files for the firmware tool executable from C:\Windows\Prefetch\<TOOLNAME>.EXE-*.pf — confirms the precise execution timestamp and DLLs or driver files loaded during execution
- Image the SPI flash contents using a hardware SPI programmer (Dediprog SF100, FlashcatUSB) if available — preserve the current (potentially corrupted) firmware image before any recovery attempt for forensic chain-of-custody and comparison to known-good vendor firmware
- Collect Windows Security Event ID 4688 (Process Creation with command line) from the Security event log as a secondary corroboration source if Sysmon was not deployed on the affected endpoint
Escalation Criteria
- ! Command line contains explicit write or erase flags (--write, --erase, spi write, WRITESPI) targeting BIOS/UEFI/SPI flash regions — this constitutes active firmware modification and requires immediate critical incident response
- ! Device fails to POST or boot following firmware tool execution — potential successful firmware corruption; initiate critical hardware recovery procedures and treat as a P1 incident
- ! Firmware tool was identified as part of a known malware family payload (TrickBot Trickboot module, Bad Rabbit bootloader installer, wiper malware component) — indicates a targeted destructive campaign, escalate to CIRT and threat intelligence team immediately
- ! Multiple devices showing the same firmware tool execution pattern within a short time window (30 minutes or less) — indicates automated lateral spread with coordinated destructive intent, escalate to full-enterprise response
- ! Ring-0 hardware access driver (rw.sys, winio.sys, physmem.sys, rtcore64.sys) loaded by a non-vendor process or from a non-standard path outside C:\Windows\System32\drivers\ — kernel-level hardware access obtained outside of an expected update context is a critical escalation indicator
- ! Firmware tool execution was preceded by credential dumping, domain controller compromise, or lateral movement to multiple hosts — indicates adversary achieved deep enterprise access and is executing a destructive final stage designed to deny recovery
Investigation Guide
Forensic Artifacts
- >
Firmware tool executables on disk: search for rw.exe, chipsec.exe, flashrom.exe, fpt.exe, fptw64.exe, afuwin.exe, h2offt.exe, winphlash.exe and variants in %TEMP%, %APPDATA%, C:\ProgramData, C:\Users\Public, or alongside other malware components - >
Firmware image files (.bin, .rom, .fd, .cap, .img) dropped alongside tool executables — may contain the target firmware payload intended for flashing; file size (typically 4MB–32MB for UEFI images) can help distinguish from other binary files - >
Ring-0 hardware access kernel drivers: rw.sys, rwdrv.sys, winio.sys, winio32.sys, winio64.sys, physmem.sys, pmem.sys in C:\Windows\System32\drivers\ or non-standard paths — presence indicates kernel-level hardware access was obtained - >
Windows Security Event ID 7045 (Service Control Manager: new service installed) and Event ID 4697 (Security: new service installed) — firmware tools register kernel drivers as services; look for single-use services with random or generic names pointing to temp-path driver binaries - >
Prefetch files at C:\Windows\Prefetch\<TOOLNAME>.EXE-*.pf — confirm execution timestamps and DLLs or driver files loaded, including the ring-0 driver path - >
UEFI variable storage: Linux: /sys/firmware/efi/efivars/ directory and efivar CLI output; Windows: CHIPSEC uefi var-list or Get-SecureBootUEFI — compare against vendor baseline to identify tampered UEFI variables including SecureBoot, BootOrder, and db/dbx signature databases - >
USN Journal ($USNJRNL) entries for firmware binary, driver, and image files — provides precise creation and modification timestamps to reconstruct attack timeline - >
TrickBot-specific artifacts: TrickBot Trickboot module stored as a PE DLL often named mailsearcher32.dll, squirrel32.dll, or similar; configuration file containing RW_EVERYTHING references or chipsec shellcode
Tuning Guidance
Firmware corruption detection requires careful allowlisting to suppress legitimate vendor-driven update activity. Start by inventorying your environment's firmware update mechanisms: identify which vendor tools are deployed (Dell Command Update, HP BIOSConfigUtility, Lenovo System Update, Intel ME FW Recovery Tool) and their expected parent processes (vendor-specific update services, SCCM/Intune deployment processes, scripted maintenance). Create allowlist exceptions based on the full execution chain — grandparent service name + parent process + child tool binary + expected working directory — rather than just the tool name alone. Scheduled maintenance windows should be correlated against change management records; any firmware tool execution outside approved windows should be treated as high priority regardless of context. For ring-0 driver detection (Sysmon EventCode=6), maintain a hash-based allowlist of expected vendor driver SHA256 values rather than name-based matching, since driver filenames are easily spoofed by adversaries using BYOVD techniques. The compound signal of a firmware tool load followed by a ring-0 driver load from the same process within 60 seconds is a high-confidence behavioral pattern that should be treated as critical regardless of allowlist context. On Linux endpoints, supplement Windows-focused detections by monitoring for processes accessing /dev/mem, /dev/sda, or writing to /sys/firmware/efi/efivars/ with write permissions outside of package-manager-controlled update processes (apt, yum, dnf, fwupd).
Hunting Queries
Hunt for loading of ring-0 hardware access drivers commonly used by firmware tools and abused in BYOVD (Bring Your Own Vulnerable Driver) attacks. These drivers provide direct access to physical memory and hardware I/O ports, which is required for SPI flash write operations. Their presence outside of a known-good vendor update context is a strong indicator of firmware tampering preparation or active exploitation.
DeviceImageLoadEvents
| where Timestamp > ago(7d)
| where FileName in~ (
"rw.sys", "rwdrv.sys",
"winio.sys", "winio32.sys", "winio64.sys",
"physmem.sys", "pmem.sys",
"dbutil_2_3.sys", "rtcore64.sys",
"kprocesshacker.sys"
)
| project Timestamp, DeviceName, FileName, FolderPath,
InitiatingProcessFileName, InitiatingProcessCommandLine,
InitiatingProcessAccountName, SHA256
| sort by Timestamp desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=6
(ImageLoaded="*\\rw.sys" OR ImageLoaded="*\\rwdrv.sys" OR ImageLoaded="*\\winio.sys" OR ImageLoaded="*\\winio32.sys" OR ImageLoaded="*\\winio64.sys" OR ImageLoaded="*\\physmem.sys" OR ImageLoaded="*\\pmem.sys" OR ImageLoaded="*\\dbutil_2_3.sys" OR ImageLoaded="*\\rtcore64.sys")
| eval IsSigned=if(Signed="true", "yes", "no")
| table _time, host, User, Image, ImageLoaded, IsSigned, Signature, SignatureStatus, Hashes
| sort - _time Hunt for repeated BIOS and firmware reconnaissance via WMI or PowerShell. Adversaries performing firmware version fingerprinting before a targeted attack query Win32_BIOS, Win32_BaseBoard, or SMBIOS data to identify vulnerable firmware versions worth targeting. Multiple queries from a single non-administrative account, from scripting hosts, or across multiple devices within a short time window is anomalous and may indicate pre-attack firmware enumeration.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any (
"Win32_BIOS", "Win32_BaseBoard", "Win32_ComputerSystemProduct",
"Get-WmiObject", "Get-CimInstance"
)
| where ProcessCommandLine has_any ("BIOS", "BIOSVersion", "SMBIOSBIOSVersion", "Firmware")
| summarize QueryCount=count(), Devices=dcount(DeviceName),
FirstSeen=min(Timestamp), LastSeen=max(Timestamp),
SampleCommands=make_set(ProcessCommandLine, 5)
by AccountName, FileName, bin(Timestamp, 1h)
| where QueryCount > 3
| sort by QueryCount desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
(CommandLine="*Win32_BIOS*" OR CommandLine="*Win32_BaseBoard*" OR CommandLine="*SMBIOSBIOSVersion*" OR CommandLine="*BIOSVersion*" OR (CommandLine="*Get-WmiObject*" AND CommandLine="*BIOS*") OR (CommandLine="*Get-CimInstance*" AND CommandLine="*BIOS*"))
| stats count as QueryCount, dc(host) as Devices, earliest(_time) as FirstSeen, latest(_time) as LastSeen, values(CommandLine) as SampleCommands by User, Image, bin(_time, 1h)
| where QueryCount > 3
| sort - QueryCount Hunt for firmware image files (.bin, .rom, .fd, .cap) written to suspicious user-writable directories by non-system processes. Adversaries staging a firmware corruption attack drop the malicious firmware image payload alongside the flashing tool before execution. Firmware image files (typically 4MB–32MB) appearing in temp, AppData, ProgramData, or Public paths created by scripting hosts, browsers, or unknown binaries warrant immediate investigation as pre-attack staging artifacts.
DeviceFileEvents
| where Timestamp > ago(7d)
| where FileName endswith ".bin" or FileName endswith ".rom"
or FileName endswith ".fd" or FileName endswith ".cap"
| where FolderPath has_any (
"\\Temp\\", "\\tmp\\", "\\AppData\\",
"\\ProgramData\\", "\\Users\\Public\\", "\\Downloads\\"
)
| where not (InitiatingProcessFileName has_any (
"svchost.exe", "MsMpEng.exe", "TrustedInstaller.exe",
"wuauclt.exe", "wusa.exe"
))
| project Timestamp, DeviceName, AccountName, FolderPath, FileName,
FileSize, SHA256, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11
(TargetFilename="*.bin" OR TargetFilename="*.rom" OR TargetFilename="*.fd" OR TargetFilename="*.cap")
(TargetFilename="*\\Temp\\*" OR TargetFilename="*\\tmp\\*" OR TargetFilename="*\\AppData\\*" OR TargetFilename="*\\ProgramData\\*" OR TargetFilename="*\\Users\\Public\\*" OR TargetFilename="*\\Downloads\\*")
NOT (Image="*\\svchost.exe" OR Image="*\\MsMpEng.exe" OR Image="*\\TrustedInstaller.exe" OR Image="*\\wusa.exe")
| table _time, host, User, TargetFilename, Image, CommandLine, Hashes
| sort - _time Atomic Red Team Tests
Uses the CHIPSEC hardware security framework in read-only mode to enumerate UEFI variables, simulating the firmware reconnaissance phase that precedes a corruption attack. Adversaries use CHIPSEC to map UEFI layout, identify target regions (BIOS_REGION, ME_REGION), and verify write access before flashing. This read-only command generates identical process creation and driver load telemetry as a destructive write operation. Requires CHIPSEC installed (pip install chipsec on Windows with WDK) and administrative privileges. NOTE: CHIPSEC loads a kernel driver — run only in an isolated test environment.
Command
python chipsec_util.py uefi var-list Cleanup
sc stop chipsec 2>nul & sc delete chipsec 2>nul Expected Telemetry
Sysmon Event ID 1: Process Create with Image=python.exe, CommandLine containing 'chipsec_util.py uefi var-list'. Sysmon Event ID 6: Driver load for chipsec.sys (or chipsec_hlpr.sys) from a temp or install directory. Security Event ID 7045: New service installed for the CHIPSEC kernel driver. Windows may prompt for UAC on driver installation.
Expected Detection
KQL: Signal='KnownFirmwareTool' on 'chipsec.exe' or 'KnownFirmwareTool' via chipsec command line match. SPL: ToolHit=1 if chipsec.exe matches; DriverLoadHit=1 if chipsec.sys is also captured by EventCode=6. Hunting query 1 fires on chipsec driver load.
Executes RW-Everything (rw.exe) in command-line mode to read a PCI configuration register, simulating the hardware access step that precedes firmware read or write. RW-Everything loads the rw.sys ring-0 driver providing unrestricted access to physical memory, I/O ports, PCI, MSR registers, and SPI flash — the same driver access path used in real firmware corruption attacks. The PCI read is non-destructive. NOTE: This test loads a kernel driver and requires administrative privileges — run only in an isolated lab environment.
Command
Rw.exe /Min /NoLogo /Stdout /Command="PCI 0 0 0 0 10" Cleanup
sc stop RW 2>nul & sc delete RW 2>nul Expected Telemetry
Sysmon Event ID 1: Process Create with Image=Rw.exe and CommandLine containing '/Command="PCI 0 0 0 0 10"'. Sysmon Event ID 6: Driver load for rw.sys from tool directory or System32\drivers\. Security Event ID 7045: New service named 'RW' registered pointing to rw.sys. Service exits after tool completes but driver load telemetry persists.
Expected Detection
KQL: Signal='KnownFirmwareTool' on rw.exe filename match. SPL: ToolHit=1, DriverLoadHit=1 (if EventCode=6 captured), RiskScore >= 3. Hunting query 1 fires on rw.sys in driver load events.
Uses bcdedit via PowerShell to modify a non-critical Boot Configuration Data value and immediately restore it, generating the same command-line telemetry as the bootloader modification technique used by Bad Rabbit ransomware. Bad Rabbit replaced the legitimate Windows bootloader by modifying BCD entries to point to a malicious boot image, preventing OS boot. This test modifies only the OS description string (cosmetic, non-destructive) before restoring it, confirming the detection fires on the characteristic bcdedit /set pattern. Requires administrative privileges.
Command
powershell.exe -ExecutionPolicy Bypass -Command "bcdedit /set '{current}' description 'df00tech-atomictest-T1495'; Start-Sleep -Seconds 3; bcdedit /set '{current}' description 'Windows Boot Manager'" Cleanup
bcdedit /set "{current}" description "Windows Boot Manager" Expected Telemetry
Sysmon Event ID 1: Process Create for powershell.exe with CommandLine containing 'bcdedit /set' and ExecutionPolicy Bypass. Two additional Sysmon EventCode=1 events for bcdedit.exe child processes. Security Event ID 4688 (if command-line auditing enabled) for both bcdedit invocations. PowerShell ScriptBlock Log Event ID 4104 capturing the full command.
Expected Detection
KQL: Signal='UEFIOrBCDTamper' — matches 'bcdedit /set' in PowerShell command line. SPL: UEFITamper=1, RiskScore >= 1. SuspiciousParent may also fire if PowerShell is considered a suspicious parent context.
Uses flashrom on Linux to probe for SPI flash chips using the internal programmer, simulating the pre-attack reconnaissance step an adversary performs before targeting firmware on Linux systems. The --no-action flag combined with verbose output (-V) runs programmer detection and chip identification without performing any read or write operations — generating identical process creation telemetry to a destructive write invocation. Requires flashrom installed (apt install flashrom or yum install flashrom) and root privileges. The command is expected to fail or produce warnings in a VM but generates the required audit telemetry.
Command
sudo flashrom -p internal --no-action -V 2>&1 | head -60 Expected Telemetry
Linux auditd EXECVE record with a=flashrom, argv containing '-p', 'internal', '--no-action', '-V'. Syslog entry capturing sudo invocation and flashrom execution. On systems with Sysmon for Linux (EventID 1): Process Create event for flashrom. /var/log/auth.log entry recording sudo authentication for the flashrom command.
Expected Detection
Linux auditd rule: EXECVE records matching comm='flashrom'. Sysmon for Linux: ProcessCreate event with Image containing 'flashrom'. EDR platforms monitoring execve syscalls will capture this event. Alert should fire on 'flashrom' process name in Linux process monitoring rules.
Uses Intel's Flash Programming Tool (fptw64.exe) to read the SPI flash descriptor region to a local file, simulating the firmware dump step that precedes a targeted BIOS write attack. Adversaries dump the current firmware image to understand region layout and create a corrupted replacement image before flashing it back. The -DESC flag reads only the descriptor region (non-OS critical), producing the characteristic fptw64.exe process creation and .bin file creation telemetry. Requires Intel FPT available from the Intel CSE Tools package or CSME System Tools. NOTE: FPT may install a kernel driver — run in an isolated test environment.
Command
fptw64.exe -DESC -d %TEMP%\df00tech_flashdesc.bin Cleanup
del %TEMP%\df00tech_flashdesc.bin 2>nul Expected Telemetry
Sysmon Event ID 1: Process Create with Image=fptw64.exe, CommandLine containing '-DESC -d'. Sysmon Event ID 11: File Create event for df00tech_flashdesc.bin in %TEMP%. Security Event ID 7045 may appear if FPT installs a kernel service for hardware access. The .bin file size will reflect the flash descriptor region size (typically 4KB).
Expected Detection
KQL: Signal='KnownFirmwareTool' on fptw64.exe or fpt.exe filename match. SPL: ToolHit=1, RiskScore >= 1. File-based hunting query (query 3) fires on .bin file creation in %TEMP% by a non-system process.