T1560: Archive Collected Data
An adversary may compress and/or encrypt data that is collected prior to exfiltration. Compressing the data can help to obfuscate the collected data and minimize the amount of data sent over the network.CitationDOJ GRU Indictment Jul 2018 Encryption can be used to hide information that is being exfiltrated from detection or make exfiltration less conspicuous upon inspection by a defender.
Both compression and encryption are done prior to exfiltration, and can be performed using a utility, 3rd party library, or custom method.
Security context for executives and security teams
Archive Collected Data matters because it is often the staging point between internal data collection and data leaving the organization. Compression reduces volume; encryption can make review harder. For leaders, the practical question is whether the organization can see unusual packaging of sensitive data on Linux, macOS, and Windows before it becomes an exfiltration or breach-response problem.
Executive priority
Prioritize this as a control-evidence and incident-readiness issue. Because ATT&CK places this technique in the collection tactic and links it to multiple sub-techniques, defensive coverage depends on endpoint audit quality, file activity visibility, and the ability to correlate archiving behavior with prior collection and later network transfer. Executives should ask whether SOC and IR teams can prove they collect the logs needed to identify bulk archive creation, encrypted archives, or archive activity by unusual users, processes, or locations.
Technical view
T1560 covers compression and/or encryption of collected data before exfiltration across Linux, macOS, and Windows. ATT&CK provides no official detection text, but relationship context includes DET0526, Detect Archiving and Encryption of Collected Data, and mitigation M1047 Audit. Detection engineering should validate coverage across the related paths: archive via utility, archive via library, and archive via custom method. Utility-based activity may be visible through process and command-line auditing; library or custom-method activity may require file creation, file type, entropy, access-pattern, and parent-process context rather than simple tool-name matching.
Likely telemetry
- Endpoint process creation and command-line logs for archive or encryption utilities where available
- File creation, rename, size, extension, and location metadata for archive-like outputs
- File header or file signature evidence for archive formats, where file inspection is permitted
- User, host, and parent-process context around bulk file reads followed by archive creation
- Audit logs from Linux, macOS, and Windows systems covering user activity and system configuration relevant to collection staging
Detection direction
- Do not rely only on known utility names; ATT&CK notes utility, third-party library, and custom methods, so detections should include behavioral file-staging patterns.
- Tune for context: legitimate backup, software packaging, administrative compression, developer builds, and log rotation can resemble this behavior.
- Look for archive creation after access to sensitive repositories or many source files, especially when followed by outbound transfer indicators.
- Use file signatures and metadata where available to reduce dependence on extensions, since extensions can be misleading.
- Map detections separately for Windows, macOS, and Linux so platform-specific audit gaps are visible.
Mitigation priorities
- Implement and regularly review auditing configurations, consistent with M1047 Audit, across systems where sensitive data may be collected.
- Confirm audit logs capture process execution, file creation, and user activity needed to reconstruct archive staging events.
- Establish baselines for legitimate archiving and encryption activity by role, host type, and business process.
- Prioritize monitoring around sensitive data stores and systems where collection would create material business, compliance, or operational risk.
- Ensure incident response playbooks treat unexpected archive creation as a possible collection-stage signal and correlate it with access history and network activity.
Additional notes and limits
This technique consolidates older revoked concepts for compressed data and encrypted data, and has sub-techniques for utility, library, and custom methods. The breadth of related groups and software shows the behavior is common across different threat reporting, but those relationships should be used for context, not as evidence of current targeting in any specific environment.
MITRE does not provide an official detection description for this object. The supplied relationship to DET0526 identifies a detection strategy, but its detailed content is not included here. Local validation is required to determine whether endpoint, file, audit, and network telemetry can actually observe this behavior in the organization’s environment.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Archive Collected Data
An adversary may compress and/or encrypt data that is collected prior to exfiltration. Compressing the data can help to obfuscate the collected data and minimize the amount of data sent over the network.CitationDOJ GRU Indictment Jul 2018 Encryption can be used to hide information that is being exfiltrated from detection or make exfiltration less conspicuous upon inspection by a defender.
Both compression and encryption are done prior to exfiltration, and can be performed using a utility, 3rd party library, or custom method.
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.
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: 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.