S0027: Zeroaccess
Zeroaccess is a kernel-mode Rootkit that attempts to add victims to the ZeroAccess botnet, often for monetary gain. [1]
Analyst context for executives and security teams
Zeroaccess matters because it represents malware designed to hide at a deep operating-system level while attempting to add victims to a botnet for monetary gain. For executives and security leaders, the key issue is not just infection cleanup; it is whether endpoint, incident response, and forensic processes can still be trusted when malware may conceal files, services, drivers, network connections, or other system components.
Executive priority
Treat this as a resilience and assurance problem. Kernel-mode rootkit behavior can undermine normal monitoring and make incident scope difficult to prove. Leaders should ask whether the organization has independent endpoint telemetry, offline or trusted-response procedures, and evidence that hidden persistence or NTFS-based concealment can be investigated. This is relevant to incident decision-making, audit confidence, and prioritizing controls that reduce dwell time when standard host views may be incomplete.
Technical view
The supplied ATT&CK context links Zeroaccess to Rootkit behavior (T1014) and NTFS File Attributes (T1564.004). SOC and IR teams should validate whether their tooling can identify signs of hidden drivers, hidden files, altered system-information views, concealed network connections, and suspicious NTFS attributes such as alternate data streams or extended attributes. Because ATT&CK provides no official detection text and no platform list for the malware object itself, validation should be based on the related techniques and local endpoint architecture rather than assumed product coverage.
Likely telemetry
- Endpoint detection and response events for driver loading, service creation, process activity, and suspicious kernel-level behavior
- Host forensic artifacts showing discrepancies between normal operating-system views and lower-level or offline inspection
- File-system metadata, including NTFS Master File Table records, alternate data streams, and extended attributes where Windows/NTFS is in scope
- Network telemetry that may reveal botnet-related communication attempts or unexpected connections hidden from normal host tools
- Incident response collection from trusted media or independent tooling when rootkit interference is suspected
Detection direction
- Validate that endpoint and forensic tools can detect or investigate rootkit-style hiding, not only standard file and process indicators.
- Compare multiple evidence sources, such as EDR, native OS commands, file-system inspection, and network telemetry, to identify inconsistencies caused by hiding or hooking behavior.
- Where Windows NTFS systems are in scope, test visibility into alternate data streams, extended attributes, and MFT-level anomalies related to T1564.004.
- Tune detections to account for legitimate drivers, security software, and administrative tooling to reduce false positives around low-level system activity.
- Document blind spots explicitly: ATT&CK does not provide official detection guidance for Zeroaccess, so coverage claims should be proven through internal testing and incident response exercises.
Mitigation priorities
- Prioritize least-privilege and administrative-control hygiene to reduce opportunities for kernel-level or privileged malware installation.
- Maintain endpoint hardening, patching, and trusted security tooling capable of collecting low-level host evidence.
- Prepare incident response procedures for suspected rootkits, including isolation, trusted acquisition, offline analysis, and rebuild criteria when host integrity cannot be assured.
- Ensure Windows file-system investigations include NTFS attributes when relevant, not only visible files and directories.
- Use network monitoring as a compensating source of evidence when host telemetry may be unreliable due to rootkit behavior.
Analyst notes and limits
The official ATT&CK description identifies Zeroaccess as a kernel-mode rootkit associated with adding victims to the ZeroAccess botnet, often for monetary gain. The strongest relationship-driven context is its use of Rootkit (T1014) and NTFS File Attributes (T1564.004). The practical defensive value is to verify whether the organization can still scope and respond when malware is designed to hide from normal host visibility.
The malware object does not specify platforms, tactics, aliases, labels, or official detection guidance. Platform-specific guidance is therefore limited to the related techniques, especially Windows relevance for NTFS File Attributes. Local environment evidence is required before making claims about exposure, detection coverage, or incident impact.
Zeroaccess
Zeroaccess is a kernel-mode Rootkit that attempts to add victims to the ZeroAccess botnet, often for monetary gain. [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 | Zeroaccess is a kernel-mode rootkit.CitationSophos ZeroAccess |
| Enterprise | T1564.004 | NTFS File Attributes Sub-technique | Some variants of the Zeroaccess Trojan have been known to store data in Extended Attributes.CitationCiubotariu 2014 |
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 | 5f4be134889d… |
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]
Sophos ZeroAccess
Wyke, J. (2012, April). ZeroAccess. Retrieved July 18, 2016.
Open source URL -
[2]
mitre-attack S0027Open 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.