Before data leaves your environment, attackers usually gather it in one place, and that pile of copied files, new bucket objects or temporary database stages is the last point where you can stop a theft without chasing data across the internet. MITRE ATT&CK tracks this as T1074 Data Staged, a Collection (TA0009) technique with two sub-techniques, T1074.001 Local Data Staging and T1074.002 Remote Data Staging, on ESXi, IaaS, Linux, macOS and Windows. This guide is for detection engineers, cloud security teams and data owners. It goes beyond archive staging on endpoints, which our T1560 and T1074 Archive and Stage Collected Data Defensive Guide already covers, and concentrates on staging on central servers, cloud instances, object storage and data platforms, with the detections and data controls that apply there.
Key takeaways
- Staging is the choke point. ATT&CK notes attackers stage centrally to reduce connections to their command and control servers and evade detection. That same concentration makes the staging location a high-value detection point.
- Cloud staging uses your own resources. ATT&CK describes staging inside an instance or virtual machine, including a newly created one. Buckets, snapshots and data platform stages in your account serve the same purpose.
- Object-level logs are off by default. AWS states CloudTrail does not log data events by default, and Microsoft states Azure Storage resource logs are not stored until you create a diagnostic setting. Without them, cloud staging is invisible.
- Prevention is about the perimeter, not the copy. ATT&CK v20 lists no mitigations for T1074. Data perimeter controls decide whether staged data can move on; copy volume and destination monitoring decide whether you see it.
- Staging and transfer are different techniques. Moving data to an account the attacker controls is T1537 Transfer Data to Cloud Account (Exfiltration). Detect both, but treat staging as the earlier, cheaper place to act.
What the technique covers
ATT&CK v20 (technique version 1.5, last modified 12 May 2026) describes adversaries staging collected data in a central location or directory before exfiltration, in separate files or combined through T1560 Archive Collected Data.
| Form | ATT&CK definition | Typical locations seen in procedure examples | Detection strategy |
|---|---|---|---|
| T1074.001 Local Data Staging | Staging on the local system, including in local databases or the Windows Registry | C:\Users\Public, %TEMP%, C:\PerfLogs, /tmp, log directories | DET0261 |
| T1074.002 Remote Data Staging | Data from multiple systems gathered on one system; in cloud, within an instance or VM, possibly a new one | File servers, OWA and web servers, internet-facing hosts, designated servers, cloud instances | DET0071 |
| T1074 (parent) | Either of the above | All of the above, plus cloud buckets and mounted volumes in the IaaS analytic | DET0014 |
MITRE ATLAS has an AI-specific mirror, AML.T0127 Data Staged, for staging collected AI artefacts and data.
How adversaries use it: real cases
Procedure examples from the ATT&CK v20 data, with the source ATT&CK cites, plus one NHI Mgmt Group breach analysis:
- Snowflake customer intrusions (2024): attackers logged in with infostealer-harvested credentials on accounts without MFA, enumerated tables, created temporary stages and copied whole tables out, activity that looked like normal database use. This is staging inside a cloud data platform, not on an endpoint. See the Snowflake Breach 2024 analysis.
- APT29, SolarWinds Compromise (C0024): staged data and files in password-protected archives on a victim's Outlook Web Access server (Volexity). Internet-facing servers are favoured staging points because exfiltration from them looks like normal web traffic.
- Threat Group-3390 (G0027): moved staged encrypted archives to internet-facing servers previously compromised with China Chopper before exfiltration (Secureworks).
- Sea Turtle (G1041): staged collected email archives in the public web directory of a website accessible from the internet (2024 research cited by ATT&CK).
- Scattered Spider (G1015): stages data in a centralised database before exfiltration (CISA advisory, November 2023).
- menuPass (G0045): staged data on remote managed service provider systems or other victim networks before exfiltration (PwC Cloud Hopper, 2017), staging in a trusted third party's environment.
- UNC3886 (G1048): staged captured credentials in a compressed file under
/var/logwith a name that blends in with log rotation (Google Cloud Mandiant, 2024).
Cloud side staging in detail
In cloud and SaaS, the attacker rarely needs a foothold on an endpoint. A stolen access key, service principal or data platform account is enough to gather data in a place that is fast and cheap to move later. The patterns below are described for detection; ATT&CK places some of the supporting actions in separate techniques, named in the table.
| Staging pattern | What it looks like | Related ATT&CK technique | Key signal |
|---|---|---|---|
| New instance as a collection point | A VM created by an unusual identity, with storage attached and inbound copy traffic from many hosts | T1074.002; T1578.002 Create Cloud Instance | Instance creation by a non-provisioning identity; flow logs showing many-to-one transfers |
| Snapshots of data volumes | Snapshots of database or file server disks outside backup schedules | T1578.001 Create Snapshot | Snapshot creation by an identity that is not your backup service |
| Aggregation bucket in the victim account | Bulk copy of objects from many buckets or prefixes into one bucket | T1074 (IaaS analytic); data source T1530 Data from Cloud Storage | Spikes of copy and get object events concentrated on one destination |
| Data platform stages | Temporary stages or unload locations created in a data warehouse, then bulk unload | T1074 (collection inside a SaaS platform) | Stage creation and large unload operations by service or contractor accounts |
| Hand-off to an external account | Sharing a snapshot or copying objects to an account outside your organisation | T1537 Transfer Data to Cloud Account | Cross-account sharing and copy events to untrusted account IDs |
The data-from-cloud-storage step that usually precedes aggregation is covered in the T1530 Data from Cloud Storage Defensive Guide.
What to detect and where
ATT&CK's three detection strategies give platform analytics. The table condenses them.
| Platform | Analytics | Data components and log sources (from ATT&CK) | Practical rule |
|---|---|---|---|
| Windows | AN0040, AN0724 (local); AN0194 (remote) | File Access (Security 4663, 4656, 4670); File Creation (Sysmon 11); Process Creation (Sysmon 1); Network Share Access (SMBClient/Security 31001); PowerShell copy commands from UNC paths | Many reads across shares followed by writes into one directory, especially public, temp or PerfLogs paths, then archiving |
| Linux and macOS | AN0041, AN0725, AN0042, AN0726 (local); AN0195, AN0196 (remote) | auditd execve, creat and open; unified log file and exec events; flow data for SSH, scp and rsync | Inbound scp, rsync or NFS mounts aggregating into /tmp, /var/tmp, /mnt, /Users/Shared |
| ESXi | AN0044, AN0727, AN0197 | VMFS access and file creation (vmkernel); snapshot creation; shell commands; NFS access logs | Snapshots or large file writes to datastores from shell or unknown agents |
| IaaS | AN0043, AN0198 | Cloud Storage Access (CloudTrail GetObject, CopyObject); Google Cloud audit write operations; VPC flow logs between instances | Copy and get object bursts concentrated on one destination bucket or instance, by an unusual identity |
Turn on the logs first
- AWS: CloudTrail does not log data events by default and charges for them. Enable S3 data events with advanced event selectors, scoped to sensitive buckets or prefixes using
resources.ARNconditions to control cost. - Google Cloud: VPC Service Controls records perimeter access through Cloud Audit Logs; enable Data Access audit logs for Cloud Storage on sensitive projects.
- Microsoft Azure: Blob resource logs are not stored until you create a diagnostic setting; route them to Log Analytics and query the
StorageBlobLogstable. Microsoft shows filtering onOperationNamecontainingCopyBlobSourceto list copies reading from an account.
Sequences worth alerting on
- Fan-in: one host or bucket receiving data from many sources within an hour, outside backup windows.
- Read then aggregate then archive: share or object reads, then writes to one location, then an archive tool or compression.
- Staging on internet-facing hosts: large new archives in web roots or OWA directories, the APT29 and Sea Turtle pattern.
- Unusual identity, bulk data: a contractor, CI role or long-unused service account creating stages, snapshots or instances and then moving gigabytes.
Data controls by cloud
ATT&CK v20 lists no mitigation objects for T1074, so the controls below are NHI Mgmt Group recommendations drawn from each provider's documentation. Providers are listed alphabetically.
| Provider | Preventive control (from provider docs) | Detection control (from provider docs) |
|---|---|---|
| AWS | Data perimeter: service control policies, resource control policies and VPC endpoint policies so identities reach only trusted resources (the resource perimeter uses the aws:ResourceOrgID condition key) and resources accept only trusted identities | CloudTrail S3 data events for GetObject, PutObject and CopyObject on sensitive buckets |
| Google Cloud | VPC Service Controls perimeters: by default block communication to Google Cloud services across the perimeter, so data cannot be copied to unauthorised resources outside it; test with dry run mode first | Cloud Audit Logs for perimeter access and Cloud Storage Data Access logs |
| Microsoft Azure | Permitted scope for copy operations (AllowedCopyScope, preview as of November 2026): restrict copy sources to the same Microsoft Entra tenant or to private endpoints in the same virtual network; not set by default | StorageBlobLogs via a diagnostic setting, with alerts on CopyBlobSource volume and unexpected callers |
For the design detail, see the Cloud Data Perimeter Guide, the AWS Resource Control Policies and Data Perimeter Guide and the VPC Service Controls Guide.
On endpoints and servers, the practical controls are restricting write access to public and shared staging paths, application control for archive tools on servers that do not need them, and egress filtering from internet-facing hosts.
Where identity fits
Cloud staging is almost always done with a non-human or neglected credential: an access key, a service principal, a CI role or a data platform service user. The Snowflake intrusions used accounts without MFA whose passwords had not been rotated. Three identity controls make staging harder and louder: scope storage and snapshot permissions to the workloads that need them, keep network restrictions on data platform service users so a stolen credential cannot be used from anywhere, and alert when an identity that normally reads a few objects starts copying many. See the Cross-Account and Cross-Tenant Access Guide for the trust paths staged data most often leaves by.
How to test and roll out
- Inventory staging-friendly locations: public and temp paths on servers, web roots on internet-facing hosts, sensitive buckets and data platform accounts.
- Enable logging in scope: object-level logs on sensitive buckets only at first, to control cost; file access auditing on key file servers.
- Emulate: an authorised tester copies benign test data from several sources into one location on-premises and into one bucket in a test account, using an emulation framework mapped to T1074.
- Validate alerts and baselines: confirm fan-in and bulk copy rules fire; record normal backup and ETL jobs as named exclusions.
- Apply perimeter controls in observe mode: VPC Service Controls dry run, and in AWS test policies on a non-production organisational unit before attaching them widely.
- Roll back: detach a perimeter policy or return a perimeter to dry run if business flows break, and add the flow as an explicit exception rather than removing the control.
Metrics
- Percentage of sensitive buckets and storage accounts with object-level logging on.
- Accounts and projects inside a data perimeter, as a share of those holding sensitive data.
- Time from bulk copy start to alert triage.
- Number of staging alerts closed as known ETL or backup (should fall as baselines improve).
- Data platform service users with network restrictions and no static password.
Common failure patterns
- Assuming cloud logs are on: management events are logged, object reads and copies are not, so the bulk copy that matters is missing.
- Watching only for exfiltration: alerts fire on the final transfer, after staging has finished and the window to stop it has closed.
- Ignoring internet-facing servers: web and mail servers are favoured staging points and often have the weakest file monitoring.
- Treating data platform activity as business as usual: in the Snowflake intrusions, staging used ordinary SQL from accounts with no network restrictions.
- Excluding backup identities wholesale: attackers who steal a backup or ETL credential inherit the exclusion.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1074, T1074.001, T1074.002; TA0009; DET0014, DET0261, DET0071 | Technique and detection analytics |
| MITRE ATT&CK (related) | T1560; T1530; T1578.001; T1578.002; T1537 | Steps before and after staging |
| MITRE ATLAS | AML.T0127 Data Staged | AI system equivalent |
| NIST SP 800-53 Rev 5 | AC-4 Information Flow Enforcement; SC-7(10) Prevent Exfiltration | Perimeter and flow controls |
| NIST SP 800-53 Rev 5 | AU-12 Audit Record Generation; AU-6 Audit Record Review; SI-4 System Monitoring | Object-level and file access logging and review |
| NIST CSF 2.0 | PR.DS-01; DE.CM-09; DE.AE-02 | Protect data at rest; monitor and analyse |
Practitioner checklist
- Enable object-level logging on sensitive buckets and storage accounts.
- Alert on fan-in to one host, bucket or instance outside backup windows.
- Monitor public, temp and web root paths on servers for large new archives.
- Alert on snapshots and instances created by identities outside your provisioning and backup tooling.
- Put sensitive accounts and projects inside a data perimeter, tested in observe mode first.
- Restrict data platform service users by network and remove static passwords.
- Name and baseline every ETL and backup identity rather than excluding them broadly.
- Correlate staging alerts with T1537 cross-account transfer alerts.
Standards and references
- MITRE ATT&CK: Data Staged (T1074)
- MITRE ATT&CK: Remote Data Staging (T1074.002)
- AWS: Logging data events with CloudTrail
- AWS: Data perimeter policy examples
- Google Cloud: VPC Service Controls overview
- Microsoft: Monitor Azure Blob Storage
- Microsoft: Restrict the source of copy operations to a storage account
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: T1560 and T1074 Archive and Stage Collected Data Defensive Guide · T1530 Data from Cloud Storage Defensive Guide · ATT&CK Collection Tactic Guide · Cloud Data Perimeter Guide · Data Exfiltration Guide