AN0724: Analytic 0724
Detects file reads across locations followed by writes to temp or staging directories, often compressed or encrypted, indicating local staging behavior.
Analyst context for executives and security teams
This analytic is about spotting Windows systems that read files from multiple locations and then write the collected data into temporary or staging directories, sometimes in compressed or encrypted form. For leaders, the value is not just “finding file activity”; it is validating whether the organization can see potential data staging before a later incident decision depends on it.
Executive priority
Prioritize this as an evidence-readiness and resilience question: can the SOC prove when sensitive files were gathered and staged on Windows endpoints? This matters for incident response scoping, data-handling investigations, compliance evidence, and decisions about whether an event may involve preparation for data movement. Because no ATT&CK relationships or tactic mapping were supplied, treat this as a useful behavioral analytic rather than a complete risk story by itself.
Technical view
For Windows coverage, validate telemetry that can correlate file reads across multiple source locations with subsequent writes into temp or other staging paths. Detection engineering should focus on sequence, volume, path context, file type, and whether outputs appear compressed or encrypted. Since the official detection logic is not provided, teams must define local thresholds and exclusions based on normal administrative tools, backup agents, software installers, compression utilities, and legitimate application temp-file behavior.
Likely telemetry
- Windows endpoint file read events
- Windows endpoint file write/create events
- Process creation telemetry tied to file activity
- Command-line and parent/child process context where available
- File path metadata for temp and staging directories
Detection direction
- Validate that endpoint telemetry records both reads and writes, not only process starts.
- Correlate many or diverse file reads followed by writes to temp or staging directories within a practical time window.
- Tune against known-good software deployment, backup, indexing, archiving, and administrative workflows.
- Review whether compressed or encrypted output files are visible to the telemetry source, but avoid relying on that alone because staging may use ordinary file names or extensions.
- Prioritize alerts where the reading process touches unusual locations, sensitive directories, or files outside its normal application context.
Mitigation priorities
- Ensure endpoint logging policy and EDR configuration capture file access and file creation events needed for this behavior.
- Reduce unnecessary write access to temp or staging locations where business workflows do not require it.
- Apply least-privilege access controls to sensitive file locations so broad local collection is harder to perform.
- Maintain allowlists or baselines for legitimate compression, backup, installer, and administrative tooling to improve triage quality.
- Use incident response playbooks that preserve staged files, process context, user context, and timestamps for scoping decisions.
Analyst notes and limits
This object is a detection analytic, not a technique or campaign description. The supplied fields identify Windows as the platform and describe a local staging-style pattern, but no tactic, relationship context, analytic logic, data source mapping, or mitigation mapping was supplied. Treat it as a detection design prompt that requires local telemetry validation and environment-specific tuning.
No official detection content, relationships, tactics, aliases, or labels were provided. This take does not assert active exploitation, attacker attribution, guaranteed detection, or applicability beyond Windows. Effectiveness depends on the organization’s endpoint telemetry depth and ability to correlate file events over time.
Analytic 0724
Detects file reads across locations followed by writes to temp or staging directories, often compressed or encrypted, indicating local staging behavior.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | ad0e07dde0e6… |
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 AN0724Open 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.