ARTEX

完整交互见在线 Demo。

全局「审批记录」和任务内「拦截审批」支持点击行或展开按钮查看详情。展示结构参考 AegisHook 的审批详情组件,沿用 ARTEX 的组件和主题:

• 工具请求与审批裁决左右分栏,手机端上下排列;待审批记录可在详情中允许或拒绝。
• 展开上下文可查看当前轮输入、会话记录片段、模型或规则初判、执行输出、调用 ID 与参数/审查配置的 SHA-256 指纹。
• 审批状态和执行结果分别保存。模型直接允许也会记录;重复提交已处理审批返回 HTTP 409。
• GET /api/intercept/history/{id} 按需读取详情,原列表接口不返回上下文和输出。数据库启动迁移自动补列;旧记录显示未记录,旧任务归档可正常恢复。

上下文是工具请求产生时保存的会话记录片段,最多 24 条、每条 8 KiB;当前轮输入最多 32 KiB,执行输出最多 64 KiB,截断会明确标注。 当前裁判模型仍只接收工具名称和参数,展示的会话上下文不代表模型已使用这些内容作出判断。 当前 Norma SDK 的审批钩子不包含调用 ID,因此仅在当前运行中能够唯一匹配工具请求事件时关联结果;相同参数的并发调用无法唯一匹配时,会显示未关联,避免错误归属。

支持从 ScopeSentry 直接同步资产数据,免去重复收集:

• 在「资产同步」页填 ScopeSentry 的地址与 API Key,接入数据源;
• 按项目或任务维度选择要同步的目标与资产类型(域名 / 子域 / IP / 端口 / 站点 / 端点...);
• 一键导入并按公司资产范围归并,直接进入 ARTEX 的资产图供 agent 探索使用。

依赖数据库 PostgreSQL;探索需配置 LLM(ANTHROPIC_API_KEY 或 OPENAI_API_KEY,也可在 UI 里配)。

git clone https://github.com/Autumn-27/ARTEX.git
cd ARTEX
./install.sh

脚本会:检测 / 自动安装 Docker → 让你选 1 全部 Docker 或 2 本地编译运行:

• 1 全部 Docker:填一个 Postgres 密码(可回车随机)→ 自动写 .env → docker compose up -d。
• 2 本地运行:选数据库(连已有 / 用 Docker 起一个)→ 生成 config.json → go 编译内嵌单二进制 → 启动。

装好后打开 **http://localhost:8787**(首次进入 /setup 设置管理员密码)。

git clone https://github.com/Autumn-27/ARTEX.git
cd ARTEX
cp .env.example .env # 填 POSTGRES_PASSWORD、可选 ANTHROPIC_API_KEY
docker compose up -d # 拉取 autumn27/artex 镜像 + postgres
# → http://localhost:8787

镜像已含常用工具(ripgrep/curl/vim/npm/nmap...);./skills 与 ./data 以绑定挂载持久化。

到 Releases 下载对应平台的 zip,解压后得到 artex + start.sh(Windows 为 start.bat)+ skills/ + config.example.json:

cp config.example.json config.json # 填好 database 连接
./start.sh # → http://localhost:8787

请用 start.sh / start.bat 启动,而不是直接跑 ./artex。它是个守护脚本:程序退出后按退出码决定是否重新拉起,页面上的一键更新靠它完成换装。直接运行 ./artex 时更新完就不会被拉起了。 后台常驻:nohup ./start.sh >artex.log 2>&1 &。

# 1) 前端静态导出
cd web && npm ci && npm run build:static && cd ..
# 2) 拷进内嵌目录
cp -r web/out server/webui/dist
# 3) 编译(-tags embedui 才内嵌前端)
CGO_ENABLED=0 go build -tags embedui -o artex ./cmd/artex
./start.sh

build.sh 会先构建并嵌入前端,再使用 Go linker 去除调试信息,并将发布文件压缩为 zip。Release 模式默认生成 Linux amd64/arm64、macOS amd64/arm64 和 Windows amd64 的 zip 包:

./build.sh --release
# 产物:dist/artex-0.3.3-*.zip

UPX 自解压二进制可能与部分 Linux 内核、虚拟化环境或安全策略不兼容,因此默认不启用。可用 ARTEX_TARGETS 自定义目标;确认目标运行环境兼容时,可显式传入 --upx 进一步缩小二进制:

ARTEX_TARGETS=linux/amd64,windows/amd64 ./build.sh --release
./build.sh --target linux/amd64 --upx

升级只换程序、不动数据:Postgres 数据卷 pgdata、./data(jwt.key / SQLite 等)、./skills 都会保留。数据库迁移无需手动执行——artex 每次启动会幂等重跑 schema.sql(含 ADD COLUMN / CREATE INDEX IF NOT EXISTS),即"重启即迁移"。升级前仍建议先备份 ./data 与数据库。

在 系统配置 页(侧边栏「系统配置」→ /system/settings)的版本与更新卡片里,可以直接检查并安装新版本,无需登录服务器。

点「更新」后:下载当前平台的发布包 → 比对 Release 的 SHA256SUMS → 用 -h 冒烟测试新二进制 → 暂存为 artex.new → 程序退出,由 start.sh / start.bat 重新拉起并完成换装。页面会自动等到新版本上线后刷新。

• 失败不会留下坏程序:校验或冒烟不通过就丢弃暂存件、继续跑当前版本;换装后的新版若连续 3 次启动失败,会自动回滚到 artex.old(失败的那个留作 artex.failed 供排查)。
• 随时可回退:上一版本保留为 artex.old,卡片上有「回滚到上一版本」。注意数据库结构不会回退。
• 更新会中断正在运行的任务——更新即重启,请在空闲时进行。
• 开发构建不给更新:版本号是 dev 或 git describe 带后缀时禁用,避免正式版覆盖掉本地调试的二进制。
• Docker 下只换程序、不换镜像:镜像里的 playwright / nmap 等工具链不会跟着升级,且 docker compose up -d 重建容器后会退回镜像自带的版本。要连镜像一起升级仍请用 docker compose pull artex && docker compose up -d artex。
• 访问 GitHub 需要代理时,在同一页面配置全局代理即可,更新链路会走它。更新只从 GitHub 域名下载并强制 HTTPS。

cd ARTEX
./update.sh

脚本先可选 git pull 拉取最新代码,再让你选 1 Docker 更新 或 2 本地编译更新(与 install.sh 对应):

• 1 Docker:可指定目标镜像 tag(回车沿用 .env 的 ARTEX_TAG,缺省 latest)→ docker compose pull → docker compose up -d(换新镜像重启即自动迁移)。
• 2 本地:重建前端静态产物 → 重新编译 ./artex(完成后重启进程生效)。

cd ARTEX
git pull # 更新 compose / 脚本(可选)
# 指定版本:在 .env 设 ARTEX_TAG=v0.2.0;不设则用 latest
docker compose pull artex
docker compose up -d artex # 换新镜像重启 → 自动迁移 schema
docker image prune -f # 清理旧镜像(可选)

到 Releases 下载新版本 zip,停掉旧进程后覆盖 artex 与 skills/(保留你的 config.json 与 data/),重启即可:

cp -r <解压目录>/skills ./ && cp <解压目录>/artex ./
./start.sh

git pull
cd web && npm ci && npm run build:static && cd ..
cp -r web/out server/webui/dist
CGO_ENABLED=0 go build -tags embedui -o artex ./cmd/artex
# 重启 ./start.sh

数据库(config.json,或用环境变量 ARTEX_PG_DSN 覆盖):

{
 "database": {
 "host": "127.0.0.1", "port": 5432,
 "user": "artex", "password": "yourpass",
 "dbname": "artex", "sslmode": "disable"
 }
}

LLM:export ANTHROPIC_API_KEY=sk-...(或 OPENAI_API_KEY),也可在 UI 的「LLM 配置」页填写。 可选:ARTEX_LLM_PROVIDER / ARTEX_LLM_MODEL / ARTEX_LLM_BASE_URL / ARTEX_LLM_PROXY。

并发:每个任务的 work agent 数在「系统设置」里配置(默认 3)。

常用参数:./start.sh -addr :8787 -proxy :8788(-addr 前端+API,-proxy 流量录制代理)。启动脚本会把参数原样透传给 artex。

任务详情的「复测」页签可分页选择本任务的漏洞、查看历次结论和证据,并手动发起复测。启动后保留当前页签,显示转圈图标和「复测中」;确认修复后同步更新漏洞状态。

在漏洞列表每行操作区点击「复测」,或在漏洞详情的「漏洞复测」区域点击「发起复测」,填写可选的修复版本、测试条件或限制,系统会创建独立的复测 Agent 会话,启动后保留当前页面。列表的平铺、按任务分组和资产视图均支持该入口;复测运行时显示转圈图标和「复测中」,需要查看时点击进入对应会话,结束后恢复「复测」。复测无需重新启动原扫描任务,结论分为「仍可复现」「已修复」「无法确认」,每次的结论、证据和会话链接保存在漏洞详情中。

新版后端首次启动会预置可编辑的「漏洞复测」(retester)Agent,可在 Agent 管理中配置提示词、LLM、运行预算和工具。默认使用其绑定的 LLM,未绑定则使用全局激活配置。复测会话成功完成且结论为「已修复」时,系统自动将漏洞处置状态改为「已修复」;执行中、失败、停止或其他结论保留原状态。原始证据和报告始终保留。也可在状态下拉菜单中手动选择「已修复」。同一漏洞正在复测时复用已有会话,停止、失败或服务重启后可重新发起。

本版历史记录通过漏洞详情和会话查看,暂未纳入漏洞报告导出或任务归档包,也未自动关联流量包。演示模式只生成明确标注的模拟记录,不请求真实目标。

./dev.sh # 后端(:8787) + 流量代理(:8788) + 前端 next dev(:5173) → http://localhost:5173

• 后端:go run ./cmd/artex(不带 -tags embedui 则不内嵌前端)
• 前端:cd web && npm run dev(/api 反代到后端,带热更新)
• 测试:go test ./...
• Mock 预览(无后端):cd web && NEXT_PUBLIC_MOCK=1 npm run dev

ARTEX 是一套 LLM 多 agent 驱动的自主渗透系统:Go 单体后端(内嵌 Next.js 前端)+ PostgreSQL,agent 能力由 norma SDK 提供(agentcore / tool / permission / harness / memory / transcript)。核心是双图架构,以及围绕它的两条自主性机制:worker 间过程级信息交换与 planner 多轮共享 todolist 稳定攻击链路。

flowchart TB
 subgraph FE["前端 Next.js(go:embed 内嵌单二进制)"]
 UI["仪表盘 · 任务 · 资产 · 覆盖图 · 流量 · 工作空间 · 系统配置"]
 end
 subgraph SRV["server(Go net/http)"]
 API["REST /api/* JWT 鉴权 SSE"]
 ENG["engine 调度循环"]
 MGR["Manager 任务/引擎/store 生命周期"]
 end
 subgraph AG["agent(norma SDK)"]
 GO["goals 目标分解 + 提取范围"]
 PL["planner 规划者(唯一意图生成者)"]
 WK["worker 执行者 ×ばつN"]
 MA["mainagent 人在环路"]
 end
 subgraph DB["PostgreSQL"]
 AGRAPH["资产图 assets / companies / task_scope"]
 EGRAPH["探索图 exploration_nodes / anchors / activity"]
 end
 subgraph SUB["支撑子系统"]
 PROXY["流量记录代理 MITM + CA 留痕"]
 GUARD["guard / intercept 工具审批门"]
 ENR["enrich DNS / HTTP 异步补全"]
 EXT["MCP · skills · memory · report"]
 end
 UI -->|HTTP| API
 API --> MGR --> ENG
 ENG --> PL
 ENG --> WK
 API --> MA
 API --> GO
 PL --> DB
 WK --> DB
 MA --> DB
 GO --> DB
 WK -->|"Bash / HTTP 全程留痕"| PROXY
 WK --> GUARD
 WK --> ENR
 PL -.-> EXT
 WK -.-> EXT
 MA -.-> EXT

系统把「目标是什么」和「测到了什么程度」拆成两张相互独立、又通过锚点相连的图:

• 资产图(Asset Graph,全局共享):跨任务同一份的资产真值库。节点为 root_domain / subdomain / ip / service / app / endpoint,归属公司;域名→子域→服务→端点的父子关系与去重 key 全部由程序计算,agent 只提交原始信息。
• 探索图(Exploration Graph,每任务独立):一次任务的"思考与推进"过程。节点为 goal(目标)/ intent(意图)/ fact(事实)/ finding(漏洞)/ hint(提示),靠 spawns / derived_from / yields / proves 等边连成血缘链,回答"哪个方向派生自哪些事实、产出了什么"。
• 两图靠锚点相连:exploration_anchors(node_id, asset_id) 把意图/事实/漏洞锚定到具体资产上——于是既能从"探索方向"看它打的是哪些资产,也能从"某个资产"反查它在本任务被哪些意图测过、得出过哪些事实。这也支撑了资产测试覆盖度与资产覆盖图(范围内资产 + 已测高亮)。

flowchart LR
 subgraph EG["探索图(每任务独立 · 推进链)"]
 direction TB
 G["goal 目标"]
 I1["intent 意图 A"]
 F1["fact 事实"]
 I2["intent 意图 B"]
 FD["finding 漏洞"]
 G -->|spawns| I1
 I1 -->|yields| F1
 F1 -->|derived_from| I2
 I2 -->|proves| FD
 end
 subgraph AG["资产图(全局共享 · 真值库)"]
 direction TB
 RD["root_domain"]
 SD["subdomain"]
 SV["service"]
 EP["endpoint"]
 RD --> SD --> SV --> EP
 end
 I1 -. anchor .-> SD
 F1 -. anchor .-> SV
 I2 -. anchor .-> EP
 FD -. anchor .-> EP

分工:planner 读探索图态势、判目标、只在有未覆盖的新方向时派意图进 frontier;worker 领一条意图、用真实工具执行、把新资产/事实/漏洞写回两图后即停。资产图是共享事实,探索图是每任务的推进链。

引擎是事件驱动的闭环:图一变就唤醒 planner,planner 派意图,worker 领意图执行并写回,写回又触发下一轮——直到目标被证明(prove_goal)。

sequenceDiagram
 autonumber
 participant EV as 图变更 debounce
 participant P as planner
 participant FR as frontier 意图队列
 participant W as worker
 participant PX as 记录代理
 participant DB as 双图 + activity
 EV-->>P: 唤醒
 P->>DB: 读态势(graph_overview 预取 + coverage/scope)
 P->>FR: 派 0..N 个意图(带 asset_ids)
 Note over P,FR: 大多数唤醒派 0 个——无新方向即结束
 W->>FR: claimNext 领一条意图
 W->>DB: 取意图 asset_ids 的原始资产作为初始信息
 W->>PX: 真实工具执行(Kali / Bash / HTTP)
 PX-->>W: 响应(全程留痕 + CA 验证)
 W->>DB: 写回 fact / asset / finding + 每步 activity
 DB-->>EV: 图变更
 EV-->>P: 再次唤醒(闭环)

一次深入的探索里,很多有价值的观察(某个报错、某段响应、某个隐藏参数)出现在一个 worker 的执行过程中,却未必被写成正式 fact。为避免重复劳动、让链路上的 worker 能站在彼此的肩膀上,worker 具备跨 work 检索过程的能力:

• search_all_worker_traces(q):在本任务其他 work 的执行过程里按关键字检索(自动排除自己这条意图的步骤),命中项带 intent_id;
• list_worker_traces / get_worker_trace(intent_id, step_ids=[...]):先看有哪些 work 跑过,再取某个 work 具体几步的完整内容做细节交换。

这样即便探索图上还没有对应的 fact,后续 worker 也能复用他人过程中的观察——信息在 worker 之间以"执行过程"为粒度流动,而边界不变(每个 worker 仍只做自己领到的那条意图)。

flowchart LR
 WA["worker A(意图 #12)"] -->|"每步 activity"| ACT[("探索图 · activity 过程库")]
 WB["worker B(意图 #34)"] -->|"每步 activity"| ACT
 WC["worker C(意图 #56)"] ==>|"1) search_all_worker_traces(q)"| ACT
 ACT ==>|"2) 命中 A/B 的步骤(排除自己)"| WC
 WC ==>|"3) get_worker_trace(id, step_ids)"| ACT
 ACT ==>|"4) 返回完整过程内容"| WC

真实攻击链往往是有前后依赖的多步序列(如:发现注入点 → 拿到凭据 → 横向 → 提权),一次性把这些并行派下去只会乱套。planner 因此持有一份按任务保留、跨唤醒共享的规划待办(todolist):

• planner 是事件驱动的——图一变就被唤醒,但每次唤醒是全新会话;共享的 todolist 让它把一条串行利用链记录一次、然后在后续多轮里按依赖逐步派意图,而不是把整条链在一轮里全部前置展开;
• 每轮只对「前置步骤已完成、其依赖的 fact 已存在」的下一步派意图,并随进展更新清单(把已被 fact 满足的步骤标完成)。

flowchart TB
 subgraph TODO["共享 todolist(按任务保留 · 跨唤醒常驻)"]
 direction LR
 T1["1 注入点 [已完成]"]
 T2["2 取凭据 [进行中]"]
 T3["3 横向 [待前置]"]
 T4["4 提权 [待前置]"]
 T1 -.前置满足.-> T2 -.-> T3 -.-> T4
 end
 R1["第 1 轮唤醒 派意图1"] --> T1
 R2["第 2 轮(1产出 fact) 派意图2"] --> T2
 R3["第 3 轮(2产出 fact) 派意图3"] --> T3

于是攻击链在"事件驱动 + 无状态会话"的环境下依然稳定推进、不重复、不错序——这是 ARTEX 能自主走完多步利用链的关键。

扫码关注微信公众号 SecSentry,在公众号后台私信即可入群交流。

https://github.com/oritera/Cairn

仅供授权测试与研究使用。