Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1537: Transfer Data to Cloud Account

Adversaries may exfiltrate data by transferring the data, including through sharing/syncing and creating backups of cloud environments, to another cloud account they control on the same service.

A defender who is monitoring for large transfers to outside the cloud environment through normal file transfers or over command and control channels may not be watching for data transfers to another account within the same cloud provider. Such transfers may utilize existing cloud provider APIs and the internal address space of the cloud provider to blend into normal traffic or avoid data transfers over external network interfaces.[1]

Adversaries may also use cloud-native mechanisms to share victim data with adversary-controlled cloud accounts, such as creating anonymous file sharing links or, in Azure, a shared access signature (SAS) URI.[2]

Incidents have been observed where adversaries have created backups of cloud instances and transferred them to separate accounts.[3]

EnterpriseT1537TechniqueObject v1.5 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Transfer Data to Cloud Account is an exfiltration technique where data is moved to an adversary-controlled account within the same cloud service. It matters because normal egress monitoring may miss it: the activity can look like legitimate cloud sharing, sync, backup, snapshot, or provider API use rather than a classic outbound file transfer.

Executive priority

Treat this as a cloud data-governance and incident-readiness issue, not only a network monitoring issue. Leaders should ask whether the organization can prove who can share data externally, create backup copies or snapshots, generate shared access links, and transfer cloud resources to other accounts across IaaS, SaaS, and office suite environments. This is especially relevant for audit evidence, data loss prevention priorities, and incident decisions involving sensitive data exposure.

Technical view

SOC and IR teams should validate visibility into cloud-native sharing and backup actions, including snapshot permission changes, anonymous sharing links, shared access signature-style access, file sync/share events, and cross-account resource transfer indicators. Because official ATT&CK detection text is not provided, detection should be built from cloud audit logs, SaaS/office suite activity logs, DLP events, and account/resource relationship context. The related DET0573 detection strategy indicates cross-platform detection is relevant, but no detailed detection logic was supplied here.

Likely telemetry

  • Cloud control-plane audit logs for API activity
  • SaaS and office suite file sharing, sync, and external collaboration logs
  • IaaS snapshot, backup, image, storage object, and permission-change events
  • Events showing creation or use of anonymous sharing links or shared access signatures
  • Resource ownership, account ID, tenant, and external principal access records

Detection direction

  • Baseline normal cloud sharing, backup, and snapshot behavior by user, service account, tenant, and business unit.
  • Alert on new or unusual external account access to sensitive storage, snapshots, backups, or shared files.
  • Correlate large data-access or copy activity with permission changes, link creation, or cross-account sharing events.
  • Tune for legitimate administrative backup and collaboration workflows to reduce false positives.
  • Do not rely only on perimeter egress monitoring; the technique may use provider APIs or internal cloud provider address space.

Mitigation priorities

  • Prioritize user account management and least privilege for identities allowed to share, export, back up, or snapshot cloud data.
  • Harden software and cloud service configuration to restrict anonymous links, broad sharing, and risky backup or snapshot permissions.
  • Use DLP policies for sensitive data in SaaS, office suite, and cloud storage environments.
  • Apply network filtering where applicable, while recognizing that cloud-native same-provider transfers may require control-plane and data-plane monitoring beyond traditional egress controls.
  • Regularly review external sharing, backup, snapshot, and delegated-access settings as compliance evidence.
Analyst notes and limits

This technique is most material where sensitive data resides in cloud services and where legitimate collaboration or backup features can be abused. The supplied relationships identify mitigations M1018, M1037, M1054, and M1057, plus groups reported by ATT&CK as using the technique: INC Ransom, RedCurl, and Storm-0501. Use those relationships for threat-informed prioritization, not as proof of current activity in a specific environment.

MITRE did not provide official detection text for this object, and the supplied DET0573 relationship does not include detection logic. Local cloud provider, SaaS, office suite, identity, DLP, and logging configurations are required to determine actual coverage and risk.

Official MITRE ATT&CK definition

Transfer Data to Cloud Account

Adversaries may exfiltrate data by transferring the data, including through sharing/syncing and creating backups of cloud environments, to another cloud account they control on the same service.

A defender who is monitoring for large transfers to outside the cloud environment through normal file transfers or over command and control channels may not be watching for data transfers to another account within the same cloud provider. Such transfers may utilize existing cloud provider APIs and the internal address space of the cloud provider to blend into normal traffic or avoid data transfers over external network interfaces.[1]

Adversaries may also use cloud-native mechanisms to share victim data with adversary-controlled cloud accounts, such as creating anonymous file sharing links or, in Azure, a shared access signature (SAS) URI.[2]

Incidents have been observed where adversaries have created backups of cloud instances and transferred them to separate accounts.[3]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Associated objects

Groups, software, and campaigns

Group Enterprise

G1053: Storm-0501

Storm-0501 is a financially motivated cyber criminal group that uses commodity and open-source tools to conduct ransomware operations. Storm-0501 has been active since 2021 and has previously been affiliated with Sabbath Ransomware and other Ransomware-as-a-Service (RaaS) variants such as Hive, BlackCat, Hunters International, LockBit 3.0, and Embargo ransomware.[1][2][3][4]

Group Enterprise

G1039: RedCurl

RedCurl is a threat actor active since 2018 notable for corporate espionage targeting a variety of locations, including Ukraine, Canada and the United Kingdom, and a variety of industries, including but not limited to travel agencies, insurance companies, and banks.[1] RedCurl is allegedly a Russian-speaking threat actor.[1][2] The group’s operations typically start with spearphishing emails to gain initial access, then the group executes discovery and collection commands and scripts to find corporate data. The group concludes operations by exfiltrating files to the C2 servers.

Relationship explorer

All related ATT&CK context

uses · Group G1053: Storm-0501 Enterprise mitigates · Mitigation M1057: Data Loss Prevention Enterprise mitigates · Mitigation M1018: User Account Management Enterprise uses · Group G1032: INC Ransom Enterprise mitigates · Mitigation M1054: Software Configuration Enterprise detects · Detection Strategy DET0573: Cross-Platform Detection of Data Transfer to Cloud Account Enterprise mitigates · Mitigation M1037: Filter Network Traffic Enterprise uses · Group G1039: RedCurl Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1057: Data Loss Prevention

Data Loss Prevention (DLP) involves implementing strategies and technologies to identify, categorize, monitor, and control the movement of sensitive data within an organization. This includes protecting data formats indicative of Personally Identifiable Information (PII), intellectual property, or financial data from unauthorized access, transmission, or exfiltration. DLP solutions integrate with network, endpoint, and cloud platforms to enforce security policies and prevent accidental or malicious data leaks. [1] This mitigation can be implemented through the following measures:

Sensitive Data Categorization:

- Use Case: Identify and classify data based on sensitivity (e.g., PII, financial data, trade secrets). - Implementation: Use DLP solutions to scan and tag files containing sensitive information using predefined patterns, such as Social Security Numbers or credit card details.

Exfiltration Restrictions:

- Use Case: Prevent unauthorized transmission of sensitive data. - Implementation: Enforce policies to block unapproved email attachments, unauthorized USB usage, or unencrypted data uploads to cloud storage.

Data-in-Transit Monitoring:

- Use Case: Detect and prevent the transmission of sensitive data over unapproved channels. - Implementation: Deploy network-based DLP tools to inspect outbound traffic for sensitive content (e.g., financial records or PII) and block unapproved transmissions.

Endpoint Data Protection:

- Use Case: Monitor and control sensitive data usage on endpoints. - Implementation: Use endpoint-based DLP agents to block copy-paste actions of sensitive data and unauthorized printing or file sharing.

Cloud Data Security:

- Use Case: Protect data stored in cloud platforms. - Implementation: Integrate DLP with cloud storage platforms like Google Drive, OneDrive, or AWS to monitor and restrict sensitive data sharing or downloads.

Mitigation Enterprise

M1018: User Account Management

User Account Management involves implementing and enforcing policies for the lifecycle of user accounts, including creation, modification, and deactivation. Proper account management reduces the attack surface by limiting unauthorized access, managing account privileges, and ensuring accounts are used according to organizational policies. This mitigation can be implemented through the following measures:

Enforcing the Principle of Least Privilege

- Implementation: Assign users only the minimum permissions required to perform their job functions. Regularly audit accounts to ensure no excess permissions are granted. - Use Case: Reduces the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions.

Implementing Strong Password Policies

- Implementation: Enforce password complexity requirements (e.g., length, character types). Require password expiration every 90 days and disallow password reuse. - Use Case: Prevents adversaries from gaining unauthorized access through password guessing or brute force attacks.

Managing Dormant and Orphaned Accounts

- Implementation: Implement automated workflows to disable accounts after a set period of inactivity (e.g., 30 days). Remove orphaned accounts (e.g., accounts without an assigned owner) during regular account audits. - Use Case: Eliminates dormant accounts that could be exploited by attackers.

Account Lockout Policies

- Implementation: Configure account lockout thresholds (e.g., lock accounts after five failed login attempts). Set lockout durations to a minimum of 15 minutes. - Use Case: Mitigates automated attack techniques that rely on repeated login attempts.

Multi-Factor Authentication (MFA) for High-Risk Accounts

- Implementation: Require MFA for all administrative accounts and high-risk users. Use MFA mechanisms like hardware tokens, authenticator apps, or biometrics. - Use Case: Prevents unauthorized access, even if credentials are stolen.

Restricting Interactive Logins

- Implementation: Restrict interactive logins for privileged accounts to specific secure systems or management consoles. Use group policies to enforce logon restrictions. - Use Case: Protects sensitive accounts from misuse or exploitation.

*Tools for Implementation*

Built-in Tools:

- Microsoft Active Directory (AD): Centralized account management and RBAC enforcement. - Group Policy Object (GPO): Enforce password policies, logon restrictions, and account lockout policies.

Identity and Access Management (IAM) Tools:

- Okta: Centralized user provisioning, MFA, and SSO integration. - Microsoft Azure Active Directory: Provides advanced account lifecycle management, role-based access, and conditional access policies.

Privileged Account Management (PAM): - CyberArk, BeyondTrust, Thycotic: Manage and monitor privileged account usage, enforce session recording, and JIT access.

Mitigation Enterprise

M1054: Software Configuration

Software configuration refers to making security-focused adjustments to the settings of applications, middleware, databases, or other software to mitigate potential threats. These changes help reduce the attack surface, enforce best practices, and protect sensitive data. This mitigation can be implemented through the following measures:

Conduct a Security Review of Application Settings:

- Review the software documentation to identify recommended security configurations. - Compare default settings against organizational policies and compliance requirements.

Implement Access Controls and Permissions:

- Restrict access to sensitive features or data within the software. - Enforce least privilege principles for all roles and accounts interacting with the software.

Enable Logging and Monitoring:

- Configure detailed logging for key application events such as authentication failures, configuration changes, or unusual activity. - Integrate logs with a centralized monitoring solution, such as a SIEM.

Update and Patch Software Regularly:

- Ensure the software is kept up-to-date with the latest security patches to address known vulnerabilities. - Use automated patch management tools to streamline the update process.

Disable Unnecessary Features or Services:

- Turn off unused functionality or components that could introduce vulnerabilities, such as debugging interfaces or deprecated APIs.

Test Configuration Changes:

- Perform configuration changes in a staging environment before applying them in production. - Conduct regular audits to ensure that settings remain aligned with security policies.

*Tools for Implementation*

Configuration Management Tools:

- Ansible: Automates configuration changes across multiple applications and environments. - Chef: Ensures consistent application settings through code-based configuration management. - Puppet: Automates software configurations and audits changes for compliance.

Security Benchmarking Tools:

- CIS-CAT: Provides benchmarks and audits for secure software configurations. - Aqua Security Trivy: Scans containerized applications for configuration issues.

Vulnerability Management Solutions:

- Nessus: Identifies misconfigurations and suggests corrective actions.

Logging and Monitoring Tools:

- Splunk: Aggregates and analyzes application logs to detect suspicious activity.

Mitigation Enterprise

M1037: Filter Network Traffic

Employ network appliances and endpoint software to filter ingress, egress, and lateral network traffic. This includes protocol-based filtering, enforcing firewall rules, and blocking or restricting traffic based on predefined conditions to limit adversary movement and data exfiltration. This mitigation can be implemented through the following measures:

Ingress Traffic Filtering:

- Use Case: Configure network firewalls to allow traffic only from authorized IP addresses to public-facing servers. - Implementation: Limit SSH (port 22) and RDP (port 3389) traffic to specific IP ranges.

Egress Traffic Filtering:

- Use Case: Use firewalls or endpoint security software to block unauthorized outbound traffic to prevent data exfiltration and command-and-control (C2) communications. - Implementation: Block outbound traffic to known malicious IPs or regions where communication is unexpected.

Protocol-Based Filtering:

- Use Case: Restrict the use of specific protocols that are commonly abused by adversaries, such as SMB, RPC, or Telnet, based on business needs. - Implementation: Disable SMBv1 on endpoints to prevent exploits like EternalBlue.

Network Segmentation:

- Use Case: Create network segments for critical systems and restrict communication between segments unless explicitly authorized. - Implementation: Implement VLANs to isolate IoT devices or guest networks from core business systems.

Application Layer Filtering:

- Use Case: Use proxy servers or Web Application Firewalls (WAFs) to inspect and block malicious HTTP/S traffic. - Implementation: Configure a WAF to block SQL injection attempts or other web application exploitation techniques.

Change history

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 .

ATT&CK release
19.1
Object version
1.5
Created
Modified
Raw hash
34e3d925cd4a288f...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.5 Current bundle 34e3d925cd4a…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    TLDRSec AWS Attacks

    Clint Gibler and Scott Piper. (2021, January 4). Lesser Known Techniques for Attacking AWS Environments. Retrieved March 4, 2024.

    Open source URL
  2. [2]
    Microsoft Azure Storage Shared Access Signature

    Microsoft. (2023, June 7). Grant limited access to Azure Storage resources using shared access signatures (SAS). Retrieved March 4, 2024.

    Open source URL
  3. [3]
    DOJ GRU Indictment Jul 2018

    Mueller, R. (2018, July 13). Indictment - United States of America vs. VIKTOR BORISOVICH NETYKSHO, et al. Retrieved November 17, 2024.

    Open source URL
  4. [4]
    AWS EBS Snapshot Sharing

    Amazon Web Services. (n.d.). Share an Amazon EBS snapshot. Retrieved March 2, 2022.

    Open source URL
  5. [5]
    Azure Blob Snapshots

    Microsoft Azure. (2021, December 29). Blob snapshots. Retrieved March 2, 2022.

    Open source URL
  6. [6]
    Azure Shared Access Signature

    Delegate access with a shared access signature. (2019, December 18). Delegate access with a shared access signature. Retrieved March 2, 2022.

    Open source URL
  7. [7]
    mitre-attack T1537
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use