Pre-OS Boot
Adversaries may abuse Pre-OS Boot mechanisms as a way to establish persistence on a system. During the booting process of a computer, firmware and various startup services are loaded before the operating system. These programs control flow of execution before the operating system takes control. Adversaries may overwrite data in boot drivers or firmware such as BIOS (Basic Input/Output System) and The Unified Extensible Firmware Interface (UEFI) to persist on systems at a layer below the operating system. This can be particularly difficult to detect as malware at this level will not be detected by host software-based defenses. Sub-techniques include System Firmware modification (T1542.001), Component Firmware attacks targeting disk or network card firmware (T1542.002), Bootkit installation targeting the Master Boot Record or Volume Boot Record (T1542.003), ROMMONkit for Cisco network device persistence (T1542.004), and TFTP Boot abuse for network device re-imaging (T1542.005). Pre-OS implants are especially dangerous because they survive operating system reinstallation, are invisible to host-based security tools that load after the OS, and can persist through drive replacement if stored in device firmware rather than the disk itself.
What is T1542 Pre-OS Boot?
Pre-OS Boot (T1542) maps to the Defense Evasion and Persistence tactics — the adversary is trying to avoid being detected in MITRE ATT&CK.
This page provides production-ready detection logic for Pre-OS Boot, covering the data sources and telemetry it touches: Process: Process Creation, File: File Creation, File: File Modification, Command: Command Execution, Microsoft Defender for Endpoint. The queries below are rated critical severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Defense Evasion Persistence
- Technique
- T1542 Pre-OS Boot
- Canonical reference
- https://attack.mitre.org/techniques/T1542/
let FirmwareToolNames = dynamic([
"RWEverything.exe", "RWE.exe", "Rw.exe",
"chipsec_main.exe", "chipsec.exe",
"flashrom.exe",
"afuwin64.exe", "afuwin32.exe", "afudos.exe",
"WinFlash.exe", "biosflash.exe",
"FPT.exe", "FPTW64.exe", "FPTW.exe",
"H2OUVE-W-PEXE64.exe", "H2OFFT-W.exe", "H2OUVE.exe",
"AMIBCP.exe", "AMIDEWin64.exe", "AMIDEWin.exe",
"FWUpdateLocalApp.exe", "FirmwareUpdate.exe"
]);
let FirmwareKeywords = dynamic([
"chipsec", "flashrom", "rweverything",
"afuwin", "afudos", "biosflash", "winflash",
"H2OUVE", "AMIBCP", "uefi-firmware",
"fptw64", "MEManuf", "biosupdate", "uefiflash"
]);
let BootloaderFiles = dynamic([
"bootmgfw.efi", "bootx64.efi", "grubx64.efi", "shimx64.efi",
"bootmgr", "BOOTMGR", "winload.efi", "winload.exe", "ntldr", "NTLDR"
]);
let LegitBootParents = dynamic([
"setup.exe", "setuphost.exe", "dism.exe", "TrustedInstaller.exe",
"msiexec.exe", "wuauclt.exe", "sysprep.exe", "cleanmgr.exe",
"fwupd", "fwupdmgr", "bootupd"
]);
// Sub-query 1: Known firmware manipulation tool execution
let FirmwareToolExec = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName has_any (FirmwareToolNames)
or ProcessCommandLine has_any (FirmwareKeywords)
| extend DetectionType = "FirmwareToolExecution"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine, DetectionType;
// Sub-query 2: Raw disk handle access (potential MBR/VBR read or write)
let RawDiskAccess = DeviceProcessEvents
| where Timestamp > ago(24h)
| where ProcessCommandLine has "\\\\.\\PhysicalDrive"
or ProcessCommandLine has "\\\\.\\PHYSICALDRIVE"
or ProcessCommandLine has "\\\\.\\Harddisk"
or ProcessCommandLine has "\\Device\\Harddisk"
| where FileName !in~ ("defrag.exe", "chkdsk.exe", "diskpart.exe", "diskshadow.exe",
"vssadmin.exe", "wbadmin.exe", "ntbackup.exe",
"StorageD.exe", "StorageUsage.exe")
| where InitiatingProcessFileName !in~ ("services.exe", "wininit.exe", "smss.exe")
| extend DetectionType = "RawDiskAccess"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine, DetectionType;
// Sub-query 3: Boot configuration modification via bcdedit/bootrec/bcdboot
let BootConfigMod = DeviceProcessEvents
| where Timestamp > ago(24h)
| where (FileName =~ "bcdedit.exe" and ProcessCommandLine has_any ("/set", "/create", "/delete", "/import", "/store", "/deletevalue"))
or (FileName =~ "bootrec.exe" and ProcessCommandLine has_any ("/fixmbr", "/fixboot", "/rebuildbcd", "/scanos"))
or (FileName =~ "bcdboot.exe" and ProcessCommandLine !has "/help")
| where InitiatingProcessFileName !in~ (LegitBootParents)
and InitiatingProcessFileName !in~ ("svchost.exe", "wininit.exe")
| extend DetectionType = "BootConfigModification"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine, DetectionType;
// Sub-query 4: Write or modification of critical boot/EFI files
let BootFileWrite = DeviceFileEvents
| where Timestamp > ago(24h)
| where ActionType in ("FileCreated", "FileModified", "FileRenamed")
| where FolderPath has "\\EFI\\"
or FolderPath has "\\Boot\\"
or FileName in~ (BootloaderFiles)
or (FolderPath has "\\System32\\boot\\" and FileName endswith ".efi")
| where InitiatingProcessFileName !in~ (LegitBootParents)
and InitiatingProcessFileName !in~ ("wininit.exe", "svchost.exe", "System")
| extend DetectionType = "BootFileWrite"
| extend AccountName = InitiatingProcessAccountName
| project Timestamp, DeviceName, AccountName, FileName, FolderPath, ActionType,
InitiatingProcessFileName, InitiatingProcessCommandLine, DetectionType;
// Union all sub-detections
union FirmwareToolExec, RawDiskAccess, BootConfigMod, BootFileWrite
| sort by Timestamp desc Detects Pre-OS Boot persistence and defense evasion activity using Microsoft Defender for Endpoint tables. Combines four detection sub-queries: (1) execution of known firmware manipulation tools (CHIPSEC, RWEverything, flashrom, AMI BIOS tools, Intel FPT); (2) raw disk handle access to PhysicalDrive or Harddisk device paths by non-system processes, which could indicate MBR/VBR manipulation; (3) boot configuration modification via bcdedit, bootrec, or bcdboot by unexpected parent processes; and (4) file creation or modification in EFI partition or Boot directory paths including core bootloader binaries. All sub-queries filter known-legitimate update mechanisms such as Windows Update, DISM, and OEM firmware update services.
Data Sources
Required Tables
False Positives
- OEM firmware update utilities shipped with laptops (Dell Command Update, HP BIOS Update, Lenovo System Update) that run scheduled BIOS/UEFI updates — typically launched by svchost.exe or a vendor service parent
- Dual-boot system configuration tools that modify BCD entries (EasyBCD, rEFInd installer, Ubuntu grub-install during OS installation)
- Enterprise endpoint management during OS deployment — DISM, setup.exe, and MDT/SCCM task sequences legitimately write to EFI and Boot paths
- Security researchers and IT administrators running CHIPSEC or RWEverything for hardware auditing or vulnerability assessment with explicit authorization
- Backup software (Acronis True Image, Macrium Reflect) that access raw disk handles for sector-level backup of the MBR and system partition
Sigma rule & cross-platform mapping
The detection logic for Pre-OS Boot (T1542) 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 T1542
References (9)
- https://attack.mitre.org/techniques/T1542/
- https://en.wikipedia.org/wiki/Booting
- https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wild-courtesy-sednit-group/
- https://securelist.com/cosmicstrand-uefi-firmware-rootkit/106973/
- https://github.com/chipsec/chipsec
- https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/bcd-system-store-settings-for-uefi
- https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/bcdedit
- https://uefi.org/specifications
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1542/T1542.md
Testing Methodology
Validate this detection against 4 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 1Boot Configuration Modification via bcdedit
Expected signal: Sysmon Event ID 1: Process Create with Image=bcdedit.exe, CommandLine containing '/set {current} description'. Security Event ID 4688 (if command line auditing enabled). The DetectionType=BootConfigModification alert fires if the parent process is not in the LegitBootParents allowlist.
- Test 2MBR Read via Raw Disk Handle (PowerShell)
Expected signal: Sysmon Event ID 1: Process Create with Image=powershell.exe, CommandLine containing '\\.\PhysicalDrive0'. Sysmon Event ID 11: FileCreate for the temp file argus_mbr_test.bin. The '\\.\PhysicalDrive' pattern in the command line triggers the RawDiskAccess detection.
- Test 3MBR Sector Read via dd (Linux)
Expected signal: Linux auditd: syscall execve for /bin/dd with argument if=/dev/sda. Sysmon for Linux Event ID 1: Process Create with CommandLine containing 'if=/dev/sda'. Auditd rule 'auditctl -a always,exit -F arch=b64 -S open -F path=/dev/sda -k mbr_access' would generate additional OPEN syscall events for /dev/sda.
- Test 4bootrec Scan for Windows Installations
Expected signal: Sysmon Event ID 1: Process Create with Image=bootrec.exe, CommandLine containing '/scanos'. Security Event ID 4688 (if command line auditing enabled). The parent process (cmd.exe or powershell.exe) is the key indicator — bootrec invoked from user shells rather than from winre.exe or RecoveryEnvironment is anomalous.
Response Playbook
Triage
- Identify the triggering detection type from the alert. FirmwareToolExecution requires immediate escalation regardless of context. RawDiskAccess and BootConfigMod require parent process investigation. BootFileWrite requires verification of the writing process hash.
- For FirmwareToolExecution alerts: identify the binary that ran — was it a known OEM update utility from a vendor-signed path (e.g., C:\Program Files\Dell\CommandUpdate\)? Check if it was launched by a vendor service parent (DellClientManagementService, HPDeviceCheck) or an unexpected parent like cmd.exe, powershell.exe, or a user-mode process.
- For RawDiskAccess alerts: determine which process accessed the raw disk handle and what it attempted to read or write. Use PowerShell history (PSReadLine), Sysmon Event ID 1 command line, and parent process chain to determine legitimacy. Disk imaging software run by backup service accounts is expected; cmd.exe or PowerShell opening raw disk handles is not.
- For BootConfigMod alerts: run 'bcdedit /enum all' on the affected host and compare against a known-good baseline from the same OS version. Look for unfamiliar boot entries, modified device paths, or alterations to the default boot sequence. Pay particular attention to entries pointing to non-standard paths or loading unsigned drivers.
- Check the user context — was the triggering process run as SYSTEM, a local admin, or a domain admin? Firmware tools require elevated privileges; execution as a standard user account is impossible and indicates privilege escalation has already occurred.
- Review Secure Boot status on the affected device: run 'Confirm-SecureBootUEFI' in PowerShell (returns True/False) or check HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\State registry value (1 = enabled). If Secure Boot is unexpectedly disabled and no change request exists, treat as critical.
- Check the firmware version baseline: compare current BIOS/UEFI version (Get-WmiObject Win32_BIOS | Select-Object Name, Version, Manufacturer) against the approved version for this hardware model in your asset management system. An unexpected version downgrade is a strong bootkit indicator.
Containment
- If firmware tool execution is confirmed malicious or unauthorized: immediately isolate the endpoint using EDR network isolation. Do NOT reboot the host before forensic imaging — a reboot may cause the implant to activate or cover its tracks further.
- Preserve a full disk image before any remediation. Standard OS-level forensic tools may not capture pre-boot implants — use a hardware-based imaging tool or boot from external media (WinPE/live USB) to capture a sector-level image including the MBR, EFI partition, and firmware variables.
- If MBR or VBR compromise is confirmed: do NOT use bootrec /fixmbr or bootrec /fixboot as the first response — this overwrites evidence. Capture the current MBR (dd if=/dev/sda of=mbr_suspect.bin bs=512 count=1 on Linux, or PowerShell raw read on Windows) before any repair.
- For UEFI-level compromise: understand that OS reinstallation is insufficient — the implant survives. Engage the hardware vendor for a BIOS reflash procedure using a known-good firmware image delivered via out-of-band channel (USB flash, IPMI/iDRAC/iLO). Verify firmware image hash against vendor's published values before flashing.
- If the affected system has domain credentials or accesses sensitive resources: rotate all credentials that could have been exposed. Pre-OS implants can intercept keystrokes, capture credentials before disk encryption activates, and exfiltrate via network before host-based DLP loads.
- Quarantine the hardware for forensic examination. For supply chain scenarios where the same model/batch may be affected, consider proactive BIOS version auditing across similar devices.
Evidence Collection
- MBR and VBR contents: capture the first 512 bytes of PhysicalDrive0 (MBR) and the first sector of each partition (VBR). Compare against reference MBR for the OS version. Legitimate Windows MBR starts with 0x33C0, 0x8ED0 opcodes; deviations indicate modification.
- EFI partition inventory: mount the EFI System Partition (ESP) as read-only (mountvol S: /s on Windows) and list all EFI binaries, comparing hashes against known-good hashes for the boot chain. Unexpected executables in \EFI\Boot\ or vendor paths are indicators.
- UEFI variable dump: use 'bcdedit /enum firmware' to list firmware boot entries. Use CHIPSEC in read-only mode (python chipsec_main.py -m common.uefi.access_uefispec) on a forensic copy to dump UEFI variables without modifying the system.
- Boot configuration baseline: run 'bcdedit /enum all > bcd_dump.txt' and compare against a reference capture from the same device taken before the incident. Focus on {bootmgr}, {current}, and any additional entries not present in baseline.
- Sysmon Event ID 1 and 11 logs: collect all process creation and file creation events from the 72 hours preceding the alert. Look for the chain of events leading to the firmware tool execution or boot file modification.
- Firmware version audit: capture current firmware version via WMI (Get-WmiObject Win32_BIOS) and compare against the approved version for this hardware model. An unexpected downgrade may indicate firmware rollback to a vulnerable version.
- Prefetch artifacts: collect C:\Windows\Prefetch\BCDEDIT.EXE-*.pf, BOOTREC.EXE-*.pf, and any firmware tool prefetch files. Prefetch timestamps give a reliable execution history even if event logs have been cleared.
- Secure Boot policy: capture HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\ registry hive and the contents of the EFI variable SecureBoot (via 'Get-SecureBootUEFI SecureBoot'). Also capture the Platform Key (PK), Key Exchange Key (KEK), and db/dbx signature databases.
Escalation Criteria
- ! Any confirmed modification to BIOS/UEFI firmware, EFI variables, or bootloader binaries outside of an approved change management window — escalate immediately to IR team and hardware vendor
- ! Secure Boot disabled on a system that had it enabled, with no corresponding change request or IT ticket — indicates deliberate bypass of boot integrity controls
- ! bcdedit entries pointing to non-standard paths, unsigned boot applications, or entries that were not present in the baseline configuration — potential bootkit persistence mechanism
- ! Firmware tool (CHIPSEC, RWEverything, flashrom) executed by a user-mode process, non-admin user, or with a non-standard parent (PowerShell, cmd, Office process) — indicates active exploitation, not legitimate administration
- ! Multiple hosts in the same hardware batch showing firmware version downgrades or unexpected BIOS changes — potential supply chain or targeted hardware compromise affecting a fleet
- ! Evidence of credential harvesting or network exfiltration activity correlated with the firmware modification timeline — indicates a multi-stage attack using pre-OS persistence to survive remediation
Investigation Guide
Forensic Artifacts
- >
MBR (sectors 0-1 of PhysicalDrive0): signature bytes at offset 0x1FE-0x1FF should be 0x55AA; boot code at 0x000-0x1BD should match known-good Windows MBR for the OS version - >
EFI System Partition: mounted at a hidden partition (typically ~100-200MB FAT32); unexpected binaries in \EFI\Boot\ or vendor directories indicate compromise - >
UEFI Variables (nvram): accessible via 'Get-SecureBootUEFI' on Windows or /sys/firmware/efi/efivars/ on Linux; Platform Key (PK), KEK, and db/dbx changes indicate Secure Boot manipulation - >
Windows BCD Store: C:\Boot\BCD or the EFI system partition BCD; accessible via 'bcdedit /enum all' — baseline comparison reveals unauthorized entries or path modifications - >
Firmware Update Log: vendor-specific logs in C:\ProgramData\ or Windows Event Log Microsoft-Windows-Kernel-PnP for driver/firmware installs - >
CHIPSEC output (forensic mode): run 'python chipsec_main.py' to audit SPI flash protection, UEFI variable permissions, and known BIOS vulnerabilities without modifying the system - >
TPM Measurements (PCR values): if TPM is present, PCR[0]-[7] store hash measurements of the boot chain. Unexpected PCR values indicate pre-OS code tampering even when the implant hides itself - >
Prefetch files for firmware tools: C:\Windows\Prefetch\CHIPSEC*.pf, RWEVERYTHING*.pf, FPT*.pf, AFUWIN*.pf provide reliable execution timestamps
Tuning Guidance
Pre-OS Boot detections have a challenging false positive landscape because legitimate firmware updates are rare but not absent. Establish a firmware update baseline by auditing all devices and recording approved BIOS versions per hardware model. Create a firmware update maintenance window policy and allowlist bcdedit/bootrec executions that occur within those windows from approved deployment tool parents (SCCM ccmexec.exe, Intune managementservice.exe, Dell DellCommandUpdate.exe). For the RawDiskAccess sub-detection, the highest false positive source is disk imaging and backup software — build a signed binary allowlist by capturing hashes of approved backup agent binaries (Acronis, Veeam, Macrium) rather than allowlisting by name alone, since an attacker could rename a malicious binary. For FirmwareToolExecution, any execution outside of authorized IT windows should be treated as high-confidence regardless of parent process, as these tools have very limited legitimate use cases on managed endpoints. Consider implementing a BIOS version audit job that runs weekly via your EDR's live query to detect unauthorized firmware version changes across the fleet. The medium confidence rating reflects that the most dangerous firmware implants (LoJax, CosmicStrand) operate at a layer largely invisible to endpoint telemetry — this detection catches the installation phase but may not detect an already-installed implant. Supplement with TPM attestation checks and periodic hardware-based integrity verification for high-value targets.
Hunting Queries
Hunt for devices or accounts with anomalous bcdedit/bootrec execution frequency over 30 days. A bootkit installation mechanism may repeatedly modify BCD entries to ensure persistence survives partial remediation attempts. This query finds high-frequency patterns and unexpected parent process diversity that the 24-hour primary detection window would miss.
// Hunt for bcdedit execution frequency anomalies over 30 days
// Reveals recurring automated boot config modifications that bypass 24h detection windows
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName =~ "bcdedit.exe"
| summarize ExecutionCount=count(),
UniqueCommandLines=dcount(ProcessCommandLine),
CommandLines=make_set(ProcessCommandLine, 10),
UniqueParents=dcount(InitiatingProcessFileName),
ParentProcesses=make_set(InitiatingProcessFileName),
FirstSeen=min(Timestamp),
LastSeen=max(Timestamp)
by DeviceName, AccountName
| where ExecutionCount > 5
or UniqueParents > 2
or (UniqueCommandLines > 3 and ExecutionCount > 2)
| sort by ExecutionCount desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
(Image="*\\bcdedit.exe" OR Image="*\\bootrec.exe" OR Image="*\\bcdboot.exe")
earliest=-30d
| stats count as ExecutionCount,
dc(CommandLine) as UniqueCommandLines,
values(CommandLine) as CommandLines,
dc(ParentImage) as UniqueParents,
values(ParentImage) as ParentProcesses,
earliest(_time) as FirstSeen,
latest(_time) as LastSeen
by host, User, Image
| where ExecutionCount > 5 OR UniqueParents > 2
| sort - ExecutionCount Hunt for TFTP (UDP/69) network connections from endpoints — a strong indicator of T1542.005 (TFTP Boot) activity. TFTP has no legitimate use on standard workstations; connections to port 69 may indicate an adversary re-imaging a network device or an endpoint being configured to network-boot a malicious image. Network devices (routers, switches) making unexpected TFTP connections to non-authoritative servers are also flagged.
// Hunt for TFTP network connections from endpoints (T1542.005 indicator)
// Legitimate TFTP is rare on endpoints — connections to port 69 from workstations are suspicious
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemotePort == 69 or LocalPort == 69 // TFTP UDP 69
| where RemoteIPType != "Loopback"
| summarize ConnectionCount=count(),
UniqueRemoteIPs=dcount(RemoteIP),
RemoteIPs=make_set(RemoteIP),
Processes=make_set(InitiatingProcessFileName),
CommandLines=make_set(InitiatingProcessCommandLine)
by DeviceName, InitiatingProcessFileName
| sort by ConnectionCount desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
(DestinationPort=69 OR SourcePort=69)
NOT (DestinationIp="127.*" OR DestinationIp="::1")
earliest=-7d
| stats count as ConnectionCount,
dc(DestinationIp) as UniqueRemoteIPs,
values(DestinationIp) as RemoteIPs,
values(Image) as Processes,
values(CommandLine) as CommandLines
by host, Image
| sort - ConnectionCount Hunt for registry modifications to Secure Boot policy, Code Integrity settings, Device Guard configuration, and BCD store entries. Adversaries deploying bootkits must typically disable Secure Boot enforcement or add their signing key to the db variable before the bootkit can execute. Registry changes to these paths by non-system processes are rare and warrant investigation even if the primary firmware tool detection did not fire.
// Hunt for Secure Boot registry policy modifications
// Attackers disabling Secure Boot leave registry traces before the UEFI change takes effect
DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey has "SecureBoot"
or RegistryKey has "\\ControlSet001\\Control\\CI\\"
or RegistryKey has "\\Control\\DeviceGuard"
or (RegistryKey has "\\BCD" and RegistryValueName has_any ("path", "device", "description", "application"))
| where ActionType in ("RegistryValueSet", "RegistryKeyCreated")
| where InitiatingProcessFileName !in~ ("TrustedInstaller.exe", "svchost.exe", "setup.exe",
"dism.exe", "msiexec.exe", "services.exe")
| project Timestamp, DeviceName, AccountName, RegistryKey, RegistryValueName,
RegistryValueData, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=13
earliest=-7d
(TargetObject="*SecureBoot*" OR TargetObject="*\\Control\\CI\\*" OR
TargetObject="*DeviceGuard*" OR TargetObject="*\\BCD*")
NOT (Image="*\\TrustedInstaller.exe" OR Image="*\\svchost.exe" OR
Image="*\\setup.exe" OR Image="*\\dism.exe" OR Image="*\\msiexec.exe")
| table _time, host, User, TargetObject, Details, Image, CommandLine
| sort - _time Atomic Red Team Tests
Modifies the BCD boot entry description for the current Windows installation using bcdedit. This simulates an adversary who has obtained SYSTEM or Administrator privileges and is modifying boot configuration as part of a bootkit installation or boot persistence mechanism. The modification is cosmetic (description field only) and is fully reversible with the cleanup command. Requires elevation (Run as Administrator).
Command
bcdedit /set {current} description "Argus Pre-OS Boot Test Entry" Cleanup
bcdedit /deletevalue {current} description Expected Telemetry
Sysmon Event ID 1: Process Create with Image=bcdedit.exe, CommandLine containing '/set {current} description'. Security Event ID 4688 (if command line auditing enabled). The DetectionType=BootConfigModification alert fires if the parent process is not in the LegitBootParents allowlist.
Expected Detection
KQL: BootConfigMod sub-query fires on FileName='bcdedit.exe' with '/set' in ProcessCommandLine. SPL: BootConfigMod=1, SuspicionScore=1. Alert severity: Critical if initiated from user shell (cmd.exe or powershell.exe parent).
Opens a raw file handle to the first physical disk's Master Boot Record using .NET System.IO.FileStream with read-only access. This technique is used by bootkits and forensic tools alike to read or write the pre-boot sector directly, bypassing filesystem abstractions. The test reads 512 bytes (one sector) from PhysicalDrive0 and saves it to a temporary file for verification — no data is written to the MBR. Requires elevation (Run as Administrator). The command creates observable telemetry with the raw disk path pattern that the detection targets.
Command
powershell.exe -NoProfile -Command "$stream = New-Object System.IO.FileStream('\\.\PhysicalDrive0', [System.IO.FileMode]::Open, [System.IO.FileAccess]::Read, [System.IO.FileShare]::ReadWrite); $mbr = New-Object byte[] 512; $stream.Read($mbr, 0, 512) | Out-Null; $stream.Close(); [System.IO.File]::WriteAllBytes(\"$env:TEMP\argus_mbr_test.bin\", $mbr); Write-Host \"MBR read OK. Signature: $($mbr[510].ToString('X2'))$($mbr[511].ToString('X2'))\"" Cleanup
Remove-Item "$env:TEMP\argus_mbr_test.bin" -ErrorAction SilentlyContinue Expected Telemetry
Sysmon Event ID 1: Process Create with Image=powershell.exe, CommandLine containing '\\.\PhysicalDrive0'. Sysmon Event ID 11: FileCreate for the temp file argus_mbr_test.bin. The '\\.\PhysicalDrive' pattern in the command line triggers the RawDiskAccess detection.
Expected Detection
KQL: RawDiskAccess sub-query fires on ProcessCommandLine containing '\\.\PhysicalDrive'. SPL: RawDiskAccess=1, SuspicionScore=1. The MBR signature bytes read back should be '55AA' (0x55, 0xAA at offsets 510-511) confirming a valid MBR was accessed.
Reads the first 512 bytes of the primary disk (/dev/sda) using the 'dd' utility — the standard Unix tool for low-level disk I/O. This is both a legitimate forensic technique and a common method used by bootkits and rootkit installers to read the current MBR before overwriting it. The test reads (does not write) the MBR to a temporary file. The detection fires on the /dev/sda or /dev/disk input device path pattern in process arguments. Requires root privileges. Run on Linux endpoints with Sysmon for Linux or auditd installed.
Command
dd if=/dev/sda of=/tmp/argus_mbr_test.bin bs=512 count=1 2>/dev/null && echo "MBR read complete. Bytes: $(wc -c < /tmp/argus_mbr_test.bin)" Cleanup
rm -f /tmp/argus_mbr_test.bin Expected Telemetry
Linux auditd: syscall execve for /bin/dd with argument if=/dev/sda. Sysmon for Linux Event ID 1: Process Create with CommandLine containing 'if=/dev/sda'. Auditd rule 'auditctl -a always,exit -F arch=b64 -S open -F path=/dev/sda -k mbr_access' would generate additional OPEN syscall events for /dev/sda.
Expected Detection
Linux Sysmon detection fires if deployed. For auditd-based detection: search for execve syscall with /dev/sda, /dev/sdb, or /dev/nvme0n1 as an 'if=' argument to dd, particularly where the current user is not root executing a scheduled backup.
Executes bootrec /scanos — the Windows Recovery Environment tool that scans all disks for Windows installations and reports them without making changes. While /scanos is read-only, it is part of the bootrec suite (alongside the destructive /fixmbr and /fixboot commands) and its execution outside of Windows RE is unusual. This test validates that the detection captures the full bootrec command family, not just the destructive sub-commands. Execution from a standard user shell (rather than Windows RE) is the suspicious pattern. Requires elevation.
Command
bootrec /scanos Expected Telemetry
Sysmon Event ID 1: Process Create with Image=bootrec.exe, CommandLine containing '/scanos'. Security Event ID 4688 (if command line auditing enabled). The parent process (cmd.exe or powershell.exe) is the key indicator — bootrec invoked from user shells rather than from winre.exe or RecoveryEnvironment is anomalous.
Expected Detection
KQL: BootConfigMod sub-query fires on FileName='bootrec.exe' with '/scanos' in ProcessCommandLine when parent is not in the LegitBootParents allowlist. SPL: BootConfigMod=1, SuspicionScore=1. Note: /scanos specifically may be added to exclusions in tuned environments; the higher-confidence targets are /fixmbr and /fixboot.