AN1035: Analytic 1035
Detects tampered hardware or firmware via anomalous host status telemetry. Behavioral chain: (1) Pre-OS or firmware components exhibit unexpected version changes, signature failures, or modified boot paths; (2) System management/firmware tools log hardware inventory drift; (3) Sensor health telemetry or boot attestation events fail baseline checks; (4) Follow-on process execution from altered firmware or unknown drivers after boot.
Analyst context for executives and security teams
AN1035 is a Windows-focused detection analytic for signs that hardware or firmware state has changed in ways that do not match the expected baseline. Its business value is that firmware and pre-OS tampering can undermine trust in the endpoint before normal security tooling starts, so leaders should treat coverage as a resilience and assurance question, not just an endpoint alerting question.
Executive priority
Prioritize this analytic where Windows systems support sensitive operations, regulated evidence, privileged administration, or business-critical services. The key decision is whether the organization can prove endpoint integrity from firmware through boot into the operating system, and whether incident responders have enough baseline and attestation evidence to decide when a device must be isolated, rebuilt, or investigated further.
Technical view
SOC and IR teams should validate whether they collect and retain host status telemetry that can show unexpected firmware or pre-OS version changes, signature failures, modified boot paths, hardware inventory drift, failed sensor health checks, failed boot attestation events, and post-boot execution from unknown drivers or altered firmware paths. Because no official detection logic is supplied, teams should build detection around deviations from known-good baselines and correlate firmware-management events with driver/process execution after boot.
Likely telemetry
- Windows host status and health telemetry
- Firmware or pre-OS component version and signature status
- Boot path and boot attestation events
- System management or firmware tool logs
- Hardware inventory and configuration drift records
Detection direction
- Establish known-good baselines for firmware versions, boot paths, hardware inventory, sensor health, and attestation outcomes before treating drift as malicious.
- Correlate multiple signals in the behavioral chain rather than relying on a single version change or inventory update.
- Tune for legitimate firmware updates, hardware replacement, maintenance windows, and OEM or administrative tooling activity to reduce false positives.
- Validate telemetry availability before assuming coverage, because the analytic depends on pre-OS, firmware, management, and post-boot evidence that many environments do not collect consistently.
- Escalate cases where attestation failure or firmware drift is followed by unknown driver loading or unusual process execution after boot.
Mitigation priorities
- Maintain authoritative asset, hardware, firmware, and configuration baselines for Windows systems in scope.
- Use controlled change management for firmware updates, boot configuration changes, and hardware replacement so detection teams can distinguish approved drift from suspicious drift.
- Ensure endpoint health, boot attestation, firmware-management, and driver/process telemetry are collected centrally with retention suitable for incident response.
- Define IR procedures for suspected firmware or hardware tampering, including isolation, evidence preservation, and criteria for rebuild or hardware replacement.
- Review coverage for high-value Windows endpoints first, especially systems used for privileged access, sensitive operations, or compliance-relevant workloads.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, not a technique, and has no tactic mapping or relationship context. Its value is strongest as a coverage validation item: can the organization observe integrity drift before and during boot, then connect that evidence to post-boot behavior?
The official detection field is not provided, and no relationships are supplied. This take is therefore limited to the official description, Windows platform scope, and the referenced MITRE detection strategy URL. Local baselines, tooling, firmware vendors, and logging architecture are required to operationalize the analytic.
Analytic 1035
Detects tampered hardware or firmware via anomalous host status telemetry. Behavioral chain: (1) Pre-OS or firmware components exhibit unexpected version changes, signature failures, or modified boot paths; (2) System management/firmware tools log hardware inventory drift; (3) Sensor health telemetry or boot attestation events fail baseline checks; (4) Follow-on process execution from altered firmware or unknown drivers after boot.
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 | a5ae18aad0ed… |
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 AN1035Open 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.