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令牌的密钥材料。具体来说主要针对两种密钥令牌签名证书在Azure AD中这可能是用于签署SAML令牌的证书的私钥。攻击者可能通过漏洞如Golden SAML漏洞本身通常与ADFS相关、权限提升或内部人员泄露等方式获取。应用程序的客户端密钥在某些场景下攻击者可能窃取了一个已注册企业应用程序的客户端密钥Client Secret或证书。结合足够高的权限如Application.ReadWrite.All他们可以修改该应用的SAML单点登录配置上传自己的签名证书。一旦攻击者掌握了有效的签名密钥他们就可以“锻造”出任何SAML响应。他们可以声称自己是任何用户包括高管、特权账户访问任何配置了基于该IdP进行SAML认证的云应用如Office 365, Salesforce, AWS SSO等。因为SP端验证签名是通过IdP的公钥证书而这个证书是公开且受信的所以伪造的令牌会畅通无阻。2.3 典型攻击链分解一个完整的GoldenSAML攻击链通常包含以下几个阶段每个阶段都会在日志中留下痕迹初始入侵与立足通过钓鱼邮件、漏洞利用等方式获取一个初始立足点如一台加入域的工作站。日志体现为可疑的登录、进程创建、网络连接。横向移动与权限提升在内部网络横向移动目标是获取域管理员或类似的高权限账户以访问IdP服务器或具备访问云身份目录如Azure AD所需权限的账户。日志体现为大量的横向移动命令如PsExec, WMI、Kerberos票据请求、权限提升事件。密钥材料窃取这是GoldenSAML的核心。攻击者使用高权限账户通过特定工具或API调用从IdP如ADFS服务器导出令牌签名证书的私钥或从Azure AD中读取/修改应用程序的证书配置。这是我们需要重点检测的“关键动作”。令牌伪造与滥用攻击者在自己的机器上使用窃取的密钥使用如ADFSDump、Mimikatz针对ADFS或ROADtools等工具伪造SAML响应。然后他们使用这个伪造的令牌向云应用发起认证请求。日志体现为从非企业IP、非常用设备发起的、但携带“有效”SAML断言的登录事件。目标达成与数据渗出成功以高权限用户身份访问云应用如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或身份认证攻击相关的数据集。访问仓库在GitHub上搜索Security-Datasets或直接访问其项目页面。寻找相关数据集在目录中查找如APT29、GoldenSAML、AzureAD、CredentialAccess等关键词。一个高质量的数据集通常会包含一个清晰的README描述攻击场景、包含的日志源如Windows Security, Sysmon, Azure AD SigninLogs以及攻击的时间线。下载与解压下载数据集的压缩包通常是JSON或EVTX格式。例如你可能找到一个名为APT29_GoldenSAML_Simulation.zip的数据集。数据预览使用文本编辑器、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服务器窃取令牌签名证书。实验步骤在攻击者机器上使用域管理员凭证通过PsExec或WMI连接到ADFS服务器。上传Mimikatz到ADFS服务器。执行命令mimikatz.exe privilege::debug crypto::certificates /export exit。这个命令会尝试导出系统存储中的证书及其可能的私钥。日志分析重点对照Security-DatasetsWindows安全日志 (EventID 4688)会记录PsExec或WMI远程创建进程的事件。注意ParentProcessName可能是svchost.exeWMI或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响应。实验步骤编写伪造脚本使用Python的signxml库构建一个基本的SAML响应XML结构。关键字段包括Issuer设置为你的IdP实体ID如https://sts.windows.net/tenant-id/。NameID设置为目标用户如ceocompany.com。Assertion属性包含认证时间、会话索引等。使用窃取的私钥对整个Assertion进行签名。发起认证请求模拟浏览器向Office 365的登录端点https://login.microsoftonline.com发送一个包含伪造SAML响应的HTTP POST请求。这可以通过编写Python的requests脚本完成需要正确模拟SAML的RelayState和SAMLResponse表单提交。使用工具简化也可以使用修改版的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可能是falseTrustType可能是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中以下关键信息存储在哪个字段安全概念Security-Datasets / OSSEM 常见字段名在Splunk中的可能字段在Elastic中的可能字段在Azure Sentinel中的字段进程创建process.command_line,process.parent.nameCommandLine,ParentProcessNameprocess.command_line,process.parent.nameProcessCommandLine,ParentProcessName用户登录user.name,user.domainuser,domainuser.name,user.domainAccountName,AccountDomain源IP地址source.ipsrc_ipsource.ipSourceIPAddress目标应用file.path,url.originalImage,dest_urlfile.path,url.originalTargetFilePath,RequestURLSAML颁发者token.issuer.name自定义解析token.issuer.nameTokenIssuerType(Azure AD日志)分析数据集时对照上表理解每个事件对应的字段。这能确保你写的规则在你的环境中能正确触发。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 organizations 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查询语言。例如转换为KQLsigma convert -t azure -c tools/config/azure-unsupported.yml rule.yml。5.3 在SIEM中验证与优化规则将生成的查询如KQL粘贴到你的SIEM中执行。时间范围首先针对Security-Datasets提供的日志文件时间范围运行验证规则是否能准确抓取到数据集中的攻击事件。这是验证规则有效性的第一步。误报分析将规则在更长时间范围比如过去7天的生产或模拟环境日志中运行。查看触发警报的事件。分析它们是否是误报。如果是误报回到Sigma规则中优化filter部分。可能需要添加更多的排除条件如特定的用户组测试账户、特定的源IP范围跳板机、特定的应用程序ID等。调整阈值与关联有些行为单次出现可能是误报但频繁出现就是高危。例如可以修改规则为“在15分钟内同一源IP对多台服务器尝试执行可疑命令行工具”。这需要SIEM支持关联规则或你使用更复杂的查询。建立仪表板将关键检测规则的结果可视化。创建一个仪表板监控“异常SAML颁发者”、“关键服务器上的可疑进程”、“高权限账户的异常登录地点”等指标。6. 高级狩猎与行为关联分析单一的检测点容易被绕过。高级的威胁狩猎需要将攻击链上的多个低置信度指标关联起来形成高置信度的警报。6.1 构建攻击时间线利用Security-Datasets中标注了时间戳的事件我们可以重建攻击者的行动序列。例如T1来自外部IPX对用户A的成功密码喷射攻击EventID 4624LogonType 3多次失败后成功。T2 (30分钟后)用户A从IPX通过PowerShell Remoting连接到服务器SRV-ADFSEventID 4688ParentProcessName为svchost.exeNewProcessName为powershell.exe。T3 (2分钟后)在SRV-ADFS上创建进程mimikatz.exe命令行包含crypto::certificatesSysmon EventID 1。T4 (1小时后)从完全不同的IPY可能为攻击者基础设施发起的以高管用户B身份成功的SAML登录到Office 365且令牌颁发者异常Azure AD Signin Logs。这个时间线清晰地描绘了从初始入侵到GoldenSAML攻击完成的路径。在SIEM中你可以编写一个关联规则来检测这种跨主机、跨日志源的模式。6.2 基于用户实体行为分析UEBA的思路即使攻击者使用了伪造的令牌他们的“行为”也可能露出马脚。我们可以利用数据集来训练或定义异常行为登录时间异常用户通常在上午9点到下午6点从本地登录。但数据集中的攻击登录发生在凌晨2点。资源访问模式异常用户BCEO平时主要访问邮箱和日历。但攻击后日志显示其短时间内密集访问了所有下属的OneDrive目录和SharePoint管理站点。地理跳跃不可能用户A在伦敦刚完成本地登录5分钟后就从新加坡的IP发起了SAML登录。这是物理上不可能的。这些分析依赖于对用户和历史日志建立基线。Security-Datasets虽然是一次性数据集但可以启发你思考应该收集哪些数据来建立这些基线如Azure AD的UserInsights或者自己计算用户登录的地理位置、时间、应用使用的频率分布。6.3 模拟数据与生产数据的结合Security-Datasets是完美的训练集。你可以将数据集导入你的SIEM的测试或开发环境。运行你编写的检测规则和狩猎查询确保它们能命中数据集中标记的恶意事件。将优化后的规则部署到生产环境的SIEM中。持续监控生产环境中的警报并将确认的误报和漏报反馈回来进一步优化你的检测逻辑。这个过程就是检测工程的闭环。7. 防御纵深与缓解措施探讨检测是最后一道防线我们更应该思考如何从架构上增加攻击者的成本这就是防御纵深。保护密钥存储对于ADFS将令牌签名证书存储在硬件安全模块HSM中。定期轮换证书虽然GoldenSAML攻击在证书有效期内都有效但轮换可以限制暴露窗口。严格限制对ADFS服务器的物理和网络访问以及本地管理员权限。对于Azure AD应用程序证书使用Azure Key Vault存储证书并配置基于角色的访问控制RBAC和Just-In-TimeJIT访问策略。避免将证书文件存储在代码仓库或文件共享中。强化监控与告警启用并集中收集所有关键系统的日志域控制器、ADFS服务器、Azure AD审计日志与登录日志。实施我们上面编写的Sigma规则并确保警报能及时送达安全团队。为高权限账户全局管理员、应用程序管理员等启用特权身份管理PIM要求进行实时审批才能激活权限。实施零信任原则设备合规性通过Microsoft Intune等工具要求访问公司资源的设备必须合规加密、密码、补丁等。GoldenSAML攻击中攻击者使用的设备很可能不符合要求。条件访问CA配置严格的条件访问策略。例如“对于从高风险IP登录的高权限用户要求使用受管理的设备并进行多因素认证MFA”。注意传统的MFA在GoldenSAML攻击面前是无效的因为攻击者是在SAML断言层面伪造了“已认证”的用户。但是基于设备状态和登录风险的CA策略依然能起到阻断作用。最小权限原则严格限制应用程序和服务主体的权限。定期审查并清理不必要的API权限。定期攻击模拟与红队演练定期使用类似我们今天的流程在隔离环境中模拟GoldenSAML攻击。检验你的检测规则是否能告警你的蓝队是否能响应。这比任何理论都有效。通过这次从原理到实践从攻击到检测的完整旅程我希望你收获的不仅仅是对GoldenSAML这个特定攻击的理解更是一套使用像Security-Datasets这样的开源资源进行威胁研究、检测工程和防御加固的方法论。安全是一个动态对抗的过程唯有持续学习、亲手实践才能构筑起有效的防线。