Archive via Utility

Before data leaves a network, it's usually packaged first. A folder full of individual files is slow and conspicuous to move; a single compressed archive is faster, smaller, and far easier to move as one unit, whether that's over the network or onto removable media.

This technique covers exactly that packaging step: using a real, ordinary compression tool, the same one any employee might use, to bundle collected data into an archive before it goes anywhere else.

Once an attacker has gathered the files they want, they run a standard compression utility, WinRAR, 7-Zip, tar, or an equivalent, against that collected data, often into a single named archive in a staging location. Nothing about the tool itself is unusual; these are the same utilities installed on countless ordinary systems for entirely legitimate reasons.

Attackers frequently add a password or encryption to the archive at this step too, which serves two purposes at once: it can help the file evade content-inspection tools that would otherwise flag sensitive data leaving the network, and it keeps the contents private even if the archive is later discovered.

Data source: endpoint process-creation telemetry for the archive utility (Sysmon Event ID 1), plus the PowerShell script-block record (Event 4104) of the launching parent

{
  "host": {
    "name": "wkstn-example"
  },
  "user": {
    "name": "j.doe"
  },
  "event": {
    "code": "1",
    "action": "Process Create"
  },
  "process": {
    "name": "tar.exe",
    "parent": {
      "name": "powershell.exe"
    },
    "command_line": "tar.exe -cf C:\\Users\\Public\\staged-docs.tar -C C:\\Users\\Public\\outbox ."
  }
}

Prebuilt Elastic rule: Sensitive Files Compression (Linux only, specific credential paths)

Filter process-creation events for known archiving utilities, then look closely at two things: the argument list (an encryption or password flag is a much stronger signal than a plain compress command) and the output location. A new archive appearing in a user's temp directory, a public share, or anywhere outside where that tool is normally used is worth real attention. Do not expect a file-creation event for the archive: Sysmon's FileCreate is usually an allowlist, so the process event is the evidence. The prebuilt Sensitive Files Compression rule covers only Linux archiving of specific credential files; general staging needs its own hunt or rule.

Correlating with what happened immediately before matters: an archiving event that follows a burst of file access from elsewhere on the network (see T1039) tells a much more complete story than either signal alone. The sequence, collect then compress, is often more convincing than any single step.

Compression utilities are everywhere for entirely mundane reasons: scheduled backups, log rotation, software packaging, and ordinary users zipping up files to email or upload them. The bare fact that WinRAR or 7-Zip ran proves very little by itself. tar ships with Windows, so its presence is no more exotic than 7-Zip's.

The distinguishing signal is context: a known backup script running on its normal schedule against its normal target reads very differently from an interactive user session suddenly archiving a broad, sensitive folder into a password-protected file in a staging location it's never used before. The account on a process event is the executing context, which for agents, services and scheduled tasks is often SYSTEM rather than the person behind the action, so SYSTEM is not exculpatory; a re-authenticated event such as a file-share access or a logon carries the real identity.

• MITRE ATT&CK T1560.001: Archive via Utility
• Elastic Security: Sensitive Files Compression

1 scenario in this catalog covers T1560.001. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →