How T1560 archive collected data shows up in intrusions and why it matters for detection
T1560 Archive collected data describes an adversary compressing or encrypting data it has already gathered, usually into a small number of files, before that data leaves the environment. If your SOC sees a new archive appear in a temporary or staging location shortly after a burst of file reads from business shares, treat it as a possible collection step and investigate it as one. For the attacker, archiving consolidates scattered documents into fewer, smaller containers that are faster to copy, easier to hide inside normal traffic and simpler to protect with a password. The archive is often the last point where collection is still visible on the endpoint before exfiltration begins.
The technique has three sub-techniques. In broad terms, they describe whether the archiving is done with an operating system utility already present on the host, with a programming library loaded into a tool's own process, or with custom code written for the intrusion. The distinction matters because each leaves different evidence: a command-line archiver appears as a process, a library call may appear only inside another program, and custom code may have no familiar name at all. In the MITRE ATT&CK tactic for Collection (TA0009), T1560 is grouped with other techniques used to gather data, and ATT&CK Enterprise 20.0, released by MITRE on October 13, 2026, is the version these pages target. Technique IDs use the T#### form, and sub-techniques add a three-digit suffix. Confirm the tactic list in the STIX bundle for the version you use, since releases can rename or deprecate techniques.
For the SOC lead, the practical question is which hosts should ever create archives. Build a baseline of archiving tools and archive file types on servers, workstations and developer hosts, then decide which combinations are expected for each role. An archive written by a backup agent into a backup path is a different case from a compressed file written to a shared folder by a process that normally compresses nothing. Pair process telemetry with file creation telemetry so an archive event can be traced to its parent process and to the files read beforehand. Record which of these checks you have confirmed in your own environment, because the detection's accuracy depends on that baseline.
Which telemetry reveals T1560 archive collected data
This table maps each telemetry source to the archiving behavior it reveals, the open-source collector that gathers it, and the fields that must be normalized across Linux, macOS and Windows. Read it as a checklist: confirm each collector is deployed and each field is populated before relying on any single signal. Process Creation and Command Execution carry the strongest evidence, while File Creation and File Access provide context around staging directories.
| Telemetry (data component) | Signal to look for | Open-source collector | Fields to normalize |
|---|---|---|---|
| Process Creation (DC0032) | Archiver or compression utility launched by an unexpected account, parent process or host role | Sysmon for Windows, auditd on Linux, Wazuh agent event ingestion | Image path, command line, parent image, user, host, timestamp |
| Command Execution (DC0064) | Archive commands invoked through shells, scripts or remote management sessions | auditd execve records, Wazuh command monitoring, Velociraptor artifacts | Command line, working directory, session or logon ID, user |
| File Creation (DC0039) | New archive files appearing in staging directories, often with bulk file sizes or unusual extensions | Sysmon file create events, Wazuh file integrity monitoring, auditd file watches | Target path, file name, extension, size, creating process |
| File Access (DC0055), supporting context | Mass reads of source directories shortly before archive creation, indicating the collection step | auditd watch rules, Sysmon file access where configured, Velociraptor file hunts | Accessed path, count of files, accessing process, time window |
| Platform mapping for Linux and macOS | Same archive signal across execve and file events, with paths that differ by distribution and OS | auditd, Wazuh agents for Linux and macOS, Velociraptor | Normalize path separators, executable names and user identifiers to one schema |
| Platform mapping for Windows | Same archive signal across process and file events, with paths and user context from event logs | Sysmon, Windows event forwarding, Wazuh agents, Velociraptor | Normalize image paths, user SIDs to account names and event timestamps to UTC |
| Ingestion and time sync | Events from all three platforms correlate on the same host and time base | Wazuh manager, Security Onion or other SIEM, host time synchronization | Host name, agent ID, UTC timestamp, source platform label |
Detection ideas for archive creation on Linux, macOS and Windows
Archive creation is ordinary work for backup agents, build runners and developers, which is why T1560 is hard to alert on in isolation. The cards below describe detection logic in words for each platform, then the tuning and baselining steps that keep alerts useful. Each card names one signal or one control so teams can map them directly to their own telemetry.
Archiver launched against staging directories
Flag archive utilities (for example, compression or tar-style tools) when their process creation event references a directory that also received recently created files from a user session. Illustrative logic: a compression process started by an interactive shell against a folder that was populated in the last few minutes is more suspicious than the same process run by a scheduled job against its usual source tree. On Linux and macOS, use Process Creation and Command Execution data; on Windows, use Process Creation with command line logging enabled. Check the parent process and the working directory together, since the parent alone rarely separates attacker activity from routine work.
Archives written to unusual paths
Alert when File Creation events show a new archive file (by extension or container header written by the archiver) in a location outside the approved backup, build or export paths. Examples of locations to review include temporary directories, user profile roots, public or shared folders and hidden directories. Illustrative case: a new archive appearing in a world-readable temp path on a server that normally writes archives only to a backup volume. Confirm which paths your backup and build tools use, and keep that list in version control so reviewers can see changes.
Bursts of archive creation per account
Count archive file creations per user account and per parent process over a sliding window. A burst is a count well above the account's own baseline, not above a fixed global number. Start with a window of minutes and a threshold set from two to four weeks of history, then review false positives weekly. Pay attention to accounts that create archives in many directories in a short period, because collection often spans several locations. Use File Creation events from Wazuh, Security Onion or your SIEM, and record the chosen window and threshold in the rule's metadata.
Baselining backup and build jobs
Build an allowlist from the service accounts, parent processes, source paths and destination paths used by backup agents, CI runners and nightly jobs. Store each entry with an owner and a review date so exceptions do not become permanent blind spots. Confirm schedules with the platform owners, because a job that appears to run at 2 a.m. may also be the cover for a manual archive. Re-baseline after every change to the backup product, runner image or build pipeline.
Common false positive sources
Expect alerts from CI runners that package artifacts, backup agents that create snapshots, developer workstations that zip project folders before sharing, and log rotation jobs that compress old files. Tune these by matching on the account, the host group and the destination path together, not on the archive tool name alone. Route rare-but-legitimate events to a lower-priority queue with a suppression rule that expires, rather than deleting the detection. Document each suppression so an analyst can see why an alert did not fire.
Validating the rules in a cyber range
Test each rule against a range that contains representative Linux, macOS and Windows hosts, scripted backup jobs and a benign set of developer actions. Record which benign actions trigger alerts and which malicious-style archive actions are missed, then adjust thresholds. Map results to the ATT&CK version your rules target, since releases can change technique and detection content. Ask the range provider to confirm which telemetry sources are enabled on each host before the exercise starts.
How detection logic differs across Linux, macOS and Windows
On Linux, archiving usually runs as a process started from a shell, a scheduled job or an administration agent, so process creation telemetry is the primary signal. Coverage depends on whether the host collects process execution events through audit subsystem rules or an endpoint agent, and on whether command arguments are captured with the event. Without argument capture, the rule can see that an archiver ran but not what it touched.
- Process creation fields: Key on the executable name, parent process, user context and working directory. Parent-child relationships from an interactive shell or a web service account are often more useful than the binary name alone.
- Noise sources: Backup jobs, package managers, log rotation and configuration management tools routinely create archives. Build an allowlist keyed on service accounts and known job paths instead of suppressing the binary.
- File creation signals: Where file integrity or audit rules cover staging directories, new archive files appearing in unusual locations add context to the process event.
- Scheduling context: Correlate events with cron or systemd timer activity so that scheduled archiving is distinguishable from ad hoc activity.
- Coverage check: Confirm with your platform team which audit rules and agent settings are deployed on each host group.
Before you rely on any Sigma rule, check the logging configuration of each Linux environment, including container hosts.
On macOS, archiving is also a process event, but the endpoint security framework and unified logging expose different fields than Linux audit records. Many fleets rely on a commercial or open-source endpoint agent to forward process telemetry, so the fields present in your SIEM depend on that agent's configuration. Confirm which events are forwarded before writing detections that assume a particular field exists.
- Process creation fields: Key on the process image path, parent process, signing identity and the logged-in user. Code signing information helps separate vendor tools from unsigned or ad hoc binaries.
- Noise sources: Time Machine, software updaters, developer toolchains and sync clients produce archive-like activity. Scope exclusions by signed identity and managed device group.
- File creation signals: New archive files in user-writable locations such as temporary or downloads folders can strengthen a process-based rule, provided file events are enabled in the agent.
- Unified log context: Where the team collects unified logging, correlate archive events with authentication and session activity for the same user.
- Coverage check: Confirm which telemetry fields the agent exposes for each macOS version in use, since field availability can change across operating system releases.
Validate each Sigma field against sample events from your own managed Macs before deploying the rule.
On Windows, archiving commonly appears as a process creation event for a built-in or third-party compression utility, or as a script host running archive operations through a scripting engine. Process creation telemetry is only as complete as the audit policy and the command line logging settings on each endpoint, so confirm both before deploying a rule that depends on command arguments.
- Process creation fields: Key on the image name, original file name, parent process, integrity level and the account name. Parent process anomalies, such as an office application or a remote management service starting an archiver, are higher value than the binary name.
- Script host context: When archiving runs through a scripting engine, the script host process and its loaded modules may be the more reliable signal. Confirm that script block logging is enabled where your policy allows it.
- File creation signals: Archive files written to user profile or public directories, combined with the creating process, reduce false positives from installers.
- Noise sources: Backup agents, software deployment tools and administrative scripts create archives on a routine basis. Exclude them using signed publisher and service account, not by filename.
- Coverage check: Verify the audit policy settings and the Sysmon or equivalent configuration on each endpoint group, because a missing event category silently removes the detection.
Test each rule against a clean build image and against your production baseline before you rely on it.
How to validate the T1560 detection in a lab before trusting it
This sequence turns a T1560 detection hypothesis into evidence that it fires on the right telemetry, reaches the SOC queue, and produces a known false positive profile. Each step ends with a recorded output that the detection owner can review before the rule is promoted.
Agree the emulation scope in writing
The detection owner, the SOC lead and the range operator agree in writing which T1560 sub-techniques are in scope, which hosts and operating systems in the range will be used, and which Process Creation, File Creation and Command Execution sources must be present. The scope also names the ATT&CK version the mapping targets, which for these pages is Enterprise ATT&CK 20.0, and the approver who signs off on the plan. This step is done when the signed scope lists each sub-technique, its platform and its expected data components, and nobody has run anything yet.
Define expected telemetry for each sub-technique
For each in-scope sub-technique, the detection engineer writes down the events that a correct sensor should produce on each platform, such as process creation records, file creation records and command execution records, along with the fields the rule depends on, such as process name, parent process, file path and user. The list is reviewed against the detection strategy for the targeted ATT&CK version so that every expected field maps to a data component. Done when each sub-technique has a table of expected events and fields that a second engineer has reviewed.
Confirm log sources are healthy before the run
Before any emulation, the platform engineer checks that the endpoint agents, Wazuh or equivalent collectors, and any Sysmon or auditd configuration are forwarding the expected event types from each range host to the indexer. A simple heartbeat check plus a count of recent events per source type is recorded. Done when every host in scope shows the expected source types, and gaps are either fixed or written into the scope as known limitations.
Run an approved emulation without commands in this page
A tester, following a pre-approved emulation plan kept outside this page, executes the agreed actions inside the isolated range while the SOC observes in real time. The run is logged with start and end times, the host, and the user account used, so that every later event can be matched to a known action. Done when the run log lists each action with its timestamp and the range operator confirms that no activity left the range boundary.
Confirm alerts reach the SOC queue
After the run, the SOC lead checks whether the expected alerts were generated, whether they passed through the correlation and forwarding path, and whether they landed in the analyst queue with the right severity and mapping labels. Time from action to alert is recorded for each sub-technique so that delayed or dropped alerts are visible. Done when each planned action has either an alert in the queue with its timestamp or a documented reason it did not.
Record timestamps, fields and false positives
The detection engineer compares the run log, the raw events and the alerts side by side, recording the event timestamps, the fields that were present or missing, and any benign activity on the range that also matched the rule, such as routine backup or packaging jobs. Each false positive is tagged with the cause and the tuning option considered. Done when the results sheet shows, for every sub-technique, the detection result, the field completeness and the false positive list, and the detection owner has accepted or rejected each tuning change.
Re-validate when ATT&CK mappings change
The validated rule is stored with the ATT&CK version it targets, which is 20.0 for these pages, and the record names the data components and sub-techniques it covers. When a later release renames, deprecates or revokes a technique or sub-technique, or changes its detection strategy, the mapping is flagged for review and the sequence is repeated for the affected sub-techniques before the rule is trusted again. Done when the rule record is updated with the new version, the review decision and the date of the next scheduled validation.
Tuning archive detections so alerts stay actionable
Archive detections for T1560 only stay useful if the team decides, before the first alert fires, what counts as normal archiving on each host class. Build allow lists from observed baselines rather than from guesses: collect a period of archive creation events from Linux, macOS and Windows endpoints, group them by the process image, parent process, user account and target path, and then review each group with the system owner. Backup agents, log rotation jobs, build pipelines and approved reporting tools will usually dominate the list. Each allow list entry should carry an owner, a reason and an expiry date so that a stale exception does not quietly hide a new archiving tool. Confirm the exact fields your Process Creation and File Creation telemetry exposes in your own environment before writing the entries, because field availability varies by collector and log source.
A single archive event is weak evidence, so combine the archive creation signal with two kinds of context. The first is staging directory context: an archive written into a temporary, user profile or web-accessible directory, or an archive that contains files gathered from several unrelated locations shortly before it is created, deserves more weight than a routine archive in an application data folder. The second is unusual account activity: an archive created by a service account that normally never compresses files, by an interactive user outside working hours, or by an account that has just authenticated from an unfamiliar host should move the alert up the queue. Score these conditions together, and document the scoring logic so analysts can explain why an alert was escalated. Illustrative example: an archive created in a temporary directory by a non-admin account minutes after a file-share access burst would be triaged before a scheduled nightly backup. Set a review cadence and assign it to a named owner. Review new allow list entries at the time of approval, review the full exception list on a fixed schedule agreed with the security operations and system owner teams, and re-baseline after major changes such as a new backup product, a migration or an operating system upgrade. Track the ratio of archive alerts that end as true positives, and treat a rising count of closed-as-expected alerts as a signal to tighten the allow list or the context rules. Because ATT&CK content changes between releases, record the ATT&CK version your rules target and recheck the T1560 mapping when a new version is adopted. The MITRE ATT&CK updates pages list those changes, and MITRE ATT&CK updates is the natural starting point for that recheck.
Preventive controls that reduce T1560 risk
T1560 Archive Collected Data is hard to stop outright, because compression and archiving are routine activities on most hosts. The controls below reduce how much an adversary can gather, how quietly they can do it, and how fast defenders can see it. Audit coverage is the anchor, with encryption and data loss prevention supporting it.
Audit policy as the main control
ATT&CK maps Audit (M1047) to T1560 as its primary mitigation. In practice this means deciding which hosts, directories and utilities must produce process and file events, then confirming those logs reach your SIEM. Ask the team to show which Process Creation and File Creation events are actually retained for archiving utilities and staging directories. An audit policy that is written but not forwarded gives no detection value. Keep the list of monitored utilities under version control so changes are reviewed.
Process telemetry coverage
Archiving depends on command-line tools, so visibility into process creation and command lines matters more than file-level logging alone. Confirm that Linux auditing, Sysmon or equivalent on Windows, and macOS endpoint telemetry capture the process name, parent process and full command line. Check that a sample of expected archiving activity, run by an approved administrator, generates the events you expect. Gaps here usually come from disabled command-line logging or from hosts that never enrolled in the collector.
Encryption of sensitive data at rest
ATT&CK maps Encrypt Sensitive Information (M1041) to Collection techniques, and it reduces the value of an archive an adversary manages to create. Confirm which data stores hold regulated or sensitive records, and whether volume or application-level encryption protects them at rest. Encryption does not stop an archive from being created on an unlocked, logged-in host, so pair it with audit and access controls. Ask for the key management arrangement and who can decrypt.
Data loss prevention on egress paths
Data Loss Prevention (M1057) applies where an archive would leave the environment, such as through email, web uploads or removable media. Confirm which channels the DLP tooling inspects, and whether it can recognize archive formats and password-protected containers, not only plain text. Test the policy with a labeled, non-sensitive sample in a cyber range before relying on it. Treat DLP alerts as a signal to correlate with archiving events, since many archives will never be exfiltrated.
Least privilege for data stores
Limit which accounts can read sensitive shares, databases and repositories, and which accounts run archiving tools on those systems. User Account Management (M1018) supports this by governing account creation, role assignment and review. Ask for a current list of accounts with read access to high-value data, and confirm that service accounts used for backups are not also used interactively. Access reviews on a regular schedule keep this list from drifting.
Staging directories and user training
Define which directories are sanctioned for temporary archives and which are not, then monitor the rest. User Training (M1017) helps staff recognize when an unexpected archive appears in their work folders or when a request to compress data does not match their role. Confirm that the approved workflow for bulk data movement is documented, so that unusual archiving stands out. Training content should be reviewed when the approved workflow changes.
What to do in the first hours after an archive detection fires
This sequence turns a single archive alert into a scoped, preserved and contained incident with a clear handoff to exfiltration review. It keeps the analyst from acting on the alert alone and gives the incident lead evidence to decide on containment.
Confirm the host, account and alert context
The analyst confirms that the alert is not a known backup, packaging or software update job by checking the host owner, the account that ran the process, its parent process and the change window. They record the host name, user, process tree, command path and timestamp in the case. The step is done when the analyst can state in one sentence whether the activity is expected for that account and host, and the answer is written in the ticket with the source logs cited.
Review what the archive actually contains
Where the platform allows it, the analyst checks the archive's file names, sizes, creation times and location against the host's normal data. They compare the staging folder with known sensitive locations such as file shares, databases exports, mailboxes or source repositories. Because content inspection can expose sensitive data, the analyst works from metadata and listings inside an approved, access-controlled workspace. The step closes with a classification: routine, unknown or likely sensitive.
Preserve volatile and archive evidence
Before anything is deleted or rebooted, the responder captures volatile data such as running processes, active network connections and logged-in sessions, then hashes and copies the archive to evidence storage with chain-of-custody notes. The responder records who collected each item and when. The step is complete when the copies verify against their hashes and the collection log is attached to the case, so later analysis does not depend on the live host.
Scope related hosts and accounts
The analyst searches for the same archive name, hash, command pattern and account across endpoints and servers over the window that the telemetry covers, and checks for other archives created in the same directory. They also review what the account accessed before the alert. The output is a list of affected hosts, accounts and files, with any hosts that show the same pattern marked as candidates for containment. Scope is not closed until the search has been run against every source that can see those hosts.
Decide on containment with the incident lead
The incident lead weighs the classification, the scope and the business impact to choose between monitoring, restricting the account, isolating the host or blocking the staging path. The decision and its reason are recorded with the people who approved it. Containment should follow the organization's own runbook and approval rules, and the lead should confirm that isolation will not destroy evidence still needed. The step closes when a containment action is logged, or when the decision to monitor is recorded with a review point.
Hand off to exfiltration checks
The analyst passes the case, the archive metadata, the affected accounts and the time window to whoever reviews outbound traffic and cloud or SaaS uploads. The handoff asks specifically whether any archive file left the environment, through network connections, uploads, email or removable media. The step is done when the exfiltration reviewer acknowledges the handoff in the case and lists the sources they will check, so the investigation does not stall between teams.
Rehearsing T1560 detection in a private cyber range
A useful range for T1560 needs endpoints on each platform the detection covers, plus a collector that receives their telemetry. Build one Linux host, one macOS host and one Windows host, each joined to a segregated lab network with a file server or staging share that holds realistic document sets. Route agent telemetry to a Wazuh manager or a Security Onion deployment, and confirm which of them receives process creation, file creation and command execution events on each platform before any inject runs. DeployOpen builds and documents private ranges like this inside the client's own environment, and the topology should be written down before the range is handed to the SOC.
- Endpoint coverage: Each platform needs its audit or endpoint sensor configured so process and file events are captured, with the collection gaps recorded.
- Collector choice: Confirm whether Wazuh, Security Onion or both will ingest the events, and which rules or detections map to them.
- Data realism: Seed the lab with business-like file trees so that archive jobs have plausible sources and volumes.
- Isolation: Keep the range off production networks and define egress controls so that exercise activity cannot leave the lab.
- Time synchronization: Align clocks across endpoints and the collector so that timelines reconstructed during the exercise are accurate.
Before the exercise starts, check that a known benign archive event on each host appears in the collector within the window your SOC expects.
Injects should exercise each sub-technique of T1560 in plain terms, so that the detection team can see which telemetry records the activity and which records it misses. Describe each inject as a scenario and have the red or purple team execute it under a written scope and rules of engagement. Record the exact time, host, account and expected artifact for every inject so the SOC can later compare what it saw with what was run. The goal is coverage of the three sub-techniques across the three platforms, not the number of injects.
- Utility-based archiving: An inject where a standard compression utility bundles a folder of documents into a single file on each platform.
- Library-based archiving: An inject where a scripting or programming library creates an archive, which tests whether detection depends on specific binary names.
- Archive with password protection: An inject that protects an archive with a passphrase, which should be checked against encryption-related events and the file names the process writes.
- Benign look-alikes: Scheduled backup jobs and developer build steps that create archives, so analysts practice separating normal activity from suspicious activity.
- Staging followed by movement: An archive created in a temporary directory and then copied, to see whether file creation and file access events link the two steps.
Keep a control log so every inject can be matched to the telemetry it should have produced.
For the SOC, good detection means the expected events reach the collector, a rule or analytic fires for each inject that should trigger one, and the alert carries enough context to triage it. Score each inject against the detection strategy and analytics that map to the ATT&CK version your team targets, and note which data components supported each decision. Track false positives from benign look-alikes as carefully as misses, because noisy archive alerts are often disabled after an incident. Detection rules for this technique should be written as Sigma rules where possible, so they can be ported across Wazuh and Security Onion.
- Telemetry arrival: Confirm process creation, file creation and command execution events appear for every inject on every platform.
- Alert fidelity: Check that each alert names the host, user, parent process, archive file name and destination path.
- Mapping accuracy: Record which ATT&CK version and detection strategy each rule targets, since releases can rename or deprecate techniques.
- Noise measurement: Count how many benign look-alike events fired and whether tuning removed them without hiding the injects.
- Triage time: Measure how long analysts take to confirm or dismiss each alert using the documented runbook.
After the run, check that every inject has either a matched alert or a documented gap with an owner.
The incident commander needs to know whether the response process works when an archive alert arrives during a busy shift. In the exercise, the commander should decide escalation, containment and communication using the written playbook, while the SOC supplies evidence. A common failure is treating archive activity as low priority until it is linked to a staging path or an outbound transfer, so the exercise should include a scenario where the commander must decide whether to hold a host or wait for more evidence. Record decisions and their timestamps for the after-action review.
- Escalation path: Confirm who is paged for a high-confidence archive alert on each platform and how that changes when data sensitivity is high.
- Containment options: Test isolating a host or suspending an account, and confirm that the owners of those systems in the range can act within the exercise window.
- Evidence preservation: Verify that the archive file, its hash and the process details are collected before cleanup begins.
- Communication: Rehearse the internal update, including what is said about data that may have left the environment.
- Decision log: Require timestamped decisions so the after-action review can separate detection delay from decision delay.
Check that the commander's decisions match the playbook, and update the playbook where they did not.
The exercise should also test the ATT&CK mitigation Audit, which relies on logging and reviewing the activity that archiving produces. Confirm that audit policies or endpoint sensors are enabled as documented, and that someone reviews the resulting records on a defined schedule. Data Loss Prevention and Encrypt Sensitive Information are mitigations for the outcome of archiving rather than for the archive step itself, so the range should show whether protected data is actually encrypted at rest and whether egress controls would catch a staged archive. Keep the evidence from each run, because compliance teams may later ask how the controls were verified. DeployOpen prepares controls and evidence for compliance assessments, but auditors and certification bodies decide whether a control is adequate.
- Audit configuration: Export the logging settings used during the range and compare them with the production baseline.
- Review cadence: Confirm that alerts and log reviews are assigned to a named role with a schedule.
- Egress checks: Test whether a staged archive can reach an external destination and whether that attempt is logged.
- Encryption status: Verify that sensitive shares used in the range are encrypted as documented.
- Evidence pack: Store the topology, inject log, alert records and decision log together so a later review can follow the run.
Before closing the exercise, confirm the evidence pack is complete and that any gap has a recorded owner and a retest date.
Questions detection engineers ask about T1560 archive collected data
How do I stop backup jobs from flooding my T1560 archive alerts?
Start by allowlisting by identity, parent process and path, not by process name alone, because backup agents and archive utilities share binaries with attacker tooling. Backup jobs usually run under a dedicated service account, from a known parent such as a scheduler or backup agent service, and write to a known staging directory. Build those three attributes into the exclusion, then review them against the backup vendor's documented process names and your own job schedule. Keep a change record for each exclusion so that a new backup product or a moved job path does not silently widen the gap. Test the exclusions in your cyber range with a replayed backup job before they reach production.
Which ATT&CK version should my T1560 detection rules map to?
Map your rules to the ATT&CK version you have tested against, and record that version in every rule's metadata. DeployOpen's reference set for these pages is Enterprise ATT&CK version 20.0, which MITRE released on 2026-10-13 according to the attack-stix-data repository index. Confirm the version against the STIX bundle you download, because a release can rename, deprecate or revoke techniques. The attack-stix-data repository publishes one STIX 2.1 bundle per domain and version, which lets you check the T1560 technique and its three sub-techniques directly. Where a detection strategy is keyed to data components, record the data component IDs you rely on so the mapping can be reviewed when those components change.
Where are the coverage gaps for T1560 on macOS?
The main gap is visibility into archive activity that does not start with a process you already log. On macOS, archive creation can run through built-in utilities, scripting runtimes or applications with their own compression libraries, so a rule keyed only to a short list of archive binaries will miss some activity. Check whether your endpoint agent captures full command lines and parent process relationships on macOS, and whether file creation events cover the staging directories users and applications write to. Confirm these capabilities with your agent vendor rather than assuming them, since coverage differs across agent versions and macOS releases. Document the residual gap, then close it with a file creation rule on known staging locations and a review of script runtime execution.
How can I test T1560 detections without disrupting production?
Test in a private cyber range that mirrors your telemetry pipeline, not in production. Build a range with representative Linux, macOS and Windows endpoints, forward their Process Creation, File Creation and Command Execution events into your Wazuh or Security Onion stack, and run approved archive activity under a documented test plan. Use synthetic data sets of non-sensitive files so that no real business records are moved. Record the expected alert, the actual alert and the time to detect for each test case, then rerun the set after every rule change. Production validation should be limited to confirming that the log sources still arrive, using read-only checks agreed in advance with the operations team.
How do I keep Sigma rules for T1560 current when ATT&CK changes?
Treat the ATT&CK version as a versioned dependency of your rule set, and review it on every ATT&CK release. Each rule should carry its technique and sub-technique IDs, the ATT&CK version it was validated against and the data components it depends on. When a new release arrives, diff the STIX bundle for the T1560 family, check for renamed, deprecated or revoked IDs, and update the mapping in your rule repository through a normal change review. Re-run your cyber range test set against the changed rules before release. Recent releases include v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, so plan the review cadence around those dates and the updates pages on the ATT&CK site.
What should I check before trusting an archive detection in production?
Check that the telemetry the rule needs is present, complete and timely on every platform in scope. A rule built on Process Creation events fails silently if the agent drops command lines, if the log forwarder falls behind, or if a host group was never enrolled. Confirm event volumes against a baseline, verify field names after each agent upgrade, and test one known archive action per platform end to end, from endpoint to alert. Also confirm that the Audit mitigation, M1047, is in place for the systems that generate these events, so that the logging is configured and retained as intended. Record the results as evidence for your compliance team.
How DeployOpen builds T1560 detections and range scenarios
DeployOpen treats T1560 Archive collected data as a detection engineering and validation project inside your own environment, not a generic monitoring rollout. Each engagement starts from a written scope that names the platforms, telemetry and ATT&CK version in use, then delivers detections, test evidence and runbooks you keep.
How we scope
- Confirm which platforms (Linux, macOS, Windows) and log sources hold archive-tool and staging activity in your estate
- Record the ATT&CK version the detections target, since releases can rename or deprecate technique content
- Agree in writing which T1560 sub-techniques and telemetry types are in and out of scope before work starts
How we build
- Map Process Creation, File Creation and Command Execution coverage to Sigma-style rules and Wazuh or Security Onion pipelines
- Tune each rule against your baseline of legitimate backup and compression jobs to limit false positives
- Document how the Audit mitigation is implemented through logging configuration, with the owner of each setting named
How we hand over
- Deliver rule logic in plain language, with source-to-alert mapping and known blind spots written down
- Provide cyber range test results showing which simulated archive scenarios fired, and which did not
- Hand over runbooks for triage, containment and evidence preservation, tested with your responders
How we support
- Fixed-scope engagements end with a documented handover and a clear list of follow-up items
- Ongoing support, upgrades and continuous testing for these detections are available as a retainer
- Re-test rules after ATT&CK version changes or changes to your logging stack
