从原理到实践：基于Security-Datasets复现与检测GoldenSAML攻击

1. 项目概述：为什么我们要亲手复现GoldenSAML攻击？

如果你是一名安全工程师、SOC分析师或者对身份认证安全感兴趣的研究者，那么“GoldenSAML”这个词对你来说一定不陌生。它早已不是新闻，而是近年来针对云身份和SAML协议最臭名昭著的攻击手法之一。你可能读过很多分析报告，知道它利用了SAML令牌签名密钥的泄露，可以伪造任意用户的身份令牌，从而在Azure AD、Okta等身份提供商环境中实现“上帝模式”的访问。但读报告和亲手做一遍，完全是两码事。

这就是我写这篇长文的原因。我发现，很多关于高级威胁的讨论都停留在理论层面，大家知道概念，但缺乏第一手的、可操作的感知。当警报真的在SIEM里响起时，你能否迅速识别出那些细微的、偏离基线的异常行为？这需要经验，而经验最好的来源，就是在受控环境中亲手“制造”一次攻击。所以，我决定结合Security-Datasets这个宝藏项目，带大家完整地走一遍GoldenSAML攻击的复现、数据采集和检测规则提炼的全过程。这不是一次简单的工具演示，而是一次从攻击者视角出发，最终服务于防御者能力建设的深度实践。

Security-Datasets是什么？简单说，它是一个开源的、高质量的安全事件数据集集合，专门为检测工程和威胁研究而生。它提供了从真实攻击场景中捕获的、经过匿名化处理的日志数据，并附有清晰的攻击描述和标签。我们用它，就相当于站在了巨人的肩膀上，不必从零开始搭建复杂的环境和发动攻击，可以直接聚焦于最核心的部分：日志分析和检测逻辑构建。

本次实践的目标很明确：第一，深入理解GoldenSAML攻击链的每一个技术环节及其在日志中的“指纹”；第二，掌握使用Security-Datasets进行检测研究的标准方法论；第三，产出可落地、可解释的检测规则或查询语句（比如Sigma规则、KQL查询）。无论你用的是Splunk、Elasticsearch、Microsoft Sentinel还是其他SIEM平台，这里面的思路都是相通的。

2. 核心原理与攻击链拆解：GoldenSAML的“魔力”何在？

在动手之前，我们必须把原理吃透。GoldenSAML攻击的核心，在于对安全断言标记语言（SAML）身份验证流程中一个关键信任环节的破坏。

2.1 SAML单点登录流程回顾

想象一下，你登录公司用的SaaS应用（如Salesforce）。你不是直接在Salesforce输入密码，而是点击“通过公司账号登录”，跳转到公司的身份提供商（IdP，如Azure AD）的页面。登录成功后，IdP会生成一个SAML响应（一个XML文档），里面包含“小明成功登录了”这个断言，并用IdP的私钥对这个断言进行数字签名。Salesforce（服务提供商，SP）持有IdP的公钥证书，它验证签名无误后，就信任这个断言，让你登录。这里的信任基石，就是IdP的签名私钥绝对安全。

2.2 GoldenSAML的攻击切入点

GoldenSAML攻击发生在攻击者已经初步入侵了IdP环境（如Azure AD租户）之后。其目标不是破解密码，而是窃取或伪造用于签署SAML令牌的密钥材料。具体来说，主要针对两种密钥：

1. 令牌签名证书：在Azure AD中，这可能是用于签署SAML令牌的证书的私钥。攻击者可能通过漏洞（如Golden SAML漏洞本身，通常与ADFS相关）、权限提升或内部人员泄露等方式获取。
2. 应用程序的客户端密钥：在某些场景下，攻击者可能窃取了一个已注册企业应用程序的客户端密钥（Client Secret）或证书。结合足够高的权限（如Application.ReadWrite.All），他们可以修改该应用的SAML单点登录配置，上传自己的签名证书。

一旦攻击者掌握了有效的签名密钥，他们就可以“锻造”出任何SAML响应。他们可以声称自己是任何用户（包括高管、特权账户），访问任何配置了基于该IdP进行SAML认证的云应用（如Office 365, Salesforce, AWS SSO等）。因为SP端验证签名是通过IdP的公钥证书，而这个证书是公开且受信的，所以伪造的令牌会畅通无阻。

2.3 典型攻击链分解

一个完整的GoldenSAML攻击链通常包含以下几个阶段，每个阶段都会在日志中留下痕迹：

1. 初始入侵与立足：通过钓鱼邮件、漏洞利用等方式，获取一个初始立足点（如一台加入域的工作站）。日志体现为：可疑的登录、进程创建、网络连接。
2. 横向移动与权限提升：在内部网络横向移动，目标是获取域管理员或类似的高权限账户，以访问IdP服务器或具备访问云身份目录（如Azure AD）所需权限的账户。日志体现为：大量的横向移动命令（如PsExec, WMI）、Kerberos票据请求、权限提升事件。
3. 密钥材料窃取：这是GoldenSAML的核心。攻击者使用高权限账户，通过特定工具或API调用，从IdP（如ADFS服务器）导出令牌签名证书的私钥，或从Azure AD中读取/修改应用程序的证书配置。这是我们需要重点检测的“关键动作”。
4. 令牌伪造与滥用：攻击者在自己的机器上，使用窃取的密钥，使用如ADFSDump、Mimikatz（针对ADFS）或ROADtools等工具，伪造SAML响应。然后，他们使用这个伪造的令牌向云应用发起认证请求。日志体现为：从非企业IP、非常用设备发起的、但携带“有效”SAML断言的登录事件。
5. 目标达成与数据渗出：成功以高权限用户身份访问云应用（如Outlook, SharePoint, CRM），窃取敏感数据。日志体现为：异常的数据访问模式、大量下载操作。

理解这个链条，我们就能有的放矢地在Security-Datasets中寻找对应的日志证据，并思考在哪个环节部署检测最有效。

3. 环境与工具准备：搭建你的“数字靶场”

我们不会在真实生产环境进行攻击。我们的实验室环境基于Security-Datasets提供的数据，但为了彻底理解，我建议你在一个隔离的虚拟机或实验网络中，配置一个简化的模拟环境。这能让你对工具和命令有肌肉记忆。

3.1 基础实验环境配置

• 操作系统：一台Windows Server（模拟ADFS或域控制器）和一台Windows 10/11（模拟攻击者机器）。可以使用VMware Workstation或VirtualBox。
• 域环境：搭建一个基础的Active Directory域（例如：lab.local），并创建几个测试用户。
• Azure AD租户（可选但推荐）：可以申请一个Microsoft 365开发者订阅（免费），获得一个独立的Azure AD租户用于实验。这是理解云侧日志的关键。
• 日志收集器：在你的实验机器上安装Elastic Agent、Winlogbeat或直接配置Windows事件转发，将安全日志、Sysmon日志等集中发送到一个临时的Elasticsearch实例或直接写入文件。我们的目的是复现攻击并捕获原始日志。

3.2 关键工具介绍

在攻击复现环节，我们会用到以下工具。请务必仅在你自己控制的实验环境中使用。

• Mimikatz：老牌凭证提取工具。在GoldenSAML场景中，其crypto::certificates和crypto::keys模块可用于从ADFS服务器的内存或磁盘中提取证书和私钥。这是模拟密钥窃取阶段的核心。
• ADFSDump：专门针对ADFS的凭证导出工具，能更直接地获取令牌签名证书。
• ROADtools (ROADrecon/ROADlib)：一套针对Azure AD的测试工具。ROADrecon可以用于信息收集，而通过Python脚本利用ROADlib，可以模拟使用窃取的应用程序证书或密钥来构造SAML请求。
• SAML-tracer (浏览器插件)：Firefox或Chrome的插件，用于在浏览器中拦截和查看SAML请求与响应，帮助我们理解SAML流的原始格式，对于分析日志中的SAML断言字段至关重要。
• Python with cryptography, signxml libraries：用于手动编写脚本，使用窃取的私钥对自建的SAML断言进行签名，这是理解令牌伪造本质的好方法。

3.3 Security-Datasets 数据集定位与下载

这是本次实践的数据基石。访问Security-Datasets的GitHub仓库，找到与SAML或身份认证攻击相关的数据集。

1. 访问仓库：在GitHub上搜索Security-Datasets或直接访问其项目页面。
2. 寻找相关数据集：在目录中查找如APT29、GoldenSAML、AzureAD、CredentialAccess等关键词。一个高质量的数据集通常会包含一个清晰的README，描述攻击场景、包含的日志源（如Windows Security, Sysmon, Azure AD SigninLogs）以及攻击的时间线。
3. 下载与解压：下载数据集的压缩包（通常是JSON或EVTX格式）。例如，你可能找到一个名为APT29_GoldenSAML_Simulation.zip的数据集。
4. 数据预览：使用文本编辑器、jq命令（针对JSON）或EvtxECmd等工具（针对EVTX）快速浏览一下日志的结构和内容。注意关键字段：EventID、Timestamp、LogonType、ProcessName、CommandLine、TargetUserName、IpAddress、UserAgent，以及对于云日志，要特别关注IdentityProviderType、AuthenticationProtocol、TokenIssuerType、HomeTenantId等。

注意：Security-Datasets的数据是匿名化和模拟生成的，但依然反映了真实的攻击模式。在分析时，要专注于行为模式而非具体的IP或主机名。

4. 攻击复现与日志生成：亲手“铸造”Golden令牌

现在，让我们在实验环境中，分步骤模拟攻击，并观察每一步产生的日志。我会将实验日志与Security-Datasets中的数据进行对照分析。

4.1 阶段一：权限提升与密钥窃取模拟

假设我们已经通过某种方式获得了域管理员权限。现在要模拟从ADFS服务器窃取令牌签名证书。

实验步骤：

1. 在攻击者机器上，使用域管理员凭证通过PsExec或WMI连接到ADFS服务器。
2. 上传Mimikatz到ADFS服务器。
3. 执行命令：mimikatz.exe "privilege::debug" "crypto::certificates /export" "exit"。这个命令会尝试导出系统存储中的证书及其可能的私钥。

日志分析重点（对照Security-Datasets）：

• Windows安全日志 (EventID 4688)：会记录PsExec或WMI远程创建进程的事件。注意ParentProcessName可能是svchost.exe（WMI）或PSEXESVC.exe，而NewProcessName指向了mimikatz.exe的路径。这是非常明确的恶意工具执行信号。
• Sysmon日志 (EventID 1)：提供了更丰富的进程创建信息，包括CommandLine（完整的命令行）、Hashes（文件哈希）、ParentCommandLine。这里会清晰地看到Mimikatz的命令参数。
• Sysmon日志 (EventID 10)：如果Mimikatz尝试访问lsass进程的内存来提取密钥，可能会触发进程访问事件。
• 在Security-Datasets中：你会找到类似的事件序列。数据集可能已经过滤并突出了这些关键事件。你需要学习它们是如何关联的：一个来自“攻击者IP”的WMI连接，随后在“ADFS服务器”上创建了可疑进程。

实操心得：在真实环境中，攻击者会尝试禁用日志或清除痕迹。因此，检测不能只依赖单一事件。要建立“高权限账户” + “从非常用源IP发起的管理会话” + “在关键服务器上执行可疑命令行工具” 这样的复合检测规则。Sigma规则非常适合描述这种逻辑组合。

4.2 阶段二：伪造SAML令牌并发起登录

假设我们已经拿到了私钥（.pfx文件或.key/.crt组合）。现在我们要伪造一个以CEO身份登录Office 365门户的SAML响应。

实验步骤：

1. 编写伪造脚本：使用Python的signxml库，构建一个基本的SAML响应XML结构。关键字段包括：
   • Issuer：设置为你的IdP实体ID（如https://sts.windows.net/<tenant-id>/）。
   • NameID：设置为目标用户（如ceo@company.com）。
   • Assertion属性：包含认证时间、会话索引等。
   • 使用窃取的私钥对整个Assertion进行签名。
2. 发起认证请求：模拟浏览器向Office 365的登录端点（https://login.microsoftonline.com）发送一个包含伪造SAML响应的HTTP POST请求。这可以通过编写Python的requests脚本完成，需要正确模拟SAML的RelayState和SAMLResponse表单提交。
3. 使用工具简化：也可以使用修改版的ROADtools脚本，直接加载证书并向Azure AD请求一个刷新令牌或访问令牌，这背后其实也封装了SAML流程。

日志分析重点（对照Security-Datasets - Azure AD Signin Logs）：这是检测GoldenSAML的黄金位置。所有Azure AD的登录都会在这里留下记录。我们需要关注那些“看起来合法但细节诡异”的登录。

• IdentityProviderType：正常的企业SAML登录，这里会是Enterprise。GoldenSAML登录也会显示为Enterprise，因为它模仿了企业IdP。
• AuthenticationProtocol：会是saml。
• TokenIssuerType：这是关键字段。对于正常的联合登录，颁发者是你的本地ADFS服务器或PingFederate等。在GoldenSAML攻击中，攻击者是从自己的基础设施颁发令牌。因此，TokenIssuerType可能会是AzureAD（如果攻击者错误配置）或者是一个你从未见过的、异常的颁发者名称或IP地址。在Security-Datasets的数据里，你可能会发现TokenIssuerType字段的值明显不符合企业常规配置。
• ClientAppUsed：可能是Browser或Mobile Apps and Desktop clients。注意是否有异常。
• DeviceDetail：攻击者使用的设备（浏览器指纹、操作系统）很可能与目标用户的常用设备不符。IsManaged可能是false，TrustType可能是AzureAd而非ServerAd。
• Location：登录的IP地理位置可能与用户常在地或公司网络出口IP相差甚远。
• RiskDetections（如果启用条件访问策略）：Azure AD Identity Protection可能会标记出“匿名IP地址”、“不熟悉的登录属性”等风险。

实操心得：检测GoldenSAML登录的核心是建立用户和设备的基线，然后寻找SAML协议下的异常偏离。一个简单的有效检测逻辑是：IdentityProviderType == "Enterprise" AND TokenIssuerType NOT IN ["Your-ADFS-Server-Name", "Your-Ping-URL"]。同时，结合地理位置、设备信息和新颖的ClientAppUsed进行综合评分。Security-Datasets的价值在于，它提供了标注好的“异常”登录样本，你可以直接基于这些样本的字段特征来编写你的检测查询。

5. 基于Security-Datasets的检测规则工程

现在，我们有了理论，也模拟了攻击，手头还有Security-Datasets提供的“标准答案”数据集。接下来就是最关键的一步：如何将这些知识转化为自动化检测规则？

5.1 日志范式化与字段映射

不同的SIEM对同一类日志的字段命名可能不同。Security-Datasets的数据通常采用一种通用或基于某特定收集器的格式（如OSSEM的通用名称）。在编写规则前，你需要理解你的SIEM中，以下关键信息存储在哪个字段：

分析数据集时，对照上表，理解每个事件对应的字段。这能确保你写的规则在你的环境中能正确触发。

5.2 编写Sigma规则：从行为到检测逻辑

Sigma是一种通用的、YAML格式的检测规则语言。它不依赖于特定SIEM，可以被编译成Splunk SPL、Elasticsearch Query DSL、Microsoft Sentinel KQL等。使用Sigma是当前检测工程的最佳实践。

让我们针对GoldenSAML攻击链的两个关键阶段，编写Sigma规则。

规则一：检测可能的令牌签名密钥窃取行为这个规则聚焦在ADFS或域控制器上执行Mimikatz等凭证导出工具的行为。

title: Potential SAML Token Signing Key Theft via Credential Dump Tool id: a1b2c3d4-5678-90ef-ghij-klmnopqrstuv # 生成一个唯一UUID status: experimental description: Detects the execution of known credential dumping tools (e.g., Mimikatz) on systems that may host SAML token signing keys, such as ADFS servers or domain controllers. references: - https://attack.mitre.org/techniques/T1552/004/ # Unsecured Credentials: Private Keys - https://github.com/Security-Datasets/APT29_Simulation author: Your Name date: 2023-10-27 tags: - attack.credential_access - attack.t1552.004 - attack.goldensaml logsource: category: process_creation product: windows detection: selection: Image|endswith: - '\mimikatz.exe' - '\sekurlsa.exe' - '\procdump.exe' # 用于转储lsass CommandLine|contains|all: - 'crypto::' - 'certificates' - 'keys' filter: User|contains: 'SYSTEM' # 或者针对特定服务器主机名进行过滤 condition: selection and not filter falsepositives: - Authorized penetration testing - Legitimate administrative activity using similar tools (very rare) level: high

规则二：检测异常的SAML身份验证请求这个规则针对Azure AD Signin Logs，寻找来自异常令牌颁发者的企业SAML登录。

title: Anomalous SAML Token Issuer for Enterprise Logon id: b2c3d4e5-6789-01fg-hijk-lmnopqrstuvw status: test description: Identifies successful enterprise logons (SAML) where the token issuer does not match the organization's known and trusted identity providers. This could indicate a Golden SAML attack. references: - https://o365blog.com/post/goldensaml/ - https://github.com/Security-Datasets/AzureAD_Threat_Hunting author: Your Name date: 2023-10-27 tags: - attack.initial_access - attack.t1550.002 - attack.goldensaml logsource: category: signin_logs product: azure_ad detection: selection: IdentityProviderType: 'Enterprise' # 企业SAML登录 ResultType: 0 # 0 表示成功登录 TokenIssuerType: - 'Unknown' # 未知颁发者 - 'AzureAD' # 对于本地SAML IdP，来自AzureAD的颁发者是异常的 - '*attack*' # 示例：包含可疑关键词 # 在这里排除你已知的合法颁发者 filter: TokenIssuerType: - 'corp-adfs.company.com' # 你的合法ADFS - 'ping.company.com' # 你的合法PingFederate condition: selection and not filter falsepositives: - New identity provider deployment not yet added to filter list. - Logs from test or non-production tenants. level: medium

使用Sigma CLI：编写完规则后，使用sigma convert命令将其转换为你的SIEM查询语言。例如，转换为KQL：sigma convert -t azure -c tools/config/azure-unsupported.yml rule.yml。

5.3 在SIEM中验证与优化规则

将生成的查询（如KQL）粘贴到你的SIEM中执行。

1. 时间范围：首先针对Security-Datasets提供的日志文件时间范围运行，验证规则是否能准确抓取到数据集中的攻击事件。这是验证规则有效性的第一步。
2. 误报分析：将规则在更长时间范围（比如过去7天）的生产或模拟环境日志中运行。查看触发警报的事件。分析它们是否是误报。
   • 如果是误报：回到Sigma规则中，优化filter部分。可能需要添加更多的排除条件，如特定的用户组（测试账户）、特定的源IP范围（跳板机）、特定的应用程序ID等。
3. 调整阈值与关联：有些行为单次出现可能是误报，但频繁出现就是高危。例如，可以修改规则为“在15分钟内，同一源IP对多台服务器尝试执行可疑命令行工具”。这需要SIEM支持关联规则或你使用更复杂的查询。
4. 建立仪表板：将关键检测规则的结果可视化。创建一个仪表板，监控“异常SAML颁发者”、“关键服务器上的可疑进程”、“高权限账户的异常登录地点”等指标。

6. 高级狩猎与行为关联分析

单一的检测点容易被绕过。高级的威胁狩猎需要将攻击链上的多个低置信度指标关联起来，形成高置信度的警报。

6.1 构建攻击时间线

利用Security-Datasets中标注了时间戳的事件，我们可以重建攻击者的行动序列。例如：

1. T1：来自外部IPX对用户A的成功密码喷射攻击（EventID 4624，LogonType 3，多次失败后成功）。
2. T2 (30分钟后)：用户A从IPX通过PowerShell Remoting连接到服务器SRV-ADFS（EventID 4688，ParentProcessName为svchost.exe，NewProcessName为powershell.exe）。
3. T3 (2分钟后)：在SRV-ADFS上创建进程mimikatz.exe，命令行包含crypto::certificates（Sysmon EventID 1）。
4. T4 (1小时后)：从完全不同的IPY（可能为攻击者基础设施）发起的，以高管用户B身份成功的SAML登录到Office 365，且令牌颁发者异常（Azure AD Signin Logs）。

这个时间线清晰地描绘了从初始入侵到GoldenSAML攻击完成的路径。在SIEM中，你可以编写一个关联规则来检测这种跨主机、跨日志源的模式。

6.2 基于用户实体行为分析（UEBA）的思路

即使攻击者使用了伪造的令牌，他们的“行为”也可能露出马脚。我们可以利用数据集来训练或定义异常行为：

• 登录时间异常：用户通常在上午9点到下午6点从本地登录。但数据集中的攻击登录发生在凌晨2点。
• 资源访问模式异常：用户B（CEO）平时主要访问邮箱和日历。但攻击后，日志显示其短时间内密集访问了所有下属的OneDrive目录和SharePoint管理站点。
• 地理跳跃不可能：用户A在伦敦刚完成本地登录，5分钟后就从新加坡的IP发起了SAML登录。这是物理上不可能的。

这些分析依赖于对用户和历史日志建立基线。Security-Datasets虽然是一次性数据集，但可以启发你思考应该收集哪些数据来建立这些基线（如Azure AD的UserInsights，或者自己计算用户登录的地理位置、时间、应用使用的频率分布）。

6.3 模拟数据与生产数据的结合

Security-Datasets是完美的训练集。你可以：

1. 将数据集导入你的SIEM的测试或开发环境。
2. 运行你编写的检测规则和狩猎查询，确保它们能命中数据集中标记的恶意事件。
3. 将优化后的规则部署到生产环境的SIEM中。
4. 持续监控生产环境中的警报，并将确认的误报和漏报反馈回来，进一步优化你的检测逻辑。这个过程就是检测工程的闭环。

7. 防御纵深与缓解措施探讨

检测是最后一道防线，我们更应该思考如何从架构上增加攻击者的成本，这就是防御纵深。

1. 保护密钥存储：

   • 对于ADFS：将令牌签名证书存储在硬件安全模块（HSM）中。定期轮换证书（虽然GoldenSAML攻击在证书有效期内都有效，但轮换可以限制暴露窗口）。严格限制对ADFS服务器的物理和网络访问，以及本地管理员权限。
   • 对于Azure AD应用程序证书：使用Azure Key Vault存储证书，并配置基于角色的访问控制（RBAC）和Just-In-Time（JIT）访问策略。避免将证书文件存储在代码仓库或文件共享中。

2. 强化监控与告警：

   • 启用并集中收集所有关键系统的日志：域控制器、ADFS服务器、Azure AD审计日志与登录日志。
   • 实施我们上面编写的Sigma规则，并确保警报能及时送达安全团队。
   • 为高权限账户（全局管理员、应用程序管理员等）启用特权身份管理（PIM），要求进行实时审批才能激活权限。

3. 实施零信任原则：

   • 设备合规性：通过Microsoft Intune等工具，要求访问公司资源的设备必须合规（加密、密码、补丁等）。GoldenSAML攻击中，攻击者使用的设备很可能不符合要求。
   • 条件访问（CA）：配置严格的条件访问策略。例如：“对于从高风险IP登录的高权限用户，要求使用受管理的设备并进行多因素认证（MFA）”。注意：传统的MFA在GoldenSAML攻击面前是无效的，因为攻击者是在SAML断言层面伪造了“已认证”的用户。但是，基于设备状态和登录风险的CA策略依然能起到阻断作用。
   • 最小权限原则：严格限制应用程序和服务主体的权限。定期审查并清理不必要的API权限。

4. 定期攻击模拟与红队演练：

   • 定期使用类似我们今天的流程，在隔离环境中模拟GoldenSAML攻击。
   • 检验你的检测规则是否能告警，你的蓝队是否能响应。这比任何理论都有效。

通过这次从原理到实践，从攻击到检测的完整旅程，我希望你收获的不仅仅是对GoldenSAML这个特定攻击的理解，更是一套使用像Security-Datasets这样的开源资源进行威胁研究、检测工程和防御加固的方法论。安全是一个动态对抗的过程，唯有持续学习、亲手实践，才能构筑起有效的防线。