红队与人工智能：大语言模型在渗透测试中的五大应用场景

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

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

即使没有专用工具，HTTP的人类可读性结合其可预测结构，也使其特别适合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（一家咨询、研究和教育公司）的合伙人。