红队与AI：5种利用LLM进行渗透测试的方法

大型语言模型（如ChatGPT、Gemini和Claude）正在重新定义人们获取信息和执行日常任务的方式。网络安全行业也不例外。团队正在将LLM用于各种场景，从安全运营中心自动化到防范网络钓鱼攻击、安全意识教育等各个方面。

LLM特别出色的一个领域是帮助从业人员分析应用程序的安全性——特别是在支持红队活动方面。基于LLM的工具和插件已经带来诸多益处，包括分析从Burp Suite或Zed Attack Proxy等测试应用导出的HTTP流信息（例如通过上下文菜单）的工具，以及位于代理链中批量卸载请求和响应以供LLM审查的工具。

即使没有专用工具，HTTP的人类可读性结合其可预测的结构，也使其特别适合LLM分析。然而，与任何新技术相关的事物一样，很难知道从何处以及如何开始。为此，让我们探讨几种利用LLM进行渗透测试的方法。

但首先，有几点注意事项需要注意：

• 注意服务条款和防护机制。每个LLM对于允许的内容和可接受使用的构成可能有不同的规则。了解这些限制以确保遵守。有些LLM设有防护机制，即使你遵守规则也会限制使用。其他LLM可能会过滤它们认为在不同上下文中可能敏感的信息——例如，JSON Web Token中的非认证字段。
• 下面详述的五个用例并非详尽无遗；这些并非唯一的潜在部署方式。所包含的用例在大多数测试条件下普遍适用，并且因为它们可靠地增加了显著价值。你可能会有本文未涵盖的需求或情况。

1. 会话状态和登录流程

分析应用程序状态维护是利用LLM进行渗透测试的好方法。模型可以帮助建立状态（如登录流程）以及用于维护状态的工件，其中包括安全断言标记语言断言、承载令牌、通用唯一标识符、JWT、会话cookie和文档对象模型工件。

人类解码这些内容并不总是容易的。将原始请求和响应块（如头部和请求/响应体）剪切并粘贴到登录请求中可以提供大量有用信息。即使从业人员无法仅剪切粘贴一个请求（例如，当登录交换涉及多个请求时），他们仍然可以从中获得价值。ZAP、Burp和其他流行工具允许专业人员将这些导出为文本文件或HTTP存档文件，供LLM后续分析。

一个重要提示：虽然大多数推理模型甚至可以解包和分析编码的工件（例如URL编码、Base64编码或十六进制编码），但更复杂的数据结构和多层编码会增加LLM产生幻觉并提供不准确数据的可能性。这种现象在较小和自托管的推理模型中尤其明显。

2. 逆向工程站点构成

登录和状态维护在此列表中排名第一，因为这是许多问题可能发生的地方。考虑OWASP Top 10中有多少（特别是其API Top 10）与认证、授权和状态相关。也就是说，状态维护可能不是最常执行的任务。这一荣誉属于识别站点架构和构建——这是每次渗透测试中必需的步骤，而且在许多情况下，每次测试中涉及多个组件。

LLM可以在这里发挥重要作用：定义给定站点构建方式的潜在组合多种多样。站点可能混合使用不同的应用脚手架策略、中间件、PaaS、API、语言和其他因素。任何个体测试人员，无论经验多么丰富，几乎不可能一眼识别出所有内容。测试人员今天可能使用React前端和基于Scala的Play Framework后端，明天则要应对Django上重度使用GraphQL的Node应用。

逆向工程给定应用程序的构建方式、理解各部分如何组合以及研究有关其架构的具体问题是一项繁重的工作。这也是利用LLM使此任务更轻松的好机会。

通过检索增强生成，向LLM提供请求和响应以及从站点抓取的数据（例如，HTTP流的捕获、Wget或Playwright的输出等）。这可以是商业LLM中项目文件的一部分，也可以是内部托管模型中本地数据文件的一部分。

3. 识别遗留组件

使用LLM进行渗透测试也有助于那些在应用程序中寻找有问题、遗留、易受攻击或已停用组件的人员。考虑一个基于WordPress构建的站点。识别正在使用的插件和主题，并将其与易受攻击版本进行交叉引用可能很麻烦，即使使用WPScan等专用工具也是如此。

而这仅仅是WordPress。几乎每个页面都存在类似的潜在问题。旧版库（如jQuery、Angular或Handlebars）——更不用说较小或特殊用途的库——可能是重大的安全难题。LLM可以帮助识别那些过时的库，更重要的是，那些可能为应用程序提供潜在攻击路径的库。

LLM在这里特别有效，因为它们可以比人类更容易地识别库的易受攻击版本，且无需显式版本字符串，例如基于API中特定方法调用方式的句法差异或已弃用函数的使用。LLM可能会看到对jQuery中.live()方法的调用，并正确指出这种用法已被弃用。因此，使用的版本可能容易受到基于live的跨站脚本攻击。LLM在几分钟内提供的内容，否则可能需要专业人员花费数小时研究——或者更糟，可能完全错过。

4. 逆向工程压缩代码

在应用领域，压缩代码带来的挫败感小时数几乎超过任何其他问题。对于有时间限制的测试，解包和分析压缩代码是一个主要的时间消耗，许多测试人员除非绝对必要，否则会避免这样做。即使如此，时间限制（例如，有上限小时数的测试）可能会妨碍彻底性。

虽然存在有助于膨胀和解包压缩代码的工具，但在许多情况下，扩展主要与间距有关。当变量和函数名称完全不透明时，仍然很难恢复到人类可读的内容。LLM没有这样的限制。它们可以帮助以其他方式难以实现的方式解包和理解压缩代码。例如，LLM可能识别一个压缩函数，该函数解析JWT并返回user.admin而不检查签名——即使该函数名为q()且变量名称毫无意义。

请注意，大多数LLM，即使是较小模型，对于标准库和框架也是准确的。然而，它们对于仅在被分析应用中出现的自定义代码更容易产生幻觉。为此，虽然LLM可以产生有益的基线数据，但如果逆向工程压缩代码是从业人员正在进行的攻击场景的核心，请信任但要验证。

5. 载荷制作和变异

人类容易倦怠——特别是在非工作时间测试窗口期间工作以及经过多个小时的连续测试后。工程师在制作载荷、提出模糊测试种子和执行其他测试程序时可能犯错。生成式LLM提供了一种替代方案。诸如“生成一个XSS载荷以绕过基于React的清理器并在鼠标悬停时触发”的提示可以极大地帮助测试人员验证可利用性。LLM还为那些探测注入用例（包括SQLi、LDAP注入和XML注入）以及XSS、路径遍历、JWT操纵和其他载荷的人员提供帮助。

另一个重要注意事项：这种类型的用例直接触及许多商业LLM通过其防护机制允许的边缘。预计这里会有很多阻力，包括断然拒绝执行，除非从业人员拥有本地托管模型或企业级LLM，允许他们定义自己的策略阈值。即使在LLM阻止响应的情况下，与LLM创建者讨论方法（如果不允许更具体的内容，则以抽象方式）以绕过过滤或编码机制，仍然有相当大的潜在价值。

Ed Moyle是一位拥有超过25年信息安全经验的技术作家。他是SecurityCurve（一家咨询、研究和教育公司）的合伙人。