DET0268: Detect Archiving via Library (T1560.002)
DET0268 is a detection strategy for identifying when collected data is compressed or encrypted through software libraries before exfiltration. The business...
Analyst context for executives and security teams
DET0268 is a detection strategy for identifying when collected data is compressed or encrypted through software libraries before exfiltration. The business issue is not the archive file itself; it is that library-based archiving can blend into normal application, scripting, or system behavior and may bypass detections that only look for command-line use of tools like zip or rar.
Executive priority
Security leaders should treat this as a coverage-validation item for data-loss readiness and incident response. Ask whether the SOC can detect suspicious archive creation across Linux, macOS, and Windows when no obvious archiving executable is launched. This matters for audit evidence, data protection controls, and response decisions because archiving can be a staging step before data leaves the environment.
Technical view
The related ATT&CK technique is T1560.002, Archive via Library, under collection, with Linux, macOS, and Windows listed on the related technique. Because the detection strategy object has no official detection text, teams should validate telemetry around applications and scripts that invoke archive/compression libraries, create compressed or encrypted archive outputs, or stage large collections of files. Detection should not rely only on process names for archive utilities; library use may appear inside Python, application processes, or native components.
Likely telemetry
- Endpoint file creation and modification events for archive-like outputs and staged collections of files
- Process execution and command-line telemetry for scripting runtimes and applications that may perform archiving
- Module, library, or package load telemetry where available, especially for compression or archive libraries
- EDR file I/O telemetry showing bulk reads followed by archive creation
- File metadata signals such as sudden size changes, compression/encryption-like characteristics, or unusual staging directories
Detection direction
- Validate whether detections cover library-based archive creation, not only standalone archive utilities.
- Correlate suspicious archive outputs with preceding collection behavior and subsequent outbound transfer indicators where telemetry exists.
- Tune for environment-specific baselines: backup agents, software deployment tools, developer workflows, and legitimate compression jobs can create similar artifacts.
- Prioritize anomalous parent processes, unusual user context, unexpected directories, high file counts, or archive creation outside known business workflows.
- Document blind spots where endpoint sensors do not capture module/library loads, script behavior, or file-content characteristics.
Mitigation priorities
- Establish baselines and allowlists for legitimate archiving workflows before relying on high-severity alerts.
- Ensure endpoint logging captures file creation, process context, and script/runtime activity on Linux, macOS, and Windows assets relevant to sensitive data.
- Restrict unnecessary scripting/runtime capabilities and package/library use where business operations allow.
- Apply least-privilege access to sensitive repositories so bulk collection and archiving opportunities are reduced.
- Use DLP, egress monitoring, and incident response playbooks to connect archive staging with potential data movement.
Analyst notes and limits
The strongest analytic value is in correlation. A single archive file may be benign, but archive creation by an unusual process, after broad file access, or before outbound transfer is more decision-useful for SOC and IR teams.
The supplied detection strategy has no official description, detection logic, platforms, or tactics. Platform and tactic context comes only from the relationship to T1560.002. Local baselines and telemetry availability are required to turn this into reliable detections.
Detect Archiving via Library (T1560.002)
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 | T1560.002 | Archive via Library Sub-technique | This object detects Archive via Library. |
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 | 224367762634… |
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 DET0268Open 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.