How T1537 transfer data to cloud account shows up in intrusions
T1537 lets an adversary move stolen data into a cloud account that the adversary or a related party controls. In practice this step usually follows collection, once the data has been gathered and staged. What makes it hard to spot is the destination: the upload goes to a cloud storage or SaaS service that the organization already allows, often over encrypted HTTPS on ports that are open for business reasons. A SOC lead who relies only on perimeter allow and deny rules, or on destination reputation alone, can see a large outbound transfer and still have no clear signal that it is hostile. The page targets Enterprise ATT&CK version 20.0, so mappings written against that version should name it explicitly.
The activity tends to surface in three places: the content of network traffic where it is visible, the application logs of the cloud or SaaS services involved, and the metadata of storage objects and snapshots. Network Traffic Content (DC0085) is one of the data components ATT&CK detection strategies most often reference for exfiltration techniques, but encryption limits what it reveals, so the defender usually needs the cloud-side record to confirm which account received the data. Ask your platform and security teams which audit logs your sanctioned services produce, how long they are retained, and whether they can be forwarded to your log pipeline in near real time. Gaps in any of those answers are the first thing to close.
Decisions to make now are about ownership and baseline. Identify which cloud tenants, storage buckets and SaaS workspaces are sanctioned for each business unit, and document which identities are expected to create external shares or upload large volumes. Without that baseline, an upload to an unfamiliar tenant looks identical to a legitimate vendor exchange. Confirm with your cloud and SaaS providers the exact event types they record for tenant changes, sharing, and object creation, since these define what your detections can actually see. The mitigations User Account Management (M1018) and Data Loss Prevention (M1057) are the natural places to turn these decisions into controls.
Telemetry that reveals T1537 transfer data to cloud account
This table maps each telemetry source to the T1537 behavior it can reveal, the ATT&CK data component where one applies, and the open-source collector that gathers it. Read it as a coverage checklist: a source that is missing from your environment leaves a gap in detection, especially for sanctioned SaaS and cloud services where audit logs may be the only record of an upload.
| Telemetry source | ATT&CK data component | What it can reveal | Open-source collection |
|---|---|---|---|
| Network traffic content | Network Traffic Content (DC0085) | Payload-level evidence of uploads to cloud storage endpoints, where inspection is permitted and TLS is terminated or decrypted | Zeek or Suricata sensors feeding Security Onion |
| Network traffic flow | Network Traffic Flow (DC0078) | Sustained outbound volume from internal hosts to cloud provider address ranges, even when content is encrypted | Zeek connection logs or Suricata flow records in Security Onion |
| Network connection creation | Network Connection Creation (DC0082) | New connections from endpoints or servers to cloud storage or sync domains that do not normally appear in their history | Wazuh agents and Sysmon-style endpoint events, plus Zeek connection logs |
| Application log content | No ID supplied in ATT&CK data components | Upload, share and external-link events inside SaaS and office suite tenants, including the account and file involved | Wazuh log collection from exported audit logs, forwarded through syslog or API pulls |
| Snapshot metadata | No ID supplied in ATT&CK data components | Creation or copying of cloud disk and storage snapshots that are later moved or shared outside the account | Wazuh integrations or cloud-native audit exports, reviewed in Security Onion dashboards |
| Cloud control plane audit logs | Varies by platform, confirm mapping in your ATT&CK version | Storage bucket policy changes, cross-account access grants and API calls that expose data to an external identity | Vendor audit trails forwarded to Wazuh for correlation |
| Identity and sign-in logs | Varies by platform, confirm mapping in your ATT&CK version | Unusual sign-ins or new tokens that precede bulk transfers to a cloud account | Wazuh ingestion of identity provider exports |
Detection logic for T1537 transfer data to cloud account
T1537 covers data moved into cloud storage, SaaS or Office Suite tenants that the organization does not control. The cards below pair each detection idea with its tuning baseline and the benign activity most likely to trigger it, so the team can separate adversary staging from routine sync and backup traffic.
Outbound volume to cloud storage
Track bytes sent from each host or service account to known cloud storage and file-sharing domains, compared with that asset's own rolling baseline over a comparable period. The signal is a sustained rise in upload volume from a host that normally uploads little, especially outside business hours. Tune thresholds per asset group rather than per organization, because build servers and file servers behave differently. Common false positives include backup agents, sync clients, large media uploads and scheduled software update downloads that run in the opposite direction.
Uploads to unapproved tenants
Maintain an inventory of approved cloud tenant identifiers for each sanctioned storage and SaaS service, then flag uploads to tenants or accounts that are not on that list. This matters for T1537 because an adversary may use a personal or attacker-controlled tenant on a service the organization already allows. Confirm with your proxy, CASB or DNS logs whether tenant identifiers are visible in your environment before relying on this logic. Common false positives include new business units onboarding a sanctioned service that has not yet been added to the inventory.
New OAuth grants before large writes
Correlate new OAuth consents, API client registrations or service principal creation in cloud identity logs with subsequent high-volume write or download events from the same identity within a short window. A new client that begins writing many objects shortly after being granted access deserves review, particularly when the grant requests broad file or mailbox scopes. Common false positives include approved integrations, backup vendors and developer tooling that legitimately register new clients during rollout.
Bulk sharing and external links
In Office Suite and SaaS audit logs, alert on spikes in sharing actions, anyone-with-link creation and external collaborator invitations by a single user or application within a short period. Compare the count with that user's historical sharing pattern and the sensitivity labels on the affected files. Common false positives include project handovers, legitimate client collaboration and migration tools that create many shares in one batch, so route these alerts to the data owner for confirmation before escalation.
Validating a T1537 transfer data to cloud account detection
This sequence proves, in an authorized lab or cyber range, that each T1537 detection sees a benign transfer to a cloud account, fires with the expected fields, and produces alert data your team can tune before it relies on the rule in production.
Authorize and scope the emulation in writing
The security lead, the owner of the test cloud tenant and the SOC manager agree in writing on the scope, the systems in bounds, the test accounts, the window, the stop conditions and who can halt the exercise. Only benign, pre-agreed data is used, and no real customer or production data leaves the environment. Record the ATT&CK version the detections target, for example the Enterprise ATT&CK version your detection mappings name, so later reviewers know which technique definition was tested. The step is done when the signed scope document and the rules of engagement are stored with the test record.
Agree the emulation plan and expected signals
The red or purple team lead and the detection engineer write a short emulation plan that lists the cloud service categories in scope, such as IaaS storage, an office suite or a SaaS file-sharing service, and the benign transfer each one will receive. For every planned transfer, the detection engineer records the expected telemetry: which Network Traffic Content, Application Log Content and Snapshot Metadata records should appear, and which fields each detection should populate, such as the account, the destination tenant and the object name. The step is done when every planned transfer has a matching expected-signal entry.
Run the approved benign transfer
The operator performs the agreed benign data transfer from a designated test account to a test cloud tenant that the organization controls, using only the methods listed in the plan. The operator logs the exact start and end times, the account used, the source host, the destination tenant and the object identifiers in a shared exercise log, so every later check can be matched to a known event. The step is done when the exercise log holds one complete entry per planned transfer and the operator confirms that no unplanned data was moved.
Confirm each telemetry source recorded the transfer
The detection engineer searches each log source in the SIEM or data lake, such as network sensor content, cloud or SaaS audit logs, and the storage or snapshot metadata feed, using the timestamps and identifiers from the exercise log. For each source, the engineer notes whether the transfer appears, the delay between event and ingestion, and any fields that are missing or parsed incorrectly. Gaps are logged as collection issues with an owner, not silently accepted. The step is done when every source in the plan has a yes or no result, with ingestion lag recorded for each.
Check that each detection fires with expected fields
The detection engineer runs or reviews each T1537 detection rule against the captured events and checks that it fires for the planned transfers and only for them. The engineer verifies that the alert carries the expected fields, such as the initiating account, the destination tenant, the object and the time, because responders depend on these to triage. If a rule does not fire, the engineer determines whether the cause is the telemetry, the logic or the field mapping, and records that finding against the rule version. The step is done when each rule has a documented fire or no-fire result tied to a specific planned transfer.
Record timings, alert counts and false positives
The detection engineer compiles a results sheet that lists, for each rule, the time from transfer to ingestion, the time from ingestion to alert, the alert count and any alerts that do not match a planned transfer. Each unexpected alert is traced to its cause, such as a sanctioned sync job or a backup tool, and either tuned with a documented exception or accepted with an owner. The step is done when the results sheet is reviewed by the SOC lead and every false positive has a recorded disposition.
Close out, tune and retest after changes
The team reviews the results with the SOC lead, the cloud owner and the data protection or compliance contact, then decides which rules are ready, which need tuning and which need new telemetry. Changes are recorded against the rule version, and the emulation is rerun for any changed rule or log source before it is treated as validated. The team also confirms the Data Loss Prevention and User Account Management controls referenced in the detection design were checked in the same window, where they were in scope. The step is done when the signed validation report, the open issues list and the retest schedule are filed with the exercise record.
Triage and response when a cloud transfer alert fires
Start triage by answering one question: is the destination an account your organization owns and governs? Confirm the destination tenant or account identifier against your asset inventory and your approved cloud list, then check who owns it. An upload to a personal consumer storage account, an unknown tenant, or a partner tenant that no one has sponsored is a stronger signal than an upload to a sanctioned workspace, even when the volume looks small. Next, examine the identity and session behind the transfer: the user or workload identity, the authentication method, the device or network origin, whether the session was created recently or from an unusual location, and whether the account has recent privilege or role changes. Record these facts before you change anything, because they decide whether you are looking at an insider action, a compromised account or a misconfigured sync client.
Decide early whether the data class makes this an incident. Map the files or objects involved to your data classification scheme and to any contractual or regulatory obligations for that data, such as customer records, payment data, health information or source code. A transfer of public marketing material is a policy exception; a transfer of regulated personal data is an incident candidate even if the user says the upload was accidental. Before containment, preserve the evidence: export the relevant cloud audit logs (control plane and data plane events for the storage or SaaS service), proxy and secure web gateway logs, DLP events and endpoint records for the same window. Confirm with each provider which log categories you are entitled to export and how long they are retained, since some are short-lived and must be pulled promptly.
Containment should be proportionate and reversible where possible. Revoke active sessions, refresh tokens and API keys tied to the identity, and force re-authentication, but first confirm with the account owner or manager that revocation will not disrupt a business-critical process. Block the destination through controls you already operate, such as a proxy or firewall category or domain rule, a DLP destination policy or a cloud access security broker policy, and avoid building new bespoke blocks during an incident. Notify the data owner and the privacy or legal function as soon as the data class is confirmed, and let them decide on external notification timelines. Record every action with a timestamp so the post-incident review can show what was contained, when and by whom. Confirm the exact revocation and blocking capabilities of each platform in your environment with its vendor documentation before you rely on them in a runbook.
Rehearsing T1537 transfer data to cloud account in a cyber range
In an IaaS range, the team builds a test cloud account or subscription that mirrors production logging and storage patterns, with seeded sample data in object storage and a sensor path for control plane and network events. The goal is to confirm that a transfer of data from an authorized bucket or volume to an external cloud account is visible, attributable and containable. Use synthetic data only, and confirm with the provider which audit log categories and snapshot or sharing events are available on your service tier.
- Range setup: Create a sandboxed test account with a seeded storage bucket, a non-production identity with narrow permissions, and a log pipeline forwarding control plane audit logs and flow logs to your SIEM, such as Wazuh or Security Onion.
- Injects: Have the red team, operating under written rules of engagement, copy seeded data to a second test account the range does not own, and cross-account snapshot sharing to an unlisted principal.
- Expected detection: An alert on the cross-account grant or copy event, linked to the identity that performed it, with the destination account identifier included in the alert.
- Response record: Triage notes stating the source, destination, identity and time window, plus a containment action such as revoking the grant and disabling the identity, logged with timestamps.
- Good performance: Alert within the time your runbook sets as the target, a clean containment record, and no false closure of an authorized backup job as an incident.
Before running, confirm with your provider which events are retained, how long, and whether they are delivered in near real time.
In an Office Suite range, the team uses a test tenant with seeded mailboxes, shared drives and document libraries. The focus is on sharing and external transfer events, such as links shared outside the organization, mail forwarding to an external domain, or synchronization of a library to an unmanaged device. Tenant audit logs and data loss prevention alerts are the main evidence, so validate that they reach the collector before the exercise starts.
- Range setup: Provision a test tenant with a seeded library, a sample mailbox, and a sensitivity label applied to synthetic records, with unified audit logging enabled and forwarded to your SIEM.
- Injects: Simulate a user creating an anonymous or external sharing link to a seeded document, and a rule forwarding messages to an external test domain.
- Expected detection: Alerts on external sharing and forwarding events, with the document or mailbox, the sharing scope and the creating identity captured.
- Response record: Triage notes that separate sanctioned external collaboration from unexpected transfer, then removal of the link or forwarding rule and a note on whether the data was labeled.
- Good performance: Events correlated to the correct user, a documented decision on whether the share was approved, and containment recorded with the actions taken.
Confirm with the vendor which sharing and forwarding events appear in your license tier and how quickly they are available to your collector.
SaaS ranges test transfers that occur through business applications, such as a CRM export, an bulk download from a collaboration platform, or an integration that pushes records to a third-party service. The telemetry is usually application audit logs plus identity provider sign-in records, which means the team must correlate across two sources. Seed the test application with fictitious customer records and confirm that the export and integration events are logged at the level you need.
- Range setup: Create a test workspace in each application with synthetic records, a service integration to a test external endpoint, and application audit logs plus identity provider sign-in logs forwarded to one correlation point.
- Injects: Run a bulk export of seeded records by a test user at an unusual hour, and add a new API token or integration pointing to an endpoint outside the approved list.
- Expected detection: An alert on the bulk export or new integration, correlated with an unfamiliar sign-in context if the scenario includes one.
- Response record: Triage notes stating the application, record volume, integration target and identity, followed by revocation of the token and suspension of the session.
- Good performance: Correlation of application and identity events within the target window, accurate volume reporting, and a containment entry that the application owner can review.
Check with each application owner which export and integration events are logged, and whether volume figures are available for the alert.
Which mitigations reduce T1537 exposure
T1537 Transfer data to cloud account is hard to stop with network controls alone, because the destination is a sanctioned-looking cloud service that the attacker controls through a legitimate identity. The two ATT&CK mitigations below act on the two conditions that make the technique work: data leaving toward unsanctioned destinations, and accounts that can write to cloud storage without a current business need.
Data loss prevention controls
Data Loss Prevention (M1057) is the mitigation most directly aimed at uploads to cloud accounts the organization does not own. Content and destination rules can block or flag transfers of sensitive data to unsanctioned cloud storage, file sharing and SaaS endpoints, and can alert on large or unusual uploads from endpoints and browsers. Confirm which channels your DLP covers (managed endpoints, browser sessions, sync clients, sanctioned cloud tenants and API traffic), whether it inspects TLS-encrypted traffic, and whether tenant restrictions can distinguish your corporate tenant from a personal or foreign tenant. DLP typically cannot see data moved through unmanaged devices or encrypted channels it does not decrypt.
Account lifecycle and cloud admin rights
User Account Management (M1018) limits misuse by controlling who can create, change and use accounts that can reach cloud storage and SaaS data. Review how accounts are provisioned and deprovisioned, remove dormant and orphaned accounts, and restrict cloud and SaaS administrator roles to named people with time-bound elevation. An account that can create storage buckets, invite external users or generate API keys is the path an attacker needs to point data at a cloud account they control. This control cannot see activity inside a valid session, so pair it with the authentication and cloud audit logs described elsewhere on this page.
Egress allowlisting for cloud domains
Restricting outbound connections to a defined list of sanctioned cloud tenants limits which cloud accounts a managed host can reach. This is a filtering decision, mapped in ATT&CK to Filter Network Traffic (M1037) rather than to the two mitigations this section covers, so treat it as a companion control. Confirm that the list is maintained by tenant identifier where the platform allows it, not only by broad domain name, because a shared domain can host many tenants. Confirm also how exceptions are approved and who reviews them. Allowlists do not stop uploads from unmanaged devices or from users connected through personal networks.
Privileged access reviews
Access reviews for cloud and SaaS roles confirm that each standing privilege still has an owner and a business reason. Focus on service accounts and integration tokens, which often outlive the projects that created them and rarely have multi-factor authentication. Ask for the review cadence, who approves exceptions, and whether reviews include OAuth grants to third-party applications. A review does not show what a valid account did between reviews, so it should feed alerting, not replace it.
Dormant account cleanup
Unused accounts give an intruder a quiet identity to reuse. Confirm how the organization identifies accounts with no sign-in for a defined period, how contractor and leaver accounts are closed, and whether shared or break-glass accounts are documented with an owner. Ask whether deprovisioning in the identity provider also removes access to connected SaaS applications, since some applications keep local accounts. Cleanup reduces the attack surface but will not reveal an account that has been used recently by an attacker, so the detection logic in this page still applies.
Questions SOC leads ask about T1537 detection
How do we separate sanctioned sync traffic from real cloud exfiltration?
Start by building a baseline of which sanctioned SaaS and IaaS destinations your users and service accounts normally reach, and how much data they usually move. Sanctioned sync tools tend to show steady, predictable volumes tied to known accounts and devices, while exfiltration often shows unusual volume, off-hours activity, new tenants or personal accounts, or large uploads from users who rarely upload. Treat the baseline as your own: it should come from your environment's telemetry over a representative period, not from a generic threshold. Review each rule against the tenant identifiers and application names your vendor logs actually record.
How do we detect data transfers inside encrypted SaaS traffic?
Most SaaS uploads are encrypted in transit, so network content inspection alone rarely shows what was moved. Detection usually relies on the combination of destination, identity, volume and timing visible in network metadata, proxy or CASB logs, and the SaaS vendor's own audit logs. Where your policy permits TLS inspection for managed endpoints, confirm legal and privacy approval first and check which applications pin certificates and break under inspection. Confirm with each vendor which file, sharing and download events its audit log exposes and what fields identify the user, object and destination.
Which logs should we retain so an T1537 investigation is possible?
Retain the logs that let you answer who moved what, to where, and when. In practice that means identity and authentication events, SaaS audit and file-sharing events, cloud control plane events for snapshot and storage actions, proxy or firewall connection records, and endpoint process records for the sync clients you use. Set retention with your legal and compliance owners, since the right period depends on your regulatory obligations and internal policy. Verify that vendor logs are exported to your SIEM before you need them, because some audit trails have short native retention.
How often should we retest T1537 detections after an ATT&CK release?
Retest whenever the ATT&CK version your detections target changes, and record the version in each rule's metadata. MITRE publishes releases with renamed, deprecated or revoked content, and ATT&CK v18 moved detections into detection strategies and analytics, so mappings written against earlier versions need review. Beyond release-driven reviews, schedule regular validation runs in a private cyber range and after major changes to your SaaS or cloud estate. Confirm your testing cadence with your security governance owners, since it should reflect your risk appetite and change volume.
How do we find and handle shadow SaaS used for data transfer?
Shadow SaaS is usually found by reviewing DNS, proxy and firewall records for destinations that no approved application uses, then grouping them by user population and data volume. Once you know which unsanctioned services receive data, decide whether each should be blocked, brought under governance or accepted with conditions. Coordinate with HR, legal and the business owners before taking action against individuals, because many cases are workflow gaps rather than intent. Keep the discovery process repeatable so new services are caught as they appear.
Which ATT&CK mitigations should we check for T1537 coverage?
Check two mitigations first: Data Loss Prevention (M1057) and User Account Management (M1018). Data Loss Prevention capability depends on what your SaaS and endpoint platforms can enforce, such as blocking uploads to unapproved tenants or restricting sharing outside the organization. User Account Management covers how accounts, service identities and permissions are created, reviewed and removed, which limits what a compromised account can move. Confirm with each platform owner which controls are native, which need licensing or add-ons, and which are unavailable in your environment.
How do we rehearse T1537 detection in a cyber range without disrupting production?
Run the rehearsal in a private cyber range that mirrors your SaaS, identity and logging stack using test tenants and synthetic data. Define the expected detection outcome for each scenario before the exercise, then compare the alerts that fire with what your SIEM and case tools record. Record gaps in field mapping, time synchronization and alert routing, not only missed alerts. Confirm with your vendors which test accounts and API limits are allowed so the exercise does not breach their terms of service.
How DeployOpen builds T1537 detections and cyber range exercises
DeployOpen works on T1537 Transfer data to cloud account as a self-hosted implementation and testing engagement inside the client's own cloud accounts or networks. Each step is agreed in writing, so the detection logic, telemetry sources and rehearsal plan match the cloud platforms the organization actually runs.
How we scope
- Confirm which IaaS, Office Suite and SaaS platforms are in scope for cloud upload monitoring.
- Inventory the approved cloud storage tenants and sanctioned accounts that users may legitimately reach.
- Agree in writing which telemetry sources, such as network content and application logs, the detection will use.
How we build
- Map detection logic to the ATT&CK version the client targets, recording the version in every rule.
- Build open-source detections in Wazuh or Sigma format, tuned to the client's own log sources and naming.
- Pair the detection with DLP and user account management controls described in the mitigation guidance.
How we hand over
- Deliver rule documentation, test evidence and a clear list of known blind spots for each platform.
- Provide a response runbook covering triage, account containment and evidence preservation steps.
- Run a cyber range exercise with the client's analysts to validate detections before handover.
How we support
- Fixed-scope engagements can be followed by ongoing support available as a retainer.
- Retainers can cover rule updates when ATT&CK releases rename, deprecate or revoke related techniques.
- Ask any provider to confirm how they will retest detections after platform changes in your environment.
