Ostorlab 与人工渗透测试：更多严重发现、更短时间、更低成本

Ostorlab 将通常需要测试人员调查应用行为、提出攻击假设、执行测试并验证影响的渗透测试工作自动化。对于采购人工渗透测试的应用安全团队，比较的重点是在相同范围内，Ostorlab 能否发现更多严重漏洞、更快交付结果并降低评估成本。

据我们团队报告，在每一次已完成的并行对比概念验证中，Ostorlab 都比同期开展的人工渗透测试发现了更多严重漏洞，更早完成测试，成本为人工测试的十分之一至四十分之一。 已完成的对比涵盖移动应用、Web 应用、源代码和 Active Directory 测试。

Ostorlab 与人工渗透测试：团队报告的 PoC 结果

这些结果来自我们团队在特定范围和访问条件下开展的项目，并非独立基准测试，也不是对其他应用的保证。本文未公布样本数量、逐项匹配的发现数量、项目时长或成本明细。因此，报告的成本范围不能用来预测您的总体节省；在您的范围内进行比较时，应计入准备、人工复核、复测和工程投入。

技术案例说明了 Ostorlab 结果背后的调查与验证工作。在一次移动应用评估中，智能体从 Flutter iOS 二进制文件提取凭据，测试其允许访问的 API 受众，并验证了身份管理 API 的访问权限。在一次企业应用评估中，智能体在没有客户端密钥的情况下获取管理令牌，并使用该令牌访问了可执行外部提供的服务器端代码的功能。这些案例展示了客户聘请渗透测试人员执行的调查工作。

对比背后的技术证据

以下匿名化案例来自 Ostorlab 发现记录和执行历史，说明平台调查并确认了什么。它们没有指出某位人工测试人员漏掉了哪些发现，也不能独立证实汇总对比结果；本文未公布客户级评分记录或审计报告。

移动应用凭据案例及无密钥令牌到服务器端执行的链路详见案例 1–3。补充技术证据涵盖注册、签名和日志问题，其中还包含一个独立的 AD 实验环境案例，供评估内部测试的读者参考；它不属于客户对比证据。代码片段使用合成值，用于说明所报告的机制，而非复现捕获的客户交互。

在安排沟通前，您可以先查看 Web 示例报告或移动应用示例报告，了解交付物。

案例 1：泄露的移动应用凭据访问了租户管理 API

Ostorlab 评估了一款使用 Flutter 构建的 iOS 应用。该应用使用 Auth0 机器到机器凭据获取 API 访问令牌。编译后的应用二进制文件包含 client_id 和 client_secret，这些值在构建时通过 Flutter 的 DART_DEFINES 机制传入。评估测试了这些凭据是否有效，以及它们可以访问哪些 API。

预期边界。 机器到机器凭据的权限应限制在服务所需的单个受众和操作集合内。嵌入已分发客户端的凭据不能被视为秘密；任何能够获取构建版本的人都可以取得它。因此，评估既检查凭据是否仍然有效，也检查它还能向哪些服务进行身份验证。

调查过程。 智能体从 Mach-O 二进制文件提取凭据，并向租户的 /oauth/token 端点请求令牌。请求返回 HTTP 200 和一个已签名的 JWT；伪造凭据则返回 HTTP 401。令牌包含 read:TSC 权限范围、客户端凭据授权类型，以及可追溯至租户 JWKS 端点的签名密钥。

最初的发现被评为高危。记录还将其标为“Fixed & Verified”（已修复并验证），但本案例可用的材料没有说明具体修复或复测时间线。仅凭该标签，无法确认凭据已轮换或其访问权限已移除。

为评估应用所调用 API 之外的访问权限，Ostorlab 向同一令牌端点提交了针对 38 个候选受众的令牌请求。这里的受众表示请求访问的 API。针对租户 Management API 受众的令牌请求返回 HTTP 200，令牌携带八项权限范围，包括 update:users、delete:users、create:users 和 create:client_credentials。对 Management API 的一次非破坏性 GET 请求返回了包含 1,000 条记录的用户目录的第一页，其中有电子邮件、电话号码、最近 IP 地址和登录行为。评估验证了这次读取，但未执行令牌允许的用户创建、更新或删除操作。

令牌端点接受了提取出的客户端凭据，并为内部服务受众和 Management API 受众签发令牌。随后的目录请求确认了通过 Management API 进行读取的权限。

HTTP 交互示例 · 主机、客户端和令牌均为合成值。

# The credential is extracted from the mobile binary.
POST /oauth/token HTTP/1.1
Host: tenant.example.invalid
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=MOBILE_CLIENT&client_secret=EXTRACTED_SECRET&audience=AUDIENCE_A
# Article outcome: a read:TSC token for the internal service.

POST /oauth/token HTTP/1.1
Host: tenant.example.invalid
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=MOBILE_CLIENT&client_secret=EXTRACTED_SECRET&audience=MANAGEMENT_API
# Article outcome: a token with eight management scopes.

GET /api/v2/users?per_page=100 HTTP/1.1
Host: tenant.example.invalid
Authorization: Bearer FAKE_MANAGEMENT_TOKEN

# Article outcome: the first page of a 1,000-record directory.

评估结果。 提取出的凭据可以获取内部服务和 Management API 的令牌。目录读取确认了个人信息访问权限；管理写权限仍未测试。因此，修复验证需要覆盖客户端允许的受众，而不能仅检查应用调用的 API。可用记录没有说明在这两项发现之间曾尝试哪种修复。

Ostorlab 自动化的工作。 此次评估结合了二进制分析、在线凭据验证、受众枚举和受控 API 读取。人工开展同样调查的测试人员需要执行并关联这些步骤。Ostorlab 确认了凭据在应用所调用 API 之外的实际可用权限，使应用安全团队获得了可确定优先级的已验证风险，以及范围更完整的复测要求。

修复方向。 从客户端移除并轮换密钥。审查客户端允许的受众和权限范围，将租户管理凭据与面向客户端的服务凭据分离。使在易受攻击配置下签发的令牌失效。复测应枚举客户端完整的授权范围，而不仅是应用调用的受众。

更详细的分析见 Agentic Deep Scan 案例研究。

案例 2：无密钥令牌请求获得管理访问权限

在一次企业应用评估中，Ostorlab 发现某身份服务配置可在没有客户端密钥的情况下签发管理令牌。调查确认了令牌可以使用：受保护的目录操作接受该令牌，并返回数百条组织成员资料。返回的过期信息显示，令牌有效期可能明显超过短会话时长，从而增加持久访问风险。

预期边界。 请求管理访问权限的客户端应先证明相应身份和权限。签发的令牌还需要适当限制受众、权限范围和有效期。测试同时检查签发和使用，因为这是两个独立的安全决策。

调查过程。 Ostorlab 使用客户端标识符和管理权限范围提交令牌请求，未提供客户端密钥。身份服务返回了 bearer 令牌。随后，Ostorlab 检查返回令牌的声明，并用它调用受保护的目录操作，获得了组织成员资料。

签发和接受是两个独立检查。评估验证了两者：无密钥令牌请求产生了一个受保护目录操作可以接受的凭据。

HTTP 交互示例 · 路由、字段值和令牌占位符均为合成内容。

# Request shape is illustrative; the article omits routes and exact fields.
POST /example/token HTTP/1.1
Host: identity.example.invalid
Content-Type: application/x-www-form-urlencoded

client_id=DEMO_CLIENT&scope=DEMO_ADMIN_SCOPE
# No client_secret and no client-authentication header.
# Article outcome: an administrative bearer token was issued.

GET /example/protected-directory HTTP/1.1
Host: directory.example.invalid
Authorization: Bearer FAKE_ISSUED_TOKEN

# Article outcome: protected access returned organizational profiles.
# Synthetic request shape; this is not a literal captured exchange.

评估结果。 测试证明，在不提供客户端密钥的情况下可以获得令牌，且该令牌会被受保护的目录操作接受。目录请求使用的是通过被测试签发路径获取的令牌，而非预先提供的管理员凭据。这建立了身份服务配置错误与未授权 API 访问之间的联系。

修复方向。 审查客户端身份验证要求和允许的授权类型；限制其权限范围与受众；按用途缩短有效期；并酌情使在易受攻击配置下签发的凭据失效。复测既应覆盖新的签发尝试，也应检查如何处理先前签发的凭据。

修复复测必须验证两项控制：令牌端点的客户端身份验证，以及受保护 API 的授权。

案例 3：集成功能执行了外部提供的服务器端代码

在同一次企业应用评估中，Ostorlab 使用案例 2 中的管理令牌，访问了供应商提供的 IAM 模块中的一项需身份验证的集成功能。该功能接受自定义 C#，并在应用服务器进程内编译。受控计时测试、子进程执行、主机诊断和出站网络检查证明，代码以应用的 IIS 应用池身份执行；该账户属于 BUILTIN\Administrators，并拥有 SeDebugPrivilege 和 SeImpersonatePrivilege。

预期边界。 扩展功能需要明确的信任模型：谁可以提供可执行代码、代码在哪里运行，以及它获得哪些权限。能够访问集成配置界面，本身不能构成允许外部代码在高权限应用进程中执行的合理信任边界。

调查过程。 智能体按照功能预期的接口进行测试，编写了实现该接口的探针，使载荷在构造函数运行前通过编译和类型检查。应用使用 Roslyn 在进程内编译源代码，通过 AssemblyLoadContext.Default.LoadFromStream() 加载生成的程序集，并通过 Activator.CreateInstance() 创建实例。

正常请求用于建立基线。构造函数载荷引入了受控延迟。记录的响应时间随请求的延迟递增：基线约为 122 ms；两秒、五秒和十秒探针对应的响应时间分别约为 2.13 s、5.14 s 和 10.15 s，重复探针呈现相同规律。后续测试记录了子进程执行、运行代码的身份，以及向测试人员控制的主机建立出站 DNS 和 TCP 连接的情况。

集成功能在其服务器进程中编译并实例化外部提供的 C#。阶梯式延迟测试支持构造函数已执行的结论；独立的子进程测试、主机诊断和出站连接检查确认了进一步影响。

C# 探针示例 · 应根据已授权测试环境所要求的集成接口进行调整。

using System;
using System.Threading;

public sealed class IntegrationProbe
{
    // Implements the interface the integration feature expects.
    public IntegrationProbe()
    {
        Thread.Sleep(2000);
        Console.WriteLine(Environment.UserName);
    }
}

// Compare baseline with 2, 5, and 10 second constructor delays.
// This snippet illustrates timing and identity diagnostics only.
// The article reports subprocess execution and egress from separate tests.

阴性对照。 智能体还测试了一个同类集成端点，该端点在实例化前强制执行类型限制。同一探针在编译或实例化之前即被拒绝，且未出现计时效应。此对照说明，两个集成端点在执行外部代码前采用了不同的验证。

评估结果。 计时测试证明了构造函数执行。独立的子进程、身份和出站连接测试确认了执行权限和网络访问。集成端点要求身份验证，该身份验证由案例 2 获取的令牌提供。已验证的顺序为：无密钥令牌签发、管理 API 访问，以及经过身份验证的服务器端代码执行。

修复方向。 将不可信集成放在高权限应用进程之外：

• 使用具有适当操作系统强制安全边界的独立工作进程。可回收的 AssemblyLoadContext 支持卸载程序集，但不是安全沙箱。Microsoft 说明了加载隔离与进程安全边界之间的区别。
• 为工作进程配置低权限身份、受限的密钥访问权限和出站连接允许列表。
• 限制可以创建或修改集成的主体。
• 复测授权、进程身份、受保护资源访问和禁止的出站连接。如果执行集成本就是预期功能，仅编译成功不代表修复失败。

Ostorlab 自动化的工作。 在案例 2 和 3 中，智能体需要将一项发现获得的凭据用于另一项测试，构造兼容集成接口的探针，比较计时结果，并确认进程权限和网络访问。这属于评估中的攻击链调查和影响验证。与人工渗透测试比较时，应评估双方是否发现并验证了完整路径，以及完成这些工作所需的时间和成本。

将 Ostorlab 与人工渗透测试并行运行

向 Ostorlab 和人工渗透测试提供方提供等同的目标、账户、访问权限和允许执行的操作，使您的团队能够在相同条件下比较调查过程和已验证的发现。在可行情况下，从具有代表性的预发布环境和专用测试账户开始。如果必须测试生产环境，应在执行前与应用负责人约定允许的操作、数据访问、流量限制和事件升级流程。在应用中发现连接，并不自动意味着获得了测试其身份提供商或分析服务的授权。

确定评估范围时，可使用以下运行计划：

这些事项需要与评估团队确认，并不意味着每项操作都会自动获得批准或自动撤销。

范围与操作控制

十月平台更新说明了范围指导、防火墙排除项、流量控制、监控和请求操作审批。范围白名单用于指导智能体，并不是强制网络边界。防火墙排除项会阻止已配置的地址和网络。监控可增加偏离检测和可选的停止机制。

审批设置控制智能体提交的决策请求。“Ask me, block if no answer”（询问我，无回复则阻止）让请求的操作等待决策；它并不要求每次工具调用前都由人工审核。操作人员必须根据项目配置这些设置。

执行窗口与停止条件

执行窗口规定日期、时间和时区。在窗口外创建的扫描会等待；可暂停的扫描在窗口关闭时暂停，并在下一个窗口恢复。不可暂停的扫描在窗口关闭后仍会继续，直到完成。将窗口结束时间作为操作截止时间之前，应确认所选扫描类型的行为。周期性计划还需要单独的最终停止条件。

支持的调度行为详见执行窗口文档。这些截图来自公开文档中的平台示例，并非匿名化评估中捕获的证据。

比较调查证据与交接

只有当您的团队能够验证发现时，发现数量才有意义。比较人工提供方的支撑证据与 Ostorlab 的调查记录，包括双方如何确认可利用性和影响。Ostorlab 的 AI Pentest 分析视图将计划和任务与记录的工具名称、参数、输出和时间戳关联起来。检查重要发现从最初假设到确认影响的响应的完整过程。报告应能够区分源代码追踪、成功的运行时测试和被阻断的攻击阶段。

交接应说明起始权限、已复现影响、未成功的分支、待完成检查和拟议修复。应在合并重复根因和攻击链后，统计独立且已验证的发现。不要将未经测试的假设计为已确认的严重漏洞。

执行记录也有助于操作人员验证清理。一项经审查的 Web 评估记录了支持会话的创建、检查、撤销以及再次检查以确认注销的过程。对配置变更、上传文件和已签发凭据，也应采用同样的流程。明确记录尚未处理的遗留项并指定负责人；记录操作不等于撤销操作。

将对比延伸至修复

对比应包含将发现转化为已验证修复所需的工作。Ostorlab 可提供定制修复建议，并通过受支持的代码仓库集成交付代码变更提案，从而将发现带入修复流程。开发人员在现有拉取请求流程中审查差异，运行相关检查，并通过后续测试评估修改后的应用是否解决了原始问题。

拟议修复应针对评估发现的控制问题。注册问题需要记录所有权检查；含凭据的日志需要修改日志记录与序列化调用点；无密钥令牌问题需要审查令牌签发及下游授权。

下表列出从案例推导的修复和复测标准，并不声称已经创建或合并任何具体补丁：

• Ostorlab Autofix 支持定制修复建议、通过拉取请求提交变更以及后续验证流程。
• 源代码测试将受影响路径和代码修订与修复关联起来。

生成的补丁仍需工程审查和适当测试。后续评估证据用于支持关闭发现；仅有变更提案或构建成功，不能证明可利用路径已经消除。

将该流程与人工渗透测试所包含的修复和复测服务进行比较。记录开发人员能否复现发现、实施拟议修复，并验证原始访问或执行路径已被阻断，同时记录您团队所需的投入。

将 Ostorlab 与您的人工渗透测试提供方进行比较

将报告的 PoC 结果作为待验证的主张：更多已验证的严重发现、更短测试时间和更低评估成本。有效对比应从相同构建版本、目标、账户、源代码访问权限、授权和排除项开始。约定评估窗口，并确定如何处理测试期间的变更。应记录未完成的项目和限制，而非将其从结果中删除。

授权 PoC 前，要求提供明细报价，说明包含项目、用量限制、超额条款、复测额度和客户准备工作。范围和访问权限确认后，再约定交付日期。使用这些条款和实际投入，判断已完成 PoC 中报告的评估成本优势能否转化为您团队更低的总成本。

替换现有渗透测试前需要确认的问题

Ostorlab 在我们的测试计划中承担什么角色？ 通过初始并行评估，确定它能在您的范围内承担哪些应用测试活动：已认证工作流测试、跨应用和 API 调查，以及变更后的重复测试。范围、业务意图、争议发现、操作决策和修复验收仍由人员负责。对约定覆盖范围之外的活动保留专项测试。根据发现、交付、成本和保证要求，决定 Ostorlab 可以替代当前人工项目的哪些部分。

是否必须提供源代码？ Ostorlab 支持移动应用构建版本、Web 应用、API 和源代码测试。移动凭据案例从已发布二进制文件开始；签名和日志案例使用了源代码访问权限。应明确约定评估模式。仅审查源代码不能证明在线后端的行为，而仅开展运行时测试与源代码辅助评估具有不同的可见性。

我们的团队需要准备什么？ 提供构建版本或目标 URL、已授权服务、角色分离的测试账户、有代表性的测试数据，以及相关 API 或工作流文档。对于登录后的流程，与评估团队安排所需的 MFA 或 OTP 测试配置。指定应用负责人、操作人员，以及负责复现和复测的工程联系人。在确定范围时确认准备投入。

我们的代码、凭据和证据会被送到哪里？ 与安全和采购团队一起审查信任中心和本地部署扫描选项。在提供敏感材料前，确认所选部署方式、模型提供方、数据流、保留策略和访问控制；不要假设每种部署的安排都相同。

报告能否满足外部保证要求？ 与要求评估的一方共同审查示例报告。在变更现有项目之前，确认所需范围、方法、测试人员资质或独立性、人工审核、报告和复测证据。要求 Ostorlab 明确拟议服务中包含的人工验证与签署。仅有技术发现，不能证明报告符合所有保证要求。

在下一次人工渗透测试中对比 Ostorlab

Ostorlab 报告的人工渗透测试对比优势是更多严重发现、更短测试时间和更低评估成本。案例展示了平台能够执行的技术工作：跨 API 调查凭据、串联身份和执行弱点，并通过记录的测试验证影响。针对您应用的对比，应确认这些能力是否改善当前渗透测试的结果和成本效益。

准备一个有代表性的应用、其连接的 API，以及现有人工渗透测试范围。在范围讨论中约定：

1. 输入： 构建版本或 URL、测试账户和角色、纳入范围的源代码访问权限、文档、授权和排除项。
2. 交付物： 包含已复现发现及证据限制的报告、调查记录访问权限、拟议修复，以及约定的清理和复测交接。
3. 成功标准： 已验证发现与重叠情况、可用结果交付时间、总成本和工程投入，双方采用相同定义。
4. 承诺： 测试开始前明确书面范围、运行计划、交付日期、明细报价和各项负责人。

预约 Ostorlab 与人工渗透测试对比 PoC ，为您的应用约定等同范围、成功标准和商业条款。如果您希望先查看证据格式，可以从 Web 示例报告或移动应用示例报告开始。

补充技术证据

以下章节记录了注册授权、移动签名、移动日志，以及一个独立的 Active Directory 实验环境评估。每节均说明测试方法、观察到的结果和仍需进行的验证。

注册记录所有权：未授权读取和写入；激活仍被阻断

在一次自助注册评估中，Ostorlab 跟踪了记录获取和密码创建的工作流。匿名会话可以获取属于另一主体、由测试人员控制的记录，取得可用的 CSRF 令牌，并针对该注册记录提交密码创建请求。成功响应及持久化的记录版本变化证实了未授权写入。

预期边界。 工作流必须确认调用方有权对正在修改的特定注册记录执行操作。CSRF 令牌解决的是另一个问题：请求是否携带预期的浏览器会话令牌。拥有 CSRF 令牌不能证明调用方拥有请求中指定的记录。

调查过程。 智能体使用不同主体，包括匿名访客会话，测试为评估创建的记录。它获取其他主体的注册记录，取得会话的 CSRF 句柄，提交针对该记录的密码创建请求，然后再次读取记录检查最终状态。

CSRF 验证和记录授权解决不同问题。访客会话使用自己的 CSRF 令牌即可读取并修改其他主体的测试注册记录；但激活和登录阶段未完成。

HTTP 交互示例 · 两个主体和注册记录均由测试人员控制。

# Session A does not own test enrollment B.
GET /example/enrollments/TEST_RECORD_B HTTP/1.1
Cookie: guest=FAKE_SESSION_A

# Obtain FAKE_CSRF_A through the public enrollment flow.
POST /example/enrollments/TEST_RECORD_B/password HTTP/1.1
Cookie: guest=FAKE_SESSION_A
X-CSRF-Token: FAKE_CSRF_A
Content-Type: application/json

{"password":"SYNTHETIC_TEST_PASSWORD"}

GET /example/enrollments/TEST_RECORD_B HTTP/1.1
Cookie: guest=FAKE_SESSION_A

# Article: write accepted; record version changed on readback.
# Final activation and login did not complete.

步骤	证据	评估的边界
从非所有者会话读取测试注册记录	成功返回记录	记录保密性与所有权检查。
获取访客会话的 CSRF 令牌	可通过公开流程取得令牌	匿名调用方能否获得有效的请求令牌。
为其他主体的测试记录提交密码创建请求	创建响应成功	改变状态的操作是否得到授权。
再次读取记录	版本变化已持久化	初始响应之外的持久影响。
尝试最终激活和登录阶段	该阶段未完成	已验证攻击路径的限制。

证据能够证明什么。 评估确认了跨主体记录访问，以及在测试注册记录上预设凭据的能力。它也记录了攻击链停止的位置。在所评估部署中，最终激活和登录仍被阻断，因此本案例不声称已经完成对活跃用户账户的接管。

修复方向。 将每项注册操作绑定到获授权主体，或绑定到专门设计且范围严格受限的注册能力。在读取和写入时都检查这种绑定。验证记录、调用方和被修改身份字段之间的关系。回归用例应包括所有者、另一已认证用户、匿名会话，以及有效 CSRF 令牌与错误记录的组合。

注册缺陷属于授权失效：应用接受了携带有效 CSRF 令牌的请求，却未验证该会话是否有权访问或修改指定记录。

移动签名：密钥可恢复；后端是否接受签名尚未测试

在一次移动应用源代码 PoC 中，Ostorlab 追踪了从两个嵌入式字节数组重建的应用级 HMAC 签名密钥。签名覆盖时间戳和固定应用标记，而方法、路径和请求体均不在签名输入中。这是一项源代码层面的发现；要证明后端接受该签名，仍需进行运行时测试。

预期边界。 请求签名只能证明其密钥和签名消息所代表的属性。因此，审查检查了客户端如何取得密钥，以及哪些请求组成部分实际进入签名操作。

调查过程。 智能体从重建函数追踪到 API 请求构造器。恢复共享密钥所需的两个数组均随客户端分发。API 层随后使用重建值对时间戳和应用标记签名，再将签名放入请求头。

已发布的客户端包含重建共享密钥所需的材料。追踪到的签名覆盖时间戳和固定标记；方法、路径和请求体均未纳入签名输入。后端行为仍未测试。

伪代码示例 · 重建函数和 HMAC 辅助函数代指原始实现。

// Both embedded arrays are distributed with the client.
const sharedKey = reconstructKey(embeddedArrayA, embeddedArrayB);

// Simplified representation of the traced signing inputs.
const signedInput = timestamp + APP_MARKER;
const signature = hmac(sharedKey, signedInput);

headers["X-Example-Signature"] = signature;

// request.method is absent from signedInput.
// request.path is absent from signedInput.
// request.body is absent from signedInput.
// The reconstruction algorithm and header name are illustrative.
// Backend acceptance was not established by the source review.

源代码追踪	代码支持的安全结论
两个重建数组均存在于客户端	混淆未能阻止共享密钥被恢复。
请求构造器使用共享密钥	被追踪的调用点复用了同一签名材料。
向 HMAC 提供时间戳和固定标记	这些值被签名覆盖。
方法、路径和请求体未进入签名输入	签名未绑定这些请求组成部分。

证据能够证明什么。 审查确认了签名材料可恢复，并明确了签名消息的组成。它没有证明 bearer 身份验证或所有后端所有权检查都能被绕过。后端不在该源代码归档中，因此这些问题需要后续运行时评估。

修复方向。 重新审视对分发至每个客户端安装实例的密钥所赋予的信任。明确签名的安全目的、代表的身份、绑定的请求内容，以及服务器对时效性的检查。在服务器端明确执行用户和对象授权。在适当迁移中轮换已暴露的签名材料，同时修正底层设计。

源代码证据定位了密钥重建代码和签名字段。仍需通过运行时测试确定后端如何验证签名，以及其他控制是否阻止未授权请求。

移动日志：脱敏缺口已复现；在线传输尚未验证

在另一次 Android 评估中，Ostorlab 追踪了身份验证值从 OpenID 结果流经应用日志、脱敏函数和遥测序列化的路径。本地复现显示，在未识别的字段名称和字符串格式下，具有凭据形态的值通过了过滤器。记录指出了泄露路径和仍待执行的运行时检查。

预期边界。 身份验证材料在进入日志前应被排除或安全脱敏。过滤器需要处理应用实际使用的序列化形式，包括结构化字段和字符串表示。

调查过程。 源代码显示，身份验证成功路径上存在日志记录。一处调用将包含 cookie 值的请求头映射序列化；另一处将身份验证结果作为字符串写入日志。脱敏函数只能识别特定类 JSON 格式中的一组预定义字段。包含凭据的字符串不符合这些名称或格式。

本地复现包含阳性对照：已识别的授权和刷新令牌字段被成功脱敏，而存在问题的 cookie 和授权码形态字符串仍然保留。这一区别确认了一个基本正常运行的脱敏机制中的具体缺口。

同一过滤器能够遮蔽已识别的授权和刷新令牌字段，却遗漏 cookie 映射和身份验证结果字符串。源代码追踪延伸至遥测序列化；未观察到在线凭据传输或重放。

可在本地运行的示例 · 使用合成凭据和简化脱敏规则。

const mask = text => text.replace(
  /("(?:authorization|refresh_token)"\s*:\s*")[^"]*"/gi,
  '$1[REDACTED]"'
);

const known = '{"authorization":"FAKE_BEARER"}';
const refresh = '{"refresh_token":"FAKE_REFRESH"}';
const cookie = '{Cookie=FAKE_COOKIE}';
const result = 'AuthResult(code=FAKE_AUTH_CODE)';

if (mask(known).includes("FAKE_BEARER")) throw Error("control");
if (mask(refresh).includes("FAKE_REFRESH")) throw Error("control");
if (!mask(cookie).includes("FAKE_COOKIE")) throw Error("gap");
if (!mask(result).includes("FAKE_AUTH_CODE")) throw Error("gap");

// The known fields are masked; the cookie and code survive.
// This reproduces the failure class, not the original filter.

随后，Ostorlab 继续追踪生成的消息进入日志 SDK 序列化路径的过程。运行时流量捕获和凭据重放仍未完成，因此本文不将其描述为已观察到的在线凭据外泄或已完成的会话接管。

修复方向。 尽可能移除包含凭据的日志语句，并使结构化属性、序列化请求头和对象字符串表示的脱敏处理保持一致。除错误路径外，也应测试身份验证成功路径。在回归测试中使用合成密钥，并断言排队的日志事件及其传输形式均不包含这些值。

评估定位了身份验证日志调用点、脱敏规则遗漏的格式，以及序列化路径。这些位置确定了凭据脱敏所需的代码修改和回归测试。

独立 AD 实验环境：ACL 到证书的攻击链，以及未完成的清理

在一次 Active Directory 实验环境评估中，智能体从低权限域用户出发，枚举目录的访问控制范围。审查覆盖了用户、组、计算机和域根对象的 3,002 条 ACL 记录，发现了一条非继承的 WriteOwner ACE，使普通用户能够取得证书颁发机构服务账户的所有权。它是全部记录中唯一允许非 Tier-0 主体控制 Tier-0 对象的 ACE。

CA 服务账户属于 Cert Publishers，对一个证书模板拥有 GenericAll 权限，并且可通过 RC4 进行 Kerberoasting。

证书模板上的 GenericAll 授权构成 ESC4 条件：它允许智能体在以另一主体身份请求证书前，修改模板安全设置。服务账户上的 WriteOwner ACE 则是进入这条模板控制路径的独立入口。Cert Publishers 成员身份和可进行 RC4 Kerberoasting 属于额外暴露，并非 ESC4 步骤的前提条件。

预期边界。 CA 服务账户及其证书模板属于 Tier-0 对象。普通用户不应拥有这些对象；模板 ACL 应限制为 CA 和目录管理员；每次签发都应被记录且可撤销。CA 账户上的 WriteOwner ACE 不是常规委派。

调查过程。 智能体取得服务账户所有权，重写 DACL 为自己授予 GenericAll，并控制了该账户。它修改模板以允许注册，以管理员身份请求证书，使用该证书进行身份验证，并复制 krbtgt，随后伪造黄金票据。误签发的管理员证书仍未撤销。

一条非继承 ACE 使普通用户获得了 CA 服务账户的所有权。智能体将此所有权通过 ESC4 模板串联到证书签发和域复制。

执行伪代码示例 · 名称为合成值，并非真实工具语法。

# Lab: ordinary user -> CA service account -> template -> certificate -> DCSync.
# Names and values are synthetic.

ace = read_ace(target="svc-ca", trustee="user-a")
# One non-inherited WriteOwner ACE in 3,002 ACL rows.

seize_owner(target="svc-ca", as="user-a")
grant_generic_all(target="svc-ca", to="user-a")
reset_secret(target="svc-ca")

template = modify_template("CorpAuthTemplate", enroll="svc-ca")
cert = request_certificate(template, subject="Administrator")
session = authenticate_with(cert)
replicate_krbtgt(session)
forge_golden_ticket()

# The misissued administrator certificate was not revoked.

步骤	证据	评估的边界
枚举整个目录的 ACL	3,002 条记录；CA 服务账户上存在一条授予普通用户的非继承 WriteOwner ACE	Tier-0 对象是否与普通用户隔离。
取得所有权并重写 DACL	在运行环境中复现了所有权接管和 GenericAll 授权；写入已回滚，恢复后逐字节一致	ACE 是否可被利用，而不只是存在。
控制 CA 服务账户	该账户属于 Cert Publishers，并对模板拥有 GenericAll	服务账户权限是否延伸至证书签发。
修改模板并请求证书	存在 ESC4 条件；管理员证书被签发	模板 ACL 是否阻止以高权限主体身份注册。
使用证书进行身份验证并复制 krbtgt	域复制及黄金票据	基于证书的身份验证是否达到域控制器权限。
检查撤销状态	误签发的管理员证书仍未撤销	组织能否收回该凭据。

证据能够证明什么。 ACL 接管在运行环境中得到复现，且该账户权限能够影响 CA 会使用的模板。证书和复制阶段被记录为智能体的严重攻击链；评估结束时，误签发的证书仍未撤销。这是实验环境评估，不是客户结果或对比基准。未撤销的证书属于未完成的清理事项，不能作为已完成恢复的证据。同等项目需要指定负责人撤销证书并验证结果，然后才能确认清理完成。

评估结果。 控制 CA 服务账户后，可以访问并修改证书模板，以请求管理员证书。记录的过程将最初的 ACL 配置错误与基于证书的身份验证和域复制关联起来。该实验环境没有比较自动化评估与人工评估的表现。

修复方向。 移除该 ACE，并审查 Tier-0 对象上的所有非继承授权。将 CA 服务账户与普通管理操作分离，将模板 ACL 限制为 CA 和目录管理员，禁用服务账户的 RC4，对模板变更和证书签发要求审批与日志记录，撤销误签发证书，并轮换 krbtgt 两次。复测应验证低权限用户无法拥有 CA 账户或修改模板，DCSync 失败，且轮换后伪造票据被拒绝。

内部测试报告应记录起始身份、受影响 ACL、获取的权限、验证结果、失败的测试和残留项。管理员需要这些信息，才能在授权范围内复现发现、修复委派并验证清理。