2026-10-16 02:29:33 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

利用 Azure IMDS（实例元数据服务）

SecWriter
SecWriter

securitainment

2026年10月9日 18:18
中国香港

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

在追查另一个漏洞（已提交 MSRC）的途中，我在 Azure IMDS 中发现了大量错误配置与滥用方式。

一个什么都没坏、却什么都暴露的场景，你该叫它什么？漏洞、滥用，还是错误配置？答案取决于视角。

它开始的方式和大多数入侵一样：一台 Azure 虚拟机、对互联网开放的 RDP，以及一个有人打算改却一直没改的密码。但接下来发生的事，才是它不同的地方。仅仅一条 curl 命令，攻击者就拿到了 Key Vault、域控、SIEM 和 AI 基础设施的钥匙。没有利用代码，没有零日，一切都只是平台完全按设计工作。

总的来说，每一台 Azure 虚拟机都自带一个内建于平台本身的静默后门。

Azure 实例元数据服务（IMDS）在每台虚拟机上都可以通过 169.254.169.254访问，并会向任何发起请求的进程签发 OAuth 2.0 持有者令牌（bearer token）。一次未经认证的 HTTP 请求就能返回一个令牌，它可以横扫整个 Azure 订阅、枚举每一个资源、抽取 Key Vault 中的每一个密钥、在远程虚拟机上执行 shell 命令，并且在不接触活动虚拟机的情况下从域控器的磁盘快照中拉取 Active Directory 密码哈希。

我从一条 curl 一路追踪到完整的域沦陷，用时不到 40 分钟，全程只产生三条可检测的日志记录。

本文记录了攻击者可以从单个端点武器化的、不同的 IMDS 令牌受众（audience），常见 RBAC 错误配置的真实爆炸半径，从 ARM 令牌到全局管理员的六条权限提升路径，以及一项粉碎了红蓝双方对托管标识令牌中目录角色假设的新发现——每一项发现都有实时 API 响应作为支撑。此外，本文把研究与一个真实攻击场景融合在一起。

它始于一台暴露的 Azure 虚拟机和一个容易拿下的立足点。获得访问权后，我开始探索系统，想弄清自己落在了什么上面。很快我注意到实例元数据服务（IMDS）可以访问，而这一点改变了一切。凭借虚拟机被赋予的权限，我可以查询 IMDS 并开始拉取凭据，把一次简单的初始访问转变为一个在环境中横向移动的更大机会。

来自一线

关于 Azure 安全，有一个令人不适的真相：保护你的虚拟机免遭凭据窃取的那个东西，本身就是你拥有的最大凭据。

微软设计托管标识（Managed Identity）是为了解决一个真实问题。虚拟机需要向云服务进行身份认证。把密钥存在磁盘上是危险的。所以微软构建了 IMDS——一个按需铸造 OAuth 令牌的元数据服务，消除了存储凭据的需要。

问题不在于 IMDS 的存在。问题在于 IMDS 会把令牌交给虚拟机上运行的任何东西。虚拟机上任何权限级别的任何立足点，都是通往云端的即时入口，而令牌请求本身完全不可见。

我们想回答一个简单的问题：一条 curl 命令能带你走多远？答案是令人恐惧的。

从一个受控实验环境中的单台 Azure 虚拟机出发（该环境包含多个资源组和数十项资源），我们演示了一条完整的利用链：基础设施级侦察、Key Vault 机密抽取、跨多台虚拟机的远程代码执行、经离线磁盘分析的 Active Directory 域沦陷，以及通过查询组织自己的 Sentinel 工作区来了解防御方在监视什么、从而实现 SIEM 规避。

本研究有三项重要贡献。第一，我们编目了 IMDS 令牌受众，并按攻击潜力对每一个进行分类，形成了目前最全面的公开参考。第二，我们展示了几乎存在于每一个 Azure 订阅中的 RBAC 配置的真实爆炸半径。第三，我们揭示了一个关键断裂：Entra ID 目录角色与 Microsoft Graph API 权限之间的脱节——攻击方和防御方都一贯搞错，这一发现改变了你评估托管标识风险的方式。

提示：Azure 虚拟机默认不应拥有任何权限、不应有 RBAC 角色，因为每一个角色都是一个爆炸半径。

从 Shodan 开始

在深入技术细节之前，先把这场攻击作为一个故事讲出来——包含命令、它的简单程度、输出等等。这是攻击者会一步一步遵循的叙述。

我们知道 Azure 虚拟机会因错误配置或弱访问控制而暴露于网络。在许多情况下，这种暴露并非源于精巧的利用，而是被忽视的设置、过于宽松的规则，或对网络边界的错误假设的组合。这一点已为人所知多年，并不新鲜。

发现阶段：初始访问

攻击者打开 Shodan 或同类工具，搜索暴露的虚拟机。在 Shodan 中，查询语句是：

shodan search 'org:\" Microsoft Corporation\" port:3389 \"Remote Desktop Protocol\" -\"nla\"'

「敞开的前门」（直接脆弱性）

asn:AS8075 port:3389 has_screenshot:true screenshot.label:login

这是查找已禁用 NLA的黄金标准。由于 NLA 会在会话开始前强制认证，Shodan 只有在登录界面于认证前被提供时才能截到图。如果你在这里看到 Windows 背景或用户名字段，这台机器就是在尖叫着请求暴力破解或认证前利用。

元数据泄露者

asn:AS8075 \"Remote Desktop Protocol\" \"NTLM Info\"

这条针对 NTLM SSP 响应。即便没有完整的利用代码，这个查询也能拉出 Azure 虚拟机的内部计算机名、域名和确切的 OS 构建版本。它基本上就是一张免费的内部命名规范网络地图——而你连一个恶意数据包都没发出去。

遗留协议转向点

asn:AS8075 port:3389 \"Remote Desktop Protocol\" -\"CredSSP\"

这条筛选出未使用凭据安全支持提供程序（CredSSP）的 Azure RDP 实例。通过从结果中排除 CredSSP，你能找出那些很可能回退到不安全的 RDP 安全层的「遗留」配置，使其成为中间人攻击的首选目标。

初始访问

这一阶段可以用已知攻击工具（如 Hydra、Crowbar）针对 Azure 虚拟机内的本地用户账户进行。密码往往是弱的，而这个本地用户在该 Azure 虚拟机上通常是本地管理员。最有意思的是，有些虚拟机配置了 Entra ID 登录，却没有标准的安全措施。

好吧，到目前为止这些都是多年前就已知的。而且这只是引言——精彩的部分现在才开始。在跳到 ARM 令牌之前，我们应该简要介绍一下 IMDS。

IMDS 架构

IMDS 如何工作？简述。

Azure 实例元数据服务（IMDS）是一个 REST API，提供关于运行中的虚拟机（VM）或虚拟机规模集（VMSS）的基本数据。它的架构被设计为高度安全、本地化且不可路由。

IMDS 把数据组织成若干类别，即「根（roots）」，每个都有特定的架构用途：instance、identity、attested、loadbalancer等等。

Azure 实例元数据服务在每台 Azure 虚拟机上运行于链路本地地址 169.254.169.254。它实现在 Hyper-V 主机的虚拟机监控程序层，可供客户操作系统内的任何进程访问。该服务不需要认证。唯一的要求是 HTTP 头 Metadata: true，它作为一种最小化的 SSRF 防护机制而非认证控制而存在。

令牌端点接受一个 resource参数，用于指定令牌应被限定到哪个 Azure 服务。这将成为所得 JWT 中的受众声明（aud）。关键点在于：IMDS 会为任何有效的受众 URL签发令牌，无论该托管标识是否对目标服务拥有权限。授权是在出示令牌时于目标服务处强制执行的，而不是在令牌签发点。这一架构决策意味着，攻击者可以通过喷洒针对已知受众的令牌请求并逐一测试，来静默枚举哪些服务可访问。

令牌请求的基本形式如下：

GET http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/

针对该虚拟机的每次请求都返回一个 JWT，其解码后的载荷如下：

与安全相关的令牌属性

IMDS 所签发令牌的若干固有特性，使其在攻击者手中成为高影响力的攻击原语：

托管标识通过由 Azure 平台管理的基于证书的凭据进行认证。没有任何机制可以要求多因素认证。
截至 2026 年 3 月，针对工作负载标识的条件访问策略仍处于有限预览阶段，尚未广泛部署。大多数托管标识令牌绕过全部条件访问控制。
所签发令牌的 exp声明授予了整整 24 小时的有效窗口。在此期间，该令牌无法被单独吊销。唯一的补救措施是完全禁用该托管标识或删除其服务主体。
不可见的获取过程

：因为对 169.254.169.254的 HTTP 请求在虚拟机监控程序层处理，从不经过网络。没有任何日志会捕获该令牌请求，唯一的审计信号出现在该令牌随后被用于目标服务之时。
* 完整的资源路径泄露

：因为 xms_mirid声明揭示了完整的 Azure 资源层级——订阅 ID、资源组名与虚拟机名。截获该令牌的攻击者立即就知道你的组织结构。

令牌侦察

我称之为「IMDS 令牌」，但实际上 IMDS 可以返回多种类型的访问令牌，取决于目标资源——无论是 Azure 资源管理器（ARM）、Microsoft Graph 还是其他服务。

资源枚举

使用 ARM 令牌的第一个动作是绘制环境地图。使用来自 bounty1 的令牌，我们查询 Azure 资源管理器 API 以枚举可访问的资源。

订阅查询返回了单一订阅，处于某一特定层级且消费限额已禁用。资源组枚举揭示了横跨多个 Azure 区域的若干资源组：

这条命令利用虚拟机的托管标识，直接从 Azure 实例元数据服务拉取一个临时 OAuth 2.0 访问令牌。没有凭据、没有密钥、毫无摩擦——只是一个按需铸造的令牌，可用于对其它 Azure 资源进行认证与操作。

在实践中，这意味着对控制平面的即时、无密码访问，且完全与你所持有的身份权限一致。

curl -H \"Metadata: true\" \"http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/\"

注意：该令牌可以从任何位置使用，无论身处环境内部还是外部。

要在 Azure 虚拟机上完整武器化令牌收集，你可以运行 imds-token-collector.ps1。该脚本会系统性地收集通过 IMDS 暴露的每一个可访问令牌及相关产物，交给你一整套可串联并在整个环境中滥用的凭据。

影响可能非常重大，因为一切都取决于该 Azure 虚拟机被赋予的权限——无论是通过 RBAC 角色还是其他访问配置。若权限足够，该令牌可迅速转化为整个环境的大范围暴露。

这个令牌里的王冠珠宝

从 Azure 实例元数据服务窃取的一个 JWT，就包含了攻击者绘制基础设施、识别高价值目标并规划下一步所需的一切。

我是谁？——身份声明

我在哪？——基础设施声明

那么，最好的声明是哪一个？哪些可以用来做下一步？

xms_mirid

—— 基础设施蓝图
* oid

—— 授权的万能钥匙
* aud

—— 武器选择器
* wids

—— 权限信号
* xms_tcdt

—— 成熟度评估器

洞察：配置这台托管标识的 Azure 管理员和安全运营人员在数周内做了几十个决定：分配哪个角色、哪个范围、哪条 Key Vault 策略、是否启用诊断。而窃取令牌的攻击者可以在 60 秒内通过读取几个声明把这些决定全部逆向出来。令牌就是一份自白书，它精确地告诉攻击者防御者在安全上投入了多少、又在哪里偷了懒。

受众目录

这就是 IMDS 从「仅仅令人担忧」转变为「真正灾难性」的那个点——一旦你意识到它可以在整个受众目录上铸造令牌。

它是什么

一份完整参考，涵盖 Azure 实例元数据服务会按需铸造的每一个 OAuth2 令牌受众。从基础设施管理到患者健康记录，各服务类别的资源端点，都可以通过 169.254.169.254上的一次未经认证的 HTTP 调用访问。

它证明了什么

一台被攻陷的虚拟机不是一台被攻陷的虚拟机。它是一个拥有 55 条生产线的令牌工厂，每条线都在制造通往不同王国的钥匙——基础设施用 ARM、机密用 Vault、身份用 Graph、数据用 Storage、AI 用 OpenAI，等等。

如何使用

从任何拥有托管标识的 Azure 虚拟机上运行每条命令或喷洒脚本。每一个返回令牌的受众都是一个攻击面。每一个能对其目标 API 生效的令牌都是一扇敞开的门。该目录把每扇门映射到门后的东西，于是攻击者知道该先推开哪一扇，防御者知道该锁上哪一扇。

受众面

55 个受众，一个端点，零认证，而每一个令牌都能解锁一个不同的王国。攻击面可以是一个或多个。

IMDS 不验证意图、不在请求时强制权限检查、也不实施任何有意义的速率限制。它会为任何被请求的受众按需签发令牌，其速度与频率仅受限于你的 HTTP 客户端能发出多少次调用。

攻击者可以在很短时间内喷洒各种服务受众，而每个令牌都能解锁一个不同的数据平面——存储、数据库、AI 模型、消息队列、容器镜像仓库，等等。

根本原因

默认配置假定未分配任何角色。一台带有系统分配托管标识的全新 Azure 虚拟机，其 RBAC 分配为零。理论上，来自 IMDS 的令牌是无用的——它有身份但没有权限。这个设计是默认安全的。

在实践中，这个默认状态大约维持五分钟。有人需要让虚拟机从 Key Vault 读取数据或部署资源，于是——如我们所知——有人运行了一个分配权限的 Terraform 模块，因为文档里的示例用的就是「参与者（Contributor）」角色。

结果就是你下面看到的那样：订阅上的「读者（Reader）」。资源组上的「参与者（Contributor）」。两个设置。门户表格里的两行。没有警告，没有告警，没有任何迹象表明出了问题。而那两项设置就是一条完整的攻击链。

无论这些角色是管理员为了快速修复而手动分配的、是因为模块默认写了 Contributor 而由 Terraform 分配的，还是照着微软快速入门指南粘贴的 ARM 模板分配的——结果都一样：IMDS 免费发放的托管标识令牌，没有强认证，没有日志。

教训

我们以一个问题开始这项研究：一条 curl 命令能带你走多远？答案比我们预想的更令人不安。

对每台 Azure 虚拟机上存在的链路本地地址发起一次未经认证的 HTTP 请求，就能返回一个实际上解锁整个订阅的令牌，让从 Key Vault 提取机密、获取远程机器的 shell 访问权、在整个环境中横向移动变得轻而易举。

这反映了 2026 年云身份安全令人不适的现实：攻陷一个 Azure 环境的主要难点在于获得对虚拟机的初始访问。此后，托管标识通过允许 IMDS 无需认证、无有意义日志、无速率限制地按需为几乎任何受众签发令牌，使持续提权成为可能。

看起来低风险的权限在实践中往往转化为高影响力能力，支持侦察、远程代码执行，甚至域级沦陷；而过于宽松的 Key Vault 配置可以暴露所有机密、密钥与证书（包括可导出的私钥）；磁盘快照则可能代表关键系统（如域控器）的完整副本，可以在不被检测的情况下被静默挂载——使得起初有限的访问迅速演变为完全控制，其阻力远低于大多数防御者的预期。