红队行动Live-20241203

📚 目录

1. 开篇与本周攻击目标概述

• 1.1 ADFS (Active Directory Federation Services) 攻击

• 1.2 不安全参数设置利用 (可能为 IOD)

• 1.3 ServiceDesk 应用攻击 (192.168.21.123)

2. ADFS 深入理解与利用策略

• 2.1 ADFS 的核心价值与攻击动机

• 2.2 从信息收集到攻击链构建 (微软官方文档学习)

• 2.3 ADFS 内部机制与关键数据结构

• 2.4 ADFS 与云认证 (OpenID Connect, OAuth) 的关系

• 2.5 ADFS 攻击核心思路：提取凭据与伪造令牌

• 2.6 ADFS 支持的协议 (SAML, WS-Federation 等)

3. ADFS 攻击工具与实践

• 3.1 ADFSDump 工具介绍与编译要求

  • 3.1.1 工具来源与开发者 (Mandiant/Google)

  • 3.1.2 编译环境 (.NET Framework 4.5, Visual Studio)

  • 3.1.3 运行上下文：ADFS 服务器本地，服务账户权限

• 3.2 ADFSDump 执行与信息提取

  • 3.2.1 导出加密密钥 (DKM) 与配置数据库 (WID/SQL Express)

  • 3.2.2 识别联合认证的应用 (Relying Parties) 如 ServiceDesk

• 3.3 ADFSSpoof 工具介绍与令牌伪造

  • 3.3.1 工具作用：利用导出的密钥和配置伪造 SAML 令牌

  • 3.3.2 伪造令牌所需参数详解 (PfxBlob, DKM, Endpoint, Identifier, NameID, Issuer 等)

  • 3.3.3 理解 SAML 语言与数据结构的重要性

• 3.4 Golden SAML 攻击概述

• 3.5 ADFS 攻击的复杂性与调试

  • 3.5.1 时间同步问题对令牌生成的影响

  • 3.5.2 防御机制 (Defender 运行时查杀) 与免杀挑战

4. 不安全对象直接引用 (IOD) 作为备选路径

• 4.1 IOD (Insecure Object Direct References) 概念回顾

• 4.2 IOD 常见表现形式

  • 4.2.1 URL 参数篡改 (ID, 订单号, 账号)

  • 4.2.2 API 端点参数修改

  • 4.2.3 Cookie/Session 篡改与劫持

  • 4.2.4 文件路径遍历/包含 (更广义的 IOD 视角)

• 4.3 IOD 与其他漏洞的结合 (如 SSRF)

• 4.4 当前场景下的 IOD 利用可能 (ServiceDesk)

5. ServiceDesk 应用攻击通用思路

• 5.1 目标：获取系统 Shell 或敏感数据

• 5.2 寻找可控点 (通用策略)

  • 5.2.1 执行脚本/命令 (如计划任务、系统检查功能)

  • 5.2.2 文件上传 (插件、附件、头像等)

  • 5.2.3 配置修改 (数据库连接、模板编辑、API接口)

  • 5.2.4 数据库直接访问/注入

• 5.3 定位公开漏洞 (CVE, Exploit-DB, GitHub, Google)

• 5.4 Payload 武器化 (结合收集信息、约束条件、免杀)

• 5.5 关注系统配置、管理中心、仪表盘、插件管理等高权限区域

• 5.6 利用系统模块漏洞 (如低版本模块可被重新安装利用)

6. 总结与后续安排

• 6.1 本周任务：尝试 ADFS 转储/伪造或 IOD 路径突破 ServiceDesk

• 6.2 周六实操预告 (ServiceDesk 权限获取)

---

1. 开篇与本周攻击目标概述

新的一周开始，本周（周二及后续）的核心攻击目标将围绕以下几个方面展开，旨在推进当前域渗透的进度：

1.1 ADFS (Active Directory Federation Services) 攻击

• 背景: 上周通过 Kerberoasting 获得了 adfs_svc 账户凭据，并成功通过 PS Remoting (在 Parrot OS 环境下) 登录了 192.168.20.15 (ADFS 服务器)，但获得的是一个 JEA 受限 Shell。

• 目标: 深入理解 ADFS 的原理和利用方式，尝试从该服务器提取敏感信息或利用其特性进行横向移动或权限提升。

1.2 不安全参数设置利用 (可能为 IOD)

• 这是一个备选的攻击路径，暗示了可能存在不安全的对象直接引用 (IOD) 或类似的参数配置漏洞，可以被利用来绕过某些限制或获取非授权访问。

1.3 ServiceDesk 应用攻击 (192.168.21.123)

• 目标: 对 192.168.21.123 上运行的 ManageEngine ServiceDesk Plus 应用进行攻击。

• 关联: 之前发现该应用支持 SAML 单点登录，可能与 ADFS 服务相关联。

2. ADFS 深入理解与利用策略

2.1 ADFS 的核心价值与攻击动机

• ADFS 定位: 域内非常重要的企业级基础设施，用于实现联合认证 (Federated Authentication) 和单点登录 (Single Sign-On, SSO)。

• 攻击者视角: 任何提供认证和授权的服务都是高价值目标。ADFS 因其核心地位，一旦被攻破：

  • 可能泄露用于签名令牌的私钥，导致攻击者能伪造任意用户的身份。

  • 可能存储了信任关系配置，泄露与其他应用或组织的连接信息。

  • 可能获取到具有高权限的服务账户凭据。

• 攻击思路: 只要在内网中遇到 ADFS，就必须投入精力去尝试利用。

2.2 从信息收集到攻击链构建 (微软官方文档学习)

• 学习方法: 遇到未知或不熟悉的应用（如 ADFS），应首先查阅其官方文档（如微软 Learn 网站）来理解其功能、架构、关键组件和认证流程。

• 沉浸式思考: 将官方文档信息与渗透测试的攻击思路相结合，思考哪些特性可能被利用，哪些数据是敏感的，哪些流程可能存在缺陷。

2.3 ADFS 内部机制与关键数据结构

• 应用层基础设施: ADFS 是微软域环境下应用层面的认证基础设施，与底层的 LDAP、Kerberos 协同工作。

• 关键概念: 需要理解 ADFS 中的重要数据结构和参数，例如：

  • Relying Party Trusts (RPT): 信任方，指那些信任 ADFS 进行用户认证的应用程序或服务 (如 ServiceDesk)。

  • Claims Issuance Policies: 声明颁发策略，定义了 ADFS 如何为用户生成安全声明 (Claims)。

  • Token-Signing Certificate: 用于对 ADFS 颁发的安全令牌 (如 SAML 断言)进行签名的证书，其私钥是核心保护对象。

  • Token-Encrypting Certificate: 用于加密令牌内容的证书（较少见，但存在）。

  • Configuration Database: ADFS 的配置数据可以存储在 Windows Internal Database (WID) 或 SQL Server 中。

• 目标: 了解这些组件，才能知道在获得 ADFS 服务器权限后应该寻找什么，以及如何利用它们。

2.4 ADFS 与云认证 (OpenID Connect, OAuth) 的关系

• 现代认证协议: ADFS 也支持与现代的开放认证协议集成，如 OpenID Connect (OIDC) 和 OAuth 2.0，用于云应用和移动应用的身份验证与授权。

• 对比:

  • 云端SSO (Google, GitHub, 微信等): 主要提供身份标识的统一，用户使用已有账号登录第三方应用，避免重复注册。对应用本身的可控信息有限。

  • 企业级 ADFS: 在企业内网和私有云中，ADFS 能提供更深度的集成、更细致的策略控制和更丰富的声明信息，支持的协议和认证数据也更复杂。

• ADFS 的不可替代性: 在企业内部复杂认证场景下，ADFS 的功能比公有云SSO更为强大和灵活。

2.5 ADFS 攻击核心思路：提取凭据与伪造令牌

利用 ADFS 的核心思路主要有两种：

1. 提取敏感数据: 从 ADFS 服务器上导出关键信息，主要是令牌签名证书的私钥 (Token-Signing Certificate private key) 和 ADFS 配置数据库。

2. 伪造身份/令牌: 利用获取到的私钥和配置信息，伪造有效的安全令牌（如 SAML 断言），冒充任意用户登录集成了 ADFS 的应用程序。

2.6 ADFS 支持的协议 (SAML, WS-Federation 等)

• ADFS 支持多种标准的联合身份验证协议，其中最核心和常见的是：

  • SAML (Security Assertion Markup Language): 一种基于 XML 的开放标准，用于在不同安全域之间交换身份验证和授权数据（即声明断言）。是 Web 浏览器单点登录的常用协议。

  • WS-Federation: 另一种基于 Web 服务的联合身份验证协议。

  • OpenID Connect / OAuth 2.0: 用于现代 Web 应用和 API 的认证授权。

• 对 SAML 的理解: 由于 SAML 是 ADFS 攻击中的核心，攻击者需要对 SAML 断言的结构、关键字段（如 Issuer, Subject, Conditions, Attributes, Signature）以及XML签名的原理有一定的了解。

2.7 网络安全咨询和情报服务 等

• Mandiant 美国麦迪安网络安全公司
  Mandiant 现在是Google Cloud的一部分
  Commando VM
  

• Orange-Cyberdefense 欧洲的首选安全提供商
  GOAD
  

• 埃森哲 网络安全
  分析师界的全球领导者

3. ADFS 攻击工具与实践

3.1 ADFSDump 工具介绍与编译要求

• 工具作用: 用于从 ADFS 服务器导出配置信息、令牌签名证书私钥和相关的 Relying Party Trust 信息。

• 来源与开发者: 由 Mandiant (现 Google Cloud 子公司) 的安全研究人员开发并开源。

• 下载连接: https://github.com/mandiant/ADFSDump

• 编译要求:

  • 语言: C#

  • 框架: 需要特定版本的 .NET Framework (如 4.5)。

  • 工具: Visual Studio。

  • 重要性: 渗透测试人员需要具备编译此类 C# 工具的能力，
    因为很多针对 Windows 的高级利用工具都是以源码形式发布的，
    不直接提供可执行文件（出于安全和避免滥用考虑）。

• 运行上下文:

  • 必须在已攻陷的 ADFS 服务器上本地运行。

  • 需要具有能够访问 ADFS 配置数据库 (WID 或 SQL Server) 和证书存储的权限，通常是 ADFS 服务账户的上下文或本地管理员权限。

3.2 ADFSDump 执行与信息提取

• 默认执行: ADFSDump.exe --domain <DOMAIN> --server <DC_FQDN> (在 ADFS 服务器上运行，指定域和DC)。

• 主要导出内容:

  • ADFS 配置数据库信息 (通常是 WID，Windows Internal Database，一种基于 SQL Server Express 的文件数据库)。

  • 令牌签名证书 (Token-Signing Certificate) 及其私钥，通常以 PFX (PKCS#12) 格式的 Base64 编码字符串形式导出。

  • 加密的 DKM (Distributed Key Management) 主密钥 (如果使用)。

  • Relying Party Trusts (RPT) 列表及其配置细节，例如哪些应用程序信任此 ADFS 进行身份验证。

• 主要相关文章

  • https://www.hunters.security/en/blog/adfs-threat-hunting-2-golden-saml

  • https://www.orangecyberdefense.com/global/blog/cloud/exploring-the-golden-saml-attack-against-adfs

  • https://www.netwrix.com/golden_saml_attack.html

3.3 ADFSSpoof 工具介绍与令牌伪造

• 工具作用: 与 ADFSDump 配套使用，利用从 ADFSDump 获取到的令牌签名证书私钥和 RPT 配置，来伪造 SAML 令牌，冒充指定用户访问特定的 Relying Party (应用程序)。

• 编译要求: 通常也是 C# 编写，可能需要 Visual Studio 和 .NET Framework。

• 下载链接: https://github.com/mandiant/ADFSpoof

• 伪造令牌所需参数详解: (命令行参数可能非常多且复杂)

  • PfxBlob: 从 ADFSDump 获取的 Base64 编码的 PFX 证书数据。

  • PfxPassword: PFX 文件的密码 (通常是 "adfs" 或默认值，ADFSDump 会尝试恢复)。

  • DkmKey (可选): 如果 DKM 用于保护私钥，需要提供。

  • TargetRelyingParty: 目标应用程序的标识符 (Relying Party Identifier)。

  • NameIdentifier: 要冒充的用户的标识 (如 UPN)。

  • AuthMethod: 认证方法 (如 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport)。

  • Issuer: ADFS 服务的颁发者 URI。

  • 其他声明 (Claims) 参数，如角色、组等。

• 理解 SAML 语言与数据结构的重要性:

  • 要成功构造 ADFSSpoof 的参数并理解其输出，必须对 SAML 断言的 XML 结构、各字段含义（如 <Issuer>, <Subject>, <NameID>, <Conditions>, <AttributeStatement>, <Signature>）有所了解。

  • 否则，使用工具会像“拼积木”或“照猫画虎”，难以排错或适应变化。

3.4 Golden SAML 攻击概述

• 核心: 利用窃取的 ADFS 令牌签名私钥，攻击者可以为任何用户（包括不存在的用户或高权限用户）创建完全有效的 SAML 断言，并用其访问任何信任该 ADFS 的应用程序（包括云服务如 Office 365, Azure, AWS 等）。

• 威力: 类似于 Kerberos Golden Ticket，是一种持久的、难以检测的域级/联邦级权限维持和访问方式。

3.5 ADFS 攻击的复杂性与调试

• 时间同步问题对令牌生成的影响:

  • 伪造 SAML 令牌时，令牌的有效期 (NotBefore, NotOnOrAfter) 和时间戳非常重要。

  • 如果攻击机、ADFS 服务器、目标应用程序服务器之间存在显著的时钟偏差，生成的令牌可能会因无效（未到生效时间或已过期）而被拒绝。

  • 解决方案: 确保攻击机与目标域的域控制器（通常是 ADFS 服务器的时间源）进行时间同步 (sudo ntpdate <DC_IP>)。注意，直接与 ADFS 服务器同步可能因 UDP 隧道限制而失败，应优先同步 KDC。

• 防御机制 (Defender 运行时查杀) 与免杀挑战:

  • 靶场环境更新后，在 ADFS 服务器上运行 ADFSDump.exe 等工具可能受到 Windows Defender 的运行时查杀。

  • 这与静态文件查杀不同，是工具在内存中执行恶意行为时被检测。

  • 应对: 需要免杀技术。如果当前阶段不想引入复杂的免杀内容，可以暂时搁置此路径，或寻找 PowerShell 版本的工具（可能检测率较低）。

4. 不安全对象直接引用 (IOD) 作为备选路径

4.1 IOD (Insecure Object Direct References) 概念回顾

• OWASP Top 10 常见漏洞类型。

• 定义: 当应用程序使用用户提供的输入来直接访问对象（如数据库记录、文件、URL 参数）时，如果未对该输入进行充分的授权验证，就可能允许攻击者修改输入以访问其本无权访问的数据。

4.2 IOD 常见表现形式

• URL 参数篡改: 修改 URL 中的 ID 号、订单号、账户号等参数，尝试访问属于其他用户的数据。

  • 例：viewOrder.jsp?orderID=123 -> viewOrder.jsp?orderID=124

• API 端点参数修改: 修改 API 请求中的资源标识符。

• Cookie/Session 篡改与劫持: 修改 Cookie 中的用户 ID 或 Session ID，尝试冒充其他用户。

• 文件路径遍历/包含 (更广义的 IOD 视角): 用户提供的输入被用于构建文件路径，若未过滤 ../ 等字符，可访问任意文件。虽然常单独分类，但其本质也是对文件对象的非授权直接引用。

4.3 IOD 与其他漏洞的结合 (如 SSRF)

• IOD 可以与 SSRF (Server-Side Request Forgery) 结合产生更大危害。

• 场景: 某个 API 端点只在内部网络暴露，但可以通过 SSRF 漏洞从外部访问到这个内部 API。如果该内部 API 又存在 IOD 漏洞，攻击者就可以通过 SSRF -> IOD 的链条访问内部敏感数据。

4.4 当前场景下的 IOD 利用可能 (ServiceDesk)

• 目标: 192.168.21.123 上的 ManageEngine ServiceDesk Plus。

• 思路: 如果 ADFS 路径因防御或时间同步问题暂时受阻，IOD 可能成为攻击 ServiceDesk 的备选方案。需要检查 ServiceDesk 的各项功能，看是否存在用户可控的参数能直接引用内部对象，并尝试修改这些参数以访问越权数据或功能。

• 前提: 需要能访问 ServiceDesk 应用并理解其参数传递方式。

5. ServiceDesk 应用攻击通用思路

当获得对一个内容管理系统 (CMS)、企业资源规划 (ERP)、客户关系管理 (CRM) 或类似的企业应用（如 ServiceDesk）的访问权限（即使是低权限）后，通用的攻击思路是寻找可控点以提升权限或获取敏感信息，最终目标通常是获取服务器的 Shell。

5.1 目标：获取系统 Shell 或敏感数据

5.2 寻找可控点 (通用策略)

寻找应用中允许用户输入或配置，并可能与后端系统交互的功能点：

1. 执行脚本/命令:

   • 计划任务、定时报告、系统检查、自定义脚本执行接口。

   • 某些运维功能可能直接提供命令行接口。

2. 文件上传:

   • 插件、主题、模板、附件、用户头像、导入数据等功能。

   • 尝试上传 Webshell、恶意脚本或可执行文件。

   • 注意文件类型、大小、路径限制及绕过。

3. 配置修改:

   • 数据库连接字符串修改（可指向攻击者控制的恶意数据库或执行命令）。

   • 模板文件编辑（可插入恶意代码）。

   • API 接口配置、外部服务集成配置。

   • 日志路径或格式配置（可能导致日志污染或写入 Webshell）。

4. 数据库直接访问/注入:

   • 如果应用提供数据库查询接口，尝试 SQL 注入。

   • 如果能修改数据库连接配置，可能直接连接并操作数据库。

5.3 定位公开漏洞 (CVE, Exploit-DB, GitHub, Google)

• 针对应用的具体版本 (ServiceDesk Plus v11.1) 搜索已公开的漏洞和利用代码。

5.4 Payload 武器化 (结合收集信息、约束条件、免杀)

• 根据发现的可控点或漏洞，以及目标环境的约束（如杀软、防火墙、WAF），构造和优化 Payload。

• 强调将信息收集、对环境的理解、对约束条件的认知整合到 Payload 构建中，这是一个“武器化”的过程，而不仅仅是简单的“构造”。

5.5 关注系统配置、管理中心、仪表盘、插件管理等高权限区域

这些区域通常拥有更多与系统底层交互的功能，是漏洞的高发区。

5.6 利用系统模块漏洞 (如低版本模块可被重新安装利用)

• 如果应用允许安装或管理模块/插件，检查是否存在已知漏洞的旧版本模块。

• 有时可以将存在漏洞的旧版本模块重新上传安装，从而利用其漏洞。

6. 总结与后续安排

6.1 本周任务：尝试 ADFS 转储/伪造或 IOD 路径突破 ServiceDesk

学员在本周需要尝试以下路径：

1. ADFS 路径 (主线):

   • 在 ADFS 服务器 (192.168.20.15) 的受限 Shell 中，尝试使用 ADFSDump 导出数据。

   • 如果成功导出，尝试使用 ADFSSpoof 伪造令牌。

   • 注意解决时间同步和潜在的 Defender 免杀问题。

2. IOD/ServiceDesk 路径 (备选):

   • 如果 ADFS 路径暂时不通，研究 ServiceDesk 应用 (192.168.21.123)，寻找 IOD 漏洞或利用其已知漏洞/可控点。

6.2 周六实操预告 (ServiceDesk 权限获取)

• 周六将重点演示 ServiceDesk 的权限获取过程。

• PowerShell 相关的深入学习（枚举、复杂命令等）将安排在后续节奏稍缓时进行。

• 即使 ADFS 路径因免杀等原因暂时搁置，靶场设计上仍有其他路径可以推进。

-.-