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

AN1271: Analytic 1271

Anomalous creation or mounting of hidden partitions or virtual file systems. Defender view: detection of registry modifications linked to non-standard file systems, suspicious disk I/O patterns, or bootkit-like behavior where hidden volumes are accessed outside normal file system APIs.

EnterpriseAN1271AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic matters because hidden partitions or virtual file systems can undermine normal visibility on Windows systems. For leaders, the decision value is not that every unusual disk event is malicious, but that attackers or bootkit-like activity may operate outside standard file system monitoring, creating a gap in incident confidence, recovery assurance, and forensic completeness.

Executive priority

Prioritize this as a resilience and assurance issue for Windows endpoints and servers where compromise could affect recovery, regulated evidence, or operational continuity. Security leaders should ask whether SOC and IR teams can see abnormal partition creation, hidden volume mounting, registry changes tied to non-standard file systems, and suspicious disk I/O—not just file activity exposed through normal APIs.

Technical view

AN1271 is a Windows detection analytic focused on anomalous creation or mounting of hidden partitions or virtual file systems. Because ATT&CK provides no specific detection logic or tactic mapping, teams should validate visibility around registry modifications linked to non-standard file systems, disk and volume events, suspicious disk I/O patterns, and bootkit-like behavior where hidden volumes are accessed outside normal file system APIs. Treat this as a coverage-validation analytic rather than a ready-to-run rule.

Likely telemetry

  • Windows registry modification telemetry related to storage, drivers, file systems, mount points, or volume configuration
  • Disk, partition, and volume creation or mount events
  • Endpoint detection telemetry for raw or unusual disk I/O patterns
  • Driver or boot-related activity telemetry where available
  • Forensic or EDR evidence showing access paths outside normal file system APIs

Detection direction

  • Baseline legitimate administrative, backup, encryption, virtualization, and storage-management activity before alerting on hidden or unusual volumes.
  • Tune for combinations of signals, such as registry changes plus new or hidden volume access plus abnormal disk I/O, rather than single low-context events.
  • Confirm whether existing endpoint tools observe activity outside standard file system APIs; this is a likely blind spot for file-only monitoring.
  • Ensure IR playbooks include validation steps for hidden partitions or virtual file systems when bootkit-like behavior is suspected.
  • Because no official detection logic is supplied, require local testing and analyst review before using this as a production alert.

Mitigation priorities

  • Inventory Windows systems where disk, partition, and boot integrity monitoring is required for business or compliance reasons.
  • Restrict and monitor administrative privileges capable of modifying storage, drivers, file systems, or boot-related settings.
  • Harden endpoint logging and EDR configuration to retain registry, volume, and disk I/O evidence needed for investigation.
  • Include hidden volume and non-standard file system checks in incident response and forensic readiness procedures.
  • Validate backup and recovery processes can detect or withstand hidden storage manipulation where operational resilience is critical.
Analyst notes and limits

The object is a detection analytic, not a technique, and has no supplied relationship context, tactic mapping, aliases, or official detection query. The strongest use is to drive visibility assessment and detection engineering around Windows storage and file-system blind spots.

This take is limited to the supplied ATT&CK fields. It does not establish active exploitation, actor attribution, business impact, or guaranteed detectability. Local endpoint tooling, logging depth, administrative practices, and normal storage operations determine whether this behavior can be reliably detected.

Official MITRE ATT&CK definition

Analytic 1271

Anomalous creation or mounting of hidden partitions or virtual file systems. Defender view: detection of registry modifications linked to non-standard file systems, suspicious disk I/O patterns, or bootkit-like behavior where hidden volumes are accessed outside normal file system APIs.

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

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.0
Created
Modified
Raw hash
68b63cbb8482594a...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 68b63cbb8482…
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]
    mitre-attack AN1271
    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.