S0047: Hacking Team UEFI Rootkit
Hacking Team UEFI Rootkit is a rootkit developed by the company Hacking Team as a method of persistence for remote access software. [1]
Analyst context for executives and security teams
Hacking Team UEFI Rootkit matters because it represents persistence below the operating system: firmware-level compromise can survive normal reimaging and can undermine confidence in endpoint recovery. For leaders, the decision value is not whether this specific malware is present everywhere, but whether the organization has a defensible process to detect, investigate, and recover from rootkit or system-firmware persistence when conventional endpoint controls are insufficient.
Executive priority
Treat this as a resilience and incident-response readiness issue. Executives should ask whether high-value systems have firmware integrity expectations, whether IR playbooks address suspected rootkit or UEFI/BIOS persistence, and whether recovery procedures include hardware or firmware validation rather than only OS rebuilds. This also supports audit and compliance evidence around secure configuration, asset assurance, and recovery confidence for critical endpoints.
Technical view
ATT&CK links this malware to Rootkit (T1014) and System Firmware (T1542.001). SOC and IR teams should validate visibility for indicators of hidden system components, unexpected firmware or boot-chain changes, and persistence that remains after OS-level remediation. Because the malware object itself has no official detection text and no specified platforms, detection engineering should be driven by the related techniques and local asset scope, especially where Windows or network-device firmware monitoring is relevant from the System Firmware relationship and Linux/macOS/Windows rootkit considerations are relevant from the Rootkit relationship.
Likely telemetry
- Firmware/BIOS/UEFI version and configuration inventory for in-scope assets
- Secure boot, boot-chain, or firmware integrity status where available
- Endpoint security telemetry for hidden drivers, services, files, processes, or network connections
- Host event logs and EDR observations related to kernel-level or low-level system component tampering
- Asset management records tying firmware baselines to device models and business criticality
Detection direction
- Validate whether current endpoint and firmware telemetry can observe behavior aligned to T1014 and T1542.001 rather than relying only on file-based malware signatures.
- Prioritize high-value endpoints and systems where firmware persistence would materially affect recovery confidence or business continuity.
- Tune investigations for persistence that survives OS cleanup, unexplained reappearance of remote access software, or discrepancies between expected and observed firmware/boot state.
- Account for false positives from legitimate firmware updates, OEM utilities, security agents, and administrative boot configuration changes.
- Document blind spots explicitly: the ATT&CK malware entry provides no official detection guidance and no platform field, so local hardware, OS, and firmware-management capabilities determine practical coverage.
Mitigation priorities
- Establish authoritative firmware and boot configuration baselines for critical assets before an incident occurs.
- Restrict and monitor administrative paths used to modify firmware or boot settings, consistent with least privilege and change-control expectations.
- Ensure firmware update processes are governed, logged, and sourced from trusted channels.
- Update IR playbooks so suspected firmware/rootkit persistence triggers hardware-level validation, firmware reflash or replacement considerations, and post-recovery verification.
- Use tabletop exercises to confirm whether SOC, IR, endpoint engineering, and asset owners know when an OS rebuild is not sufficient evidence of eradication.
Analyst notes and limits
The supplied ATT&CK object identifies Hacking Team UEFI Rootkit as a persistence method for remote access software and relates it to rootkit behavior and system firmware modification. The strongest defensive takeaway is readiness for low-level persistence: inventory, baselining, firmware governance, and escalation criteria for IR. Relationship context is important because the malware entry itself is sparse.
No official detection is provided for this malware object, and the malware platform field is not specified. Any platform-specific monitoring plan must be validated against the organization’s actual assets and the related ATT&CK techniques rather than inferred as confirmed coverage for this software.
Hacking Team UEFI Rootkit
Hacking Team UEFI Rootkit is a rootkit developed by the company Hacking Team as a method of persistence for remote access software. [1]
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1014 | Rootkit | Hacking Team UEFI Rootkit is a UEFI BIOS rootkit developed by the company Hacking Team to persist remote access software on some targeted systems.CitationTrendMicro Hacking Team UEFI |
| Enterprise | T1542.001 | System Firmware Sub-technique | Hacking Team UEFI Rootkit is a UEFI BIOS rootkit developed by the company Hacking Team to persist remote access software on some targeted systems.CitationTrendMicro Hacking Team UEFI |
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.1 | Current bundle | a92bf75e8734… |
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]
TrendMicro Hacking Team UEFI
Lin, P. (2015, July 13). Hacking Team Uses UEFI BIOS Rootkit to Keep RCS 9 Agent in Target Systems. Retrieved December 11, 2015.
Open source URL -
[2]
mitre-attack S0047Open 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.