企业官网建设流程全解析

Anthropic-Cybersecurity-Skills 实战指南：基于 KQL/SPL 检测 Microsoft Entra ID 服务主体滥用

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

导读：本文以 detecting-azure-service-principal-abuse 技能文档为核心，系统讲解如何在 Microsoft Entra ID（Azure AD）中检测服务主体（Service Principal）滥用——包括新增凭据、特权角色分配、管理许可绕过与服务主体枚举等攻击模式。结合 Sentinel/Splunk 检测查询、Microsoft Graph API 审计脚本 与 工作流定义，读者将掌握一套可直接落地的检测、调查与防御方案，用于云安全监控、威胁狩猎和事件响应。

背景：为什么服务主体是云攻击者的重点目标

Azure 服务主体（Service Principal）是应用程序、服务和自动化工具访问 Azure 资源时使用的身份对象。攻击者利用服务主体可达成三重目的：

• 权限提升：为低权限身份所拥有的服务主体添加凭据，或为其分配高特权目录角色；
• 横向移动：利用被攻陷的服务主体访问其他资源与 API；
• 持久化访问：注入新客户端机密（client secret）或证书，建立难以清除的后门。

尤其值得注意的是，应用程序所有权（Application Ownership）本身就授予了管理凭据与配置权限的能力，从而形成隐蔽的权限提升路径。例如，某个普通用户被添加为应用所有者后，即可为该应用对应的服务主体添加新凭据并以该身份调用 Graph API。因此，监控服务主体相关的审计日志与登录日志是云身份安全的关键环节。

本技能在仓库 index.json 中被归类为cloud-security子域，并映射到 MITRE ATT&CK、NIST CSF 与 D3FEND 等框架（详见 SKILL.md 的 frontmatter），适合 SOC 分析师、检测工程团队与红队人员直接复用。

适用场景与前置条件

何时使用本检测技能

• 调查疑似通过服务主体进行的权限提升或持久化安全事件；
• 为该领域构建检测规则或威胁狩猎查询；
• SOC 分析师需要结构化的分析流程；
• 验证相关攻击技术在现有监控体系中的覆盖情况。

前置条件

五种关键滥用模式与检测查询

以下检测查询均直接来源于 SKILL.md 的核心章节，同时给出 Sentinel（KQL）与 Splunk（SPL）两种实现。

模式 1：向服务主体添加新凭据

攻击者向既有服务主体添加新的客户端机密或证书以维持持久访问。

Sentinel 检测查询（KQL）：

AuditLogs | where OperationName has "Add service principal credentials" or OperationName has "Update application - Certificates and secrets management" | extend InitiatedBy = tostring(InitiatedBy.user.userPrincipalName) | extend TargetSP = tostring(TargetResources[0].displayName) | extend TargetSPId = tostring(TargetResources[0].id) | project TimeGenerated, InitiatedBy, OperationName, TargetSP, TargetSPId | sort by TimeGenerated desc

Splunk 检测查询（SPL）：

index=azure sourcetype="azure:aad:audit" operationName="Add service principal credentials" OR operationName="Update application*Certificates and secrets*" | stats count by initiatedBy.user.userPrincipalName, targetResources{}.displayName, _time | sort -_time

要点：这类操作本身可能是合法的凭据轮换，因此需要结合执行者身份（InitiatedBy）、目标主体与时间窗口交叉验证，排除已知的自动化账户与维护窗口。

模式 2：向服务主体分配特权角色

攻击者将高特权目录角色添加到服务主体上，从而以自动化身份行使管理员权限。

AuditLogs | where OperationName == "Add member to role" | extend RoleName = tostring(TargetResources[0].modifiedProperties[1].newValue) | where RoleName has_any ("Global Administrator", "Application Administrator", "Privileged Role Administrator", "Cloud Application Administrator") | extend TargetSP = tostring(TargetResources[0].displayName) | extend InitiatedBy = tostring(InitiatedBy.user.userPrincipalName) | project TimeGenerated, InitiatedBy, TargetSP, RoleName, OperationName

需要重点监控的高风险目录角色（依据 api-reference.md 中的风险评级）：

模式 3：服务主体枚举检测

攻击者在侦察阶段批量枚举/servicePrincipals端点，以寻找可利用的信任关系与权限路径。

MicrosoftGraphActivityLogs | where RequestMethod == "GET" | where RequestUri has "/servicePrincipals" | summarize RequestCount = count() by UserAgent, IPAddress, bin(TimeGenerated, 1h) | where RequestCount > 10 | sort by RequestCount desc

该查询按小时聚合来自同一 UserAgent/IP 的枚举请求，阈值RequestCount > 10可依据基线环境调优。

模式 4：管理许可绕过（Admin Consent Bypass）

恶意应用诱导管理员授予针对全部主体的委托权限，实现全租户范围的数据访问。

AuditLogs | where OperationName == "Consent to application" | extend ConsentType = tostring(TargetResources[0].modifiedProperties[4].newValue) | where ConsentType has "AllPrincipals" | extend AppName = tostring(TargetResources[0].displayName) | extend InitiatedBy = tostring(InitiatedBy.user.userPrincipalName) | project TimeGenerated, InitiatedBy, AppName, ConsentType

AllPrincipals表示租户级管理许可，属于高危信号。

模式 5：OAuth 应用权限升级

攻击者为服务主体分配超出其业务所需的 Graph API 应用角色。

AuditLogs | where OperationName == "Add app role assignment to service principal" | extend AppRoleValue = tostring(TargetResources[0].modifiedProperties[1].newValue) | where AppRoleValue has_any ("RoleManagement.ReadWrite.Directory", "Application.ReadWrite.All", "AppRoleAssignment.ReadWrite.All", "Directory.ReadWrite.All", "Mail.ReadWrite") | extend TargetApp = tostring(TargetResources[0].displayName) | project TimeGenerated, TargetApp, AppRoleValue, CorrelationId

其中RoleManagement.ReadWrite.Directory与Application.ReadWrite.All属于可造成灾难性影响的写权限，一旦出现即应优先处置。

调查流程：从告警到结论的四步走

告警命中后，需要借助 Microsoft Graph PowerShell 与登录日志完成纵深调查。以下步骤取自 SKILL.md 的 Investigation Procedures 章节。

Step 1：识别被攻陷的服务主体

列出最近 7 天内新增凭据的服务主体：

# List service principals with recently added credentials Connect-MgGraph -Scopes "Application.Read.All" $suspiciousSPs = Get-MgServicePrincipal -All | ForEach-Object { $sp = $_ $creds = Get-MgServicePrincipalPasswordCredential -ServicePrincipalId $sp.Id $recentCreds = $creds | Where-Object { $_.StartDateTime -gt (Get-Date).AddDays(-7) } if ($recentCreds) { [PSCustomObject]@{ DisplayName = $sp.DisplayName AppId = $sp.AppId ObjectId = $sp.Id NewCredsCount = $recentCreds.Count LatestCredAdded = ($recentCreds | Sort-Object StartDateTime -Descending | Select-Object -First 1).StartDateTime } } } $suspiciousSPs | Sort-Object LatestCredAdded -Descending

Step 2：审查服务主体的角色分配

# Check role assignments for a specific service principal $spId = "<service-principal-object-id>" Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $spId | ForEach-Object { $resource = Get-MgServicePrincipal -ServicePrincipalId $_.ResourceId [PSCustomObject]@{ AppRoleId = $_.AppRoleId ResourceDisplayName = $resource.DisplayName CreatedDateTime = $_.CreatedDateTime } }

Step 3：检查应用程序所有权

所有权等同于凭据控制权，需排查异常所有者：

# List owners of all applications (ownership = credential control) Get-MgApplication -All | ForEach-Object { $app = $_ $owners = Get-MgApplicationOwner -ApplicationId $app.Id foreach ($owner in $owners) { [PSCustomObject]@{ AppName = $app.DisplayName AppId = $app.AppId OwnerUPN = $owner.AdditionalProperties.userPrincipalName OwnerType = $owner.AdditionalProperties.'@odata.type' } } } | Where-Object { $_.OwnerUPN -ne $null }

Step 4：审查服务主体登录活动

AADServicePrincipalSignInLogs | where ServicePrincipalId == "<target-sp-id>" | project TimeGenerated, ServicePrincipalName, IPAddress, Location, ResourceDisplayName, Status.errorCode | sort by TimeGenerated desc

关注异常地理位置、非预期资源访问与失败错误码聚集的时段。

源码级支撑：仓库中的自动化检测实现

该技能目录内附带两个可直接运行的检测脚本，是上述查询能力的自动化落地版本，也是理解检测逻辑的源码级参考。

agent.py：Microsoft Graph 客户端审计

scripts/agent.py 基于azure-identity+requests封装了AzureGraphClient类，核心能力包括：

• list_service_principals()：分页拉取/v1.0/servicePrincipals（$top=200）；
• get_sp_credentials(sp_id)：读取服务主体上的密码凭据；
• get_sp_app_roles(sp_id)：读取应用角色分配；
• get_sign_in_logs(sp_id, days=7)：按appId eq '{sp_id}'过滤近 7 天登录日志；
• get_directory_roles()/get_role_members(role_id)：枚举目录角色及其成员。

其审计函数audit_credential_expiry()实现了与检测查询互补的凭据健康检查规则：

而audit_privileged_sp_roles()会遍历Global Administrator、Application Administrator、Cloud Application Administrator、Privileged Role Administrator等高风险角色，筛出成员类型为#microsoft.graph.servicePrincipal的对象，并标记为CRITICAL。

运行方式：

python3 scripts/agent.py \ --tenant-id <tenant-id> \ --client-id <client-id> \ --client-secret <client-secret> \ --output report.json

注意：脚本通过client_credentials授权流获取令牌（对应 api-reference.md 中的 OAuth2 Token Endpoint），使用的应用注册需具备上述审计所需的 Graph 只读权限。

process.py：Azure CLI 驱动的一键检测

scripts/process.py 面向已登录 Azure CLI 的环境，通过az rest --method GET --url https://graph.microsoft.com/v1.0/...调用 Graph API，提供三个可独立执行的检查：

# 检查近 7 天新增的服务主体凭据 python3 scripts/process.py --credentials --days 7 # 检查持有特权角色的服务主体 python3 scripts/process.py --roles # 检查所有者数量异常的应用程序（>3 个所有者） python3 scripts/process.py --ownership # 全量运行并输出报告 python3 scripts/process.py --full --output report.txt

该脚本的优势在于无需单独编写令牌获取逻辑，直接复用az命令的登录态；其check_sp_ownership()将“应用所有者数量 > 3”视为风险信号（对应模板中“所有权即凭据控制权”的假设）。

端到端工作流与调查清单

references/workflows.md 给出了从告警到处置的完整闭环：

检测工作流：日志采集（Ingest）→ 规则激活（Rule Activation）→ 告警分诊（Alert Triage）→ 调查（Investigation）→ 遏制（Containment）→ 修复（Remediation）。

调查工作流：识别受影响服务主体（名称/对象 ID/应用 ID）→ 审查近期凭据变更 → 检查角色分配中的权限提升 → 分析登录日志中的异常 IP/位置 → 审查应用所有权链条 → 评估受影响权限的爆炸半径 → 记录发现并启动事件响应。

调查过程中可直接使用 assets/template.md 中的结构化清单，覆盖六项检查（近 7 天凭据新增、特权角色分配、应用所有权、登录异常、管理许可授予、OAuth 权限升级）以及五项修复动作（轮换被攻陷凭据、移除未授权角色分配、禁用被攻陷服务主体、审查并限制应用所有权、为工作负载身份启用条件访问），便于团队规范化记录。

预防性控制措施

检测之外，SKILL.md 提供了三项关键加固手段。

限制应用注册

# Disable user ability to register applications Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions @{ AllowedToCreateApps = $false }

配置应用许可策略

# Require admin approval for all app consent requests New-MgPolicyPermissionGrantPolicy -Id "admin-only-consent" ` -DisplayName "Admin Only Consent" ` -Description "Only admins can consent to applications"

部署 Sentinel 分析规则

在 Microsoft Sentinel 中创建覆盖以下场景的分析规则：

• 新增服务主体凭据
• 向服务主体分配特权角色
• 批量服务主体枚举
• 向未知应用授予管理许可
• 服务主体从异常位置登录

框架映射与合规基线

MITRE ATT&CK 映射

该技能覆盖的 ATT&CK 技术（依据 SKILL.md 与 standards.md）：

CIS Microsoft Azure Foundations Benchmark v2.1 对照

• 1.11：确保所有特权用户启用多因素认证；
• 1.14：定期审查来宾用户；
• 1.15：用户应用许可设置为“不允许用户许可”。

Microsoft Secure Score 建议

• 要求对非托管应用进行管理员审批；
• 移除未使用的应用权限；
• 限制服务主体凭据生命周期；
• 为工作负载身份实施条件访问。

服务主体滥用风险指标速查

依据 api-reference.md，日常审计可按下表快速分级：

总结

检测 Azure 服务主体滥用需要检测查询、脚本自动化与人工调查三者的协同：KQL/SPL 查询负责从审计与登录日志中捕捉异常模式，agent.py 与 process.py 提供可重复执行的批量审计能力，而四步调查流程与模板清单则保证告警能够被准确分诊和处置。将本文所述规则纳入 Sentinel/Splunk 并配合 standards.md 中的 CIS 与 Secure Score 基线，可有效压缩服务主体滥用带来的权限提升与持久化风险窗口。

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills