DET0887: Detection of Hardware
DET0887 is MITRE’s detection strategy for identifying reconnaissance focused on a victim’s hardware. The supplied ATT&CK record is sparse, but its relation...
Analyst context for executives and security teams
DET0887 is MITRE’s detection strategy for identifying reconnaissance focused on a victim’s hardware. The supplied ATT&CK record is sparse, but its relationship to T1592.001 indicates business value: hardware details can help an adversary tailor targeting, identify defensive protections, or refine later intrusion planning. Leaders should treat this as an early-warning and exposure-management question: do we know what hardware information about our environment is externally observable, and can we recognize unusual attempts to collect it?
Executive priority
Prioritize this as a reconnaissance visibility and asset-exposure issue rather than a confirmed intrusion signal. It supports decisions around attack surface management, SOC intake for pre-compromise activity, incident triage context, and audit evidence that hardware inventories and externally exposed information are governed. The key executive question is whether critical systems, specialized access controls, encryption hardware, or other defensive components are unnecessarily discoverable and whether teams have a process to investigate collection attempts.
Technical view
The ATT&CK object provides no official detection logic, platforms, or tactics, but it detects T1592.001 Hardware, which is under reconnaissance and uses the PRE platform context. SOC and detection engineering teams should validate whether they can observe attempts to enumerate or infer host hardware details, especially where such activity touches public-facing assets, procurement/support portals, documentation repositories, exposed management interfaces, or identity-authenticated resources. IR teams should treat confirmed hardware reconnaissance as context for scoping possible targeting, not as standalone proof of compromise.
Likely telemetry
- External attack surface and asset inventory records showing exposed hardware-related details
- Web, API, and portal access logs for requests to pages or endpoints containing hardware inventory, support, or configuration information
- Authentication and access logs for repositories, CMDBs, helpdesk systems, procurement systems, or asset-management platforms
- Network and application logs from public-facing services that may reveal device models, host types, or hardware components
- Change and data-access audit logs for internal documentation that describes host hardware or defensive hardware components
Detection direction
- Start by identifying where hardware details are stored or exposed, then confirm those sources generate searchable audit logs.
- Tune for unusual access patterns to hardware inventory or documentation, such as atypical users, unauthenticated scraping behavior, abnormal request volume, or access from unexpected locations.
- Correlate suspected hardware reconnaissance with other reconnaissance indicators rather than escalating solely on a single hardware-information request.
- Account for false positives from legitimate IT operations, asset management, support vendors, procurement, vulnerability management, and compliance evidence collection.
- Document blind spots explicitly, especially unmanaged public content, third-party portals, and systems that expose hardware banners or metadata without centralized logging.
Mitigation priorities
- Reduce unnecessary exposure of hardware details in public documentation, service banners, support pages, and externally accessible repositories.
- Apply least-privilege access and audit logging to asset inventories, CMDBs, procurement records, and internal documentation containing hardware details.
- Maintain accurate asset inventory so defenders can distinguish approved discovery from suspicious collection activity.
- Review third-party and support workflows that may reveal hardware models, versions, or defensive components.
- Use detection findings to improve reconnaissance playbooks, threat-intelligence enrichment, and incident-response scoping rather than treating this detection strategy as a complete control by itself.
Analyst notes and limits
This take is based on the supplied DET0887 metadata and its relationship to T1592.001 Hardware. Because MITRE provided no official description or detection text for DET0887, the guidance is framed around the related technique: adversaries may gather victim host hardware information for targeting during reconnaissance.
Platforms, tactics, official detection logic, and detailed data sources are not specified on the detection-strategy object. Local architecture, logging coverage, asset repositories, and external exposure must be validated before asserting detection coverage or control effectiveness.
Detection of Hardware
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
All related ATT&CK context
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 | 667ba3dc8a30… |
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 DET0887Open 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.