DET0344: Detection Strategy for Fileless Storage via Registry, WMI, and Shared Memory
DET0344 is a MITRE ATT&CK detection strategy for finding Fileless Storage behavior, where adversaries may hide data outside normal files, such as in the Wi...
Analyst context for executives and security teams
DET0344 is a MITRE ATT&CK detection strategy for finding Fileless Storage behavior, where adversaries may hide data outside normal files, such as in the Windows Registry, WMI repository, event logs, or Linux shared-memory locations. The business significance is that file-centric security controls and evidence collection may miss this behavior, which can weaken incident response, audit confidence, and resilience planning if teams assume “no suspicious files found” means “no malicious storage found.”
Executive priority
Security leaders should treat this as a coverage-validation issue rather than a single tool alert. The key decision is whether SOC and IR teams can inspect and preserve non-file storage locations on relevant Windows and Linux systems when investigating stealthy activity. This affects incident scoping, forensic readiness, control assurance, and prioritization of endpoint telemetry beyond traditional file scanning.
Technical view
The supplied ATT&CK object has no official detection text, platforms, or tactics of its own, but it detects T1027.011 Fileless Storage, which is associated with stealth and Linux/Windows platforms. SOC and detection teams should validate whether their endpoint, system, and forensic collection processes cover non-file storage locations referenced by the related technique: Windows Registry, WMI repository, event logs, and Linux shared-memory directories such as /dev/shm, /run/shm, /var/run, and /var/lock. Detection engineering should focus on suspicious creation, modification, execution linkage, or unusual access patterns involving these storage locations, correlated with process, user, and host context.
Likely telemetry
- Windows Registry access and modification telemetry
- WMI repository activity and WMI-related process telemetry
- Windows event log modification or unusual event log usage evidence
- Linux filesystem and process activity involving shared-memory or volatile directories such as /dev/shm and /run/shm
- Endpoint process lineage, command-line, user, and host context
Detection direction
- Validate that detection content is not limited to conventional file writes or file hashes.
- Correlate non-file storage changes with process execution, persistence-like behavior, unusual parent-child process chains, or unexpected user context.
- Tune carefully for administrative and system-management activity, since Registry, WMI, event logs, and shared-memory locations can have legitimate operational use.
- Confirm IR playbooks preserve relevant volatile and non-file artifacts before reboot, cleanup, or containment actions remove evidence.
- Use the relationship to T1027.011 as the primary analytic anchor because this detection strategy object does not provide its own official detection logic.
Mitigation priorities
- Prioritize endpoint visibility and forensic readiness for non-file storage mechanisms on supported Windows and Linux systems.
- Ensure incident response procedures include collection of Registry, WMI, event log, and shared-memory artifacts where relevant.
- Review privilege and administrative access controls that permit modification of these storage locations.
- Assess whether existing managed detection, EDR, SIEM, and logging pipelines retain enough context to investigate fileless storage behavior.
- Document coverage and gaps as compliance or audit evidence where monitoring and incident response capability must be demonstrated.
Analyst notes and limits
This take is based on DET0344 and its relationship to T1027.011 Fileless Storage. The detection strategy name specifically references Registry, WMI, and shared memory, while the related ATT&CK technique provides the practical context for Windows and Linux storage locations. Local validation is required to determine whether existing tooling actually collects these artifacts and whether detections are effective in a specific environment.
The official DET0344 object supplied here has no description, no official detection text, no tactics, and no platforms specified. Claims about exact analytics, efficacy, active exploitation, attribution, or guaranteed coverage cannot be made from the provided fields. Platform references are derived from the related T1027.011 technique, not from DET0344 itself.
Detection Strategy for Fileless Storage via Registry, WMI, and Shared Memory
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1027.011 | Fileless Storage Sub-technique | This object detects Fileless Storage. |
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 | cad3c60465b9… |
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 DET0344Open 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.