Goby POC 接入 LLM:让漏洞验证从硬匹配走向智能辅助判断

匿名者  16小时前

a88d83bb46b27cb35525246d6063a104.png

a5c94140d41b12119defd2f642b01355.jpg

▌前言

对 POC 作者来说,写脚本的难点往往不只是“怎么发请求”,而是如何让验证链路在真实环境里稳定跑完。 

登录流程里出现验证码,自动化验证就可能被迫停下来;响应内容格式变化,原本稳定的匹配规则就可能失效;漏洞证据分散在图片、页面、配置、日志等不同内容里,人工一眼能判断,脚本却很难灵活处理。 

Goby 在 2.9.31 版本中支持 POC 在执行过程中调用 LLM 能力,让 AI 参与到图片识别、内容理解、证据提取等环节中。它不是替代 POC 判断漏洞,而是帮助 POC 补上过去不容易自动化的判断步骤,让验证链路更容易跑完整。

当前已经支持两类典型能力:

  • 图片内容识别:遇到验证码,POC 也能继续往下跑。
  • 敏感信息提取:响应内容太杂,AI 帮你捞出关键证据。

接下来我们详细看看这两个能力分别给我们带来了哪些便利。

▌能力一:图片识别接入后,登录类 POC 更容易跑完整

以若依管理系统默认口令检测为例。

默认口令验证本身并不复杂,核心流程通常是访问登录接口、提交账号密码、判断返回结果。但在真实环境中,登录流程前面经常会出现验证码。


310865e6e23624eb026c8bbe9c15c0bc.png

过去遇到这种情况,在需要验证的后台场景中(例如登录绕过、弱口令验证、后台访问检测等),POC 则需要依赖额外 OCR 逻辑,由于非模板性质的ocr识别准确度偏低,即使使用也极易导致脚本自动化检测失败。

现在,POC 可以在获取验证码图片后,把图片内容交给 LLM 识别,并通过 prompt 约束模型只返回验证码结果。随后,POC 再把识别结果带入登录请求,继续完成后续验证。


4d834338137f0ee4fac6bfd322591f27.png

接下来,一起看下Goby POC模板中的实现方式:

登陆验证请求:


a05c2305415d518d3f62b8a7f61b767c.png

用法示例:

code, err := ss.RecognizeImage(imageBytes)

也可以为当前 POC 指定更明确的识别要求:

code, err := ss.RecognizeImageWithPrompt(imageBytes, "只返回图片中的验证码文字")

完整代码模块如下:


9d36df17e8fbfbf5d68d23879f856328.png

这一步带来的变化很直接:显著提升自动化插件的检测成功率。


51b3ba0460fab5d8f7f2b9ebdfb35056.png


51b3ba0460fab5d8f7f2b9ebdfb35056.png

▌能力二:敏感信息提取接入后,信息泄露类 POC 能更快拿到证据

以某系统信息泄露漏洞 为例:

某接口存在配置信息泄露风险,返回内容中可能包含企业微信凭证、邮箱账号密码、钉钉应用 key、移动端应用密钥、系统版本号以及数据库配置信息等敏感内容。


95075c34731851537b1e33a54a664c95.png

在传统 POC 逻辑里,通常会通过关键词或正则判断漏洞是否可能存在,例如检查响应中是否包含password、secretwx.corpid等字段。 这种方式能判断“是否疑似泄露”,但到了 EXP 输出和证据整理环节,仍然需要继续写规则,从原始响应里提取真正有价值的内容。

接入 LLM 后,POC 提供了 defaultAI两种模式:default模式保留原始响应输出,方便完整复核;AI模式则调用敏感信息提取能力,从响应内容中自动整理出更关键的敏感信息。


27ea130a2b2c2af940a4d32da60bbbf1.png


1cf2978373334227cdf7ba3d20cedcec.png


具体的用法如下:

直接让 LLM 从响应内容中提取敏感信息:

items, found, err := ss.ExtractSensitiveInfo(resp.RawBody)

如果只关心某类信息,也可以指定提取目标:

items, found, err := ss.ExtractSensitiveInfoWithPrompt(resp.RawBody, "只提取数据库账号和密码")

完整代码模块如下:


64f9f2ea37def9853f28ea339319be3f.png

▌总结

以前,写POC真正的难点不是怎么判断漏洞是否存在,可能要花大量精力消耗在“猜测响应可能长什么样、字段可能叫什么、正则应该怎么补上”这种事情上。现在,POC 可以在合适的位置调用 LLM,把接近人工判断的步骤纳入自动化流程。

更理想的 POC 写法应该围绕验证链路展开:

访问目标➡️触发接口➡️获取响应或图片➡️提取能证明漏洞存在的关键信息➡️再根据证据确认漏洞是否成立。

这也是 Goby POC 模块接入 AI 能力时的核心思路:不是替代安全人员做结论,而是把最耗时、最琐碎、最容易重复的部分先处理掉,让使用者更快进入复核和判断状态。

▌写在最后

这次更新只是 AI 介入 POC 的第一步。

我们已经先支持了两个比较明确的场景:图片内容识别,以及敏感信息提取。它们背后的目标是一致的:让 POC 作者少花时间处理复杂、脆弱、难维护的匹配规则,把精力放回漏洞验证流程本身。

如果你在写 POC 时遇到过这些问题,欢迎反馈给Gobybot:

  • 哪些漏洞场景最难写稳定匹配规则?
  • 哪些验证码、图片、响应内容影响了 POC 自动化验证?
  • 哪些敏感信息或配置内容很难用固定规则提取?

欢迎各位师傅在实际编写 POC 的过程中反馈使用体验和改进建议。 

如果你的反馈或建议被采纳,将有机会获得 Goby 周边或红队版激活码奖励。欢迎把真实场景里的问题抛给我们,一起把 POC 与 AI 的结合打磨得更实用、更稳定。


最新评论

昵称
邮箱
提交评论