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

Anthropic-Cybersecurity-Skills 实战指南基于 KQL/SPL 检测 Microsoft Entra ID 服务主体滥用【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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 IDAzure AD中检测服务主体Service Principal滥用——包括新增凭据、特权角色分配、管理许可绕过与服务主体枚举等攻击模式。结合 Sentinel/Splunk 检测查询、Microsoft Graph API 审计脚本 与 工作流定义读者将掌握一套可直接落地的检测、调查与防御方案用于云安全监控、威胁狩猎和事件响应。背景为什么服务主体是云攻击者的重点目标Azure 服务主体Service Principal是应用程序、服务和自动化工具访问 Azure 资源时使用的身份对象。攻击者利用服务主体可达成三重目的权限提升为低权限身份所拥有的服务主体添加凭据或为其分配高特权目录角色横向移动利用被攻陷的服务主体访问其他资源与 API持久化访问注入新客户端机密client secret或证书建立难以清除的后门。尤其值得注意的是应用程序所有权Application Ownership本身就授予了管理凭据与配置权限的能力从而形成隐蔽的权限提升路径。例如某个普通用户被添加为应用所有者后即可为该应用对应的服务主体添加新凭据并以该身份调用 Graph API。因此监控服务主体相关的审计日志与登录日志是云身份安全的关键环节。本技能在仓库 index.json 中被归类为cloud-security子域并映射到 MITRE ATTCK、NIST CSF 与 D3FEND 等框架详见 SKILL.md 的 frontmatter适合 SOC 分析师、检测工程团队与红队人员直接复用。适用场景与前置条件何时使用本检测技能调查疑似通过服务主体进行的权限提升或持久化安全事件为该领域构建检测规则或威胁狩猎查询SOC 分析师需要结构化的分析流程验证相关攻击技术在现有监控体系中的覆盖情况。前置条件类别要求订阅许可带 Microsoft Entra ID P2 许可的 Azure 订阅日志数据可访问 Azure AD 审计日志Audit Logs与登录日志Sign-in LogsSIEM 平台Microsoft Sentinel 或 SplunkAPI 权限具备 Microsoft Graph API 调查权限账号角色最低为 Global Reader 或 Security Reader五种关键滥用模式与检测查询以下检测查询均直接来源于 SKILL.md 的核心章节同时给出 SentinelKQL与 SplunkSPL两种实现。模式 1向服务主体添加新凭据攻击者向既有服务主体添加新的客户端机密或证书以维持持久访问。Sentinel 检测查询KQLAuditLogs | 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 descSplunk 检测查询SPLindexazure sourcetypeazure:aad:audit operationNameAdd service principal credentials OR operationNameUpdate 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 中的风险评级角色风险说明Global Administrator完全租户控制Application Administrator可创建/管理所有应用Cloud Application Administrator管理云应用注册Privileged Role Administrator管理角色分配模式 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, ConsentTypeAllPrincipals表示租户级管理许可属于高危信号。模式 5OAuth 应用权限升级攻击者为服务主体分配超出其业务所需的 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 -DescendingStep 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.pyMicrosoft Graph 客户端审计scripts/agent.py 基于azure-identityrequests封装了AzureGraphClient类核心能力包括list_service_principals()分页拉取/v1.0/servicePrincipals$top200get_sp_credentials(sp_id)读取服务主体上的密码凭据get_sp_app_roles(sp_id)读取应用角色分配get_sign_in_logs(sp_id, days7)按appId eq {sp_id}过滤近 7 天登录日志get_directory_roles()/get_role_members(role_id)枚举目录角色及其成员。其审计函数audit_credential_expiry()实现了与检测查询互补的凭据健康检查规则发现规则严重级别已过期但未移除的凭据MEDIUM30 天内即将过期LOW密码凭据数量 2疑似后门HIGH而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.pyAzure 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 ATTCK 映射该技能覆盖的 ATTCK 技术依据 SKILL.md 与 standards.md技术ID说明Account Manipulation: Additional Cloud CredentialsT1098.001向服务主体添加凭据Valid Accounts: Cloud AccountsT1078.004使用被攻陷的服务主体Account Discovery: Cloud AccountT1087.004枚举服务主体Steal Application Access TokenT1528通过服务主体窃取应用访问令牌Use Alternate Authentication Material: Application Access TokenT1550.001使用应用令牌作为替代认证材料CIS Microsoft Azure Foundations Benchmark v2.1 对照1.11确保所有特权用户启用多因素认证1.14定期审查来宾用户1.15用户应用许可设置为“不允许用户许可”。Microsoft Secure Score 建议要求对非托管应用进行管理员审批移除未使用的应用权限限制服务主体凭据生命周期为工作负载身份实施条件访问。服务主体滥用风险指标速查依据 api-reference.md日常审计可按下表快速分级指标说明严重级别多个密码凭据疑似后门持久化HIGH过期凭据未移除凭据卫生缺口MEDIUM服务主体持有 Global Admin 角色过度授权的自动化CRITICAL异常登录位置服务主体凭据被攻陷HIGH服务主体新增凭据凭据注入式持久化CRITICAL总结检测 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 ATTCK, 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考