Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN0918: Analytic 0918

Detection of EFI/firmware manipulation attempts via abnormal driver loads, unsigned kexts, or tampered NVRAM variables associated with component firmware configuration.

EnterpriseAN0918AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic is about spotting possible macOS EFI or firmware-level tampering, such as abnormal driver loads, unsigned kernel extensions, or modified NVRAM variables tied to component firmware configuration. For leaders, the significance is that firmware-layer activity can sit below normal operating system visibility and may affect trust in the endpoint itself, making incident containment and recovery decisions harder if telemetry is weak.

Executive priority

Prioritize this as a resilience and assurance question for macOS environments: do security teams have enough endpoint and system integrity evidence to distinguish legitimate firmware or driver changes from suspicious ones? This matters for incident response confidence, executive decision-making during high-severity endpoint investigations, and audit evidence around device integrity controls. Because no ATT&CK relationships or tactic mapping are supplied, treat this as a coverage-validation item rather than proof of a specific threat campaign or attack stage.

Technical view

For SOC, detection engineering, and IR teams, validate visibility into macOS events related to EFI or firmware configuration, abnormal driver loading, unsigned kext activity, and NVRAM variable changes. Since the official detection text is not provided, teams should not assume a ready-to-run analytic exists; instead, they should build or assess local logic around deviations from expected firmware, kernel extension, and NVRAM baselines. Investigation workflows should include confirming whether changes align with approved updates, hardware servicing, security tooling, or administrative activity.

Likely telemetry

  • macOS endpoint telemetry covering kernel extension or driver load activity
  • Evidence of unsigned or unexpected kexts
  • NVRAM variable state and change records where available
  • Firmware or EFI integrity/configuration observations from endpoint management or security tooling
  • Administrative change records for macOS updates, firmware updates, hardware servicing, or security tool deployment

Detection direction

  • Establish known-good baselines for expected macOS firmware, EFI-related configuration, driver loads, kexts, and NVRAM variables.
  • Tune detections to separate approved operating system, firmware, hardware, and security-agent changes from abnormal or unsigned components.
  • Validate whether telemetry persists across reboot and whether endpoint tools can observe firmware-adjacent changes rather than only user-space activity.
  • Escalate cases where unsigned kexts, abnormal driver loads, or unexpected NVRAM changes coincide with other suspicious endpoint behavior, while avoiding unsupported attribution or campaign assumptions.
  • Document blind spots where macOS fleet management or EDR tooling does not collect firmware, EFI, kext, or NVRAM evidence.

Mitigation priorities

  • Maintain controlled macOS update and firmware update processes with clear change records for SOC and IR correlation.
  • Restrict and monitor administrative pathways that can alter system-level configuration, drivers, kexts, or NVRAM settings.
  • Use endpoint management and security tooling to enforce or verify expected device integrity states where supported.
  • Create IR procedures for suspected firmware or EFI tampering, including evidence preservation, trusted rebuild/reimage decision criteria, and hardware/vendor escalation paths.
  • Review compliance evidence requirements for device integrity monitoring if macOS endpoints are in regulated or high-trust business workflows.
Analyst notes and limits

The supplied ATT&CK object is a detection analytic for macOS focused on EFI/firmware manipulation indicators. It has no supplied tactic mapping, no relationship context, and no official detection logic, so the most defensible use is as a prompt to validate telemetry and response readiness for firmware-adjacent endpoint integrity events.

This take is limited to the official STIX fields and the single external reference provided. It does not establish active exploitation, adversary attribution, affected products beyond macOS, or guaranteed detection coverage. Local baselines, tooling capabilities, and change-management records are required to determine whether observed activity is suspicious.

Official MITRE ATT&CK definition

Analytic 0918

Detection of EFI/firmware manipulation attempts via abnormal driver loads, unsigned kexts, or tampered NVRAM variables associated with component firmware configuration.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
32baf9480f5f779d...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 32baf9480f5f…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN0918
    Open source URL
Source and licensing

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.