AzCopy or Azure Storage Explorer Usage on Unusual Host

Identifies the first time, in a historical window, a host runs AzCopy copy or sync to Azure Blob, Data Lake, or File storage, or starts Azure Storage Explorer. These Microsoft utilities are legitimate data-transfer tools; ransomware and cloud-ransomware operators drop portable copies and use SAS-authenticated jobs to pull data from victim storage and push it to attacker-controlled accounts.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/09/09"
  3integration = ["endpoint", "windows", "m365_defender", "crowdstrike"]
  4maturity = "production"
  5updated_date = "2026/09/09"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies the first time, in a historical window, a host runs AzCopy copy or sync to Azure Blob, Data Lake, or File
 11storage, or starts Azure Storage Explorer. These Microsoft utilities are legitimate data-transfer tools; ransomware and
 12cloud-ransomware operators drop portable copies and use SAS-authenticated jobs to pull data from victim storage and push
 13it to attacker-controlled accounts.
 14"""
 15false_positives = [
 16    "IT or DevOps using AzCopy for authorized migrations on a host that has not used it in the history window.",
 17    "Users launching Azure Storage Explorer (including the installer) for the first time on a host.",
 18]
 19from = "now-9m"
 20index = [
 21    "logs-crowdstrike.fdr*",
 22    "logs-endpoint.events.process-*",
 23    "logs-m365_defender.event-*",
 24    "logs-windows.sysmon_operational-*",
 25]
 26language = "kuery"
 27license = "Elastic License v2"
 28name = "AzCopy or Azure Storage Explorer Usage on Unusual Host"
 29note = """## Triage and analysis
 30
 31### Investigating AzCopy or Azure Storage Explorer Usage on Unusual Host
 32
 33AzCopy and Azure Storage Explorer are Microsoft utilities for moving data to and from Azure Storage. Threat actors abuse them as living-off-the-land binaries: they run `azcopy copy` with SAS URLs against `*.blob.core.windows.net` (GetBlob from a victim account, PutBlob to an attacker account, or Blob-to-Blob between them) and launch Storage Explorer to browse or move the same data. CISA's Rhysida advisory is one example of that tradecraft.
 34
 35This is a new-terms rule: it alerts the first time a `host.id` matches in the history window (7 days). AzCopy `copy`/`sync` whose command line includes an Azure Storage hostname, or Storage Explorer (`StorageExplorer.exe`, `StorageExplorer-windows-x64.exe`, `StorageExplorer-windows-arm64.exe`, `StorageExplorer-windowsx64.exe`), fires once per host. Recurring use on the same host will not re-alert until the history window expires.
 36
 37### Possible investigation steps
 38
 39- Confirm which utility fired the alert. For AzCopy, inspect `process.command_line` for `copy` vs `sync`, `--from-to` (`BlobLocal`, `LocalBlob`, `BlobBlob`), and the SAS URL host, container, and `sp`/`se` parameters. For Storage Explorer, note the installer vs application name and silent-install flags such as `/VERYSILENT`.
 40- Identify source and destination. AzCopy command lines often contain a local path and one or two `https://<account>.blob.core.windows.net/...` URLs. Treat Blob-to-Blob copies as direct tenant-to-attacker movement even when no files touch disk.
 41- Check `process.executable` and `process.parent.executable`. A copy from a user-writable or staging path, especially spawned by PowerShell or a scripting host, is more suspicious than a packaged install.
 42- Compare `process.name` with `process.pe.original_file_name` and `process.code_signature.subject_name`. A Microsoft-signed binary from an unusual path is still the Rhysida/Storm-0501 tradecraft; a renamed unsigned copy is additional evasion.
 43- Pivot to Azure Storage diagnostic logs for the same window: GetBlob, PutBlob, and BlobBlob with user agent `AzCopy*` or `Microsoft Azure Storage Explorer*` and SAS authentication. Correlate with the SIEM rule "Azure Storage Blob Retrieval via AzCopy".
 44- Review network telemetry from the same `process.entity_id` to `*.blob.core.windows.net` or `*.dfs.core.windows.net` and estimate volume.
 45- Hunt sibling activity on the host: other Azure LOLBINs, rclone, or bulk archive creation preceding the copy.
 46
 47### False positive analysis
 48
 49- Authorized AzCopy migrations and first-time Storage Explorer use on a host will match. This rule alerts only the first time a given `host.id` matches within 7 days; allowlist by host, user, or approved destination if that first alert is expected.
 50- Do not treat a trusted Microsoft signature as benign by itself; CISA's Rhysida advisory describes the official AzCopy and Storage Explorer binaries.
 51
 52### Response and remediation
 53
 54- If exfiltration is confirmed, isolate the host, stop AzCopy and Storage Explorer processes, and preserve the command line (SAS URLs are credentials).
 55- Revoke the SAS tokens and account keys that appear in the command line; rotate storage account keys and any related Entra ID credentials.
 56- Identify which blobs were read or written (GetBlob/PutBlob/ListBlobs for the same account and time window) and assess data exposure.
 57- Remove staged binaries under unusual paths and investigate how they were delivered.
 58- Hunt for additional AzCopy, Storage Explorer, or rclone activity on other hosts in the same window.
 59
 60### Related rules
 61
 62- Azure Storage Blob Retrieval via AzCopy: cloud-side GetBlob with AzCopy user agent and SAS authentication.
 63- Potential Data Exfiltration via Rclone: similar endpoint abuse of a different cloud-sync utility.
 64"""
 65references = [
 66    "https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-319a",
 67    "https://www.cisa.gov/sites/default/files/2025-04/aa23-319a-stopransomware-rhysida-ransomware_2.pdf",
 68    "https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10",
 69    "https://learn.microsoft.com/en-us/azure/storage/storage-explorer/vs-azure-tools-storage-explorer-blobs",
 70    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
 71]
 72risk_score = 47
 73rule_id = "7265f4fa-4839-4399-924c-a91f1e45d76c"
 74setup = """## Setup
 75
 76This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
 77
 78Setup instructions: https://ela.st/install-elastic-defend
 79
 80### Additional data sources
 81
 82This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
 83
 84- [CrowdStrike](https://ela.st/crowdstrike-integration)
 85- [Microsoft Defender XDR](https://ela.st/m365-defender)
 86- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
 87"""
 88severity = "medium"
 89tags = [
 90    "Domain: Endpoint",
 91    "OS: Windows",
 92    "Platform: Windows",
 93    "Use Case: Threat Detection",
 94    "Tactic: Exfiltration",
 95    "Tactic: Collection",
 96    "Tactic: Execution",
 97    "Rule Type: New Terms",
 98    "Threat: Rhysida",
 99    "Use Case: Ransomware",
100    "Resources: Investigation Guide",
101    "Data Source: Elastic Defend",
102    "Data Source: Sysmon",
103    "Data Source: Microsoft Defender XDR",
104    "Data Source: Crowdstrike",
105]
106timestamp_override = "event.ingested"
107type = "new_terms"
108
109query = '''
110host.os.type:windows and event.category:process and event.type:start and
111(
112  (
113    (process.name:"azcopy.exe" or process.pe.original_file_name:"azcopy.exe") and
114    process.args:("copy" or "sync") and
115    process.command_line:(*blob.core.windows.net* or *dfs.core.windows.net* or *file.core.windows.net* or *blob.storage.azure.net*)
116  ) or
117  process.name:("StorageExplorer.exe" or "StorageExplorer-windows-x64.exe" or "StorageExplorer-windows-arm64.exe" or "StorageExplorer-windowsx64.exe")
118)
119'''
120
121
122[[rule.threat]]
123framework = "MITRE ATT&CK"
124[[rule.threat.technique]]
125id = "T1567"
126name = "Exfiltration Over Web Service"
127reference = "https://attack.mitre.org/techniques/T1567/"
128[[rule.threat.technique.subtechnique]]
129id = "T1567.002"
130name = "Exfiltration to Cloud Storage"
131reference = "https://attack.mitre.org/techniques/T1567/002/"
132
133
134
135[rule.threat.tactic]
136id = "TA0010"
137name = "Exfiltration"
138reference = "https://attack.mitre.org/tactics/TA0010/"
139[[rule.threat]]
140framework = "MITRE ATT&CK"
141[[rule.threat.technique]]
142id = "T1530"
143name = "Data from Cloud Storage"
144reference = "https://attack.mitre.org/techniques/T1530/"
145
146
147[rule.threat.tactic]
148id = "TA0009"
149name = "Collection"
150reference = "https://attack.mitre.org/tactics/TA0009/"
151[[rule.threat]]
152framework = "MITRE ATT&CK"
153[[rule.threat.technique]]
154id = "T1059"
155name = "Command and Scripting Interpreter"
156reference = "https://attack.mitre.org/techniques/T1059/"
157[[rule.threat.technique.subtechnique]]
158id = "T1059.009"
159name = "Cloud API"
160reference = "https://attack.mitre.org/techniques/T1059/009/"
161
162
163
164[rule.threat.tactic]
165id = "TA0002"
166name = "Execution"
167reference = "https://attack.mitre.org/tactics/TA0002/"
168
169[rule.new_terms]
170field = "new_terms_fields"
171value = ["host.id"]
172[[rule.new_terms.history_window_start]]
173field = "history_window_start"
174value = "now-7d"

Triage and analysis

Investigating AzCopy or Azure Storage Explorer Usage on Unusual Host

AzCopy and Azure Storage Explorer are Microsoft utilities for moving data to and from Azure Storage. Threat actors abuse them as living-off-the-land binaries: they run azcopy copy with SAS URLs against *.blob.core.windows.net (GetBlob from a victim account, PutBlob to an attacker account, or Blob-to-Blob between them) and launch Storage Explorer to browse or move the same data. CISA's Rhysida advisory is one example of that tradecraft.

This is a new-terms rule: it alerts the first time a host.id matches in the history window (7 days). AzCopy copy/sync whose command line includes an Azure Storage hostname, or Storage Explorer (StorageExplorer.exe, StorageExplorer-windows-x64.exe, StorageExplorer-windows-arm64.exe, StorageExplorer-windowsx64.exe), fires once per host. Recurring use on the same host will not re-alert until the history window expires.

Possible investigation steps

  • Confirm which utility fired the alert. For AzCopy, inspect process.command_line for copy vs sync, --from-to (BlobLocal, LocalBlob, BlobBlob), and the SAS URL host, container, and sp/se parameters. For Storage Explorer, note the installer vs application name and silent-install flags such as /VERYSILENT.
  • Identify source and destination. AzCopy command lines often contain a local path and one or two https://<account>.blob.core.windows.net/... URLs. Treat Blob-to-Blob copies as direct tenant-to-attacker movement even when no files touch disk.
  • Check process.executable and process.parent.executable. A copy from a user-writable or staging path, especially spawned by PowerShell or a scripting host, is more suspicious than a packaged install.
  • Compare process.name with process.pe.original_file_name and process.code_signature.subject_name. A Microsoft-signed binary from an unusual path is still the Rhysida/Storm-0501 tradecraft; a renamed unsigned copy is additional evasion.
  • Pivot to Azure Storage diagnostic logs for the same window: GetBlob, PutBlob, and BlobBlob with user agent AzCopy* or Microsoft Azure Storage Explorer* and SAS authentication. Correlate with the SIEM rule "Azure Storage Blob Retrieval via AzCopy".
  • Review network telemetry from the same process.entity_id to *.blob.core.windows.net or *.dfs.core.windows.net and estimate volume.
  • Hunt sibling activity on the host: other Azure LOLBINs, rclone, or bulk archive creation preceding the copy.

False positive analysis

  • Authorized AzCopy migrations and first-time Storage Explorer use on a host will match. This rule alerts only the first time a given host.id matches within 7 days; allowlist by host, user, or approved destination if that first alert is expected.
  • Do not treat a trusted Microsoft signature as benign by itself; CISA's Rhysida advisory describes the official AzCopy and Storage Explorer binaries.

Response and remediation

  • If exfiltration is confirmed, isolate the host, stop AzCopy and Storage Explorer processes, and preserve the command line (SAS URLs are credentials).
  • Revoke the SAS tokens and account keys that appear in the command line; rotate storage account keys and any related Entra ID credentials.
  • Identify which blobs were read or written (GetBlob/PutBlob/ListBlobs for the same account and time window) and assess data exposure.
  • Remove staged binaries under unusual paths and investigate how they were delivered.
  • Hunt for additional AzCopy, Storage Explorer, or rclone activity on other hosts in the same window.
  • Azure Storage Blob Retrieval via AzCopy: cloud-side GetBlob with AzCopy user agent and SAS authentication.
  • Potential Data Exfiltration via Rclone: similar endpoint abuse of a different cloud-sync utility.

References

Related rules

to-top