Detecting and Mitigating Archive via Library (T1560.002)

A defender who watches for tar and 7z can be missed by code that never calls them. It simply links a compression library and does the work in its own process. Archive via Library (T1560.002) is a Collection technique for Linux, macOS and Windows. It is a subtechnique of Archive Collected Data.

How attackers use it

MITRE explains that an adversary may compress or encrypt collected data before exfiltration using third-party libraries. Many exist. MITRE names the Python rarfile library, libzip and zlib. Most offer both compression and encryption.

Some archival libraries are preinstalled, such as bzip2 on macOS and Linux, and zip on Windows. MITRE draws a distinction that matters for defenders: libraries differ from utilities. A library can be linked against at compile time, while a utility needs a subshell or similar mechanism to run. That means there may be no archiver process to see at all. The activity happens inside a script interpreter or a custom binary.

Why this matters for software teams

Archive libraries are ordinary dependencies. They show up in the dependency tree of countless applications, and most of the time they are there for good reasons. But it is the reason this technique is harder to catch with process rules alone: the library is present, the code is legitimate, and what changes is how it is used and by which program.

Knowing what libraries your software ships is half the answer. If a service has no reason to compress anything and suddenly depends on an archive library, that is worth a question in code review. The same goes for scripts on build servers.

How to detect it

MITRE's analytics tie library use to process and file events.

• Windows. Python, PowerShell or custom .NET binaries running, with module loads linked to compression libraries, followed by archive file creation.
• Linux. Scripts or binaries calling libzip, zlib or bzip2, shown by dynamic linking to those libraries, with compressed files created in /tmp or user directories. The interpreters named are Python, Perl and compiled binaries.
• macOS. Library loads such as libz or libarchive from Python, Swift or Objective-C binaries, correlated in unified logs with creation of .zip, .gz, .bz2 or .dmg files.

The useful pattern is a process that has no business compressing data, such as a service account's script or a freshly dropped binary, loading a compression library and then writing an archive.

Where this fits in an intrusion

Archiving is a middle step. An adversary has already run something on a machine and found files worth taking. They gather, they pack, and then they send. This subtechnique is the packing step done without calling a tool. So the same process that is archiving is usually the one that gathered the files, and often the one that will send them.

That is useful for detection. If you see a process reading many files across user folders, writing one large output, and then opening a network connection, the library is incidental. The behavior is the signal. Correlating those three steps in one process lineage is more reliable than trying to enumerate every compression library.

Questions that cut through the noise

When a rule fires, ask:

1. What program loaded the library? A known application with its own bundled copy is normal. A script interpreter or an unsigned binary in a temporary folder is not.
2. Where did the output go? An archive in an application's own data folder is normal. A new archive in a temp or staging folder is worth a look.
3. How big is it, and what was read to make it? Many files from home directories or document shares packed into one is the pattern.
4. What happened next? An upload, a copy to a share, or a transfer to removable media ends the story.

How to reduce the risk

MITRE does not list a dedicated mitigation for this subtechnique. The controls that apply are the general ones for the parent technique: audit for unauthorized archival tools, and keep an accurate inventory of what is installed, including libraries, so that unexpected components stand out.

For your own code, the practical steps are:

1. Keep a software bill of materials for each application so archive libraries appear in the inventory.
2. Review new dependencies that handle compression or encryption, especially in components that never touched files before.
3. Remove unused dependencies, which shrinks the set of things an adversary can borrow.

Check your own environment

Start with your own code. The free in-browser dependency scan at https://gold.safeguard.sh/scan reads a dependency file on your machine, with no login, and the file never leaves your browser. It handles up to 100 dependencies, which is enough to see what compression libraries a small service pulls in. The Gold directory at https://gold.safeguard.sh lets you look up individual packages.

Click through it at your own pace, or open it full screen.

Then work the host side:

# Linux (read-only): list processes currently holding zlib open, as a quick look
lsof 2>/dev/null | grep -i libz | head

• Which services on your servers have compression libraries loaded, and is that expected?
• Do process creation and module load logs cover your servers?
• Are there Python or Perl interpreters on hosts that do not need them?

Common mistakes

• Writing detections only around archiver process names. This subtechnique exists to avoid them.
• Alerting on any compression library load. Browsers, backup agents and installers load them constantly, so scope rules to hosts and programs where it is unusual.
• Forgetting build servers and developer laptops, which have interpreters and compilers by default and often fewer logs.

Quick check

Sources

• MITRE ATT&CK T1560.002: Archive via Library