T1074: Data Staged
Adversaries may stage collected data in a central location or directory prior to Exfiltration. Data may be kept in separate files or combined into one file through techniques such as Archive Collected Data. Interactive command shells may be used, and common functionality within cmd and bash may be used to copy data into a staging location.[1]
In cloud environments, adversaries may stage data within a particular instance or virtual machine before exfiltration. An adversary may Create Cloud Instance and stage data in that instance.[2]
Adversaries may choose to stage data from a victim network in a centralized location prior to Exfiltration to minimize the number of connections made to their C2 server and better evade detection.
Analyst context for executives and security teams
Data Staged is the collection-phase behavior where an intruder gathers files into one place before trying to exfiltrate them. For leaders, the business issue is that this can be the last observable preparation point before data loss: if teams can identify unusual file aggregation, archiving, or movement into local, remote, virtualized, or cloud locations, they may gain time to contain an incident before sensitive data leaves the environment.
Executive priority
Prioritize this technique when validating data-loss readiness, ransomware/extortion playbooks, cloud security monitoring, and incident escalation criteria. ATT&CK maps this behavior across Windows, Linux, macOS, ESXi, and IaaS, so coverage decisions should not be limited to endpoint-only controls. Executives should ask whether the SOC can see abnormal data concentration on servers, virtual machines, cloud instances, and administrative staging paths, and whether incident response has clear authority to preserve evidence and interrupt suspected exfiltration preparation.
Technical view
ATT&CK provides no official detection text for T1074, but it does identify DET0014, Detection of Data Staging Prior to Exfiltration, as a related detection strategy and identifies local and remote sub-techniques. SOC and IR teams should validate visibility for file copy, file creation, archive creation, shell-driven collection activity, and movement of data into centralized directories or systems. In IaaS, teams should also validate whether newly created or unusual instances/virtual machines could be used as staging locations. Detection engineering should correlate staging indicators with surrounding collection and exfiltration behaviors rather than treating every bulk copy or archive as malicious.
Likely telemetry
- Endpoint file creation, modification, copy, and rename events on Windows, Linux, macOS, and ESXi where available
- Command-line and shell execution telemetry for cmd, bash, and other interactive shells used to copy or combine data
- Archive creation or unusually large file generation telemetry related to collected data
- File share, server, and centralized directory access logs showing aggregation from multiple systems
- Cloud/IaaS audit logs for instance or virtual machine creation and unusual data movement into those resources
Detection direction
- Use DET0014 as the starting point for a detection strategy, but confirm local logging because the ATT&CK object itself does not provide official detection logic.
- Build analytics around unusual aggregation patterns: many source paths copied to one destination, sudden growth in staging directories, or archive files created shortly before outbound transfer.
- Separate normal administrative backup, migration, software deployment, and data-processing jobs from suspicious staging through allowlists, change windows, known service accounts, and expected destinations.
- Cover both T1074.001 Local Data Staging and T1074.002 Remote Data Staging; remote staging may appear as internal movement rather than immediate exfiltration.
- For IaaS, correlate data movement with creation or unusual use of cloud instances or virtual machines, consistent with the ATT&CK description.
Mitigation priorities
- Confirm that sensitive data repositories, file servers, virtualized infrastructure, and cloud instances have sufficient logging before relying on detection outcomes.
- Reduce unnecessary write access to shared staging-capable locations and review permissions for accounts that can aggregate data across systems.
- Apply retention and monitoring to command execution, file activity, cloud audit, and server access logs so IR can reconstruct staging activity.
- Define incident response decision points for suspected staging, including evidence preservation, containment approval, and escalation before confirmed exfiltration.
- Validate backup, migration, and administrative workflows so detection rules can distinguish expected bulk data movement from suspicious aggregation.
Analyst notes and limits
Relationship context shows use of this technique by multiple ATT&CK groups and software entries, including Wizard Spider, Scattered Spider, Volt Typhoon, INC Ransom, VOID MANTICORE, Kobalos, Shark, Kevin, and QUIETCANARY. This supports treating data staging as a broadly relevant behavior, but it does not prove current activity in any specific environment. The most useful defensive question is whether the organization can detect data concentration before the exfiltration step.
The supplied ATT&CK object has no official detection text and no mitigations. This take is therefore based on the official description, platforms, tactics, external references, sub-technique relationships, and the related DET0014 detection strategy. Local asset criticality, data sensitivity, logging configuration, cloud architecture, and normal administrative workflows are required to turn this into reliable detections or controls.
Data Staged
Adversaries may stage collected data in a central location or directory prior to Exfiltration. Data may be kept in separate files or combined into one file through techniques such as Archive Collected Data. Interactive command shells may be used, and common functionality within cmd and bash may be used to copy data into a staging location.[1]
In cloud environments, adversaries may stage data within a particular instance or virtual machine before exfiltration. An adversary may Create Cloud Instance and stage data in that instance.[2]
Adversaries may choose to stage data from a victim network in a centralized location prior to Exfiltration to minimize the number of connections made to their C2 server and better evade detection.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1074.001 | Local Data Staging Sub-technique | Local Data Staging subtechnique of this object. |
| Enterprise | T1074.002 | Remote Data Staging Sub-technique | Remote Data Staging subtechnique of this object. |
Groups, software, and campaigns
G0102: Wizard Spider
Wizard Spider is a Russia-based financially motivated threat group originally known for the creation and deployment of TrickBot since at least 2016. Wizard Spider possesses a diverse arsenal of tools and has conducted ransomware campaigns against a variety of organizations, ranging from major corporations to hospitals.[1][2][3]
G1017: Volt Typhoon
Volt Typhoon is a People's Republic of China (PRC) state-sponsored actor that has been active since at least 2021, primarily targeting critical infrastructure organizations in the US and its territories including Guam. Volt Typhoon's targeting and pattern of behavior have been assessed as pre-positioning to enable lateral movement to operational technology (OT) assets for potential destructive or disruptive attacks. Volt Typhoon has emphasized stealth in operations using web shells, living-off-the-land (LOTL) binaries, hands on keyboard activities, and stolen credentials.[1][2][3][4]. The group has leveraged compromised SOHO routers to proxy command and control traffic and obscure its infrastructure, activity associated with the KV botnet.[5].
Reporting indicates a separate initial access cluster, SYLVANITE, has been observed exploiting internet-facing edge devices and transferring access to Volt Typhoon, also tracked as VOLTZITE, for follow-on operations. [6]
G1055: VOID MANTICORE
VOID MANTICORE is a threat group assessed to operate on behalf of Iran’s Ministry of Intelligence and Security (MOIS).[1] Active since at least mid-2022, VOID MANTICORE has targeted government entities, critical infrastructure, and private sector organizations across Albania, Israel, and the United States.[1][2] VOID MANTICORE conducts destructive cyber operations, combining wiper attacks with hack-and-leak campaigns. The group has operated under multiple public-facing personas, including HomeLand Justice in operations against Albania, Karma and Karma Below in campaigns targeting Israeli organizations, and Handala Hack, its current primary persona, which has claimed activity against Israeli and U.S. entities, including a March 2026 attack against Stryker Corporation.[1][3] VOID MANTICORE has been observed collaborating with Scarred Manticore, which has been linked to initial access operations preceding VOID MANTICORE’s activity.[4]
G1032: INC Ransom
INC Ransom is a ransomware and data extortion threat group associated with the deployment of INC Ransomware that has been active since at least July 2023. INC Ransom has targeted organizations worldwide most commonly in the industrial, healthcare, and education sectors in the US and Europe.[1][2][3][4]
G1015: Scattered Spider
Scattered Spider is a native English-speaking cybercriminal group active since at least 2022. [1] [2] The group initially targeted customer relationship management (CRM) providers, business process outsourcing (BPO) firms, and telecommunications and technology companies before expanding in 2023 to gaming, hospitality, retail, managed service provider (MSP), manufacturing, and financial sectors. [2] Scattered Spider relies heavily on social engineering, including impersonating IT and help-desk staff, to gain initial access, bypass multi-factor authentication (MFA), and compromise enterprise networks. The group has adapted its tooling to evade endpoint detection and response (EDR) defenses and used ransomware for financial gain. [3] [4] [5] Scattered Spider had expanded into hybrid cloud and identity environments, using help-desk impersonation and MFA bypass to obtain administrator access in Okta, AWS, and Office 365. [6]
S0641: Kobalos
Kobalos is a multi-platform backdoor that can be used against Linux, FreeBSD, and Solaris. Kobalos has been deployed against high profile targets, including high-performance computers, academic servers, an endpoint security vendor, and a large internet service provider; it has been found in Europe, North America, and Asia. Kobalos was first identified in late 2019.[1][2]
S1020: Kevin
S1076: QUIETCANARY
QUIETCANARY is a backdoor tool written in .NET that has been used since at least 2022 to gather and exfiltrate data from victim networks.[1]
S1019: Shark
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.5 | Current bundle | f635470354be… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
PWC Cloud Hopper April 2017
PwC and BAE Systems. (2017, April). Operation Cloud Hopper. Retrieved April 5, 2017.
Open source URL -
[2]
Mandiant M-Trends 2020
Mandiant. (2020, February). M-Trends 2020. Retrieved November 17, 2024.
Open source URL -
[3]
mitre-attack T1074Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.