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

S0112: ROCKBOOT

ROCKBOOT is a Bootkit that has been used by an unidentified, suspected China-based group. [1]

EnterpriseS0112MalwareObject v1.1 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

ROCKBOOT matters because it is a Windows bootkit: malware designed to persist below the normal operating system layer. For leaders, the practical issue is not routine malware cleanup; it is confidence in recovery. If a boot-level compromise is suspected, reimaging or endpoint removal actions may be insufficient unless responders validate the boot record/boot chain and recovery media integrity.

Executive priority

Treat this as a high-consequence persistence scenario for incident response readiness. The decision value is ensuring the organization can identify and recover from malware that may survive standard OS-level remediation. Executives and risk owners should ask whether IR playbooks, endpoint telemetry, forensic procedures, and rebuild standards include bootkit considerations for Windows systems, especially for environments where system availability, audit evidence, or trusted recovery are critical.

Technical view

ATT&CK links ROCKBOOT to Bootkit technique T1542.003, associated with stealth and persistence. SOC and IR teams should validate whether Windows endpoint investigations include evidence below the OS layer, such as MBR/VBR or boot configuration anomalies, and whether escalation criteria exist when persistence survives normal cleanup. Relationship context also notes APT41 uses this object, but local detections should be behavior-led rather than assuming attribution.

Likely telemetry

  • Windows endpoint security and EDR telemetry related to boot configuration or low-level disk changes
  • Forensic disk artifacts, including Master Boot Record and Volume Boot Record inspection where applicable
  • Host integrity or secure boot/boot chain validation results where available
  • Incident response rebuild and reimage records showing whether boot media and disk partitions were fully trusted
  • Alerts or logs indicating suspicious persistence that survives reboot or standard malware removal

Detection direction

  • Because ATT&CK provides no official detection text for ROCKBOOT, validate coverage against the related Bootkit behavior rather than the malware name alone.
  • Tune investigations for suspicious changes to boot sectors, boot configuration, or early-start persistence on Windows systems, while accounting for legitimate disk management, imaging, encryption, and recovery tools that can create false positives.
  • Confirm whether SOC triage has a path to escalate suspected boot-level compromise to forensic acquisition; many blind spots occur when teams rely only on OS-level process, file, and registry telemetry.
  • Use the APT41 relationship as threat-intelligence context for prioritization, not as proof of attribution in any local incident.

Mitigation priorities

  • Prioritize tested incident response procedures for bootkit suspicion, including forensic preservation and criteria for full disk rebuild or trusted reinstallation.
  • Validate endpoint hardening and boot integrity controls available in the Windows environment, including whether they produce reviewable evidence for SOC and audit use.
  • Ensure backup, golden image, and recovery processes are trusted and can restore systems without preserving compromised boot components.
  • Train SOC and IR teams to recognize when repeated reinfection or persistence after cleanup may require boot-level investigation rather than additional standard malware removal.
Analyst notes and limits

The supplied ATT&CK object is sparse: ROCKBOOT is described as a bootkit used by an unidentified, suspected China-based group, and the relationship context also lists APT41 as using it. The most defensible operational takeaway is to prepare for and validate detection/remediation of bootkit-style persistence on Windows systems, not to infer current activity or customer exposure.

No official ATT&CK detection guidance, malware aliases, labels, or tactics are provided directly for ROCKBOOT. The technical framing relies on the supplied relationship to T1542.003 Bootkit and the Windows platform field. Local environment evidence is required to determine actual exposure, detection coverage, and remediation readiness.

Official MITRE ATT&CK definition

ROCKBOOT

ROCKBOOT is a Bootkit that has been used by an unidentified, suspected China-based group. [1]

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.

ATT&CK relationship table

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1542.003 Bootkit Sub-technique

ROCKBOOT is a Master Boot Record (MBR) bootkit that uses the MBR to establish persistence.CitationFireEye Bootkits

Associated objects

Groups, software, and campaigns

Group Enterprise

G0096: APT41

APT41 is a threat group that researchers have assessed as Chinese state-sponsored espionage group that also conducts financially-motivated operations. Active since at least 2012, APT41 has been observed targeting various industries, including but not limited to healthcare, telecom, technology, finance, education, retail and video game industries in 14 countries.[1] Notable behaviors include using a wide range of malware and tools to complete mission objectives. APT41 overlaps at least partially with public reporting on groups including BARIUM and Winnti Group.[2][3]

Relationship explorer

All related ATT&CK context

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.1
Created
Modified
Raw hash
dc7deb933dbb08ac...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle dc7deb933dbb…
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]
    FireEye Bootkits

    Andonov, D., et al. (2015, December 7). Thriving Beyond The Operating System: Financial Threat Group Targets Volume Boot Record. Retrieved May 13, 2016.

    Open source URL
  2. [2]
    mitre-attack S0112
    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.