AN0776: Analytic 0776
Abnormal modification of EFI firmware binaries in /System/Library/CoreServices/ or NVRAM parameters not associated with OS updates. Unified logs capturing calls to bless or nvram commands executed from untrusted parent processes. Sudden unsigned kext loads after EFI variable tampering.
Analyst context for executives and security teams
AN0776 is a macOS-focused detection analytic for suspicious changes to EFI firmware-related files, NVRAM parameters, and follow-on unsigned kernel extension activity. For leaders, the business value is not just malware detection: firmware and boot configuration changes can affect endpoint trust, recovery confidence, and incident scoping. Teams should be able to distinguish legitimate OS update activity from abnormal firmware or NVRAM modification.
Executive priority
Prioritize this as a resilience and endpoint-trust validation item for macOS environments. Security leaders should ask whether SOC and incident response teams can see EFI/NVRAM-related change activity, correlate it with approved OS updates, and preserve evidence when boot-level or kernel-level tampering is suspected. This also supports audit and compliance discussions around endpoint integrity monitoring and change control.
Technical view
Validate visibility on macOS for abnormal modification of EFI firmware binaries under /System/Library/CoreServices/, NVRAM parameter changes, unified log entries involving bless or nvram commands, and sudden unsigned kext loads following EFI variable tampering. Because no ATT&CK tactic, relationship context, or official detection logic is supplied, teams should treat AN0776 as analytic guidance rather than a complete rule. Detection engineering should focus on correlation: command execution context, parent process trust, timing relative to OS updates, and subsequent kernel extension behavior.
Likely telemetry
- macOS unified logs showing bless command execution
- macOS unified logs showing nvram command execution
- File integrity or endpoint telemetry for /System/Library/CoreServices/ EFI firmware binary modifications
- NVRAM parameter change evidence
- OS update or patch management records for change justification
Detection direction
- Baseline legitimate OS update behavior so expected EFI or NVRAM changes are not treated as standalone incidents.
- Alert or triage when bless or nvram is launched from an untrusted or unusual parent process.
- Correlate EFI/NVRAM changes with unsigned kext load events, especially when changes are not associated with approved OS updates.
- Tune for local administration workflows to reduce false positives from authorized maintenance or update activity.
- Confirm whether endpoint tooling retains enough unified log, process lineage, file modification, and kext load detail to investigate after reboot or remediation.
Mitigation priorities
- Maintain disciplined macOS OS update and change-management records to support fast separation of legitimate update activity from suspicious modification.
- Ensure centralized collection and retention of macOS unified logs and endpoint integrity telemetry relevant to bless, nvram, EFI-related paths, and kext loads.
- Restrict and monitor administrative activity capable of changing boot, firmware, or kernel-extension state where operationally feasible.
- Prepare incident response procedures for suspected boot or firmware-related tampering, including evidence preservation and trusted recovery decisions.
- Use this analytic to guide control validation rather than assuming coverage from general endpoint monitoring.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, not a technique entry. It names macOS-specific signals and suspicious conditions but does not provide formal detection logic, tactics, mitigations, procedures, groups, or software relationships. Local baselines for OS updates, administrative tooling, and kext usage are essential for useful triage.
No official detection section, tactic mapping, or relationship context was supplied. This take does not infer active exploitation, actor attribution, business impact, or guaranteed detectability. Applicability is limited to the supplied platform: macOS.
Analytic 0776
Abnormal modification of EFI firmware binaries in /System/Library/CoreServices/ or NVRAM parameters not associated with OS updates. Unified logs capturing calls to bless or nvram commands executed from untrusted parent processes. Sudden unsigned kext loads after EFI variable tampering.
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 | ea05fe8603c7… |
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 AN0776Open 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.