Detecting T1074 Data staged

How T1074 data staged shows up before data leaves your environment

Data staged (ATT&CK technique T1074) is the step where an adversary gathers data of interest into one place so it can be moved out later. MITRE places it under the Collection tactic (TA0009), which ATT&CK defines as the adversary trying to gather data of interest to their goal. For a SOC lead, staging matters because it is often the last quiet step before exfiltration. Copies, archives or temporary working folders appear on systems that do not normally hold that data, and the activity can look like routine file handling. This page targets Enterprise ATT&CK 20.0. Detection mappings should be checked against the ATT&CK version your team actually uses, because releases can rename, deprecate or revoke techniques.

T1074 has two sub-techniques. One covers staging on the system where the data was collected. The other covers staging on a remote system that the adversary can reach. In practice, staging appears on ESXi hosts, where VM files or datastore contents may be gathered into a working location, and on IaaS workloads, where storage volumes or snapshots may be copied to a staging bucket or instance. It also appears on Linux and macOS hosts, where temporary and user directories are common landing points, and on other platforms in your estate. In an intrusion, staging usually sits after discovery and collection and before archiving and transfer out of the environment. Archiving is covered separately under T1560, so the signal you care about here is the gathering itself.

Start by listing which platforms hold your most sensitive data and where staging would be unusual on each. Then confirm, in your own environment, whether you collect process creation, file creation and file access telemetry on those hosts, and whether your cloud provider's audit logs record storage reads and copies for IaaS accounts. Those gaps decide which detections are realistic to build. Check the data component and detection strategy identifiers against the ATT&CK version you target, using the ATT&CK updates page to see what changed between releases. Decide in advance who triages a staging alert on an ESXi host or cloud account, since those responders are often different from the endpoint team.

Telemetry sources that reveal data staging

This table maps each ATT&CK data component referenced for Collection techniques to the staging signal it reveals, the platforms where it applies, and the open-source collector that typically gathers it. Use it as a starting point for coverage planning, then confirm exact coverage against the ATT&CK v20 detection strategies for T1074 and its sub-techniques. The main takeaway is that staging is usually visible as a sequence of file creation, archiving and access events, so no single data component should be relied on alone.

Data component	Staging signal to look for	Platform notes and collector
Process Creation (DC0032)	Archiving or copy utilities launched against directories holding sensitive data, especially from unusual parent processes or service accounts	Linux and macOS: process auditing via Auditd-based pipelines or endpoint agents. ESXi and IaaS: confirm coverage with the vendor or hypervisor logging available in your environment. Wazuh and Velociraptor can collect these events in general terms.
File Creation (DC0039)	New bulk archives, temporary staging folders or hidden directories appearing in locations outside normal application paths	Linux and macOS: file system watches on staging-prone paths. Wazuh file integrity monitoring and Velociraptor artifact collection can surface new files. IaaS: confirm object or disk creation logging with the cloud provider.
File Access (DC0055)	Repeated reads across many files or a single user touching a large set of data stores in a short window	Linux and macOS: audit rules on sensitive directories. Requires careful tuning to limit noise from backups and indexing jobs. Confirm whether ESXi datastore access is recorded in your logging configuration.
Command Execution (DC0064)	Shell or scripted commands that compress, copy or relocate data, captured from interpreter or shell history	Linux and macOS: shell and interpreter command logging through Auditd-based pipelines or endpoint telemetry. Useful where process records lack arguments. Confirm argument capture for your shells.
Network Traffic Content (DC0085)	Large outbound transfers of staged archives that follow a file creation or archiving event on the same host	Zeek or Suricata sensors at egress points can record transfer patterns. Content visibility depends on encryption and sensor placement, so confirm coverage in your design.
Network Connection Creation (DC0082)	Unexpected connections from a host to internal file stores or to external destinations shortly after staging activity	Zeek connection logs at network boundaries, correlated with host events. Cloud and ESXi management traffic should be confirmed with your platform logging options.

Detection ideas for staging activity in words

T1074 Data Staged sits between collection and exfiltration, so the most useful signals are changes in how files are created, read and moved before any data leaves the environment. The four approaches below share one principle: score behavior against a baseline for each host, datastore or volume, then tune thresholds and allow-lists with the owners of backup, build and migration workloads.

Bulk staging directory creation

Watch for new directories created or written in bulk on endpoints and servers, especially in locations that are not normally used for application or user data, such as temporary paths, public folders or the root of a shared volume. The logic is a count of new directories with many files written into them within a short window, compared with the host's normal pattern. Tune the window and count per host role. Expect false positives from backup agents, build pipelines that generate artifacts, and log rotation that writes into new dated folders.

Archive-like file creation spikes

Measure how many archive-type or compressed container files are created on a host within a short window, and alert when the volume departs from its baseline. Attackers often bundle collected data into a few large containers, so a sudden rise in new container files is a useful signal even when each file looks ordinary. Set the threshold by role, since file servers and build agents create many such files legitimately. Common false positive sources include scheduled backup jobs, software packaging, and data migrations that run for a planned window.

Sensitive reads followed by unfamiliar writes

Correlate a burst of reads across many sensitive files, identified by path or data classification, with writes of new files to a location the same process or account has not used before. This pattern links the collection phase to the staging phase on a single host. The key tuning decision is the list of sensitive paths and the baseline of destination paths per account. Benign sources include analytics jobs, eDiscovery exports, and reporting tools that read widely and write to shared output folders.

Staging on ESXi datastores and IaaS volumes

On virtualization hosts and cloud workloads, look for new files or large copies appearing in datastores, snapshot stores or block volumes that are not part of the expected backup or image workflow. Confirm which accounts and management paths are allowed to write there, and record the normal growth rate per datastore. Expect false positives from vMotion, snapshot consolidation, scheduled backup appliances, and infrastructure-as-code runs that create volumes. Confirm the exact telemetry your hypervisor and cloud provider expose before writing rules, since coverage differs by platform.

How to validate that the staging detection fires

This sequence proves, in a private cyber range, that a T1074 Data Staged detection produces the telemetry it depends on, raises an alert inside an agreed window, and leaves a record that engineers can tune and auditors can review.

Define the staging scenario and target version
The detection owner writes down the staging behavior to be emulated, such as collecting files into a single working directory or archive-like staging area on a test host, and the platforms in scope (for example Linux, macOS, ESXi or an IaaS guest). The owner also names the ATT&CK version the detection maps to, which for these pages is Enterprise ATT&CK 20.0, and the sub-techniques covered. This step is done when the scenario, platforms and version are written in the test plan, and the team can point to the matching detection strategy and data component IDs in the ATT&CK record for that version.
Agree scope and rules of engagement
The security lead, the range operator and the owners of each test host agree in writing which hosts, accounts and data sets may be touched, what the emulation may and may not do, who can stop it, and how the team will be told if a live system is affected. Monitoring owners confirm that the range is isolated from production networks and that the test data is synthetic. This step is complete when the signed scope and rules of engagement are filed with the test plan and every participant has acknowledged them.
Confirm baseline telemetry before emulation
Before any staging activity runs, the platform engineer checks that the agents or log sources on each test host are reporting the data components the detection relies on, typically Process Creation, File Creation and File Access, and that clocks are synchronized across the range. The engineer records which events arrive and which are missing or delayed. This step is done when a quiet baseline shows the expected event types from every test host, and any gap is either fixed or written into the test record as a known limitation.
Run a controlled staging emulation on test hosts
The red or purple team runs an agreed, scripted staging emulation on the test hosts, with the start and end times logged by the range operator. The run follows the scenario defined earlier, and the operator notes any deviation from the plan. Commands and tooling are kept in the test record for reproducibility, but are not reused outside the range. This step is complete when the run ends on schedule, the operator has the start and stop timestamps, and the team confirms the emulation matched the written scenario.
Confirm expected telemetry arrives
The detection engineer searches the log platform for the events generated by the emulation and compares them with the baseline and the scenario. The check covers whether each expected data component appears, whether fields needed by the rule are populated, and whether events carry the correct host and platform identifiers. This step is done when every expected event type is confirmed for each test host, or each gap is recorded with its cause.
Check the alert fires within the agreed window
The detection engineer confirms that the rule or analytic produced an alert within the response window the team agreed in the test plan, and that the alert carries the ATT&CK technique and sub-technique mapping. Any alert that fires late, fires on the wrong host, or does not fire is marked as a finding. This step is complete when each emulated staging action has either an alert with its identifier and timestamp or a documented miss, and the window used is stated in the record.
Record results and tune the detection
The team writes a results record for the run that lists the timestamps, host and platform, data components observed, alert identifiers, and any tuning changes such as adjusted thresholds, added exclusions or corrected field mappings. Each change is reviewed, tested again on the range, and linked to the ATT&CK version used. This step is done when the record is stored with the detection's version history and a retest shows the agreed result, so the evidence can support an internal review or a compliance assessment without overstating what it proves.

Preventive controls that reduce staging risk

Data staging is hard to stop with detection alone, so preventive controls shape where sensitive data can sit before an adversary gathers it. The five mitigations below map to Collection techniques in the Enterprise ATT&CK 20.0 data set, and each one narrows a different part of the staging problem. Confirm the exact mapping for T1074 Data staged in the ATT&CK version your team uses before you treat any mapping as settled.

Data loss prevention rules

Data loss prevention (M1057) constrains which data may be moved into temporary or shared locations and which tools can move it. For T1074, the useful question is whether your DLP policies cover staging directories, archive outputs and synced folders, not only outbound email and web uploads. Check which endpoints, servers and cloud workloads actually enforce these policies, and whether alerts from them reach the same queue as your detection rules.

Audit logging for staging activity

Audit (M1047) means enabling and retaining the logs that make staging visible, such as process creation, file creation and file access on servers and workstations. Without these records, the detection strategies for T1074 have nothing to match against. Confirm that audit policies are set on the hosts that hold sensitive data, that logs are forwarded off-host, and that retention covers the period your investigations need.

Encryption of sensitive data at rest

Encrypt Sensitive Information (M1041) makes staged copies less useful if they are exposed, and it forces adversaries to use keys or decrypted access paths that can be monitored. Encryption does not stop an insider or a compromised account from copying data into a staging folder. Verify which data stores are encrypted, who holds the keys, and whether key access is logged.

Restricting who can write to staging locations

User Account Management (M1018) governs which accounts can create files in shared directories, service accounts and administrative shares where data is commonly gathered. Review write permissions on shared paths and on the directories used by backup, sync and archive jobs. Remove standing rights that no current process needs, and document the owner of each account that is allowed to write there.

Staff training on handling sensitive data

User Training (M1017) addresses the everyday habits that create staging, such as copying files to a desktop folder to work offline or moving reports into a personal sync directory. Training works best when it names the approved locations for sensitive data and explains why ad hoc copies are reviewed. Check that the training covers the specific staging behaviors your monitoring is built to catch, and that completion is tracked.

Triage and response when a staging alert fires

When a T1074 Data staged alert fires, the first decision is whether the activity matches an approved job. Check the change calendar, the backup or ETL schedule, and the owning team's runbooks for a documented task that would gather files into a single location on the same host, at the same time, under the same service account. If a matching job exists and its scope is unchanged, record the match and close the alert with a link to the job. If nothing matches, treat the alert as an open incident until the owner confirms otherwise. Do not rely on the alert severity alone, because a staging pattern that looks routine on one platform can be unusual on another.

Next, establish the facts that drive every later decision: the host, the platform (ESXi, IaaS instance, Linux, macOS or another platform in your estate), the account that ran the activity, and the source and destination paths. For the data, confirm what was staged, how many files and how much data were involved, and whether the contents are sensitive under your classification scheme, such as personal, payment, health or source code data. Ask the data owner to confirm which repositories the affected path normally holds. Where the answer is unclear, assume the data is sensitive until it is confirmed otherwise.

Then look for related signals that show whether staging was a step toward removal. Review outbound network connections from the host for the same window, unusual access to sources the account does not normally read, archive creation close to the staging event, and authentication from unfamiliar locations for the same account. If any of these are present, escalate the incident and widen the investigation. Contain the account or host only when the evidence supports it: disabling an account or isolating a host can disrupt a production service, so agree the containment step with the service owner and document the reason. Preserve the staged files, relevant logs and volatile data before any cleanup, and escalate to the incident response lead and, where regulated data may be involved, to privacy and legal contacts.

Rehearsing T1074 detection in a private cyber range

The range should be an isolated network that carries no route to production systems, corporate directories or the internet. Place test hosts that mirror the platforms in scope for T1074: ESXi hosts for virtualization staging, Linux and macOS endpoints for file-based staging, and IaaS-style test instances that reflect how the client actually deploys workloads. Run a SIEM such as Wazuh, or a similar platform the client already operates, so the rehearsal tests the team's real tooling rather than a demo console. Sensor placement determines what is visible. Agents or collectors on endpoints supply Process Creation, File Creation and File Access events, while hypervisor and cloud control plane logs supply the platform-side view. Document each log source, its retention and its parsing path before the first exercise.

Telemetry inventory: List every source feeding the SIEM, the data component it maps to and whether it was confirmed to arrive during a test event.
Sensor coverage map: Record which hosts run endpoint agents and which rely only on network or platform logs, so gaps are known in advance.
Time synchronization: Confirm all hosts and collectors share one time source, because alert timing is scored later.
Isolation checks: Verify the range cannot reach production networks before any staging event is run.
Build record: Keep the configuration and versions of every component so the exercise can be repeated against the same baseline.

Before running any scenario, confirm with the client's platform team that every component in the build matches the version and configuration they will defend in production.

Common questions from SOC leads about T1074 detection

How do you separate data staging from backups and build activity?

Separate them by context, not by the file operation alone. Staging is a collection step in which data is gathered into one location, often compressed or renamed, shortly before it leaves the environment. Backups and builds perform similar file operations on a schedule and from known service accounts. Build a baseline per host and per account for each of these jobs, then alert on deviations such as an unknown process writing large volumes into a temporary or user profile directory, or a backup account touching paths outside its job definition. Keep an allowlist of backup agents and CI runners with their expected paths, and review it whenever those tools change. Expect some false positives in the first weeks, and treat each one as a reason to refine the baseline rather than to disable the rule.

Which telemetry gaps are most common on ESXi and IaaS platforms?

The most common gaps are missing host-level process and file logging on hypervisors and missing control-plane audit records in cloud accounts. On ESXi, confirm that shell and SSH access are logged and forwarded off the host, since local logs can be rotated or lost. On IaaS, confirm that storage and compute API calls are recorded in the provider's audit trail, that the trail is forwarded to a store the workload team cannot edit, and that snapshot and disk-attach events are included. Many teams also lack file-level visibility inside guest operating systems. Confirm each gap against your platform's documentation and your own test results, because log formats and retention options vary by product and version.

How do you tune thresholds without blinding the SOC?

Tune by narrowing scope, not by raising thresholds until alerts stop. Start with a short observation period in which rules only log matches. Group results by host, account and directory, then exclude known-good jobs with documented owners and expiry dates. Where a threshold is still noisy, add a second condition such as an unusual parent process or an off-hours window, so that the rule fires on the combination. Record every tuning change with a reason and a reviewer. This keeps an audit trail and makes it possible to show later that a suppression was deliberate. Review suppressions on a fixed schedule so that stale exclusions do not quietly remove coverage.

How should we handle ATT&CK version changes for T1074?

Name the ATT&CK version in every detection record and check it against each new release. MITRE publishes ATT&CK updates on its updates pages, and releases can rename, deprecate or revoke techniques and sub-techniques, and can change how data components are referenced. For T1074, review the technique and its sub-techniques against the release notes for each version you adopt, then update your mapping to the current data component and detection strategy identifiers. Keep the previous mapping under version control so that historical alerts can still be explained. Confirm the exact changes with the release notes for your target version before you update rules, since the details differ from release to release.

How do you test T1074 detections safely?

Test in an isolated environment that mirrors production logging, never against live data. A private cyber range lets the team generate benign staging-like activity, such as copying a set of non-sensitive test files into a single directory and compressing them, then confirm that the expected telemetry arrives and that the rule fires. Use synthetic data with clear markers so that analysts can recognize test events. Record each test with its date, the ATT&CK version targeted, the rule version and the outcome. Run the same tests after logging pipeline changes, because a broken forwarder can make a working rule look silent. Keep test accounts and hosts separate from production identities.

How do you measure whether a T1074 detection is working?

Measure coverage, timeliness and analyst outcomes together. Coverage asks whether the rule fires for each scripted test in the range and whether telemetry arrives from every in-scope host and platform. Timeliness measures the gap between the test activity and the alert reaching an analyst. Analyst outcomes track how many alerts were confirmed, dismissed as benign with a documented baseline, or escalated. A rising dismissal rate usually signals a tuning problem, while a falling alert count with no test failures may signal lost telemetry. Set targets with the SOC lead and review them after each ATT&CK version update. Confirm your own targets, since no fixed benchmark is supplied here.

Official ATT&CK sources for T1074 and the Collection tactic

Start from MITRE's own material before writing any detection for T1074 Data staged. The Collection tactic (TA0009) is defined by MITRE as the point where the adversary is trying to gather data of interest to their goal, and the T1074 technique and its sub-techniques sit under that definition. Your detection engineers should bookmark the MITRE ATT&CK tactic page for Collection and treat it as the reference for what the tactic covers, so that scope decisions for staging activity are recorded against MITRE's wording rather than against a vendor's summary.

Version control is the part most teams skip, and it matters for T1074 because the detection strategies and data component mappings changed in ATT&CK v18, released October 28, 2025. Recent releases were v19 on April 28, 2026 and v20 on October 13, 2026. Releases can rename, deprecate or revoke techniques, so every detection rule, coverage map and cyber range scenario should name the ATT&CK version it targets. Check the MITRE ATT&CK updates page before each review cycle, and confirm with your own content owner which version your SIEM content pack is built on.

For machine-readable work, MITRE publishes ATT&CK as STIX 2.1 bundles, one per domain and version, in the mitre-attack/attack-stix-data repository. Pull the Enterprise bundle for the version you have chosen and check the T1074 technique and both of its sub-techniques in that bundle, not only on the web page, so that detection IDs, data component references and mitigation links are taken from the same snapshot. Ask whether your coverage tooling can pin a specific bundle version, because a silent upgrade can change the mapping under a rule that was tested months earlier.

How DeployOpen builds T1074 detections and range exercises

DeployOpen works on T1074 Data staged as a fixed-scope engagement inside the client's own infrastructure, with detection content, validation and response documented against the ATT&CK version agreed in writing. The output is a set of detections and exercise records the client's own team can run and maintain.

How we scope

Confirm which platforms are in scope for T1074, such as ESXi, IaaS, Linux and macOS hosts.
Agree which data components, including Process Creation, File Creation and File Access, the client can actually collect.
Record the target ATT&CK version in the written scope so mappings stay stable across releases.

How we build

Write detection logic for T1074 and its two sub-techniques as plain-language analytics tied to named data components.
Build and tune rules on open-source tooling already deployed in the client environment, such as Wazuh or Sigma-based content.
Map detections to the mitigations the client already uses, including Audit and Encrypt Sensitive Information where relevant.

How we hand over

Deliver detection content, test records and tuning notes that name the ATT&CK version each mapping targets.
Document the cyber range exercises used to validate T1074 detections, including expected telemetry and alert outcomes.
Run a handover session so the client's security engineers can maintain, review and extend the detections.

How we support

Offer ongoing support, upgrades and continuous testing for T1074 detections as a retainer, if the client wants it.
Re-check T1074 mappings when MITRE releases a new ATT&CK version that renames, deprecates or revokes content.
Confirm with the client which changes need a new written scope before any additional work begins.

T1074 Data staged