文章总结： 本文系统剖析了AzureBlobStorage勒索软件的四种攻击路径：客户端加密、客户提供的密钥（CPK）、加密作用域和服务端加密（CMK），详细说明了每种方法所需权限、操作步骤及检测事件代码。文章指出方法1和3已有在野利用案例，并分析了AzureKeyVault软删除保护机制的绕过方式，为防御者提供了具体的事件日志监控建议。 综合评分： 85 文章分类： 云安全,漏洞分析,威胁情报,解决方案,数据安全
Azure Blob Storage勒索软件攻击路径剖析
Dubito Dubito
云原生安全指北
2026年6月18日 08:35 江苏
在小说阅读器读本章
去阅读
注：本文翻译自 Datadog 的文章《Holding blobs for ransom: Four methods for Azure Storage ransomware》[1]，可点击文末“阅读原文”按钮查看英文原文。
一、概述
迄今为止，大多数云存储勒索软件研究[2]主要聚焦于 AWS S3 的滥用，而对 Azure Blob Storage 的关注则相对少得多。现有的公开研究往往只涉及一两种技术，且通常缺少技术细节说明以及相关操作的事件代码。
本文将探讨攻击者滥用 Azure Storage 恶意加密受害者 Blob 的四种途径，包括逐步操作说明和用于检测的事件代码。其中方法 1 和方法 3 已有在野利用案例，而方法 2 和方法 4 尚未在公开报告中观察到。我们还将讨论 Azure 针对加密滥用的一些防护措施，以及如何绕过这些措施。
二、勒索软件方法
| | 客户端加密 | 客户提供的密钥 | 加密作用域 | 服务端加密（CMK） | | — | — | — | — | — | | Storage 数据层面权限 | ✅ | ✅ | ✅ | ❌ | | Key Vault 数据层面权限 | ❌ | ❌ | ✅ | ✅ | | 控制层面权限 | ❌ | ❌ | ✅ | ✅ | | 可记录日志 | ❌ | ❌ | 部分 | ✅ | | 有在野利用观察 | ✅ | ❌ | ✅ | ❌ |
2.1 方法 1：客户端加密
2023 年，Sophos X-Ops 报道[3]称 BlackCat 勒索软件团伙通过 Sphynx 加密程序对受害者 Azure Storage 账户中的 Blob 进行加密，从而实施勒索。其操作方式是：批量下载 Blob，加密后再重新上传以覆盖原始数据。这种方法类似于“传统”勒索软件，只是目标从文件系统换成了 Azure Storage。实际上并未使用任何 Azure 原生的加密功能。
该方法仅需获取受害者存储账户的数据层面权限，不需要订阅级别的控制层面权限。攻陷一个存储账户访问密钥（access key）就足以实施攻击。
Storage 资源日志事件代码
- •
GetBlob - •
PutBlob
2.2 方法 2：客户提供的密钥（CPK）
2025 年 1 月，Halcyon 报道[4]称，一个名为 Codefinger 的攻击者通过滥用 AWS S3 的客户提供的服务器端加密（SSE-C）功能开展勒索活动。Azure Storage 也提供了类似功能：客户提供的密钥（CPK）[5]。通过在 Blob 请求的 HTTP 头中填入 x-ms-encryption-key、x-ms-encryption-key-sha256 和 x-ms-encryption-algorithm，即可在上传时加密 Blob，在下载时解密 Blob。
curl 请求示例：
curl -X PUT "https://${ACCOUNT}.blob.core.windows.net/${CONTAINER}/${BLOB}" \
-H "Authorization: Bearer ${ACCESS_TOKEN}" \
-H "x-ms-version: 2025-01-05" \
-H "x-ms-date: $(date -u +'%a, %d %b %Y %H:%M:%S GMT')" \
-H "x-ms-blob-type: BlockBlob" \
-H "Content-Type: text/plain" \
-H "Content-Length: 13" \
-H "x-ms-encryption-key: ${ENCRYPTION_KEY}" \
-H "x-ms-encryption-key-sha256: ${ENCRYPTION_KEY_SHA256}" \
-H "x-ms-encryption-algorithm: AES256" \
--data-binary "Hello, world!"
攻击者可滥用此功能：批量下载 Blob，然后使用 CPK 重新上传，导致受害者无法访问数据，随后索要赎金以换取 AES-256 密钥。该加密密钥从未进入受害者的 Azure 环境，因此客户端无法恢复加密数据。
Azure 门户错误提示：使用客户提供的密钥加密的 Blob 在缺少该密钥时无法访问
与 AWS SSE-C 不同，Azure 资源日志不会记录 x-ms-encryption-key-sha256 头，这使得在 SIEM 中难以检测到使用 CPK 的情况。使用 CPK 的 PutBlob 请求日志与“普通”PutBlob 请求日志看上去完全一致。
2025 年 11 月，AWS 宣布[6]将于 2026 年 4 月弃用 SSE-C，原因是使用率低且存在安全隐患。然而，Azure 目前仍完全支持客户提供的加密密钥。
与客户端加密类似，CPK 仅需要数据层面权限。
Storage 资源日志事件代码
- •
GetBlob - •
PutBlob
2.3 方法 3：加密作用域
Azure 加密作用域（Encryption Scope）[7]允许用户使用不同于存储账户默认 Azure 托管密钥的密钥，对 Blob 进行服务端加密。可以创建使用客户托管 Key Vault 密钥的作用域，也可以创建使用新的 Azure 托管密钥的作用域。之后，该作用域可被应用到新建的存储账户或容器中，也可在单个 Blob 的上传/下载时指定。
滥用加密作用域是 Azure Storage 勒索软件中报道最为广泛的策略。微软发布了详细报告[8]（译文详见：云勒索新时代：Storm-0501滥用云原生功能实施数据加密勒索），披露 STORM-0501 利用加密作用域向受害者勒索赎金。在攻陷之后，其攻击链大致如下：
- • 攻击者在受害者租户中创建新的 Azure Key Vault
- • 攻击者在 Key Vault 中创建加密密钥，并在本地下载一份副本
- • 攻击者在受害者存储账户中创建加密作用域，并使用新创建的密钥
- • 攻击者使用该加密作用域加密受害者数据
- • 攻击者删除加密密钥和/或 Key Vault，使存储数据无法访问
- • 攻击者向受害者索要赎金，以换取被删除的密钥
遗憾的是，微软报告对加密作用域具体如何用于加密受害者 Blob 的描述比较模糊。加密作用域不会追溯加密已有 Blob，仅作用于未来创建的 Blob。此外，加密作用域只能在存储账户或容器创建时被设置为默认加密方式。要在账户/容器创建之后使用加密作用域，Blob 的 API 请求必须在 HTTP 头中设置 x-ms-encryption-scope，指向新创建的加密作用域。要加密已有 Blob，攻击者必须下载账户中的所有 Blob，然后使用 x-ms-encryption-scope 头重新上传，这与前两种方法类似。
curl -X PUT "https://${ACCOUNT}.blob.core.windows.net/${CONTAINER}/${BLOB}" \
-H "Authorization: Bearer ${ACCESS_TOKEN}" \
-H "x-ms-version: 2025-01-05" \
-H "x-ms-date: $(date -u +'%a, %d %b %Y %H:%M:%S GMT')" \
-H "x-ms-blob-type: BlockBlob" \
-H "Content-Type: text/plain" \
-H "Content-Length: ${#BODY}" \
-H "x-ms-encryption-scope: ${ENCRYPTION_SCOPE}" \
--data-binary "${BODY}"
另外，攻击者也可以新建存储账户或容器，将其默认加密方式设为攻击者创建的加密作用域，然后使用 CopyBlob 将 Blob 或容器迁移到新账户/容器中。这样它们就会被加密作用域使用的密钥加密。不过，需要删除原始 Blob，才能让受害者无法访问数据。
Azure 要求在存储加密操作中使用的 Key Vault 必须启用软删除保护。微软报告明确指出，STORM-0501 恶意加密的 Blob 由于这些保护机制，仍然可以被恢复。这些软删除保护也可以被绕过，我们将在后文讨论。
此方法需要同时具备广泛的控制层面和数据层面权限。控制层面权限用于创建加密作用域和 Key Vault，数据层面权限则用于创建加密密钥以及下载/重新上传 Blob。
鉴于上述种种复杂性，这种策略竟然成为攻击者的首选方法，确实令人意外。
加密作用域的创建会记录在 Azure Activity 日志中；但是，存储操作中使用加密作用域的行为不会被记录在存储资源日志中。与 CPK 类似，使用加密作用域的 PutBlob 请求与“普通”PutBlob 请求的日志记录完全一致。
Azure Activity 日志事件代码
- •
Microsoft.Storage/storageAccounts/encryptionScopes/write - •
Microsoft.KeyVault/vaults/write - •
Microsoft.KeyVault/vaults/delete - •
Microsoft.Authorization/roleAssignments/write（用于为存储账户的托管身份分配权限）
Storage 资源日志事件代码
- •
GetBlob - •
PutBlob
Key Vault 资源日志事件代码
- •
KeyCreate - •
KeyDelete
2.4 方法 4：使用客户托管密钥对存储服务进行加密
默认情况下，Azure 使用 Azure 托管服务端密钥对所有存储账户对象进行静态加密。服务端加密并非直接加密 Blob，而是用客户托管密钥包裹（wrap）现有的 Azure 托管密钥[9]。攻击者可利用这一点（方法类似于加密作用域方案）：在 Key Vault 中创建密钥，将 Storage 服务加密指向该新密钥，然后删除该密钥或 Key Vault。由于 Azure 无法解包其托管密钥，尝试检索 Blob 时会返回类似以下错误：
Azure 门户错误提示：用于存储服务加密的客户托管密钥被删除后，Blob 数据无法访问
与本文列举的其他方法相比，此方法颇具吸引力。只需对 Azure Storage 进行一次 API 调用即可使数据无法访问，无需进行可能触发警报的大规模下载和上传操作。不需要存储账户的数据层面权限。不过，截至目前尚无公开报道显示该策略已被在野利用。
curl -X PATCH \
"https://management.azure.com/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Storage/storageAccounts/${STORAGE_ACCOUNT}?api-version=2023-05-01" \
-H "Authorization: Bearer ${ACCESS_TOKEN}" \
-H "Content-Type: application/json" \
-d @- <<EOF
{
"identity": {
"type": "SystemAssigned"
},
"properties": {
"encryption": {
"keySource": "Microsoft.Keyvault",
"keyvaultproperties": {
"keyvaulturi": "${KEY_VAULT_URI}",
"keyname": "${KEY_NAME}",
"keyversion": "${KEY_VERSION}"
}
}
}
}
EOF
此方法有一个与加密作用域方法相同的重大缺陷：微软要求所有用于 Azure Storage CMK 加密的 Key Vault 必须启用软删除策略，这意味着即使密钥被删除，受害者仍可恢复该密钥（以及其加密的 Blob）。不过，在下一节中，我们将讨论如何绕过这些保护机制。
Azure Activity 日志事件代码
- •
Microsoft.Storage/storageAccounts/write，其中properties.requestbody.properties.encryption.keySource为Microsoft.Keyvault - •
Microsoft.KeyVault/vaults/write - •
Microsoft.KeyVault/vaults/delete - •
Microsoft.Authorization/roleAssignments/write（用于为存储账户的托管身份分配权限）
Key Vault 资源日志事件代码
- •
KeyCreate - •
KeyDelete
三、Azure Key Vault 保护机制及其绕过方式
如前所述，微软要求所有用于 Azure Storage CMK 加密的 Key Vault 必须启用软删除策略。如果 Key Vault 上未设置现有软删除保护策略，则在将其关联到 Azure 存储账户时，会自动设置为 90 天保留期。此外，微软会自动在保管库上启用清除保护（purge protection），防止软删除的密钥在保留期到期前被永久删除。
攻击者可以在将 Key Vault 关联到存储账户之前，将软删除保留策略设为其最小值 7 天，从而部分绕过该保护。这样，攻击者理论上可以等待保留期结束，待密钥被自动清除后再索要赎金。然而，受害者很可能在生产关键数据不可用时就已经发现问题，并可能在攻击者索要赎金之前恢复 Key Vault（以及 Blob）。
一种更高级的绕过方式是：攻击者在攻击者控制的 Entra 租户中创建 Key Vault，然后使用微软描述的方法[10]在受害者存储账户上实施跨租户 CMK 加密。
微软架构图：使用 CMK 和联合身份跨两个租户的 Azure 静态数据加密架构
攻击者在受害者环境中创建多租户应用，并在攻击者租户中添加对应的服务主体之后，可以通过添加联合凭据[11]在受害者存储账户的托管身份与该应用之间建立信任关系。随后，攻击者只需授予其租户服务主体对 Key Vault 密钥的访问权限，然后将该密钥的 URI 填入受害者的 CMK 配置中即可。
Azure 门户截图：存储账户上的跨租户客户托管密钥配置，包含多租户应用和用户分配托管身份
一旦受害者数据和/或服务端密钥被加密，攻击者可删除其控制的密钥，或直接从攻击者环境中移除该服务主体。虽然密钥仅被软删除，但由于其位于攻击者控制的基础设施中，受害者若不支付赎金将无法恢复该密钥。
此变种方法需要在受害者及攻击者控制的 Entra 租户中都具备较高的控制层面权限，例如需要应用程序管理员（Application Administrator）或全局管理员（Global Administrator）等特权角色。
Entra 事件代码
- •
Add application - •
Update Application，其中properties.targetResources.modifiedProperties.displayName为FederatedIdentityCredentials
四、防范 Azure Storage 勒索软件
微软的 Azure 勒索软件防护指南[12]对此主题有深入介绍，建议与本文一同阅读。
启用 Azure Defender for Storage[13] 以实现存储账户的威胁检测，并通过资源锁[14]、不可变策略[15]和版本控制[16]进行加固，以防止数据被销毁或覆盖。在可行的情况下，避免使用长期凭证（如存储访问密钥或 SAS 令牌），因为它们让攻击者在无需控制层面权限的情况下即可获得持久的数据层面访问能力。
在检测方面，应关注异常的 Blob 上传和下载模式，以及 Key Vault 密钥的快速创建、使用和删除。标记任何指向不熟悉或外部租户中 Key Vault 的 CMK 配置。同时监视存储保护功能的移除操作：
- •
Microsoft.Authorization/locks/delete - •
Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies/delete - •
Microsoft.Storage/storageAccounts/write（其中properties.requestbody.properties.immutabilityPolicy.state为Disabled）
五、使用 Stratus Red Team 模拟 Azure Storage 勒索软件
Stratus Red Team[17] 是一款开源工具，用于在真实云环境中模拟云攻击技术。以下技术对应于本文所述的勒索软件方法：
- • 通过加密作用域（使用客户托管 Key Vault 密钥）实施 Azure Blob Storage 勒索软件[18]
- • 通过客户提供的加密密钥（CPEK）实施 Azure Blob Storage 勒索软件[19]
- • 通过客户托管 Key Vault 密钥及保管库删除实施 Azure Blob Storage 勒索软件[20]
我们以第一种技术为例。首先，使用 Stratus Red Team 创建一个带有 Blob 容器的 Azure 存储账户：
$ stratus warmup azure.impact.blob-ransomware-client-encryption-scope
Checking your authentication against azure
Warming up azure.impact.blob-ransomware-client-encryption-scope
Initializing Terraform
Applying Terraform to spin up technique prerequisites
Storage account stratusrtidsg3a with 5 containers ready. Key Vault stratusrtqwgejtyj ready. Blobs will be created during detonation.
现在我们使用 Stratus Red Team 对目标存储账户执行攻击技术：
$ stratus detonate azure.impact.blob-ransomware-client-encryption-scope
Simulating a ransomware attack on storage account stratusrtidsg3a
Creating 51 fake blobs across 5 containers
Created 51 fake blobs
Enabling purge protection on Key Vault: stratusrtqwgejtyj
Purge protection enabled on Key Vault: stratusrtqwgejtyj
Creating RSA 2048 key in Key Vault: stratusrtqwgejtyj
Created Key Vault key: https://stratusrtqwgejtyj.vault.azure.net/keys/ransom-encryption-key/b4aaac30826542a9bea74346d51bd576
Creating encryption scope: ransom-encryption-scope with key: https://stratusrtqwgejtyj.vault.azure.net/keys/ransom-encryption-key
Created encryption scope: ransom-encryption-scope
Found 51 blobs to encrypt across 5 containers
Re-encrypting all blobs with encryption scope: ransom-encryption-scope
Successfully encrypted all blobs with encryption scope
Soft-deleting key: ransom-encryption-key from vault: stratusrtqwgejtyj
最后，清理模拟过程中创建的所有基础设施：
$ stratus cleanup azure.impact.blob-ransomware-client-encryption-scope
六、结论
关于 CPK 和加密作用域（Encryption Scope）方式的 Blob 加密在日志记录方面的局限性，我们已向微软进行了反馈。
感谢您的阅读！我们非常期待您的反馈。如有任何疑问、想法或建议，请发送邮件至 [email protected][21]，或提交 issue[22]。您也可以订阅我们的通讯或 RSS 源[23]。
引用链接
[1] 《Holding blobs for ransom: Four methods for Azure Storage ransomware》: https://securitylabs.datadoghq.com/articles/azure-blob-storage-ransomware-four-methods/
[2] 大多数云存储勒索软件研究: https://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/
[3] Sophos X-Ops 报道: https://www.bleepingcomputer.com/news/security/blackcat-ransomware-hits-azure-storage-with-sphynx-encryptor/
[4] Halcyon 报道: https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c
[5] 客户提供的密钥（CPK）: https://learn.microsoft.com/en-us/azure/storage/blobs/encryption-customer-provided-keys
[6] AWS 宣布: https://aws.amazon.com/blogs/storage/advanced-notice-amazon-s3-to-disable-the-use-of-sse-c-encryption-by-default-for-all-new-buckets-and-select-existing-buckets-in-april-2026/
[7] Azure 加密作用域（Encryption Scope）: https://learn.microsoft.com/en-us/azure/storage/blobs/encryption-scope-overview
[8] 发布了详细报告: https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/
[9] 用客户托管密钥包裹（wrap）现有的 Azure 托管密钥: https://learn.microsoft.com/en-us/azure/storage/common/customer-managed-keys-overview
[10] 微软描述的方法: https://learn.microsoft.com/en-us/azure/storage/common/customer-managed-keys-configure-cross-tenant-existing-account?toc=%2Fazure%2Fstorage%2Fblobs%2Ftoc.json&bc=%2Fazure%2Fstorage%2Fblobs%2Fbreadcrumb%2Ftoc.json&tabs=azure-portal
[11] 添加联合凭据: https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-create-trust?pivots=identity-wif-apps-methods-azp
[12] Azure 勒索软件防护指南: https://learn.microsoft.com/en-us/azure/security/fundamentals/ransomware-protection
[13] Azure Defender for Storage: https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-storage-introduction
[14] 资源锁: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources?tabs=json
[15] 不可变策略: https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview
[16] 版本控制: https://learn.microsoft.com/en-us/azure/storage/blobs/versioning-overview
[17] Stratus Red Team: https://stratus-red-team.cloud/
[18] 通过加密作用域（使用客户托管 Key Vault 密钥）实施 Azure Blob Storage 勒索软件: https://stratus-red-team.cloud/attack-techniques/azure/azure.impact.blob-ransomware-client-encryption-scope/
[19] 通过客户提供的加密密钥（CPEK）实施 Azure Blob Storage 勒索软件: https://stratus-red-team.cloud/attack-techniques/azure/azure.impact.blob-ransomware-cpek/
[20] 通过客户托管 Key Vault 密钥及保管库删除实施 Azure Blob Storage 勒索软件: https://stratus-red-team.cloud/attack-techniques/azure/azure.impact.blob-ransomware-service-storage-cmk/
[21] [email protected]: mailto:[email protected]
[22] 提交 issue: https://github.com/DataDog/security-labs-pages/issues
[23] RSS 源: https://securitylabs.datadoghq.com/rss/feed.xml
交流群
知识库
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：云原生安全指北 Dubito Dubito《Azure Blob Storage勒索软件攻击路径剖析》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论