Terrance DeJesus

Azure AD Graph 活动日志：数据采集和威胁检测，以弥合可见性差距

Azure AD Graph 活动日志会完整解析并上传到 Elasticsearch。使用现成的检测规则检测 ROADrecon 和 AADInternals 枚举。

阅读时间：11 分钟探测工程

AAD Graph 活动日志现在可以导入 Elastic，并可用于SIEM/XDR 解决方案中的威胁检测。这句话原本不应该让人感到兴奋，但它却令人兴奋。在过去十年的大部分时间里，这部分遥测数据根本不存在，无法作为客户可访问的日志流查看。Microsoft Graph 活动日志（现代的graph.microsoft.com界面）于 2024 年 4 月正式发布。传统的 graph.windows.net 表面（攻击者工具实际攻击的表面）一直处于封闭状态，直到 2026 年初才被开放。

这篇文章完整地展示了整个循环过程。为什么可见性很重要，如何将日志导入 Elastic，如何手动和使用 ROADrecon 生成真实的侦察，以及如何在 ES|QL 中查找结果。以下所有内容均已针对实际租户进行验证。

关键要点

  • AAD Graph 活动日志通过Azure 集成进入 Elastic，并以完整的 ECS 提取方式进入logs-azure.aadgraphactivitylogs-* 。

  • ROADtools、AADInternals 及其合作伙伴多年来一直处于信息不透明的状态。防守队员没能抢到球权。

  • AAD Graph 已被“弃用”，但在大多数租户中仍然可以查询。1.61 内部 API 版本仍然会返回 Microsoft Graph 不会返回的数据。

  • ECS 字段土地类型（ event.action 、 event.outcome 、 http.request.method 、 source.ip 、 user.id 、 user_agent.original ）。数据集附加信息在azure.aadgraphactivitylogs.properties.*下仍然可查询。

  • 五种检测方法可以可靠地捕捉到该活动：工具用户代理、端点广度、 *-internal API 滥用、FOCI 客户端 ID 不匹配和 4xx 激增。

防御者可见性的简史

防御者们多年来一直致力于登录、条件访问、角色分配和 OAuth 授权许可。很少有内容涵盖攻击者工具实际攻击的底层目录 API。原因是结构性的：这些 API 没有可供客户访问的日志。Microsoft Graph 活动日志率先推出（预览版于 2023 年 10 月发布，正式版于 2024 年 4 月发布）。AzureADGraphActivityLogs 终于在 2026 年初面世了。

在过去十年的大部分时间里，AAD Graph 枚举对 SOC 来说是不可见的，不是因为遥测数据被隐藏了，而是因为它根本不存在。ROADtools、AADInternals、MSOLSpray、微爆。即使配置了完美的日志记录功能，它们也无法生成任何人都能获取的数据。

当 AzureADGraphActivityLogs 开始出现在您的平台日志索引中时，情况就会发生变化。

AAD Graph 虽然已被“弃用”，但仍然非常活跃。

快速回顾一下。Azure AD Graph 是 Entra ID 目录对象的旧版 REST API，托管在https://graph.windows.net/{tenantId}/{objecttype} ，API 版本包括 1.5、1.6和1.61-internal 。自 2019 年以来，微软一直呼吁大家迁移到 Microsoft Graph，但其退役日期已经多次推迟。

弃用机制并未消失。2026 年，在传统访问路径仍然可用或应用程序未被明确阻止使用的情况下，AAD Graph 仍然可以响应请求。它之所以一直成为攻击者的目标，原因有以下几点：

  • 敌方工具尚未移植。ROADrecon 仍然将其用于gather 。AADInternals 有数十个 cmdlet 对其进行了封装。

  • *-internal API 版本会返回更多数据。1.61-internal在正常目录遍历期间，将strongAuthenticationDetail内联暴露给用户对象。Microsoft Graph 的等效功能位于由UserAuthenticationMethod.Read.All控制的单独的 /authentication/methods 端点之后。这种不对称性正是批量枚举工具所利用的。

  • 该模块并非单个切换开关。blockAzureADGraphAccess控件存在于每个应用程序的application.authenticationBehaviors上，因此阻止租户范围内的应用程序注册意味着需要遍历每个应用程序。大多数环境还没有做到这一点，因为一些遗留的自动化流程仍然依赖于 API。微软分阶段退役的执行方案是按照微软的时间表进行的，而不是按照防守方的时间表进行的。

  • 由于缺乏可见性，红队成员和攻击者可以肆意攻击 API 端点以获取相关信息。

合法的 AAD Graph 流量主要由少数微软第一方调用者主导。在我们的测试租户中，按数量排序为Microsoft.OData.Client 、 Microsoft Azure Graph Client Library 、来自第一方 AppIds 的空 UA 尾部、 Microsoft ADO.NET Data Services和 Azure 门户（针对门户应用程序 ID 的 Chrome UA）。超出该可识别范围的任何东西要么是内部工具，要么是未经授权的活动。这使其成为一个可靠的威胁搜寻/检测数据集。如果你正在拍摄的话。

建立摄取管道

如果您已经运行 Elastic Azure集成并将诊断设置转发到事件中心，请略过本节。您可能只需要启用一个额外的日志类别。从头到尾，大约需要 20 分钟。

步骤 1：用于接收日志的堆栈

任何 Elastic 部署方式都可以。Elastic Cloud 试用版是原型设计中最便捷的选择。另一个入门选择是Elastic Container Project 。启用 Azure 集成后，它会自动处理 AzureADGraphActivityLogs。

步骤 2：添加 Azure 集成

在 Kibana 中，依次选择“集成”>“Azure 日志”>“添加 Azure 日志”。插入您的 Event Hub 连接字符串、Event Hub 名称以及用于偏移检查点的存储帐户，所有这些都位于与您的租户相同的订阅中的 Event Hub 上。

专门启用 Azure 日志 v2 数据流。这是 AAD 图形活动日志的入口点。事件路由器匹配category == "AzureADGraphActivityLogs"并将文档重新路由到logs-azure.aadgraphactivitylogs-* ，数据集管道在此处应用完整的 ECS 提取。

我们还将 Azure AD Graph 活动日志拆分成一个单独的集成项，因此您可以搜索“Azure AD Graph 活动日志”并通过策略模板直接安装。

步骤 3：在 Entra ID 上启用诊断设置

这是大多数防守队员都会忽略的一步。AzureADGraphActivityLogs 作为诊断设置类别是较新的。即使您的 Entra ID 诊断设置已经配置了一段时间，新的类别也需要重新勾选。否则，数据将永远存在于微软的租户边界内。

在 Azure 门户中：

  1. Entra ID > 监控 > 诊断设置 > + 添加诊断设置。
  2. 说出它的名字。
  3. 在“日志”下，检查 AzureADGraphActivityLogs。顺便一提，如果 MicrosoftGraphActivityLogs、SignInLogs 和 AuditLogs 尚未启用，建议启用它们。该集成方案可以处理所有这些问题。
  4. 在“目标位置”详细信息下，将流传输到活动中心（与步骤 2 中的活动中心相同）。
  5. 节省。

步骤 4：验证数据流是否正常

几分钟后，您应该就能看到事件了。最快的理智检验方法：

FROM logs-azure.aadgraphactivitylogs-*
| LIMIT 20

如果文档返回的event.action 、 http.request.method和zure.aadgraphactivitylogs.properties.*字段已填充，那就没问题了。如果什么都没显示出来，通常的嫌疑人是忘记了事件中心权限、连接字符串中有拼写错误，或者 AAD Graph 类别未被勾选。

要强制执行一些事件，请登录 Azure 门户并单击“用户”或“应用程序”。该门户网站仍然会在内部调用 AAD Graph 来获取一些对象详细信息。如果上述方法没有生成任何内容，则此 curl 循环将执行以下操作：

TOKEN=$(az account get-access-token --resource https://graph.windows.net --query accessToken -o tsv)
TID=$(az account show --query tenantId -o tsv)
for obj in users groups servicePrincipals applications tenantDetails; do
  curl -sS -o /dev/null -H "Authorization: Bearer $TOKEN" \
    "https://graph.windows.net/$TID/$obj?api-version=1.6&\$top=5"
done

场形状

一旦数据开始流动，属性就会以类型化的顶级字段的形式出现。对狩猎来说最重要的那些：

  • ECS ，直接填充： event.action （源自方法 + 集合的语义动词，例如users-read, batch-execute ）， event.outcome ， event.duration ， http.request.method ， http.response.status_code, source.ip ，和source.geo.*, user.id, user_agent.original （加上解析的子字段）， url.path, azure.tenant_id, cloud.service.name = "Azure AD Graph" 。
  • 特定于zure.aadgraphactivitylogs.properties.*: app_id, 、 app_id 、 api_version 、 actor_type 、 roles 、 scopes 、 wids 、 identity_provider 、 client_auth_method 、 sign_in_activity_id 、 token_issued_at的数据集。
  • related.user 同时获得user.id和properties.app_id ，因此 OAuth 客户端维度上的枢轴与用户枢轴一起工作。

原始 JSON 数据保留在event.original中，以便进行取证重放。正常狩猎时，你不需要把手伸进去。如果要这样做，ES|QL 的JSON_EXTRACT()就是关键所在。

使用 ROADrecon 进行 AAD 图枚举

要想知道该猎捕什么，你需要知道这种活动的具体表现形式。以下两个工具包是红队和安全研究工作流程中最常见的 AAD Graph 流量来源。我分别在我们的测试租户上运行了这两个程序。

注意：本人对因滥用此代码而造成的任何后果概不负责。仅对您拥有的租户或已获得明确书面授权的租户运行这些工具进行测试。

ROADrecon：批量枚举测试

ROADrecon 是ROADtools的数据收集模块，ROADtools 是 Dirk-jan Mollema 的 Entra ID 研究框架。如果你还没用过，强烈推荐试试。gather会遍历目录中所有感兴趣的对象类型（用户、组、服务主体、应用程序、设备、目录角色、角色分配、符合条件的角色分配、OAuth2 权限授予、管理单元），并将结果写入 SQLite。

设置流程为标准流程：

pip install roadrecon
roadrecon auth --device-code -c 04b07795-8ddb-461a-bbee-02f9e1bf7b46 -r https://graph.windows.net

设备代码流程会给你一个 URL 和一个代码。我们使用 Microsoft Azure CLI 作为默认工具（ 1b730954-1685-4b74-9bfd-dac224a7b894 - AAD PowerShell），但在我们的租户中返回了 403 错误。登录后：

roadrecon gather

运行roadrecon gather并顺利完成生成的 token。从租户的角度来看，该运行在大约 1 分钟内产生了超过 2,000 个 AAD Graph 调用和日志。对 ROADrecon 已知的所有对象类型进行批量枚举。

由此，我们可以进行一些初步检测，开始标记这些异常情况。

AAD 图形威胁检测的关键字段

在开始搜寻之前，这里有一些检测异常情况的可靠起点。

字段描述你可以找到什么
event.action语义动词（HTTP 方法 + 集合，例如 `users-read`、`batch-execute`）一种用于按意图隔离 AAD Graph 活动的廉价过滤器
http.request.methodGET、POST、PATCH、DELETE读取（侦察）与写入（修改、凭证注入、持久化）
http.response.status_codeHTTP 状态返回侦察成功与侦察失败；4xx 连续出现表示权限探测或暴力破解。
user.id调用用户目录对象 ID身份归属；跳转到该用户在登录日志/审计日志中的其他活动
user_agent.original调用者的完整 UA 字符串无论是微软自有库、开发者工具（curl、Python aiohttp）还是已知的攻击性工具
url.path资源路径（/users、/policies、/servicePrincipals 等）哪些目录对象类型正在被修改；跨越不同路径的范围表明存在批量枚举。
azure.aadgraphactivitylogs.properties.app_id颁发令牌的 OAuth 客户端 ID无论流量是来自合法的第一方客户，还是来自 FOCI 交换式滥用途径
azure.aadgraphactivitylogs.properties.api_version1.5、1.6、1.61-内部等。无论调用者是否请求仅供内部使用的字段（strongAuthenticationDetail、完整的 CAP 集），这些字段都是攻击者专门针对的。
azure.aadgraphactivitylogs.properties.actor_type用户、应用程序、服务主体人工呼叫者 vs 服务主体/仅限应用程序流程
azure.aadgraphactivitylogs.properties.roles / wids调用者持有的目录角色显示名称和众所周知的角色模板 GUID调用时是否正在行使特权角色（全局管理员、应用程序管理员等）。
azure.aadgraphactivitylogs.properties.scopes调用令牌上的 OAuth 范围令牌实际授予调用者哪些目录权限
azure.aadgraphactivitylogs.properties.client_auth_method客户端如何进行身份验证（PRT、证书、密钥等）用于 PRT 滥用、设备 PRT 利用或被盗客户端凭证使用的指纹
azure.aadgraphactivitylogs.properties.sign_in_activity_id与原始登录相关的 ID从 AAD Graph 回调回溯到生成调用令牌的登录事件
azure.aadgraphactivitylogs.properties.token_issued_at代币铸造时间戳令牌年龄分析；使用几天前发行的令牌进行的调用可能表明存在过期令牌/刷新令牌滥用行为。

检测和预防

检测

任何 AAD 图形检测的前提条件都是首先要有日志。需要在 Entra ID 中启用AzureADGraphActivityLogs诊断类别，并将其路由到您可以查询的目标（至少是 Log Analytics 工作区，理想情况下，还应转发到事件中心以进行 Elastic 摄取，如上面的设置部分所述）。在此之前，本文中描述的呼叫将完全在镜头之外进行，并且以下任何狩猎都不会触发。

如果现在无法将数据导入 Elasticsearch，请启用诊断设置并将其发送到 Log Analytics。以下搜索的 KQL 等效项很简单，即使不进行进一步处理，数据也会随着保留而积累。

预防

门户中没有单一的租户级 AAD Graph 终止开关。实际的应用层控制是：

  • application.authenticationBehaviors.blockAzureADGraphAccess

应用程序资源上的每个应用程序布尔值（Microsoft Graph beta，文档）。大规模封锁意味着要逐个检查每个应用程序的注册信息，并通过手动或编程方式将其关闭。微软自己的分阶段退休计划也在按部就班地进行，不会受到影响。这种情况发展得越久，需要防守的表面积就越小。

防守方在此期间可以沿同一轴线移动：

  • 审核租户中仍然持有graph.windows.net令牌的应用程序。将不需要设置的值设为blockAzureADGraphAccess = true 。任何仍然依赖于 AAD Graph 的程序都会出现严重故障，从而暴露出你之前不知道存在的遗留自动化程序。

  • 将条件访问应用于 Azure AD Graph 作为目标资源。Azure AD Graph 服务主体 ( 00000002-0000-0000-c000-000000000000 ) 不会显示在标准的 CA 应用选择器中，但它受所有资源策略的保护，并且可以通过自定义安全属性筛选器方法单独进行定位。微软在3 月 2026 的强制执行变更使这更加实际：以前自动从 CA 强制执行中排除的低权限范围（ User.Read 、 People.Read等）现在被视为 AAD Graph 访问，因此所有资源策略实际上都会限制它们。CA 在代币发行时进行评估，因此已生效的代币在到期前将继续有效。

  • 将 CA 应用于 FOCI 客户端，攻击者工具运行于其上（Microsoft Teams、Microsoft Office、OneDrive、Azure PowerShell 等）。需要使用受管控且符合规范的设备。如果底层客户端无法登录，则交换路径将崩溃。

  • 对于服务主体调用者，工作负载身份高级版增加了服务主体范围的 CA。条件仅限于位置、身份保护风险和身份验证上下文；唯一的授权控制是阻止。可用于合并外部和风险上下文路径，但不能像用户 CA 那样将 SP 的范围限定到特定的云应用程序。

  • 禁用不需要设备代码流程的用户的设备代码流程。roadrecon auth --device-code是进入上述整个管道阻力最小的路径，在 OAuth 网络钓鱼中非常常见。

行为检测

我们发布了涵盖上述 AAD Graph 侦察形状的检测规则。每个规则都存在于Elastic detection-rules存储库中，并针对已解析的logs-azure.aadgraphactivitylogs-*数据流进行原生运行。

使用可疑用户代理访问 Azure AD Graph - KQL 匹配规则。当 AAD Graph 收到来自与攻击性工具系列（Python、aiohttp、curl、Go-http-client、axios、AzureHound、BloodHound、AADInterals 等）匹配的用户代理字符串的流量时触发。这是可靠的基线信号，因为没有任何微软第一方组件被识别为这些类型中的任何一种，而默认工具却被识别为这些类型中的任何一种。 

Azure AD Graph 用户 4xx 错误率高- ES|QL 聚合。当单个呼叫者在短时间内对 AAD Graph 产生异常高的 4xx 响应比例时触发。侦察和暴力破解令牌的使用会留下 403 和 404 错误，因为工具会访问它们没有权限访问的端点，请求它们没有的对象 ID，或者使用未经 AAD Graph 授权的客户端 ID。 

Azure AD Graph 访问异常客户端和用户- KQL new_terms 规则，中等严重性。当（调用 OAuth 客户端，已登录用户）对在过去 14 天内首次出现在 AAD Graph 上时触发。捕获 FOCI 交换、为用户不常用的客户端兑换的钓鱼刷新令牌，以及在不熟悉的客户端上使用的被盗令牌。忽略已知的、通常与 Azure AD 交互的、后端由 Microsoft 拥有的第一方应用程序。

使用异常用户和 ASN 访问 Azure AD Graph - KQL 匹配规则。排除常见的 Microsoft / AWS / GCP / Akamai / Cloudflare ASN 组织，并标记源自该集合之外的 AAD Graph 流量。攻击者的工具通常依附于住宅 ISP、VPS 提供商或匿名网络，这些网络会生成与合法第一方呼叫者不同的 ASN 分布。可通过调整排除的 ASN 列表来针对每个租户进行调整。

Azure AD Graph 潜在枚举 (ROADrecon) - ES|QL 聚合，高严重性。需要同时使用aiohttp用户代理，并且需要从单个身份发出 500 多个 AAD Graph 请求。ROADrecon 的gather命令默认使用 aiohttp，并遍历每个目录对象类型，因此该组合本质上是一个工具指纹。比通用的非微软 UA 规则更严重，因为额外的突发要求消除了开发人员原型误报类。

Entra ID OAuth 设备代码登录到 Azure AD Graph 枚举- EQL 序列，高严重性。在五分钟内，同一用户通过针对graph.windows.net的目录枚举，在非托管设备上成功使用设备代码登录到旧版 AAD Graph 受众 ( 00000002-0000-0000-c000-000000000000 )。设备代码网络钓鱼无需触及用户的密码或 MFA 即可获取 OAuth 令牌，因此攻击者利用该令牌立即读取用户、服务主体、应用程序、角色分配、策略或租户详细信息等 Graph 数据，从而获取被盗用的身份信息。跨数据流序列消除了其他 AAD Graph 规则中存在的单事件误报类。

AAD 图形可见性：接下来会发生什么？

在过去十年的大部分时间里，AAD Graph 活动就像遥测领域的暗物质一样。我们知道它的存在，因为攻击者的工具一直在指向它，但客户没有诊断流可以订阅，也没有日志可以查询。Microsoft Graph 活动日志在 2024 年 4 月正式发布时，缩小了一半的差距。AzureADGraphActivityLogs最终在 2026 年初关闭了另一半。

现在数据已经有了，剩下的就看我们的了。添加新的诊断设置，将其指向事件中心，将其引入您的堆栈，启用检测（或创建您自己的检测），然后开始监控。

本文中的检测结果只是一个起点。一旦 AAD Graph 流量进入您的堆栈，并且您的租户中正常情况的基准线是怎样的，那么相同的模式就会普遍适用。合法的微软第一方来电者构成了一个很小且易于识别的集合，任何不属于这个集合的来电者都值得仔细研究。

这项活动一直都存在。能见度终于也提高了。

祝你狩猎愉快！

参考资料

上述研究参考了以下内容：

关于 Elastic 安全实验室

Elastic Security Labs 是 Elastic Security 的威胁情报部门，致力于在威胁形势方面创造积极的改变。Elastic Security Labs 提供关于新兴威胁的公开研究，分析对手的战略、运营和战术目标，并将这些研究与 Elastic Security 的内置检测和响应功能相结合。请在 Twitter 上关注 Elastic Security Labs @elasticseclabs ，并访问www.elastic.co/security-labs/查看我们的研究。

分享这篇文章

XFacebookLinkedInReddit