Overview

Archive via Utility (T1560.001) describes adversaries using compression and archiving tools — such as tar, zip, 7-Zip, WinRAR, makecab, or certutil — to package collected data before exfiltrating it. The goal is to reduce file size, bundle multiple files into a single transferable object, and in many cases encrypt the contents to frustrate inspection.

Detecting this technique matters because it sits at the boundary between collection and exfiltration — catching it early can prevent sensitive data from leaving the environment entirely. Archiving utilities are ubiquitous and often trusted by default, making them an ideal blind spot for attackers to exploit. Every security team needs visibility here because the technique appears in ransomware pre-staging, espionage campaigns, and insider threat scenarios alike.

Attacker Perspective

Attackers abuse archiving utilities because they are almost always present on the target system, require no additional tooling, and produce output that blends in with normal administrative activity.

• Living-off-the-land on Windows: An attacker uses makecab /f filelist.ddf or diantz.exe to bundle exfiltration-ready files into a cabinet archive, leveraging a signed Microsoft binary that many allow-lists trust unconditionally.
• Linux data staging: After harvesting credentials from /etc/shadow and SSH keys from ~/.ssh/, an attacker runs tar -czf /tmp/.hidden.tar.gz /home/user/.ssh/ /etc/passwd to create a compressed archive in a world-writable directory before exfil.
• Encrypted archives to defeat DLP: Using 7za a -p"P@ssw0rd!" -mhe=on archive.7z sensitive_docs\, attackers password-protect and encrypt archive headers so that network DLP solutions cannot inspect file contents or even filenames.
• certutil Base64 encoding: On locked-down hosts where no archiving tool is available, attackers run certutil -encode payload.exe payload.b64 to convert binary data to a text stream that evades binary-aware controls and can be passed through email or web uploads.

This technique is attractive precisely because it requires no malware — every action is performed by tools the operating system already trusts.

Detection Strategy

Required Telemetry

• Windows Process Creation (Event ID 4688): Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation = Success. Additionally enable command-line logging in the registry: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. Without command-line auditing, you see the process name but not the arguments — which is where all meaningful signal lives.
• Windows Sysmon (Event ID 1 — Process Create, Event ID 11 — File Create): Deploy Sysmon with a configuration that captures CommandLine, ParentImage, User, and Hashes. Sysmon Event ID 1 is far richer than native 4688 and should be the primary source where available. Event ID 11 catches archive files written to disk (filter on extensions .zip, .7z, .rar, .cab, .gz, .tar).
• Linux Auditd: Add the following rules to /etc/audit/rules.d/archive.rules to capture execution of archiving utilities:
  -a always,exit -F arch=b64 -S execve -F exe=/usr/bin/tar -k archive_utility
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/zip -k archive_utility
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/gzip -k archive_utility
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/7za -k archive_utility
  These generate EXECVE and SYSCALL audit records that include full argument arrays (a0, a1, a2…).
• macOS Endpoint Security / Unified Log: Use an EDR agent or the macOS Endpoint Security Framework to capture ES_EVENT_TYPE_NOTIFY_EXEC events for process execution. Alternatively, enable OpenBSM audit with -a always,exit -S execve equivalent flags in /etc/security/audit_control.
• Network/Proxy Logs (Zeek HTTP, Firewall, Proxy): Zeek http.log provides uri, mime_type, method, and file magic fields. Proxy logs should capture full URI, user-agent, bytes transferred, and response codes. Enable SSL inspection if possible to see HTTPS transfers of archive files.
• EDR Telemetry: If you have CrowdStrike, Defender for Endpoint, or SentinelOne, ensure process tree telemetry and file write events are forwarded to your SIEM. These provide parent-child relationships that raw Windows Event Logs often lack.

Key Indicators

• Suspicious process: makecab.exe or diantz.exe with data file arguments. Source: Sysmon Event ID 1 / Windows 4688. Field: CommandLine. Pattern: makecab or diantz referencing paths outside C:\Windows\, or using a directive file (/f). These binaries are rarely used legitimately by end users.
• certutil encoding of non-certificate data. Source: Sysmon Event ID 1. Field: CommandLine. Pattern: certutil -encode or certutil -decode operating on files with extensions like .exe, .ps1, .doc, or .zip rather than .cer or .crt.
• tar with create flag including sensitive directories on Linux. Source: Auditd EXECVE. Fields: a0 = tar, a1 contains -c or --create, and subsequent argument array elements reference paths like /etc/, /home/, /var/log/, or /root/.
• 7-Zip or WinRAR spawned by unusual parents. Source: Sysmon Event ID 1. Fields: Image ends with 7z.exe, 7za.exe, WinRAR.exe, or Rar.exe; ParentImage is cmd.exe, powershell.exe, wscript.exe, or any scripting engine rather than explorer.exe. Password flags (-p) in the command line are high-confidence indicators.
• Archive files written to staging directories. Source: Sysmon Event ID 11. Fields: TargetFilename ends with .zip, .7z, .rar, .cab, .tar.gz; TargetFilename path includes C:\Users\Public\, C:\Windows\Temp\, %APPDATA%\, or /tmp/, /dev/shm/ on Linux — these are common staging locations.
• Large archive upload over HTTP/HTTPS. Source: Zeek http.log or proxy logs. Fields: method = PUT or POST, uri ends with .zip, .7z, .rar, .cab; resp_mime_types contains compressed; request_body_len exceeds a threshold (e.g., > 10 MB to an external IP).
• xcopy or robocopy bulk-collecting files before archiving. Source: Sysmon Event ID 1 / 4688. Field: CommandLine contains xcopy or robocopy with /s or /e flags targeting user data directories, followed within minutes by an archiving utility on the same host.

Detection Logic

Rule 1 (Broad — High Sensitivity): Archive Utility Execution on Endpoint
IF process.name IN ["7z.exe","7za.exe","WinRAR.exe","Rar.exe","zip.exe","makecab.exe","diantz.exe","tar","gzip","zip"] AND process.command_line NOT NULL AND host.type = "workstation" OR host.type = "server" THEN alert LOW

This broad rule catches any execution of known archiving binaries. Expect high volume on servers running legitimate backup jobs; tune aggressively using the tuning guidance below. It is useful as a base for stacking and correlation rather than as a standalone alert.

Rule 2 (Medium — Suspicious Parent or Location): Archiver Spawned by Scripting Engine
IF process.name IN ["7z.exe","7za.exe","WinRAR.exe","Rar.exe","makecab.exe","diantz.exe"] AND process.parent.name IN ["cmd.exe","powershell.exe","wscript.exe","cscript.exe","mshta.exe","python.exe","bash","sh"] AND process.command_line NOT CONTAINS "C:\Program Files\BackupSolution\" THEN alert MEDIUM

Legitimate archiving tools are almost never spawned by scripting engines in normal user activity. This rule surfaces attacker-controlled scripts staging data and generates moderate volume that is manageable with basic exclusions.

Rule 3 (High Precision): certutil Used to Encode Non-Certificate Files
IF process.name = "certutil.exe" AND process.command_line CONTAINS "-encode" OR process.command_line CONTAINS "-decode" AND process.command_line NOT ENDSWITH ".cer" AND process.command_line NOT ENDSWITH ".crt" AND process.command_line NOT ENDSWITH ".p7b" THEN alert HIGH

certutil encoding of arbitrary files (executables, Office documents, zip files) is almost universally malicious or a red team activity. This rule is high precision with very low false positive rate and should alert with high confidence.

Rule 4 (High Precision): Archive with Password Flag Written to Temp/Staging Path
IF process.name IN ["7z.exe","7za.exe","WinRAR.exe","Rar.exe"] AND process.command_line CONTAINS "-p" AND (file.path CONTAINS "\Temp\" OR file.path CONTAINS "\Public\" OR file.path CONTAINS "/tmp/" OR file.path CONTAINS "/dev/shm/") THEN alert HIGH

Combining password-protection with a world-writable staging directory is a strong signal of pre-exfiltration staging. Alert volume will be very low and most hits warrant immediate investigation.

Tuning Guidance

• Backup software: Enterprise backup agents (Veeam, Commvault, Veritas, Windows Server Backup) regularly invoke archiving utilities. Identify the parent process and service account used, then exclude: process.parent.name IN ["VeeamAgent.exe","cvd.exe","beserver.exe"] or user.name IN [backup_service_accounts].
• Software deployment and patch management: SCCM, Intune, and Chocolatey frequently extract or create archives during software installation. Exclude: process.parent.name IN ["ccmexec.exe","TrustedInstaller.exe","msiexec.exe"] and limit to known software staging paths like C:\Windows\ccmcache\.
• Developer and build systems: CI/CD agents (Jenkins, GitHub Actions runner, Azure DevOps agent) call zip, tar, and 7z constantly during build and artifact packaging. Exclude by host group (tag build servers separately) or by user.name IN [ci_service_accounts] combined with known working directories.
• Log rotation and sysadmin scripts: On Linux, cron jobs routinely compress logs with gzip (via logrotate) and tar. Exclude: process.parent.name = "cron" AND process.command_line CONTAINS "/var/log/" to avoid flooding on log rotation events.
• macOS Time Machine and system archiving: macOS system processes create archives as part of backup and software update. Exclude processes with process.parent.name IN ["backupd","softwareupdated","installd"] running as root from known Apple binary paths.

When the Alert Fires: Investigation Steps

1. Verify the alert against the raw log. Pull the original Sysmon Event ID 1 or auditd EXECVE record from your SIEM and confirm the CommandLine, ProcessId, UtcTime, and User fields match what triggered the rule — rule logic bugs can fire on incomplete records, and you need ground truth before spending investigation time.
2. Identify the affected host and user account. Check whether the user account is a standard user, local admin, or domain admin using your identity provider (Active Directory, Okta, Azure AD). Privileged account involvement escalates severity immediately; cross-reference the host against your asset inventory to determine if it holds sensitive data (finance, HR, source code repositories).
3. Reconstruct the full process tree. Using Sysmon Event ID 1 correlated by ProcessId and ParentProcessId, or your EDR’s process tree view, trace the chain from the archiving utility back to the root parent process. Look for suspicious ancestors such as Office applications, browser processes, or remote management tools (mshta, wscript, psexec) that indicate initial access or lateral movement delivering the staging activity.
4. Identify what files were archived and where they were written. Use Sysmon Event ID 11 (File Create) filtered by the same ProcessGuid to find the output archive path and name. Cross-reference the input paths in the command line arguments against your data classification inventory — if the archive includes paths like \Finance\, \HR\, \source_code\, or credential stores like C:\Users\\AppData\Roaming\Microsoft\Credentials\, treat this as confirmed data collection.
5. Check for outbound network connections following the archive creation. Query firewall, proxy, or Zeek http.log / conn.log for connections from the affected host occurring within 30 minutes after the archive was created. Look for large transfers (high bytes_out), connections to cloud storage domains (Mega, Dropbox, Google Drive, OneDrive used anomalously), or POST/PUT requests with archive MIME types. Correlate the destination IP against threat intel feeds.
6. Search for lateral movement indicators originating from this host. Query Windows Security Event ID 4624 (logon type 3 — network) and 4648 (explicit credential use) for authentications from the affected host to other internal systems in the same time window. Check Sysmon Event ID 3 (Network Connect) for SMB (port 445) or WinRM (port 5985/5986) connections, and look for new processes on remote hosts with the same parent chain pattern.
7. Make the escalation decision. If the archive contains sensitive data paths, a suspicious parent process chain exists, and outbound network activity to an external destination followed within minutes — escalate to confirmed incident and move to containment immediately. If the archive was written to a known backup path, the parent is a legitimate backup agent, and the user is a sysadmin performing routine work, close as a false positive and add an exclusion; document the tuning change with a justification note.

Response Playbook

Containment

• Isolate the host — keep it powered on. Use your EDR console (CrowdStrike Network Containment, Defender for Endpoint Isolate, SentinelOne Network Quarantine) to cut the host off from the network while preserving its running state for memory forensics. Do not shut it down — volatile evidence (running processes, network connections, encryption keys in memory) will be lost.
• Disable the affected user account immediately. In Active Directory: Disable-ADAccount -Identity username. In Azure AD/Entra ID: set account enabled = false via the portal or Update-MgUser -UserId UPN -AccountEnabled $false. If the account is a service account, coordinate with the application owner before disabling to avoid outage.
• Revoke all active sessions and tokens for the affected user. In Azure AD, use Revoke Sign-in Sessions. For on-premise environments, reset the Kerberos TGT by resetting the account password twice and flushing cached tickets (klist purge on affected hosts). Invalidate any OAuth tokens or API keys associated with the account.
• Block identified destination IPs and domains at the perimeter. If outbound exfiltration destinations were identified in step 5 of the investigation, immediately push block rules to your firewall and DNS resolver. For cloud storage abuse, consider blocking the specific subdomain or bucket URL rather than the entire cloud service if it is business-critical.
• Kill any actively running archiving or exfiltration processes. If the process is still running on the isolated host, terminate it via EDR remote process kill to stop ongoing data staging. Preserve the process dump first if your EDR supports it (procdump -ma ) for forensic analysis.

Eradication

• Delete identified staging archives. Locate and remove the archive files created by the attacker (confirmed in investigation step 4). Search for similar archives across all hosts the attacker accessed using your EDR’s file search capability — filter on the same filename pattern, hash, or directory path.
• Remove any persistence mechanisms discovered during investigation. Audit the affected host for scheduled tasks (schtasks /query /fo LIST /v), new services (Get-Service | Where StartType -eq Automatic), registry run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run), and cron jobs or systemd units on Linux. Remove any entries not present in your baseline.
• Reset credentials for all accounts that touched the affected host. This includes the primary user, any accounts used for lateral movement (identified in step 6), and any service accounts whose credentials may have been visible on the system (check for credential files, environment variables, or scripts containing plaintext passwords).
• Rotate all secrets that may have been staged for exfiltration. Review the file paths included in the archive command line. If SSH keys, API keys, certificates, database connection strings, or cloud credentials were included, rotate all of them immediately and audit for any usage of those credentials after the compromise window.
• Hunt for additional backdoors on lateral movement targets. For every host the attacker authenticated to (from investigation step 6), run a targeted hunt for the same archiving patterns, new local accounts, modified startup items, or anomalous processes. Use your EDR to deploy a live response script that checks each host for these indicators.

Recovery

• Re-image the host if confidence in full eradication is low. If the attacker had prolonged dwell time, used a rootkit, or if you cannot fully account for every action taken, re-image from a known-good baseline rather than attempting manual cleanup. Restore from a pre-compromise backup or deploy a fresh image with your standard configuration baseline applied.
• Verify cleanliness before reconnecting to the network. Before removing network isolation, run a full EDR scan, validate no new scheduled tasks or services exist, confirm no unexpected outbound connections are attempted, and have a second analyst review the findings independently. Only then remove containment.
• Re-enable the user account only after confirming no persistence remains. Require the user to complete a password reset through a verified channel (in-person or verified video call with IT). Brief the user on the incident without revealing investigation details that could tip off an insider threat scenario.
• Implement 72-hour enhanced monitoring on the affected host and user. Create a temporary, high-sensitivity detection rule scoped to this host and user that alerts on any archiving utility execution, outbound data transfer over 1 MB, or new authentication events. Assign a specific analyst to review these alerts daily for the monitoring window.
• Document the full incident timeline and update detections. Write a post-incident review capturing the initial access vector, dwell time, data accessed, containment time, and any detection gaps. Update your SIEM exclusion lists and detection rules with any new command-line patterns or file paths observed. Share sanitized IOCs (file hashes, domains, IPs) with your threat intel platform and peer organizations where appropriate.