文章总结： 本文介绍了azureBlobC2配置文件，旨在利用企业针对AzureBlobStorage的出站白名单进行隐蔽通信。通过在Mythic服务端预置容器并分配特定范围的SAS令牌，该工具有效隔离了代理权限，限制单点受损后的横向风险。文章详述了其基于Blob上传与轮询的通信机制、Medusa集成方法及配置流程，并指出当前SOCKS代理速度限制及未来通过ProxyBlob优化的方向，为利用受信任云服务绕过防火墙提供了实战参考。 综合评分： 95 文章分类： 红队,渗透测试,安全工具,云安全

武器化白名单：基于 Azure Blob Storage 的 Mythic C2 Profile (azureBlob)

Andrew Gomez Andrew Gomez

securitainment

2026年2月1日 13:37 中国香港

| 原文链接 | 作者 | | — | — | | https://specterops.io/blog/2026/01/30/weaponizing-whitelists-an-azure-blob-storage-mythic-c2-profile/ | Andrew Gomez, Allen DeMoura |

TL;DR:成熟企业往往会把出站流量 (e.g., egress) 管得很严，但通常也会为受信任的云服务划出非常宽泛的例外。本文展示了如何通过审阅部署指南识别这些例外，并使用一个名为 azureBlob 的新 Mythic C2 profile 将其武器化。

在最近一次 Hackathon 中，我们讨论了操作员在实战中经常遇到的一些问题。其中一个不幸但非常常见的场景是：在成熟度很高的企业环境里，极其严格的出站防火墙规则或网络代理规则，会导致操作员无法从目标主机接收回连 (callback)。为了解决这类路障，我们转而审阅各类安装与部署指南，发现许多厂商为了确保云服务在初始部署阶段可正常工作，会建议在防火墙与代理中配置非常宽泛的通配符例外。比如，Zscaler 关于 Azure Traffic Forwarding 的部署指南、Parallels Remote Application Server 与 Azure Virtual Desktop 的联合部署文档，以及 Nerdio Enterprise Manager 的要求说明，都以某种形式包含了允许出站访问 *.blob.core.windows.net的规则。

这一发现促使我们构建了一个新的 Mythic command and control (C2) profile：azureBlob。它利用 Azure Blob Storage，并以修改版 Medusa 作为 proof of concept，将其集成进 Mythic 的通信链路中。Azure Blob Storage 是 Microsoft 的云对象存储方案，针对海量非结构化数据的存储进行了优化。使用 Azure Blob Storage 作为 C2 通信载体并不新鲜 (例如 Loki 等工具早已演示过)，但我们希望做出一个 PoC：既能扩展到其他 Mythic agent，又能提供 SOCKS 支持。此外，我们还针对 Azure container 与 token scoping 采取了一些额外的 OPSEC 预防措施，细节见下文的“Container Isolation and Token Security”小节。接下来，我们将介绍如何配置与安装 Mythic C2 profile azureBlob，并说明它的工作方式。

Mythic C2 Profile 配置 (Mythic C2 Profile Setup)

在开始配置 Mythic C2 profile 之前，我们需要先在 Azure 侧做一些准备。首先，你需要在 Azure Portal 中创建一个 Storage Account。

1. 访问 https://portal.azure.com
2. 在搜索栏输入“Storage accounts”
3. 选择“+ Create”
4. 创建或选择一个 resource group
5. 选择 Region
6. 选择 Premium Performance
7. 选择“Block Blobs”account type
8. 选择“Local-redundant storage”
9. 选择“Review + Create”

Azure Storage Account 配置

接下来，你需要在“Security + Networking” -> “Access Keys”下获取 Storage Account key。

获取 Storage Account Access Key

然后，在你的 Mythic 服务器上安装 C2 profile 与 agent。

| | | — | | sudo ./mythic-cli install github https://github.com/senderend/azureBlob sudo ./mythic-cli install github https://github.com/KingOfTheNOPs/Medusa |

Mythic C2 Profile 与 Agent 安装命令

安装好 C2 profile 与 agent 后，下一步是配置 C2 profile 的 config。选择“Installed Services” -> “C2”，然后选择“View/Edit Config”。

Mythic 已安装服务 (Installed Services)

填入 Storage Account name 与 key，然后选择“Submit”。

Azure Blob C2 配置

接下来，你需要创建一个 payload，并选择 Medusa agent。

Medusa 构建参数

Azure Blob C2 参数

为便于演示，我们禁用了 HTTPS verification、payload obfuscation，并将 AESPSK 与 encrypted exchange 设置为“false”。在实际任务中，我们建议将这些值设置为“true”。在最后一页，检查 payload 配置并选择“Build Payload”。

构建流程概览 (Build Process Overview)

当该 payload 在后端生成时，Medusa 项目中的 builder.py脚本会被执行。我们修改了该脚本，使其能够判断操作员选择了哪个 profile。如果选择的是 azureBlob profile，就会向 C2 profile 发起一次 RPC 调用：为该特定 payload 创建一个 Azure Blob Storage Container，并以“agent-*”作为 container name 的前缀。Container 创建完成后，container name、SAS token 与 blob endpoint 会返回给 builder，用于完成 payload 的最终生成。下面我们将深入看看“创建 container 的 RPC 调用”在内部是如何工作的。

服务端基础设施预置 (Server-Side Infrastructure Provisioning)

我们的一个设计目标是：消除 agent 对 Azure management APIs 的任何不必要流量。所有 Azure 基础设施的预置 (provisioning) 都发生在 Mythic 服务器上，并且是在 payload 生成阶段完成。Agent 永远不会调用 Azure management APIs；它只会对其被分配的 container 发起 blob 的 PUT、GET 与 DELETE。

C2 profile 暴露了一个名为 generate_config的自定义 RPC function，供 PayloadTypes 在 build 过程中调用。当你通过 Mythic UI 构建 payload 时，流程如下：

| | | — | | # 在 PayloadType 的 builder.py 中  config_data = await SendMythicRPCOtherServiceRPC(MythicRPCOtherServiceRPCMessage(     ServiceName=”azure_blob”,     ServiceRPCFunction=”generate_config”,     ServiceRPCFunctionArguments={         “killdate”: killdate,         “payload_uuid”: self.uuid     } )) if config_data.Success:     blob_endpoint = config_data.Result[‘blob_endpoint’]     container_name = config_data.Result[‘container_name’]     sas_token = config_data.Result[‘sas_token’]     # 将这些值写入你的 agent 代码 |

该 RPC function 会从服务器的 config.json中读取 storage account credentials，创建 container，生成具备 scope 的 SAS token，并返回 agent 所需的一切信息。Agent 永远不会触达 Azure management APIs；它只会对其被分配的 container 发起 GET、PUT 与 DELETE 请求。

这种方式也意味着：C2 server 只需列举以 agent-* 为前缀的容器，就能自动发现新的 agents，而无需 agents 主动注册自身。

容器隔离与令牌安全 (Container Isolation and Token Security)

storage account key 永远不会离开 Mythic 服务器。每个 agent 都会拥有自己的 container，并且只会拿到一个 container-scoped 的 SAS token，用以限制其仅能访问自己被分配的 container。这一点是我们刻意与其他 Azure Blob C2 实现方式拉开差异的设计选择。

现有实现通常会把一个 account-wide 的 SAS token“烘焙 (bake)”到每个 agent 里，这意味着：一旦某个 agent 被烧毁/被逆向，就会泄露凭据，攻击者可借此访问其他 agents 的 blobs、列举该 storage account 下的所有 containers、读取/删除整个行动范围内的数据；甚至在获取 AES encryption keys 后，还可能对 agents 下发伪造 (rogue) tasking。

采用 container-scoped token 后，即便某个 agent 被攻破，它也只能访问自己的 container，影响面 (blast radius) 被限制在单个 agent 范围内。

SAS token 的过期时间与在 Mythic 中生成 payload 时选择的 kill date 绑定，因此当 payload 失效时，token 也会自动过期。在理解了服务端 provisioning 的工作方式后，我们再来拆解 C2 通信的工作机制。

C2 通信如何工作 (How C2 Communication Works)

Azure Blob C2 流程

消息流遵循 Mythic 标准的“postMessageAndRetrieveResponse”与“getMessageAndRetrieveResponse”模式，因此将其集成到其他 agent 中会非常直接。

| | | — | | agent-{uuid[:12]}/  ├── ats/  │   └── {message-id}.blob     # Agent-to-Server 消息  └── sta/      └── {message-id}.blob     # Server-to-Agent 响应 |

要发送一条消息：

1. Agent 生成一个唯一的 message ID
2. Agent 通过 PUT 将加密后的消息上传到 ats/{message-id}.blob
3. Agent 轮询 sta/{message-id}.blob 以获取响应
4. Agent 读取响应后删除该 response blob

C2 server 会运行一个轮询循环，用于：

1. 列出所有以 agent-* 为前缀的容器
2. 对每个容器，列出 ats/ 文件夹中的 blobs
3. 下载并删除每一条 agent 消息，然后转发给 Mythic
4. 将 Mythic 的响应写入对应的 sta/{message-id}.blob

每条消息都由一个 UUID 前缀加上 JSON 组成，格式与 Mythic 的预期一致。

Pegasus 测试 Agent (Pegasus Test Agent)

azureBlob 仓库包含 Pegasus：一个最小化的 Python agent，主要用于两件事：

1. 验证 C2 配置

   ，或在无需进行任何 agent 开发的情况下试用该 profile

2. 作为参考实现 (reference implementation)：

   代码简单、做了大量裁剪，可用作将 C2 profile 支持集成到其他 agent 的模板

该 agent 的代码包含一些占位符 (placeholders)，在 payload 生成过程中会由 Mythic 进行替换：

| | | — | | BLOB_ENDPOINT = “BLOB_ENDPOINT_PLACEHOLDER”  CONTAINER_NAME = “CONTAINER_NAME_PLACEHOLDER”  CONTAINER_SAS = “CONTAINER_SAS_PLACEHOLDER”  CALLBACK_INTERVAL = int(“CALLBACK_INTERVAL_PLACEHOLDER” or “30”)  CALLBACK_JITTER = int(“CALLBACK_JITTER_PLACEHOLDER” or “10”)  AGENT_UUID = “AGENT_UUID_PLACEHOLDER” |

当 payload 构建时，agent 的 builder.py 会调用 C2 profile 的 generate_configRPC function 来预置 container 并获取 SAS token，然后将这些值写入 agent 代码中。Account key 永远不会被写入；只有具备 scope 的 SAS token 会被写入。

Pegasus 支持 shell、whoami、pwd、hostname 和 exit 等命令。它演示了完整的消息生命周期 (checkin、get_tasking、post_response)，可供参考。

此外，这个测试 agent 不支持 crypto，因此我们不建议将其用于实战。我们构建它仅用于实验室与个人测试。

如需测试你的配置：

| | | — | | sudo ./mythic-cli install github https://github.com/senderend/azureBlob |

通过 Mythic UI 构建一个 Pegasus payload。如果它能成功 check-in，则说明你的配置正确，可以继续将该 profile 集成到你的实际 agent 中。

集成到你的 Agent (Integrating Into Your Agent)

我们将该 profile 设计为可适配任意 Mythic agent。你需要做两件事：

1. 在 builder.py 中：

   在 build 阶段调用 generate_configRPC function 来预置 container 并返回具备 scope 的 SAS token，然后用返回结果替换 agent 代码中的占位符变量

2. 在 agent 代码中：

   定义上述占位符变量，并使用在 build 阶段写入这些变量的值，实现针对 ats/ 与 sta/ 路径的 blob PUT/GET/DELETE 操作

Agent 与 Azure Storage 的通信，本质上是一些简单的 HTTP REST API 调用，使用大多数编程语言都具备的标准 request libraries 即可完成。你可能注意到，我们在服务端 (用于 C2 profile 的容器预置与 account 级管理，而不是 agent 端) 使用了 Microsoft Azure Storage Blobs Python library。虽然 Azure Storage 在许多语言中都有 client libraries 与 SDK，但对 agent 侧所需的简单 read/write/delete 操作来说，它们并非必需。我们选择使用标准库自行构建简单请求，以避免 payload 依赖，并为操作员提供更多可定制空间。

container URL 的格式为 https://{storage_account}.blob.core.windows.net/{container_name}/{blob_path}?{sas_token}。

后续工作：更快的 SOCKS (Future Work: Faster SOCKS)

在使用 Medusa 与 azureBlob profile 测试 SOCKS 时，我们观察到的速度最高约为 19-21 KB/s。

SOCKS 速度测试

这个速度谈不上令人愉快，但 Andrew Luke 与 Paul Kim 正在牵头一个工作：将 ProxyBlob 的 client side 从 Go 移植到 Python，以便纳入支持 Azure Blob Storage C2 profile 的 agents。ProxyBlob 是 Quarkslab 专门为 Azure Blob Storage 传输而设计的 SOCKS5 proxy，吞吐量可达约 1.5 MB/s。这个速度相对于我们测试的约 21KB/s 将是数量级的提升，并能把基于 Azure Blob Storage 的 agent SOCKS 能力提升到足以可靠代理攻防工具的水平。一旦我们把 PoC 打磨出来，请留意后续的博客文章。

结论 (Conclusion)

部署指南对防守方与进攻方来说都是信息金矿。很多时候，这些指南会留下空间，让人能够发展出“寄生在组织既有信任之内”的技术。Azure Blob Storage 作为 C2 通信载体并不新鲜，Loki 等常见工具已经证明了这一点；我们只是希望在既有工作基础上做进一步扩展。我们设计这个 Mythic profile，是为了帮助更多人将 Azure Blob Storage 集成进自己的 Mythic C2 agents。非常感谢 Cody Thomas 在构建该工具过程中提供的帮助，以及他为 Mythic 制作的 developer series。如果你有兴趣在 Mythic 中开发自己的 C2 profile 或 agent，我强烈推荐观看他的系列视频！同时也感谢 Andrew Luke 与 Paul Kim 在该 Mythic profile 开发期间提供的帮助。

Weaponizing Whitelists: An Azure Blob Storage Mythic C2 Profile

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：securitainment Andrew Gomez Andrew Gomez《武器化白名单：基于 Azure Blob Storage 的 Mythic C2 Profile (azureBlob)》