ARTEX：韩国银行金融行业闻风丧胆的黑客工具

原创

一个不正经的黑客
一个不正经的黑客

一个不正经的黑客

2026年10月10日 14:21
广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

源码解读 · 提示词 · 任务调度 · 漏洞证据

拆解 ARTEX：一个 AI 安全 Agent 如何找到漏洞？

从韩国金融机构事件出发，沿着一条意图的生命周期，拆开 ARTEX 的规划、执行与验证机制。

图 1 · 资产关系与探索路径，构成两种不同的上下文

01 / ARTEX / SOURCE STUDY

项目概览：从韩国金融机构事件说起

2026 年 10 月 7 日，CrowdStrike 发布报告，将一起针对韩国金融机构、发生于 9 月下旬至 10 月初的数据窃取活动，与 ARTEX 和大模型工具的使用联系起来。

研究人员从攻击者控制的开放目录中发现了 Claude Code 会话历史、ARTEX 配置和记忆文件，据此分析其操作方式。［1］

报告还披露了一段生成安全研究员简历的会话，其中包含教育背景等个人信息。CrowdStrike 表示，这些资料与实际攻击者的关联尚未得到确认，受影响金融机构的具体数量也仍未确定。

ARTEX 将自然语言目标拆分为探索意图，由 Planner 规划方向、Worker 执行验证，并通过探索图和证据记录保存过程。

ARTEX 由 Go 后端、Next.js 静态前端、PostgreSQL 和 norma Agent SDK 组成，覆盖任务、资产、探索链路、工具审批、流量、报告与复测。

系统通过资产图保存目标对象，通过探索图保存任务推进和证据关系。［2］

安装与上手：先把一条本地任务跑通

项目提供一键安装、Docker Compose、预编译二进制和源码构建方式。

Compose 路径需要 Docker、PostgreSQL 密码和模型配置。

在完整项目目录中执行 · Compose 路径

cp .env.example .env

编辑 .env，修改 POSTGRES\_PASSWORD

模型密钥可稍后在界面填写

docker compose up -d

Compose 会启动 PostgreSQL 16 与 ARTEX 应用。

首次打开 http://localhost:8787，进入 /setup 设置管理员密码，再到“LLM 配置”填写提供方、模型、接口地址和密钥。

数据分别保存在 pgdata 卷、data 目录与 skills 目录；启动前不要沿用 .env.example 中的示例数据库密码。［README.md；docker-compose.yml］

若采用 Release 二进制，需要先准备可连接的 PostgreSQL，将 config.example.json 复制为 config.json，修改 database 连接参数，再通过 start.sh 启动；Windows 使用 start.bat。

示例中的数据库端口为 5433，应按实际数据库修改；skill\_dir 写的是 /opt/artex/skills，本地使用时可删除该字段，回到可执行文件旁的 skills 目录。

已下载并解压对应平台 Release 后

cp config.example.json config.json

修改数据库连接与技能目录配置

./start.sh

启动脚本负责异常退出后的重启和更新后的重新拉起。

源码构建需要 Go 与 Node/npm；go.mod 声明 Go 1.26.3，发布工作流使用 Node 22。前端静态导出后，通过 embedui 构建后端。

首次使用，检查四个环节

① 配好模型后，创建一个本地隔离演示任务，写清目标、测试资产和停止条件。项目 README 将用途限定为源码研究与本地隔离验证，首次使用可从自己的演示应用开始。目标地址必须从 ARTEX 的执行环境可达：容器中的 localhost 指向容器本身，并不自动指向宿主机应用。

② 在任务总览核对提取出的目标与“操作约束”，按需要设置 Agent 的轮次、时间预算和工具审批，再运行任务。不要把“配置了 API Key”当作模型已经可用；到执行过程里确认出现真实的模型回复与工具返回。

③ 跟踪意图由 open 到 running，再到 done、blocked 或 exhausted；遇到失败先查看对应会话和工具输出。若希望核对 HTTP 证据，还要确认流量采集及相关工具确实启用，仅设置出站代理不会自动得到录制记录。

④ 有发现时，检查证据与报告能否互相对应，再从漏洞详情发起独立复测。一次上手的验收应是“任务能调度、工具能返回、结果能写回、过程能查到”，不以首页出现绿色状态或报告字数作为成功依据。

02 / ARTEX / SOURCE STUDY

项目架构设计：Agent 怎样分工与运行

01 / 控制、执行与存储，分别承担什么

Web 界面通过 REST 接口管理任务，并通过 SSE 接收活动更新。

server 层的 Manager 管生命周期，Engine 负责调度；agent 层把模型、提示词、领域工具和 SDK 会话组合起来。

PostgreSQL 保存业务状态，工具产物写入工作目录，流量与证据子系统提供可追溯材料。

核心数据被拆成两张图：资产图记录域名、服务、端点等对象；

探索图记录目标、意图、事实、发现和它们的来源关系。

exploration\_anchors 把探索节点连接到资产。这里的图是 PostgreSQL 表上的业务关系，默认部署不依赖独立图数据库。

图 2 · 核心调度与数据关系；审批及流量记录按配置启用

几个容易混淆的角色需要分开。

Auto 通过平台工具管理任务；Planner 组织方向；Worker 执行某条意图；mainagent 承接任务内人工对话；Reporter 根据已登记发现写报告。

项目还提供独立 pentest Agent，它同时规划与执行，并不走完全相同的 Worker 池路径。［agent/promptcatalog.go］

02 / 提示词不是一份长文，而是运行时组装

agent/prompt.go 的 renderSystem 优先读取数据库里的可编辑模板，再用运行时变量渲染；模板出错则回退代码默认值。

代码随后追加工作目录、流量工具和证据交接等说明。最终生效的提示词由模板、运行时上下文和工具说明共同组成，并随当前配置变化。

agent/worker.go · 默认 Worker 提示词节选

完成这一条意图、把发现写回知识图谱、然后停止返回。

Worker 的规约把输出分成三类：

新端点等对象交给 insert\_assets；

观察和否定结论交给 record\_fact，并区分 observed 与 inferred；

只有本次实际触发且有可复现证据时才调用 report\_finding。

方向外的线索交回 Planner，避免执行者自行扩大任务。

更有意思的是动态内容放在哪里。

Worker 把当前意图和目标资产追加进 system prompt，每次续跑重新组装；Planner 则把图概览和触发信息放入本轮 user 输入，保持系统正文较稳定。

前者优先防止长会话压缩后“忘记自己在做什么”，后者更利于复用稳定提示词。

缓存收益与上下文丢失风险，被按角色分别处理。［agent/worker.go:383；agent/planner.go:379］

agent/worker.go · 意图进入系统提示词

sysBody += renderIntentTask(intent)

Planner 的默认提示词还编码了调度策略：有依赖的链路逐步派发；互不依赖的方向可以并行；done 不原样重派，blocked 和 exhausted 要先回看执行记录；目标未达成且没有 open/running 意图时，应补充方向。

它让模型依据状态选择行动，而不是每轮自由重写计划。

源码判断

这些约束并非全部由代码强制。

例如“每轮最多四个方向”属于提示词规则，add\_intent 的批量处理没有对应的四条硬上限。

Planner 仍有 Bash 等默认工具，“规划者少做执行”也主要依赖提示词和配置。执行权限由工具绑定与平台规则共同决定。

03 / 子 Agent 如何派发：先写意图，再由池领取

常规路径是 Planner 调用 add\_intent，提交 summary、asset\_ids、parent\_ids、priority。

addOneIntent 先检查父节点和资产拦截规则，再创建 open 意图；父节点只允许 fact/finding，根方向回连起始事实。

这样每个方向可以说明“依据哪条已知信息继续探索”。

agent/tools.go · parent\_ids 类型校验（节选，省略错误文案）

if n.Kind != db.KindFact &&

n.Kind != db.KindFinding {

// 返回错误，不创建这条意图

}

提示词与工具实现存在一处约定差异：Planner 默认模板末尾允许引用上游“意图/发现”，而 addOneIntent 拒绝 intent 父节点。

模型照着前者填参数会被后者驳回。后端校验决定了实际可接受的参数类型，模板与工具描述需要与这套约束保持一致。

Engine.Run 为任务启动一个 plannerLoop 和 N 个 workerLoop。

Worker 从 frontier 取候选，再通过 ClaimIntent 的条件更新争取所有权。

它不是每轮临时孵化一批独立容器；常规 Worker 槽位由同一个 Go 后端进程里的 goroutine 承担。

db/exploration.go · ClaimIntent 中的 SQL

UPDATE exploration\_nodes

SET state='running', owner=$1

WHERE id=$2 AND exploration\_id=$3

AND kind='intent' AND state='open'

受影响行数等于 1 才算领取成功，这解决了同一行的并发竞争。

两个自然语言不同、实质重复的意图仍可能被分别创建，语义去重主要靠 Planner 比对已有方向。

Worker 的会话 ID 使用 exploration ID 与 intent ID 组合，而不是 work#1 这样的槽位名，槽位复用不会把两条意图的历史混在一起。

04 / 生命周期：暂停、超时、失败不是同一种结束

任务开始后，Engine 在真正进入规划或执行时记录首次运行时间并计算截止时间。

plannerLoop 合并短时间内的唤醒通知，同时保留心跳兜底；暂停、删除中、终态和超时收尾中的任务会被入口检查挡住。

目标全部结束但仍有人工直投意图时，由 Go 代码等待队列跑完，不再额外调用模型判断。

图 3 · 常规意图的简化状态流；取消与终局停止另有分支

领取后，runIntent 为当前执行建立子 context，接入 Guard 和人工纠偏钩子。

任务暂停通常把 running 退回 open，以便恢复后领取并续用原会话；单意图暂停进入 paused；目标已经完成而被取消的执行则进入 stopped。

这些状态表达不同的后续动作。

正常返回记 done；达到轮次或时间预算记 exhausted；执行出错记 blocked。预算到点前 SDK 可以进入收尾轮，隐藏 Bash，把已观察到的资产、事实和发现写回。

模型错误重试也要检查任务是否仍可执行，不能在暂停或终局收尾时继续重试。［server/engine.go:982；agent/worker.go:422］

源码判断

exhausted 表示没做完，不表示没有漏洞。

Planner 提示词会要求回看过程，判断是接续进度、重试外部故障，还是换方向。

如果把预算耗尽统一写成 done，下一轮就可能错误地认为这块攻击面已经覆盖。

03 / ARTEX / SOURCE STUDY

项目亮点：它如何发现并记录一个漏洞

01 / 从一条线索到一次验证

对象越权检查流程包括账号准备、对象访问、权限对照和证据登记。

Planner 提出验证方向，Worker 对比授权对象与非授权对象的响应，确认结果后写入 finding。

第一步，已有观察通过 insert\_assets 和 record\_fact 进入双图。

Planner 从图概览看到端点与访问行为，提出“检查对象访问是否受账号权限约束”的意图，并关联相应资产和事实。

这里负责提出假设的是模型；程序负责保存方向与来源关系。

第二步，Worker 领取意图，在给定测试条件下调用工具，比较本人对象、无权对象和无效对象的响应。

只有响应中出现了不应向当前账号提供的数据，才有支持越权的证据；状态码成功本身不够。

若条件不足或结果模糊，按提示词应写 inferred fact，把疑点交回规划者。

图 4 · 发现与报告路径；复测是后续独立流程，不会为每次上报自动执行

第三步，证据支持结论时调用 report\_finding，传入类别、级别、摘要、意图与证据。

工具适配器把请求交给 FindingRecorder；程序核对任务、探索记录和意图的关联，再写入发现节点、资产锚点、来源边与 findings 记录。

对协议细节和业务权限的判断仍由模型或人工完成。

02 / “已确认”到底由谁确认

Worker 默认提示词明确禁止把版本命中、CVE 匹配或“看起来可注入”直接上报为已确认漏洞。

但 report\_finding 的 schema 必填字段只有 vulnclass、severity 和 summary；evidence 不是必填，也没有要求先跑一个独立验证器再允许登记。

agent/tools.go · 上报 schema 的必填项

\"vulnclass\", \"severity\", \"summary\"

RecordFindingTx 随后会创建 state 为 confirmed 的 finding 节点。

confirmed 在这里表示漏洞已经通过上报接口登记。

该路径校验记录关联和参数，并未执行独立的漏洞复验；结论的正确性仍依赖执行阶段的验证与后续复核。

源码判断

发现能力来自模型推理与真实工具反馈，记录接口提供的是结构和追溯。

这套实现能让人检查模型为何得出结论，但它没有消除模型判断错误。要评估误报，需要另做验证集或人工复核。

03 / Reporter 是另一条事件触发链

漏洞登记成功后会通知规划层。另一路由 Scheduler 读取工具结果事件，匹配 report\_finding 触发器，再启动 Reporter 会话；失败的上报事件会被跳过。

触发器上下文中的入参和返回值可能截断，所以 Reporter 提示词要求重新读取漏洞详情与 Worker 过程，而不是只凭通知文本写报告。［server/scheduler.go:284；agent/promptcatalog.go:75］

流量自动绑定受开关与工具权限控制。

开启时，代码注入的工作流让 Reporter 在写报告前核对候选 HTTP 记录，再按 baseline、proof、verification 等用途绑定；也兼容上报时立即提交已核实引用。

关闭时会移除绑定能力和相关参数，TCP、无包或未采集场景仍可登记文字证据。

两种 ID 也必须分清：finding\_node\_id 是探索图节点，finding\_id 是独立漏洞记录。

历史 update\_finding\_report 的参数虽然也叫 finding\_id，实际仍接收节点 ID。源码专门追加编号说明，避免 Agent 反复猜编号。这是接口兼容性给提示词带来的真实负担。

报告保存支持 evidence\_version：提供版本时，后端检查它与当前证据版本是否一致，避免基于旧证据写成的新报告覆盖现状。

版本参数可省略，实际是否执行对应校验取决于调用时是否提供该值。

04 / 证据落库的价值与代价

evidence.Store.Record 在 WithEvidenceTx 中准备流量快照并写漏洞；RecordFindingTx 把发现节点、来源关系、漏洞记录及证据关联放入同一 SQL 事务。

原始请求/响应正文另由证据存储写入文件，文件写入与 SQL 回滚属于不同的处理层。

db/finding\_traffic.go · 证据事务使用的锁

SELECT pg\_advisory\_xact\_lock($1)

这里使用固定 key 的事务级 advisory lock，协调共享数据库的证据读写、导出和回收，减少正文文件与 SQL 引用在并发下互相脱节。

代价也明确：经过这把锁的操作会互相等待；当证据正文很大或导出耗时较长时，这里值得检查吞吐量。当前只是从锁粒度推断，没有压测结果。

复测又设置了一道不同的状态约束：FinishFindingRetest 只处理 pending/running 的记录；标完成却没有保存 verdict 会转失败；只有 newly completed 且 verdict 为 fixed 才更新漏洞修复状态。

重复提交不会重新覆盖后来的人工处置决定。

05 / 长任务靠什么保持上下文

Planner 用内存中的 TodoStore 跨唤醒保留串行计划，这不等于重启持久化。

探索图和活动记录则提供长期线索；Worker 可以检索其他执行过程，再按步骤取详情，找回没有被正式总结成 fact 的观察。

项目还实现了冷节点压缩。

coldGraph.hotSet 从 open/running/paused 意图向上保留祖先，并保留活跃意图的直接子节点；只有符合条件的 fact 和已结束意图进入冷候选。

finding、goal、hint 不在默认折叠类别中，生成摘要后提交前还会重新检查成员是否变热。［agent/coldgraph.go；agent/compaction.go］

这比把长历史简单截掉更贴合探索任务：仍在执行的路线依赖什么，就尽量保留什么。摘要会损失细节，后台压缩本身也消耗模型调用；节省多少上下文、是否影响发现质量，需要带具体任务数据测量。

执行边界仍需单独评价。

默认 Worker 不是逐个容器隔离；Guard 根据配置规则审批；代理环境变量只能引导遵守设置的工具。可审计、可审批与强制隔离，是三种不同能力。

04 / ARTEX / SOURCE STUDY

项目价值与同类开源产品对比

以下按源码或官方文档比较侧重点，优缺点是架构取舍，不是同条件检出率排名。

Nuclei 作为模板扫描基线加入，属于相邻工具，不是等价的自主 Agent 平台。［3—6］

项目	核心优势	主要代价 / 差异
ARTEX	资产、探索、证据关联完整	验证依赖模型；隔离需另评估
PentAGI	容器执行与记忆集成丰富	启用多组件后运维更重
PentestGPT	阶段化自主流程、会话续跑	自主路径依赖编码 Agent 后端
Strix	代码＋应用验证，便于接 CI	多 Agent 执行依赖工具环境
Nuclei	模板可审阅，便于重复验证	效果受模板覆盖与匹配质量约束

ARTEX 的工程特点是把任务依据、执行进度和证据关联落实成可查询的状态。

它提供了一个多 Agent 安全工作流的研究样本。其他项目各有侧重：PentAGI 关注容器与记忆平台，PentestGPT 组织阶段化任务，Strix 面向代码与应用验证，Nuclei 提供模板驱动的重复检查。

从提出方向到执行验证，再到证据登记和复测，ARTEX 将多个环节连接成持续推进的工作流。

其实际效果取决于模型提出的假设、工具反馈、证据质量与失败恢复机制，仍需要在相同目标、模型和预算条件下评估。

最后，ARTEX作者已经Github删库跑路了。

出于研究学习目的的同学可以公众号回复 \"微信\" 加运营微信，拉你进信安修仙-AI交流群，群里有存档。

资料与源码

［1］CrowdStrike，2026-10-07：ARTEX 与韩国金融机构攻击活动
https://www[.]crowdstrike[.]com/en-us/blog/unknown-threat-actor-uses-artex-to-target-south-korean-finance/

［2］ARTEX 上游仓库标识；来源页面当前无法访问
https://github[.]com/Autumn-27/ARTEX

［3］PentAGI 官方仓库
https://github[.]com/vxcontrol/pentagi

［4］PentestGPT 官方仓库
https://github[.]com/GreyDGL/PentestGPT

［5］Strix 官方仓库
https://github[.]com/usestrix/strix

［6］Nuclei 官方仓库
https://github[.]com/projectdiscovery/nuclei

---