Detecting T1542 Pre-OS boot

Why Pre-OS boot tampering stays hidden under the operating system

Pre-OS boot tampering (T1542) lets an adversary run code before the operating system and its security agents start, so that activity sits outside most endpoint telemetry. In ATT&CK version 20.0, T1542 is listed under the Stealth tactic (TA0005), which MITRE describes as adversaries trying to hide and conceal their actions, appearing as normal behavior. The technique has five sub-techniques covering system firmware, component firmware, bootkits, ROMMONkits on network devices and TFTP boot. For a SOC lead, the core problem is ordering: the EDR agent that would report a malicious component is loaded after the code it needs to see has already executed.

Pre-OS tampering appears in intrusions where an actor wants persistence that survives disk wipes, operating system reinstalls and agent redeployment. It is also relevant to network devices, where boot images and ROMMON settings can be changed to keep access through upgrades. The first decision for the team is scope: which device classes, such as laptops, servers, hypervisor hosts and routers or switches, need firmware visibility as part of the detection program. The second is ownership, because firmware sits between the security team, the platform team and the hardware vendor. Confirm with each vendor which firmware update, measurement and attestation features your fleet supports, since these capabilities differ by platform and model.

Because the malicious code runs before the OS, detection depends on evidence collected from outside the running system: firmware integrity measurements, boot event logs, management controller records and changes to boot configuration that the operating system can observe after the fact. Each of these only helps when there is a known-good reference to compare against. Before building any analytics, record current firmware versions, boot order and secure boot settings for each in-scope asset, and store them somewhere an attacker with OS-level access cannot quietly rewrite. The detection and validation sections later on this page depend on that baseline existing.

Which telemetry reveals Pre-OS boot changes and which open-source tool collects it

This table maps the telemetry named for T1542 Pre-OS Boot (Process Creation, Command Execution and File Creation) to each platform family and the open-source collector that gathers it. Read each row as a question: what is visible on this platform, and which agent or log path brings it to the SIEM. Firmware-level visibility depends on vendor tooling, so confirm each row in your own environment before relying on it.

Platform	Telemetry that can reveal the activity	Open-source collector	What to confirm in your environment
Linux hosts	Process Creation and Command Execution for boot-related utilities and bootloader tools, plus File Creation under the EFI system partition and boot directories	Wazuh agent with Auditd rules, or Velociraptor for on-demand file and process collection	Auditd watches cover the EFI and boot paths you care about, and the agent forwards them to the manager
macOS hosts	Process Creation and Command Execution for firmware and boot management utilities, plus File Creation in system boot and EFI-related locations	Wazuh agent with unified log collection, or Velociraptor artifacts for process and file triage	Which boot-related events the unified log exposes on your macOS versions and whether they reach the SIEM
Network devices	Command Execution and configuration change events for boot image, boot variable and firmware upgrade commands, delivered as device syslog	Device syslog forwarded to Wazuh or a Zeek-adjacent log pipeline; Security Onion can ingest the same syslog stream	Whether the device logs boot image changes and firmware upgrades at all, and at what severity
Windows hosts	Process Creation and Command Execution for boot configuration tools, plus File Creation on the EFI system partition and boot manager files	Sysmon for Windows for process and file events, collected by the Wazuh agent or Security Onion	That Sysmon captures the process and file events you need and that the EFI partition is covered by your file creation rules
Firmware and UEFI	Firmware-level changes are often not visible to host agents; visibility depends on vendor-provided management or attestation tooling	Vendor tooling where available; open-source agents may only see the OS-side effects	Which firmware events your hardware vendor exposes, and whether they can be forwarded to your SIEM

Detection logic for Pre-OS boot changes, with tuning and false positives

Pre-OS boot detections look for changes that happen before the operating system starts, so each idea pairs a telemetry source with an expectation about change windows. The cards below describe what to alert on, how to tune it and which routine work will trigger it. Set every threshold from your own baseline and confirm it against change records before you enable the alert.

Unexpected boot file changes

Watch for file creation or modification in boot locations such as the EFI system partition, /boot and firmware staging folders on Linux, macOS and Windows hosts, using File Creation (DC0039) telemetry. Tune by host group: alert when a file lands in a boot path that is not on the approved list for that image and that is not inside a recorded change window. Expected false positives come from kernel and bootloader package updates, OS imaging and firmware staging. Confirm the allow list with the team that owns each image.

Bootloader tooling outside change windows

Bootloader and EFI management tools running on endpoints should be rare and tied to a known operator or pipeline. Use Process Creation (DC0032) and Command Execution (DC0064) telemetry to alert when these tools run on hosts that are not part of an active patch or imaging job. Tune with a per-host-group list of approved operators and a change calendar feed. Expected false positives include patch cycles, imaging servers and vendor firmware utilities, so suppress them by parent process and service account where possible.

Boot configuration commands on endpoints

Boot configuration utilities on Windows and EFI variable tools on Linux can change what loads at startup. Monitor Command Execution (DC0064) events for these utilities when they are run by accounts that do not normally administer boot settings, and correlate them with Process Creation (DC0032). Tune with a short list of approved administrator accounts and a per-host rate threshold drawn from your baseline. Expected false positives come from OS imaging, endpoint management agents and hardware maintenance scripts, which should be listed by name and, where your tooling supports it, by signed hash.

Network device boot image writes

Routers, switches and firewalls can be altered through changes to their boot image or startup configuration. Use Network Connection Creation (DC0082) data for management sessions and the device syslog for writes to startup configuration or boot image. Tune by alerting on any write that lacks a matching change ticket, and on management sessions that originate outside the jump host range. Expected false positives come from scheduled configuration backups, vendor firmware upgrades and emergency changes. Confirm with each vendor which log messages record a boot image or startup configuration write on your model.

Correlate alerts with change records

A boot-related alert carries little meaning without its change context. Join File Creation, Process Creation and network device events to the change calendar, patch schedule and asset owner, then score each alert by how many expected records are missing. Tune the join window for each platform after a test cycle, because imaging and firmware work often runs longer than a standard patch job. Expected false positives fall as the change feed improves, so the main ongoing cost is maintaining that feed. Ask your change board how emergency changes are recorded.

How to confirm the Pre-OS boot detections fire

This sequence proves, in a private lab or cyber range, that each T1542 Pre-OS Boot detection reaches the SIEM with usable fidelity before anyone relies on it. It produces a dated record of coverage, latency and gaps that can be re-run when ATT&CK changes.

Fix the scope per platform and version
The security engineering lead and the detection owner agree which T1542 sub-techniques apply to each platform in the client environment, such as Linux, macOS, Windows and network devices. The scope document names the ATT&CK version it targets, which for these pages is Enterprise ATT&CK 20.0, and lists the data components each detection depends on, such as Process Creation, Command Execution and File Creation. The step is done when every in-scope sub-technique has a named owner and a written list of expected telemetry sources.
Agree the change window and rollback
The CISO or delegate, the platform team and the cyber range operator agree a change window, the lab systems involved, who may halt the exercise, and how each affected system is restored to its pre-exercise state. Because Pre-OS Boot techniques touch firmware and boot components, the rollback plan must cover re-imaging or firmware restoration from known-good, verified media, and the team should confirm that recovery is tested on lab hardware first. Done means a signed approval record and a rollback runbook that the operator has rehearsed at least once.
Baseline telemetry before the emulation
Before any emulation, the team confirms that the agents, log forwarders and integrations for each in-scope platform are sending events to the SIEM and that the timestamps and host identifiers are consistent. The team captures a quiet baseline and notes any existing alerts that could be confused with Pre-OS Boot activity, such as firmware updates or known administrative tasks. The step closes when the baseline shows the expected event types arriving for every platform in scope.
Run the agreed emulation in the lab
An emulation operator, separate from the detection author, runs the agreed sub-technique scenarios in the isolated cyber range, using a plan that the defensive team has not seen in detail. Each run is logged with a start time, the target system, the sub-technique and the operator's own record of what was executed, so that later comparison is exact. The step is complete when every scenario in the plan has been run once and the operator's log matches the plan. No attack commands are kept in the defender's report; the plan references the scenario identifiers only.
Confirm each alert reaches the SIEM
The detection engineer checks, for each scenario, whether the expected rule or analytic produced an alert in the SIEM, such as Wazuh or a Security Onion deployment, and whether the event carried the fields needed to triage it. The check also covers whether events were dropped or delayed between the endpoint and the SIEM. Missing alerts are logged as gaps against the sub-technique, not quietly fixed during the exercise. The step closes with a table of scenario, expected alert, observed alert and field completeness.
Record latency, fidelity and gaps
The team measures the time between the operator's recorded action and the first alert in the SIEM, and rates each alert for fidelity, meaning whether it points to the affected host and boot component with enough context to act on. Alerts that fire on the baseline or on unrelated firmware activity are recorded as false positive pressure. Each gap is assigned an owner, a root cause category such as missing data source, rule logic or ingestion, and a retest date agreed in the change record. The output is a coverage record per sub-technique and platform.
Re-validate after each ATT&CK release
The detection owner reviews the ATT&CK updates page for each new release, including v18 (October 28, 2025), v19 (April 28, 2026) and v20 (October 13, 2026), and checks whether any T1542 sub-technique, data component or mitigation mapping changed. If the STIX bundle for the targeted version shows a change, the scope and detection mappings are updated and the affected scenarios are re-run. The step closes when the coverage record names the ATT&CK version it was validated against and the changes have been reviewed and signed off.

Preventive controls mapped to ATT&CK mitigations Audit and Privileged Account Management

T1542 Pre-OS Boot persists below the operating system, so the controls that matter most sit at the firmware, bootloader and administrative layers. The two ATT&CK mitigations for this technique, Audit (M1047) and Privileged Account Management (M1026), work together: one makes boot-level changes visible, the other limits who can make them in the first place.

Audit logging of boot component changes

Treat changes to firmware, bootloader and boot configuration as auditable events. On Linux, watch for modifications to bootloader configuration and boot partition contents, and on Windows, record changes to boot configuration data and firmware update activity where the platform exposes them. Forward these events to a central store so that an attacker cannot erase them from the host alone. Confirm with each hardware vendor which firmware update and integrity events their management tooling can export, since this varies by platform.

Baseline boot configuration and alert on drift

Record a known-good baseline of boot entries, bootloader hashes and firmware versions for each device class. Compare current state against that baseline on a schedule and after every patch window. Drift that is not matched to an approved change ticket should raise an alert and open an investigation. A baseline that is not refreshed after authorized updates will generate noise, so define who approves a new baseline before it is needed.

Restrict administrative rights over boot components

Limit the accounts that can alter firmware settings, boot order, Secure Boot configuration and bootloader files. Use separate privileged accounts for hardware and boot administration, require approval for their use, and review membership on a fixed cadence. Remove standing administrator rights from daily-use accounts. Privileged Account Management (M1026) is the ATT&CK mitigation that covers this control, and it is most effective when privileged sessions are logged and reviewed together with boot change events.

Protect firmware with platform-supported safeguards

Ask hardware and firmware vendors which protections are available for your models, such as Secure Boot enforcement, firmware write protection and signed firmware updates. Enable only those your platform supports and document any that cannot be enabled. Set firmware administrator passwords in a managed vault and rotate them under the same process as other privileged credentials. Confirm vendor support in your own hardware before relying on any of these safeguards in a control narrative.

Separate boot change approval from operations

Route firmware and bootloader changes through the same change process used for production infrastructure, with a named approver who is not the person making the change. Pair each approved change with a log entry that records the requester, the approver and the expected hash or version. This separation makes an unexpected change stand out, because it can be compared against an approval record rather than judged from the host alone.

Review privileged boot activity on a schedule

Establish a recurring review of privileged sessions on hosts that manage firmware, out-of-band controllers and boot images. The review should confirm that each session maps to an approved task and that no boot change occurred outside a session. Record who performed the review, what was checked and what was escalated. The review output becomes evidence for an auditor, so keep it in a system that the administrators under review cannot edit.

What to do in the first hour after a Pre-OS boot alert

In the first hour, the priority is to decide whether the alert reflects an authorized change or unexplained tampering with firmware, bootloader, UEFI or network device boot images. Start by matching the alert timestamp, host or device identifier and boot component name against change records, firmware update tickets and maintenance windows held by the platform, server or network team. Confirm who initiated any recent update, whether the vendor package was approved, and whether the change was completed on the same device. If a matching approved change exists, record the link between the ticket and the alert and move on to baseline comparison. If no change explains the event, treat the alert as suspicious until proven otherwise and keep the host or device in its current state while you work.

If tampering is unexplained, isolate the affected host or device from production and administrative networks using the network controls your team already operates, and avoid rebooting, reflashing or power cycling it unless incident response directs you to. Preserve evidence from the operating system with read-only collection, such as the security logs, boot logs and the event records your Wazuh or Security Onion deployment already holds, and capture out-of-band sources such as the management controller logs, the hardware or firmware inventory and any hypervisor records for virtual machines. Hash the collected artifacts and document who handled them and when. Compare the boot components against a known-good baseline taken from the vendor image or your last verified inventory, and confirm which privileged accounts had access to the device during the window. Escalate to your incident response team once the alert is confirmed as unexplained, and hand over the timeline, the baseline comparison and the chain of custody record.

Rehearsing T1542 detection in a private cyber range

Build the Linux range as a set of isolated virtual machines or bare-metal hosts that mirror the production boot chain: firmware settings, bootloader, kernel and initramfs. Keep a known-good baseline image for each host so that every exercise ends with a verified rollback. Test runs happen only in the isolated range, under written approval that names the systems, the window and the rollback owner.

Defender-approved injects are planned changes to boot-related files, such as an approved bootloader configuration edit or an approved initramfs rebuild, applied by the platform team and logged as change records. Confirm that the detection stack ingests file creation and modification events for boot paths and that Process Creation telemetry from the change tooling is captured.

Range layout: Use a baseline image, a separate collector host and a SIEM instance that mirrors production log forwarding.
Injects: Apply only pre-approved boot file changes that match a change ticket, and record the expected event for each one.
Good detection: An alert fires within the agreed triage window and links the change to the boot path, host and user context.
Good response: The on-call analyst confirms whether the change was authorized, isolates the host if not, and starts a firmware and boot integrity check.
Exit criteria: Confirm that the rule suppresses approved maintenance noise without hiding unapproved edits.

Before each exercise, confirm the rollback steps and the log retention settings with the range owner.

How to tell whether Pre-OS boot coverage is improving

The most useful signal is whether your coverage of T1542 Pre-OS Boot and its sub-techniques is moving in the right direction, tracked per sub-technique rather than as a single yes or no for the whole technique. Keep a register with one row for each sub-technique on each platform you run (Linux, macOS, network devices and Windows), and record which data components the detection depends on, such as Process Creation (DC0032), Command Execution (DC0064) and File Creation (DC0039). Name the ATT&CK version each mapping targets. Because releases can rename, deprecate or revoke techniques, a mapping written against one version needs to be re-checked when you move to the next, and the register should show that re-check as a dated event rather than an overwritten cell.

False positive rates are the second signal, and they only mean something after tuning. Record alert volume per detection before and after each tuning change, along with the analyst disposition of each alert (true positive, benign, or unresolved). Ask your team to confirm what a benign firmware update or approved boot-configuration change looks like in your environment, and add those baselines to the register so that suppressions are traceable to an approved change. A falling false positive rate that comes from broad exclusions is not an improvement, so review suppressions on a fixed cadence and flag any that cover an entire host group.

The third signal is the number of validated scenarios over time. A scenario counts only when a cyber range exercise has produced the expected telemetry, the alert fired, and the response playbook was followed, and each should carry a date and the detection version it tested. Track which sub-techniques have at least one validated scenario and which have none, and treat the gap list as your backlog. Baseline figures for your current alert volume, false positive rate and scenario count should come from your own environment and your own records; DeployOpen can help set up the register and the validation cadence, but the numbers themselves must come from your data.

Common questions SOC leads and detection engineers ask about T1542

How do you get visibility below the operating system during Pre-OS boot?

Visibility below the OS comes from sources that run before the operating system loads, not from the endpoint agent alone. In practice, teams combine firmware and boot configuration inventory, platform management logs, and boot integrity attestation where the hardware supports it. An endpoint agent starts only after the boot chain has already run, so it cannot see a tampered bootloader or firmware image that executed first. Confirm with your hardware and firmware vendors which measurements, logs and attestation features your fleet actually exposes before you design the pipeline.

Do Sigma rules cover firmware and bootloader changes?

Sigma rules describe log-based detections, so they only cover firmware and bootloader activity when that activity is written to a log your SIEM collects. Most public Sigma rules target process creation and command execution on the running OS, which misses boot-time changes. Where firmware or boot events are logged, such as boot configuration changes or measured boot results forwarded to a central store, you can write Sigma logic against those fields. Treat coverage as something you verify per log source, and map each rule to the ATT&CK version you target.

How should we handle legitimate firmware updates without flooding alerts?

Legitimate firmware updates should be a known, scheduled change that the detection pipeline can recognize. Record each planned update in your change management system, then correlate boot measurement or firmware version changes against that record. Alerts that do not match an approved change go to triage, and matched changes are logged as evidence of control. Tune by asset group, so a change on one model family does not suppress unrelated hosts. Confirm with your vendor how update packages are signed and how they report their version, since those details determine what your rules can compare.

Which data components should we request from our vendors for Pre-OS boot detection?

Ask vendors for the logs and attributes that reveal boot-time state, mapped to the ATT&CK data components the detection strategies reference. Useful requests include firmware version and integrity measurements, boot configuration change events, management controller logs, and the file or image creation events on the systems that host boot artifacts. Process Creation and File Creation (DC0032 and DC0039) help only where the vendor exposes them. Ask each vendor to state which fields are logged, how often, and whether they can be forwarded to your SIEM without custom agents.

How do ATT&CK v19 and v20 changes affect our T1542 mapping?

ATT&CK v19, released April 28, 2026, split the Enterprise Defense Evasion tactic, so Stealth keeps ID TA0005 and a new Defense Impairment tactic has ID TA0112. Because releases can rename, deprecate or revoke techniques, your detection mappings should name the version they target, such as v19 or v20. Review your T1542 mapping against the v20 release notes and the enterprise-attack 20.0 STIX bundle, then record any differences in your rule metadata. Confirm with your detection team which version your SIEM content currently follows.

Can our own team run this detection, or do we need outside help?

Many SOC teams can run the detection themselves if they already operate a SIEM, have firmware and hardware inventory, and can ingest vendor logs. The work that usually needs more time is the firmware and vendor log inventory, the change correlation process, and rehearsing the detection in a cyber range. A fixed-scope engagement with DeployOpen can cover planning, implementing the log pipeline on open-source tooling inside your environment, and documenting the evidence. Ask any partner to put scope, deliverables and timelines in writing before work starts.

How long does it take to rehearse a Pre-OS boot detection in a cyber range?

The duration depends on how many hardware models, boot paths and log sources you want to exercise, and on how much of the pipeline is already built. No duration has been published for this exercise, so treat any figure you hear as a estimate to confirm. Break the effort into lab preparation, scenario scripting, detection validation and a review of response steps. Ask a provider for the exact scope of hardware and log sources in the range, and for the deliverables they will hand over at the end.

How DeployOpen builds Pre-OS boot detections and range exercises

DeployOpen works on T1542 Pre-OS boot as a fixed-scope engagement inside the client's own infrastructure, starting from the telemetry the client already collects. The work covers detection logic, validation in a private cyber range, documentation and handover, with ongoing support available as a retainer.

How we scope

Confirm which platforms are in the written scope, such as Linux, macOS, network devices or Windows, before any detection work starts.
Inventory firmware, bootloader and boot configuration sources the client can actually log, and record gaps in writing.
Agree the ATT&CK version the detection mappings will target, and the sub-techniques in or out of scope.

How we build

Map candidate detections to Process Creation, Command Execution and File Creation telemetry in the client's Wazuh, Security Onion or Sigma pipeline.
Write detection logic in plain terms and as Sigma rules where the log source supports them, with tuning notes for expected administrative activity.
Review the Audit and Privileged Account Management mitigations with the client and document which controls already exist and which need configuration.

How we hand over

Deliver the detection set, data source requirements and known blind spots in a written handover document.
Run a rehearsal in a private cyber range so the client's analysts can practice triage and response on the detections.
Provide a validation record that maps each detection to the ATT&CK version and sub-techniques it targets.

How we support

Offer ongoing support and continuous testing as a retainer, covering rule updates when ATT&CK releases change technique mappings.
Review detection performance with the client's SOC after the initial rehearsal, and adjust logic where telemetry changes.
Prepare the detection evidence for compliance readiness work, while noting that independent auditors issue any formal assessment.

T1542 Pre-OS boot