DET0573: Cross-Platform Detection of Data Transfer to Cloud Account
DET0573 is a detection strategy for spotting data transfer to another cloud account, tied to ATT&CK technique T1537. The business risk is that data can lea...
Analyst context for executives and security teams
DET0573 is a detection strategy for spotting data transfer to another cloud account, tied to ATT&CK technique T1537. The business risk is that data can leave the organization without looking like a classic internet upload: it may occur inside the same cloud service through sharing, syncing, backup, or provider APIs. Leaders should treat this as a cloud exfiltration coverage question, especially for SaaS, office-suite, and IaaS environments where normal user workflows can resemble risky transfers.
Executive priority
Prioritize this where sensitive data is stored in cloud services and where audit, legal, or business-continuity obligations depend on proving that data movement is governed and reviewable. The key executive question is whether the organization can distinguish approved cross-account collaboration or backup from transfer to an external account controlled by an adversary. This should inform cloud logging budgets, identity governance, DLP/CASB-style control priorities, incident response playbooks, and compliance evidence for data access and movement.
Technical view
Because the detection strategy object has no official detection text and no platforms listed, implementation should be driven by the related technique context: T1537, Exfiltration, on IaaS, Office Suite, and SaaS. SOC and detection teams should validate whether they can observe cross-account sharing, sync, backup, export, and API-driven transfer events within the same cloud provider or service. IR teams should be prepared to scope source account, destination account, data objects transferred, identities or service principals involved, timestamps, and whether the destination is organizationally owned or external.
Likely telemetry
- Cloud provider audit logs for file/object sharing, copy, sync, backup, export, and transfer events
- SaaS and office-suite activity logs showing external sharing, ownership transfer, link creation, bulk download/sync, or cross-tenant movement
- IaaS object storage and backup service logs, including API calls and destination account or bucket identifiers where available
- Identity and access logs for users, service accounts, OAuth/app grants, sessions, and administrative changes around the transfer window
- Data governance or DLP event records that identify sensitive objects moved or shared
Detection direction
- Validate that monitoring covers transfers to another account within the same cloud service, not only outbound network transfers or command-and-control channels.
- Tune detections around high-volume, unusual, or newly configured sharing/sync/backup/API transfer activity, while accounting for legitimate collaboration, migrations, eDiscovery, and backup operations.
- Correlate transfer events with identity context such as unusual user behavior, newly granted permissions, new service principals/apps, or activity from accounts not normally performing bulk data movement.
- Maintain an allowlist or business registry of approved external tenants/accounts; without destination ownership context, alert quality will be poor.
- Test whether logs preserve enough detail to answer incident questions: what data moved, from where, to whom, by which identity, and whether access was later revoked.
Mitigation priorities
- Inventory cloud services and data stores where cross-account or external sharing, sync, backup, or transfer is possible.
- Restrict external sharing and cross-account transfer permissions based on business need, especially for sensitive repositories and privileged identities.
- Require strong identity governance for users, service accounts, and third-party applications that can initiate cloud data movement.
- Centralize and retain relevant cloud, SaaS, office-suite, identity, and DLP logs so investigations can reconstruct transfer paths.
- Define approved destination accounts, tenants, and backup targets, and monitor deviations from that baseline.
Analyst notes and limits
This take is based on the MITRE detection strategy DET0573 and its relationship to T1537 Transfer Data to Cloud Account. The most important relationship-driven point is that defenders may miss exfiltration if they only monitor large external transfers and not same-provider account-to-account movement through normal cloud APIs or collaboration features.
The supplied ATT&CK detection strategy has no official description, no official detection text, and no explicit platforms or tactics. Platform and tactic context comes from the related T1537 technique only. Local cloud architecture, logging configuration, data classification, and approved sharing model are required to turn this into precise detections or control requirements.
Cross-Platform Detection of Data Transfer to Cloud Account
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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 | T1537 | Transfer Data to Cloud Account | This object detects Transfer Data to Cloud Account. |
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.0 | Current bundle | 408ae3affe80… |
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]
mitre-attack DET0573Open 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.