乐于分享
好东西不私藏

AI For Security: Hermes Agent —— 开源AI Agent + Kali 实践

AI For Security: Hermes Agent —— 开源AI Agent + Kali 实践

前文我们曾介绍过如何在 Kali Linux 上安装和使用 OpenClaw(龙虾),作为当时较为热门的 AI 安全助手,它在渗透测试、信息收集以及日常安全研究工作中提供了不少帮助。

不过随着 AI Agent 生态的快速发展,越来越多的新项目开始涌现。上个月,在朋友的推荐下,重新搭建了一台全新的 Kali 虚拟机,安装了近期讨论度较高的 Hermes。经过一个多月的实际使用与测试,无论是在响应速度、Agent 工作流体验,还是与 MCP 工具生态的整合方面,Hermes 都给我留下了不错的印象,也逐渐成为了我日常使用频率最高的 AI 安全助手之一。

本文将结合实际安装和使用过程,简单介绍 Hermes 在 Kali Linux 环境中的部署流程,并分享一些个人使用过程中的心得与踩过的坑,希望能为同样关注 AI+网络安全方向的朋友提供一些参考。

一、Hermes 简介

Hermes Agent 是由 Nous Research 开发的开源自改进 AI Agent(GitHub: NousResearch/hermes-agent),2026 年 2 月发布,MIT 协议,完全开源。

https://github.com/nousresearch/hermes-agent

核心亮点:

  • 持久记忆 + 自改进:
    不同于 ChatGPT 每次对话重置,它有长期记忆,能从对话中自动提炼 Skills(可复用技能)并不断优化如图。
  • 自主运行:
    支持长时间在服务器/VPS 上运行,通过 Telegram、Discord、微信等随时调用。
  • 强大工具调用:
    终端执行、浏览器控制、Cron 定时任务、沙箱环境等。

那么Agent 是如何接受自然语言的输入并自动完成任务的呢?

AI Agent = 大脑 (LLM) + 身体 (行动逻辑) + 记忆 (知识库) + 工具 (外部接口

二、在 Kali Linux 上安装 Hermes Agent

更新系统

sudo apt update && sudo apt upgrade -ysudo apt install -y curl git

一键安装(如果安装失败可以在GitHub上找找其他脚本)

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

验证:

hermes --versionhermes  # 启动 TUI 聊天界面

推荐使用hermes-webui(nesquena 维护)

是目前社区最受欢迎的 Hermes Agent 第三方 Web 界面,比官方内置 Dashboard 更像 Claude 的聊天风格

# 1. 克隆仓库git clone https://github.com/nesquena/hermes-webui.git hermes-webuicd hermes-webui# 2. 启动(自动引导)./start.sh

安装完成后访问地址http://localhost:8787:

首次登录账密未web界面提示默认值,登陆后最好进后台修改密码

初始化模型配置:

如果想配置国外的模型也是ok的,看个人选择,也可以根据自身需要,添加一些针对性使用方向的skill。例如:https://github.com/yaklang/hack-skills/tree/main

三、使用案例分享

Hermes部署在虚拟机Kali中,物理机本机可以访问Kali+端口进入Web Dashboard。

简单测试下Agent 的功能:

在体验 Hermes 的过程中没有刻意设计标准化测试场景,安装完成后将其直接投入到日常安全工作环境测试场景中,例如环境搭建、漏洞验证、源码审计以及逆向分析等简单测试任务。

与传统对话式 AI 不同,Agent 的价值并不仅仅体现在回答问题上,而是在面对复杂任务时,能够主动分析上下文、拆解问题路径、定位异常原因,并在任务执行过程中持续调整解决方案。

当安装过程中出现依赖缺失、网络异常、环境冲突或工具报错时,Agent 往往能够结合日志信息快速定位问题,并给出具有可操作性的修复建议;而在逆向分析、源码审计等场景下,则能够辅助梳理分析思路,帮助快速定位关键代码与潜在风险点。

本文中的几个案例并非单纯展示漏洞环境、逆向工程或代码审计本身,而是希望通过真实场景观察 Agent 在问题定位、错误分析、任务中断恢复以及复杂工作流协同中的实际表现,从而验证其在安全工作中的辅助价值与应用边界。

案例一:Docker 靶场集群搭建

在 Kali 上用 Docker 一次性搭了 6 个漏洞靶场,全部对外暴露端口,形成一个可随时测试的「靶场集群」:

所有镜像来自 Vulhub 仓库(/opt/vulhub/,158 个漏洞环境),用 docker-compose 一键启动。

Agent的搭建流程:

Agent遇到的问题:

问题一Docker Hub 拉不动镜像原因:Kali 的 443 端口被 GFW 阻断,连 GitHub/Docker Hub 都不行解决:配置了两个中国镜像加速器到 /etc/docker/daemon.json:{  "registry-mirrors": ["https://docker.1ms.run""https://docker.xuanyuan.me"]}
问题2:系统代理干扰 Docker原因:Kali 配了全局代理(http_proxy=127.0.0.1:7890),但 V2Ray 没开的时候 Docker 也走代理就挂了解决:Docker 启动前 unset http_proxy https_proxy all_proxy,或者直接在 systemd override 里清掉
搭建完成访问:
Agent在搭建过程中能够自动分析失败原因并作出相应调整人工并未通过多轮prompt进行干预,彻底解放双手。

案例二:PyInstaller 逆向

给了Agent一个 13MB 的 exe 文件(ransodesktop_encrypt_noconsole.exe),用 Python 写的 EDR 测试工具——批量加密桌面文件,检测EDR 能不能拦截。给Agent设定的场景是源码丢了是否能从 exe 中逆向还原出了完整 Python 源码。

Agent 实现思路:

逆向 PyInstaller 打包的 exe流水线:

Step 1: 识别打包方式   ↓  file命令 + strings搜索"MEIPASS" → 确认是 PyInstallerStep 2: 提取字节码   ↓  pyinstxtractor-ng → 从 13MB exe 中提取出 114 个文件Step 3: 定位主文件   ↓  找到 ransodesktop_encrypt_txt2.pyc(3298字节)→ 入口Step 4: 反编译   ↓  先试 pycdc/uncompyle6 → Python 3.12 字节码太新不支持   ↓  改用 xdis 手动反汇编 → 逐条读字节码还原逻辑Step 5: 验证 + 清理   → 输出完整 .py 文件

还原出的源码功能:

问题1:GitHub 443 不通,工具装不上pycdc 都在 GitHub 上,直接 git clone 超时解决:先用 SOCKS5 代理(-c http.proxy=socks5h://127.0.0.1:1080)clone,不行就 curl 下载 zip 包1最终 pyinstxtractor-ng 用 pip 装成功了,pycdc 从 zip 包编译
问题2:Python 3.12 字节码太新,现有反编译器不支持pycdc(Python bytecode converter)编译好了但对 3.12 的 .pyc 解析失败uncompyle6 只支持到 Python 3.8解决:退而求其次,用 xdis(Python 反汇编库)做手动反汇编pyinstxtractor-ng 提取时自动做了字节码版本修复用 xdis 的 disassemble 函数逐条输出汇编指令根据指令手动还原源码逻辑

还原出的代码:

案例三:FastAdmin 源码审计

拿 FastAdmin(一个基于 ThinkPHP 的后台管理框架)的完整源码给Agent做了白盒安全审计。聚焦三个攻击面:文件上传绕过、认证逻辑、SQL 注入。

实现思路

审计策略:先大后小,先自动化扫一遍再手动精读关键文件。

审计发现

遇到的问题

问题1:源码量太大,逐行看不现实FastAdmin 源码有几百个 PHP 文件解决:先用 grep -r 扫描高危函数(exec、unserialize、upload、evalsystem),快速定位高危文件,再精读
问题2:ThinkPHP 框架本身的坑ThinkPHP 的 ORM 调用(Db::name()->where())看起来像 SQL 注入,但实际上框架会自动参数化需要区分"框架保护""裸写 SQL"——grep 出来之后要看上下文
问题3:没搭环境,只做了白盒审计只看了代码,没有实际部署验证 .htaccess 上传是否真的能绕过解决方案是:用 Docker 搭一个 FastAdmin 环境(PHP + MySQL),然后黑盒验证白盒发现

四、总结

一个多月的实际体验,Hermes 带来的感受是Agent开始真正具备了参与完整工作流的能力。现阶段的 Agent 依然存在一定局限性。例如复杂任务中的推理偏差、工具调用失败、长链路执行稳定性不足等问题仍然客观存在。在部分场景下,人工校验和干预仍然是不可或缺的环节。

腾讯云黑客松智能渗透挑战赛各位大手子们各自分享比赛案例非常值得参考

资源链接:

https://zc.tencent.com/hackathon