AN0774: Analytic 0774
Unusual modification of boot records (MBR, VBR) or EFI partitions not associated with legitimate patch cycles or OS upgrades. Registry or WMI events associated with firmware update tools executed from unexpected parent processes. API calls (e.g., DeviceIoControl) writing directly to raw disk sectors. Subsequent abnormal boot configuration changes followed by unsigned driver loads.
Analyst context for executives and security teams
This analytic is about spotting suspicious changes to Windows boot records or EFI-related areas, especially when they do not line up with approved patching, OS upgrades, or expected firmware-update activity. For leaders, the practical risk is that boot-level tampering can undermine recovery confidence and complicate incident response because the activity occurs below normal application and user activity monitoring.
Executive priority
Prioritize this as a resilience and incident-readiness validation item, not just a SOC rule. Executives should ask whether the organization can distinguish approved boot, firmware, and OS-update activity from abnormal raw-disk or boot-configuration changes, and whether evidence would be available during an incident to prove what changed, when, and under which process lineage. This also supports audit and compliance conversations around change control for sensitive system components.
Technical view
For Windows environments, validate visibility into unusual modification of MBR, VBR, or EFI partitions; registry or WMI events tied to firmware update tools; unexpected parent processes launching those tools; API activity such as DeviceIoControl writing directly to raw disk sectors; abnormal boot configuration changes; and unsigned driver loads after those changes. Because no ATT&CK tactic mapping, relationships, or official detection logic are supplied, teams should treat this as a detection-engineering pattern requiring local baselining against patch cycles, OS upgrades, and approved firmware workflows.
Likely telemetry
- Windows process creation and parent-child process lineage for firmware update tools
- Registry events associated with firmware update activity
- WMI events associated with firmware update activity
- Signals for API calls such as DeviceIoControl that write directly to raw disk sectors
- Evidence of MBR, VBR, or EFI partition modification
Detection direction
- Baseline approved patch, OS upgrade, and firmware update windows so expected boot or EFI changes are not treated the same as unscheduled activity.
- Correlate raw disk write behavior with process lineage; unexpected parent processes should increase investigative priority.
- Tune for sequences rather than single events where possible: boot-record or EFI modification, followed by abnormal boot-configuration change, followed by unsigned driver load.
- Expect false positives from legitimate maintenance, recovery tooling, OS upgrades, and firmware updates unless change-control context is included.
- Validate whether current endpoint telemetry actually captures low-level disk writes, WMI/registry activity, boot configuration changes, and driver signing state; these are common coverage gaps.
Mitigation priorities
- Strengthen change-control evidence for Windows patching, OS upgrades, firmware updates, and boot-configuration changes.
- Limit and review execution paths for firmware update tools, with attention to unexpected parent processes.
- Ensure incident response procedures include preservation and review of boot-record, EFI, boot-configuration, and driver-load evidence when this analytic fires.
- Use maintenance-window and asset-context data to help the SOC separate legitimate administrative activity from abnormal boot-level changes.
- Prioritize validation on systems where loss of boot integrity would create high recovery, operational, or compliance impact.
Analyst notes and limits
The supplied object is a detection analytic, AN0774, for Windows. Its description provides behavioral indicators but no formal detection query, no tactic assignment, and no related ATT&CK objects. The strongest use is as a coverage-assessment and detection-design prompt for boot-level modification visibility.
This take is limited to the supplied ATT&CK fields and external reference. It does not establish active exploitation, adversary attribution, business exposure, or guaranteed detectability. Local environment data is required to determine whether the described telemetry is collected and whether observed activity is legitimate maintenance or suspicious behavior.
Analytic 0774
Unusual modification of boot records (MBR, VBR) or EFI partitions not associated with legitimate patch cycles or OS upgrades. Registry or WMI events associated with firmware update tools executed from unexpected parent processes. API calls (e.g., DeviceIoControl) writing directly to raw disk sectors. Subsequent abnormal boot configuration changes followed by unsigned driver loads.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | a2c68cc4259c… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0774Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.