文章总结： 本文复盘了一起针对8核Linux主机的隐蔽入侵事件，攻击者利用perfctl工具链、用户态Rootkit（libgcwrap.so）及假系统工具（top、lsof等）实现进程隐藏与负载欺骗。入口疑似Redis弱口令，但缺乏直接提权证据。处置中发现文件自动消失与回写现象，最终通过清除ld.so.preload、修复fstab及加固Redis/MySQL完成止血。建议加强动态库监控、定期校验系统工具完整性并禁用高危配置。
综合评分： 92
文章分类： 应急响应,漏洞分析,实战经验,内网渗透,安全运营

8 核主机负载 8.7，top 却显示空闲：一次 perfctl 入侵应急复盘

原创

messfree
messfree

MessFreeSecurity

2026年9月25日 18:18
河北

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

9 月 20 日凌晨，一台承载业务支持系统的 8 核 Linux 主机给出了两套互相矛盾的读数：负载 8.75，top 却显示 CPU 几乎全闲着。ps 里也没有那个理应占满机器的进程。直到绕开进程列表、直接计算 /proc 的 CPU 时间差，约 7.7 个核的去向才显出来。

后面的调查没有沿着一条直线走。假工具会替真工具执行命令，动态库能把恶意文件藏起来；处置期间，文件一度自行消失，又被写回。9 月 20 日完成首轮止血和业务恢复，9 月 22 日仍出现两轮回种。最后一次记录是 9 月 22 日 10:51 的阴性复查，不能把它写成整机已经可信。入口判断也改过一次：初版笔记把 SSH 爆破排在前面，补查后 Redis 公网弱口令最吻合，但缺少直接利用日志。

下文用现场笔记、系统日志、保全样本和两轮处置记录还原过程，时间均为北京时间。受害主机地址、业务域名、运维来源和口令已经脱敏；文末附录保留可公开的 IOC 和各自的证据等级。

图1：负载与监控读数矛盾的情景示意，非现场截图。8 核、负载约 8.7 与单进程约 7.7 核来自 9 月 20 日取证记录。

01:16，8 核机器快跑满了，top 却说它很闲

这不是一句“监控不准”就能带过的异常。同一台主机、同一轮排查，留下了四个读数。下面按字段摘录，未拼造终端截图：

nproc                         → 8 cat /proc/loadavg             → 8.75 8.46 7.83 … top -bn2 -d3                  → %Cpu(s): … 100.0 id ps --sort=-pcpu               → 前列是 sshd、taosd、mongod、java

负载高不等于 CPU 忙，I/O 等待也可能把负载抬上去。仅凭这四行，连“是不是有人藏进程”都还不能下结论。

现场改用进程自己的计数核对：间隔约 5 秒读取两次 /proc/<pid>/stat，用 utime+stime 的增量换算 CPU 占用。退出中的进程会被跳过，PID 启动时间也一并比较，避免把复用的 PID 当成同一个进程。完整复核脚本放在文末的技术附记。

结果不是几个百分点的采样误差：全机进程合计约 778%/800%，其中 mysqlshowscsi_m 单独占约 771%。机器确实在忙，top 所说的“100% 空闲”不能再信。

真正让排查方向改变的是同一个 PID 的两种面孔。现场记录的 PID 1495497 在 /proc/1495497/stat 中持续增加 CPU 时间，exe 指向 /usr/bin/mysqlshowscsi_mandat，cmdline 一度冒充 telegraf；用真实的 /usr/bin/ps -p 1495497 查它，却没有输出。

/proc/<pid>/stat &nbsp; &nbsp; &nbsp; → CPU 时间持续增加 /proc/<pid>/exe &nbsp; &nbsp; &nbsp; &nbsp;→ /usr/bin/mysqlshowscsi_mandat /usr/bin/ps -p <pid> &nbsp;→ 无输出 /proc 与 ps 进程数 &nbsp; &nbsp; &nbsp;→ 约 240 对 233

/proc 约 240 个 PID、ps 约 233 个，数量差只是辅助线索，采样时进程可能进出。指定 PID 一边吃掉 7.7 核、一边从 ps 消失，才值得沿着隐藏机制追下去。

绕过假工具后，真 top 仍然被骗

沿着 top 往回找，/etc/profile 把隐藏的 .local/bin 假工具目录提到 PATH 前面。保全样本里有假 top、lsof、crontab、strace、ldd，每个只有十几 KB。它们导入 getenv、putenv、execvp：先动环境，再执行真正的系统命令。表面上看，命令照常运行。

tail -5 /etc/profile           → export PATH=/bin/.local/bin:$PATH ls /usr/bin/.local/bin/        → top  lsof  crontab  strace  ldd

这解释不了全部现象。非交互 SSH 会话通常不加载这份 profile；现场排除 PATH 干扰，直接运行 /usr/bin/top，它仍报近 100% idle。假工具只是外层。

第一次查 /etc/ld.so.preload，返回的却是“文件不存在”一类结果。后来给读取命令加上本案样本的隐藏开关 AAZHDE=1，同一个文件里明明写着 /lib/libgcwrap.so；原先消失的 perfcc、.xdiag 和 .perf.c 也露出来了。

cat /etc/ld.so.preload                 → 看似不存在 env AAZHDE=1 cat /etc/ld.so.preload    → /lib/libgcwrap.so

libgcwrap.so 是用户态 rootkit，动态链接程序启动时加载它，文件与进程列表就可能被过滤。保全样本的哈希后来也与现场记录对应上；精确值放在文末附录。AAZHDE=1 只对这份样本的隐藏逻辑有用，不能当成 Linux 取证的通用“可信模式”。

还有一个不肯配合的细节：ls 显示空目录，rmdir 却报 Directory not empty。XFS 的只读目录项检查把 perfcc、.applocal.xdiag、r.log 和 trunk 名称翻了出来。下面只摘录 cron 目录的一次检查；inode 和设备名是这台机器的现场值，不能拿到别的主机照抄。

xfs_db -r -c 'inode 326273' -c 'print u3.sfdir3' /dev/vda1 → cron 目录项出现 perfcc

到这里，假工具、preload、指定 PID 和磁盘目录项才相互对上。常规工具显示“空闲”，并不是 CPU 真空着。

还有一份末尾带真实空格的假 nologin，内容其实与 bash 一样；现场未见账号使用它，路径与误报边界详见附录。

图2：本案观察到 PATH 假工具与用户态动态库两层干扰；/proc 和 XFS 目录项提供交叉核验。示意图，不代表内核 rootkit。

8 月 22 日的日志，写下了更早的活动

保全的组件与公开研究中的 perfctl/perfcc 结构相近：约 11 MB 的 perfcc 主程序、负责隐藏的 libgcwrap.so，以及现场记录在 /tmp/.perf.c/pctl 的挖矿体。pctl 与此前冒充 mysqlshowscsi_mandat 的文件 MD5 相同；近 8 核的 CPU 占用则是现场测到的影响，不靠文件名猜。

同一台主机还有代理相关外连，bprox 里列了代理端点。脚本虽写有私有 Docker 的启动逻辑，主机当时没有 Docker，记录显示走了直接运行的备用路径。配置端点与现场外连的具体数值、地址和证据等级留在附录。

恶意程序自己的 elog 最早记到 8 月 22 日 02:07:43。03:25 至 04:09 有扫盘、打包记录，磁盘也留下带 _error_ 的包名；/tmp/.xdiag/data/tty/ 与 pam 目录里还有加密的会话类数据。包名里的 _error_ 不能给外传成败盖章。面对这些记录，处置上只能把凭据按可能暴露处理，同时承认尚无业务数据成功外传的证据。

公开研究也描述过 perfctl 的 libgcwrap.so、ld.so.preload 和 perfcc 组合。本案哈希与公开旧样本不完全一样，家族相似还不能归属到同一操作者。

入口猜测改过一次：先怀疑 SSH，后来查到 Redis

初版取证笔记把 SSH 口令爆破排在入口猜测的前面：root 开着密码登录，失败尝试也多。后来回头查暴露面，一份最后修改于 7 月 4 日的 Redis 5.0.3 配置写着 bind 0.0.0.0、protected-mode no 和弱口令。9 月 20 日从外网做协议级验证，结果如下，口令已去掉：

本机监听 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; → 0.0.0.0:6379 远端 PING &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;→ -NOAUTH Authentication required 远端 AUTH <口令已脱敏> &nbsp; → +OK 远端 CONFIG GET dir &nbsp; &nbsp; &nbsp;→ /var/lib/redis

PING 返回 -NOAUTH，接着 AUTH 得到 +OK，还读到了配置目录。端口开放从“扫描结果”变成了“排查当时公网确实能认证”的事实，入口猜测因此转向 Redis。但 CONFIG GET 是读取，不是写入；配置文件的修改时间也不能证明 Redis 在 7 月到 9 月每天都对公网开放。

更缺的是中间那段：Redis 进程以 redis 用户运行，恶意文件却属 root，现场没有找到从 Redis 到 root 的命令、会话或提权记录。认证日志在 9 月 1 日至 17 日缺失，8 月 16 日轮转后还有多份 0 字节归档，SSH 成功登录也无法彻底排除。8 月 22 日 02:07:43 是最早留有证据的恶意活动，不是精确入侵时刻。

8 月 22 日 01:59，另有一个地址触及 MySQL。现有日志只支持扫描或连接尝试，没看到登录成功；这个地址也不能被提升为“入侵源 IP”，附录按扫描线索单列。

01:28，我们取证时，文件开始自己消失

01:16 到约 01:45 仍是只读取证。我们还在看进程、文件和连接，假 lsof 从 01:28 起消失，随后是挖矿体、perfcc 和定时任务；CPU 占用跌到约 6%。如果此刻只看一次“文件不存在”，很容易误判为已经清干净。

01:16  /proc 计数与 CPU 时间差显示隐藏进程仍在运行 01:28  假 lsof 等可见组件开始消失 01:3x 挖矿 CPU 占用降到约 6%，perfcc、perfclean 也消失 02:28—02:33 perfcc、pctl、Tor 相关数据重新出现

样本、配置和日志先被保全，首包计算了 SHA-256，精确值列在附录的“证据包完整性”行。02:28 至 02:33，部分组件又被写回，elog 02:33:30 的文件操作记录与之相符。文件消失并没有让调查结束，反倒说明需要先保全、再动手。

Redis 的公网认证已经实测成立，即使入口没坐实，也不能等到根除后再收口。它被改为只监听 127.0.0.1，开启 protected mode，换口令，并禁用 CONFIG、MODULE、SLAVEOF 等危险命令；MySQL 收到本机，防火墙拦数据库端口的非本机访问。复查时两个库从公网都连不到，Java 配置也同步改了。这台机器还跑着水表网关和控制台，改监听和口令必须连业务一起验。

09:43，拆掉隐藏库；重启后又被 fstab 绊住

清理不能从 rm perfcc 开始：只要 preload 的隐藏库还在，文件名与进程列表就可能继续被过滤。09:43 起，处置记录显示先用 AAZHDE=1 看见隐藏组件，清掉恶意 preload 指向，再终止挖矿及关联进程，删除 libgcwrap.so、perfcc、工作目录和伪造工具。perfclean 被删除，root crontab 的 perfcc 条目、profile 和 bash_profile 中的恶意行也被移除，最后重启以清掉内存映射的旧库。下面是现场报告的步骤摘要和复核结果，不是逐字终端流水：

清理前  /etc/ld.so.preload → /lib/libgcwrap.so 清理后  /etc/ld.so.preload → 空文件，并设置不可变属性 清理后  libgcwrap、perfcc、.xdiag、.perf.c、perfclean、假工具 → 未见 清理后  主机负载约 8.7 → 低于 1

空 preload 文件被设为不可变，用来暂时挡住旧程序重写。它不是“系统已干净”的证据。

重启还带出一个与恶意程序归属无关、却会立刻影响业务的坑：fstab 里根分区 UUID 行被注释，根分区只读，Redis、MySQL、nginx 起不来。现场恢复该行，执行 mount -o remount,rw /，再拉起 Java 和核心服务。没有证据说明是谁注释了它，不能顺手算到攻击者头上。

约 09:50，preload 为空、已知恶意路径未见，业务服务恢复，HTTPS 页面和 /prod-api/ 返回 HTTP 200。10:45 负载为 0.00，也没查到当时已知的恶意外连与定时任务。业务能响应、症状暂时消失，这是当天可写的结论；机器是否还有别的落点，留给后面的复查检验。

9 月 22 日凌晨，cron 每十秒被改一次

两天后，负载又接近 8.7，top 依然说 CPU 很闲。9 月 22 日约 04:49 的排查把视线转向 crond：日志里，从至少 00:40 起，crontab LIST/REPLACE 大约每 10 秒出现一组；00:52 有 RELOAD /etc/cron.d/perfclean；04:09 和 04:11，CROND 执行了 perfcc 相关任务。/tmp/.perf.c/smartd 与 perfcc 的 MD5 一样，pctl 则在 04:24 落地。

00:40 起  crontab LIST / REPLACE 约每 10 秒重复 00:52    crond RELOAD /etc/cron.d/perfclean 04:09—04:11 CROND 执行 perfcc 路径 04:11    /tmp/.perf.c/smartd 与 perfcc 同 MD5 04:24    /tmp/.perf.c/pctl 落地

事后对时间戳，/tmp/.perf.c/agetty (deleted) 的可执行文件、preload、perfclean 和 perfcc 都指向 00:51 左右。那是后来查到的文件时间，不是 00:51 有人在屏幕前看到了它。日志与文件时间放在一起，才看出从 cron 到载荷重落地的次序。

谁把删掉的 cron 行写回来

反复出现的 cron 行，总得有东西在写。现场临时包装真实的 /usr/bin/crontab，先记录调用者与 PPID 链，再转调原命令。这个动作改变了在线调用链，有业务风险，但抓到了回写命令的核心内容：

(crontab -l | grep -v -e perfcc -e /tmp/.perf;  echo '11 * * * * /root/.config/cron/perfcc') | crontab -

父进程先后叫 agetty、atd、systemd，/proc/<pid>/exe 却都指向 /tmp/.perf.c/ 下的文件。agetty 的 exe 后面还带着 (deleted)：磁盘文件删了，进程仍在内存里跑。假的 systemd 连启动参数也模仿，真正 PID 1 的 exe 仍是 /usr/lib/systemd/systemd。到了这里，“定时任务自己回来”不再只是现象——哪条本机命令在回写、谁发起的，都有了记录。

这里有一处必须停笔。9 月 20 日记录了重启，同一个内存进程不可能跨完整重启活到 22 日。9 月 22 日能确认的是当时有本机进程回写 cron；它在重启后如何重新出现，尚未复原，也不能完全排除新的进入路径。

05:07 的安静，没撑到写报告前

05:00 至 05:07，现场终止当时伪装的回写进程，清理 preload、主程序、perfclean、假工具和 root crontab 中的恶意条目。短时复核给出一串阴性结果：gcwrap 映射数为 0，负载落到 0.03，业务服务 active，约 45 秒没有新的 REPLACE。但那只覆盖了几轮十秒一次的回写。

在线清理本身也出了岔子：真正的 smartd 曾被误杀，随后恢复；sshd 在两轮清理窗口里三次 status=7/BUS 异常退出，SSH 短暂闪断。这些副作用不该从复盘里抹掉。

写报告前的 08:34 复查把刚才的安静推翻了：负载约 8.8，perfcc cron 行、perfclean、假工具和 gcwrap 映射又在。看门狗先换成 atd，再换成 /tmp/.perf.c/systemd。08:42 前现场再次在线压制，但“杀掉进程、删掉目录、负载下降”已经不能当结案条件。

阴性快照下面，还有阳性残留

09:30 左右又查了一轮。/proc 与 ps 都数到 181 个进程，preload 为空，root crontab 只剩正常任务，已知可疑外连也没出现。只看运行态，机器像是平静了。同一轮只读检查往磁盘再走几步，却有另一组结果：

/tmp/.xdiag/                 → 仍有约 28 个条目 /bin/.atmp/、/usr/bin/.atmp/ → 仍存在 /lib/libpprocps.so           → 11,131,211 字节；MD5 与 perfcc 相同 /lib/libfsnldev.so           → 同上；两文件均有不可变属性，非 RPM 文件 /root/.bash_profile          → test -x /bin/perfcc && FPROF=p /bin/perfcc Cron 失败邮件                → 约 42 封，提示 perfcc: command not found

两份 .so 名字像系统库，实际与 perfcc 主程序同哈希；登录脚本还留着启动钩子。约 42 封失败邮件说明 cron 曾反复尝试执行，只是那时找不到 perfcc，不能据此说每次都执行成功。这一眼把“当前没跑”和“机器已干净”分开了。

09:39 至 09:40，确认样本已保全后，现场去掉两份伪装 .so 的不可变属性并删除，清走 .xdiag、.atmp、旧 cron 目录和 bash_profile 钩子；失败邮件移进备份，保住这段反复执行的时间线。复核时已知残留路径不见，负载 0.00，/proc 与 ps 都数到 177 个进程。水表控制台、网关、Redis、MongoDB 处于 active，业务端口正常监听。

10:51 再复查，负载 0.16 / 0.03 / 0.01，进程计数没有异常差；已知挖矿/回种进程、落盘 IOC、相关外连和 perfcc REPLACE 都未见。业务服务仍在。这足以写“观察期未见已知症状”，还不足以写“主机可信”：22 日这一轮没有重启，干净机重建、全量换密与长期观察也没有完成证据。

还有一条线索不能被“回种”叙事盖过去：9 月 18 日至 22 日，一处未知来源多次以 root 密码登录成功，22 日 06:13 也有一次。它不同于已知的运维公钥来源。root 密码后来改过，但禁用密码登录和全量换密没有完成证据；这个登录来源值得单独追，不能未经证实就说它控制了 perfctl。具体地址放在附录。

图3：9 月 22 日现场确认伪装进程回写 crontab 并恢复文件；9 月 20 日重启后的重新拉起路径仍未查明。示意图，10:51 的阴性复查不等于根除。

留下来的不是一份“删文件清单”

最初的问题是工具说谎。top、ps 与 /proc 的 CPU 时间差对不上时，继续在同一套被干扰的工具里找答案，只会绕圈。指定 PID、preload、XFS 目录项和保全样本给了几个独立视角；它们对得上，判断才站得住。

更难的是验收。05:07 的 45 秒无回写、09:30 的运行态阴性，都是真的；08:34 的回潮、09:30 的残留也是真的。清理后要跨多个 cron 周期继续看 LIST/REPLACE、preload、不可变属性、登录脚本和已删文件仍在运行的进程。只写“负载降了、进程没了”太早。

Redis/MySQL 的公网入口已经收口，但整机信誉不会因此自动回来。认证日志与主机检测要恢复，root、数据库、控制台、JWT、开放 API Key 和网关配置等凭据需要按可能暴露来轮换；业务与设备接入要在干净环境里复核。现有材料没有证明重建、全量换密和长期观察已经完成。

技术附记：用进程时间差核对 CPU

下面是按现场方法整理的只读脚本 来自当时主机，这段脚本供同类排查复核方法。

import os, timedef snap():    out = {}    sampled_at = time.monotonic()for pid infilter(str.isdigit, os.listdir('/proc')):try:            raw =open(f'/proc/{pid}/stat').read().rsplit(') ', 1)            fields = raw[1].split()            ticks =int(fields[11]) +int(fields[12])            started =int(fields[19])            out[pid] = (ticks, raw[0].split('(', 1)[1], started)except (OSError, ValueError, IndexError):passreturn sampled_at, outt0, a = snap(); time.sleep(5); t1, b = snap()hz = os.sysconf('SC_CLK_TCK')rows = [((ticks-a[pid][0])/hz/(t1-t0)*100, name, pid)for pid, (ticks, name, started) in b.items()if pid in a and started == a[pid][2] and ticks > a[pid][0]]print(f'total={sum(pct for pct, _, _ in rows):.1f}%')for pct, name, pid insorted(rows, reverse=True)[:5]:print(f'{pct:.1f}%  {name}  pid={pid}')

附录：本案 IOC 与证据等级

正文只留下推动调查的少量名字；可公开的精确匹配值按自然组放在这里。表中的“高”表示本案样本复算或现场观察可靠，不自动表示某个地址属于攻击者主控。哈希只对应这次保全的版本。bprox 的 424 个端点是代理池配置，不作为现成黑名单逐项列出。

样本哈希与文件性质

| 证据等级与对象 | 精确值、用途和限制 |
| — | — |
| 高·主程序 | perfcc ：SHA-256 51e42cb2dd6ec6d9cf808eeda2cc6fa5cf8201e9e0e92345655368a9afae7edb MD5 0c07475851a9329d988f0059bdf160fe。本地三份样本复算一致，均为 11,131,211 字节；包括两份伪装 .so。 |
| 高·隐藏库 | libgcwrap.so ：SHA-256 4c04f4b381bee57ce861524beb705e2db5672d006954ac1719a5df0dc3b957a9 MD5 6d3aa15798ab561e36eeb495aa6b5ce9。本地复算，80,800 字节。 |
| 高·关联文件 | trunk.sx2 与 sctrpth 同哈希：SHA-256 a500b3d749d4f61867a2520434fa01a784460feef6bb1c62d2d8c09cf0480875；MD5 7a7efea875b3fb7e1e3ee3c63c8a86f7。文件头是 ELF，不是 gzip；未证明运行过或完成其功能分析。 |
| 中·挖矿体 | pctl ／曾用名 mysqlshowscsi_mandat 的现场 MD5 为 9da962951a74615809f37746336f0082。本地未保全到本体，没有可复算的 SHA-256。 |
| 高·假工具 | 假 top SHA-256 20de8cf7009f60af5309bf3d864e6a5f80593e26e3a3b9251927c64077e1f546 假 crontab``375b11eca5ec7545863570e528303c76a213238f36d877cb740082cd744df3ac 假 ldd``3d8945796a2332f20741be6663b61a690af2902cb2e51c58d5cf066894c48a0a 假 strace``fb00d44389266d12265a29a5fec88aed00fcf591d78dd001f091548aebd74524。假 lsof 自删，未取得样本。 |
| 高·配置文本 | /etc/ld.so.preload 中“指向 /lib/libgcwrap.so”的文本内容 MD5 为 3403c2384b6f5e625511befb81fbfa01；这不是 .so 文件的 MD5。 |
| 高·排除误报 | 假 /usr/sbin/nologin␠ 与正常 bash 相同的 SHA-256：f420671b28650f60f5461c63353ca0a123b900dbfec0a9ddded83643f068a88e。禁止单独按这个哈希报恶意，要结合文件名尾随空格和 /etc/shells 条目。 |
| 高·配置物证 | bprox 文件 SHA-256 bb0b5fddf841b8a7e8cea1e20050c1ff71816e5365811b4491cb1418b4a7ca58。它是配置文件指纹，不是 424 个恶意 IP 的证明。 |
| 高·证据包 | 首包 物证-20260920-0140.tgz 的 SHA-256 32a32a2f93331d0b82b008b27a6cbe0a388bf9370e6dd862e69755279e9a98a9，用于核对取证包，不是恶意 IOC。 |

落点、回种与采证位置

| 证据等级与类别 | 路径或行为；如何解释 |
| — | — |
| 高·加载 | /etc/ld.so.preload → /lib/libgcwrap.so；另见 /usr/lib/libgcwrap.so。主程序在 /usr/bin/perfcc、/root/.config/cron/perfcc，伪装副本在 /lib/libpprocps.so、/lib/libfsnldev.so。单独一个 preload 路径不是通用恶意特征，须看内容与样本。 |
| 高·落点 | /tmp/.perf.c/ 、/tmp/.xdiag/；出现过 /tmp/.perf.c/pctl、/tmp/.perf.c/smartd、/tmp/.perf.c/agetty、/tmp/.perf.c/atd、/tmp/.perf.c/systemd、/usr/bin/mysqlshowscsi_mandat。agetty 的 exe 曾带 (deleted)。 |
| 中·仅配置 | /tmp/.perf.c/httpd 出现在本地配置中，未证明现场运行。/usr/bin/wbin/ 关联脚本中的私有 Docker 逻辑，主机没有安装 Docker。 |
| 高·假工具 | /bin/.atmp/ 、/usr/bin/.atmp/ 有残留；假工具在 /bin/.local/bin/ 或 /usr/bin/.local/bin/ 映射。/etc/profile 写有 export PATH=/bin/.local/bin:$PATH。 |
| 高·持久化 | /etc/cron.d/perfclean ：9 * * * * root perfcc；root crontab：11 * * * * /root/.config/cron/perfcc；约每 10 秒出现 crontab LIST/REPLACE。/root/.bash_profile 钩子是 test -x /bin/perfcc && FPROF=p /bin/perfcc。 |
| 高·假登录 shell | /usr/sbin/nologin␠ 与 /etc/shells 中的 /sbin/nologin␠；␠ 表示真实的尾随空格，不能去掉后再匹配。 |
| 高·伪装包 | trunk.sx2 、sctrpth 和 trunk.7a7efea875b3fb7e1e3ee3c63c8a86f7_error_.sx2.tar.gz。后者带 _error_，不能据此确定外传成败，也不能凭扩展名当正常归档。 |
| 高·采证位置 | /tmp/.xdiag/data/tty/ 、/tmp/.xdiag/data/pam/sshd.log、/usr/bin/.atmp/tmp/.applocal.xdiag/r.log、/tmp/.xdiag/scf/、/tmp/.xdiag/hs.txt、/tmp/.xdiag/pi、/tmp/.xdiag/exi。这些是取证位置，不能整组当恶意可执行文件。 |
| 中·采证位置 | /tmp/.xdiag/int/xppi 、/tmp/.xdiag/int/bprox，需结合内容与同机行为解释。 |

网络、账号与配置地址

| 证据等级与观察类型 | 地址与边界 |
| — | — |
| 高·样本配置 | 82.197.71.254:40208 是直连配置值；Tor 配置主机字符串是 nbvutgzgzszkmcyp52vxxdax7q4kw635kzel5x3mhmk6r6lng65elcqd，按地址格式可写作 nbvutgzgzszkmcyp52vxxdax7q4kw635kzel5x3mhmk6r6lng65elcqd[.]onion。配置存在，未证明成功通信。 |
| 中·配置片段 | /CRR5u70lyG 只是路径片段，不能写成已成功访问的 URL。 |
| 高·外连 | 184.178.172.25:15291 、199.102.104.70:4145；观察到连接，不等于确认矿池或攻击者 C2。 |
| 高·登录 | 154.16.112.232 在日志中以 root 密码登录成功；历史反向解析 peanut[.]dmpress[.]org 仅为中置信关联。该来源与 perfctl 的关系待查。 |
| 高·扫描/失败 | 178.159.37.70 仅见 MySQL 扫描/连接尝试，未见登录成功；SSH 失败尝试来源有 117.80.223.38、218.60.77.234、219.151.181.179。 |
| 低·清单参考 | 另份笔记提及 104.238.180.207、104.243.33.118，本地未收录原始清单，不能据此判断两者参与本机入侵。 |
| 高·代理池 | bprox 有 424 个端点、374 个不同 IP，其中一个是 127.0.0.1；完整端点保存在独立取证清单。这个配置池不宜直接作为恶意主控封禁名单。 |

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：MessFreeSecurity messfree
messfree《8 核主机负载 8.7，top 却显示空闲：一次 perfctl 入侵应急复盘》