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

AN1037: Analytic 1037

Detects tampered Mac hardware/firmware by analyzing unified logs, EndpointSecurity events, and Apple Mobile File Integrity (AMFI) checks. Behavioral chain: (1) Boot process reports firmware signature mismatch; (2) Secure Boot policy altered; (3) new EFI drivers or hardware devices appear in inventory; (4) system extension loads from unapproved developer IDs post-boot.

EnterpriseAN1037AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Analytic 1037 is a macOS-focused detection analytic for signs that hardware, firmware, boot policy, EFI components, or post-boot system extensions may have been tampered with. Its business value is in helping leaders verify whether high-trust endpoints can still be trusted: if boot integrity, firmware state, or approved developer controls are compromised, normal endpoint monitoring and incident response assumptions may be weakened.

Executive priority

Prioritize this where macOS systems support privileged users, sensitive business workflows, development environments, regulated data access, or operationally critical functions. The key leadership question is whether the organization has evidence to prove device integrity after suspicious boot, firmware, or system-extension activity. This analytic supports resilience, IR decision-making, and compliance evidence by identifying whether teams can collect and review low-level macOS integrity signals, not just application or user activity logs.

Technical view

For SOC, IR, and detection engineering teams, validate whether macOS telemetry captures the behavioral chain described by the ATT&CK object: firmware signature mismatch during boot, Secure Boot policy changes, new EFI drivers or hardware inventory changes, and system extensions loading from unapproved developer IDs after boot. Because no separate official detection logic is supplied, teams should treat this as a detection-design requirement rather than a ready-to-run rule. Confirm that unified logs, EndpointSecurity events, AMFI-related checks, boot/security policy state, hardware inventory, EFI-related inventory, and system-extension metadata are available, retained, and correlated by device and time.

Likely telemetry

  • macOS unified logs related to boot, firmware, Secure Boot, AMFI, and system extension activity
  • EndpointSecurity events from macOS endpoints
  • Apple Mobile File Integrity checks or related integrity decision logs
  • Firmware or boot integrity status records, including signature mismatch indicators where available
  • Secure Boot policy state and policy-change evidence

Detection direction

  • Validate collection before tuning: this analytic depends on endpoint integrity and low-level macOS telemetry that may not be collected by default in all environments.
  • Correlate the chain across time on the same host: boot-time firmware mismatch, Secure Boot policy alteration, new EFI or hardware inventory, and unapproved developer ID system-extension loading are stronger together than as isolated events.
  • Baseline approved hardware, EFI components, developer IDs, and system extensions to reduce false positives from legitimate maintenance, OS upgrades, hardware repair, or approved security tooling changes.
  • Create analyst context for expected macOS update and enrollment workflows so defenders can distinguish authorized platform changes from suspicious tampering indicators.
  • Account for blind spots where endpoints are offline, recently reimaged, unmanaged, lack EndpointSecurity visibility, or do not forward unified logs with sufficient retention.

Mitigation priorities

  • Establish authoritative macOS hardware, firmware, EFI, Secure Boot, and system-extension baselines for managed devices.
  • Ensure endpoint management and security tooling can preserve and forward the required macOS unified log, EndpointSecurity, AMFI, and inventory evidence.
  • Restrict and review system extension approvals and developer IDs through managed policy where applicable.
  • Define an incident response path for suspected device integrity compromise, including containment, forensic preservation, and re-trust or rebuild decisions.
  • Include boot integrity and approved extension evidence in audit or compliance readiness checks for sensitive macOS fleets.
Analyst notes and limits

The ATT&CK object is a detection analytic, not a technique, and no tactics or relationships are supplied. The strongest use is as a coverage checklist for macOS device-integrity monitoring and incident response readiness. Local baselines and asset criticality are required to decide severity and response.

Official detection logic is not provided, and no relationship context, adversary attribution, active exploitation claim, or impact statement is supplied. This take is limited to the macOS platform and telemetry types explicitly described in the official object.

Official MITRE ATT&CK definition

Analytic 1037

Detects tampered Mac hardware/firmware by analyzing unified logs, EndpointSecurity events, and Apple Mobile File Integrity (AMFI) checks. Behavioral chain: (1) Boot process reports firmware signature mismatch; (2) Secure Boot policy altered; (3) new EFI drivers or hardware devices appear in inventory; (4) system extension loads from unapproved developer IDs post-boot.

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
d70eb6b67db24296...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle d70eb6b67db2…
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 AN1037
    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.