【应急响应】Linux 服务器被黑:一次从 WebShell 到后门账户的完整排查-仿真靶场

wp参考：https://pan.baidu.com/s/1fb4eL4U1UaXOdMT4iYDMjA?pwd=kgvqhttps://mp.weixin.qq.com/s/nYNSnPB5xTAslb_rVvioLg?scene=1&click_id=12

在线靶场地址：https://vip.mhtsec.com/ulab/lab.html?page=target-detail&id=38

这道靶场主要考什么

Linux 服务器被黑应急响应靶场考点该靶场环境来自暗月 2025 培训课程，请使用 web123/Abc@1234 通过 SSH 远程连接，如需 root 使用 sudo -i 切换。flag 答题程序在桌面文件夹中，执行后答题获取最终 flag。

1. 日志分析能力

• • Web 访问日志（Apache access.log / error.log）时间线提取与关键字检索
• • Linux 认证日志（/var/log/auth.log）登录成功/失败、sudo 使用记录解析
• • 日志轮换与压缩日志（*.log.* / *.gz）联合查询技巧（grep/zgrep）
• • 结合时间戳快速定位攻击路径与源头 IP

2. 文件系统取证

• • 基于 mtime/cmin 的近期文件查找（find -mtime -1 / -cmin -720）
• • 敏感后缀（*.php*.sh*.so）与临时目录（/tmp/dev/shm/var/tmp）重点排查
• • 精确打印文件创建/改动时间（-printf %TY-%Tm-%Td %TH:%TM:%TS %p）
• • Web 根目录深挖与后门文件内容静态分析

3. 账号与权限审计

• • /etc/passwd、/etc/group 中 shell 用户与特权组（root、sudo）梳理
• • 用户家目录创建时间（ls -ld /home/*）与系统新增账号定位
• • sudo 授权记录与提权操作复现
• • SUID 可执行文件扫描（find / -perm -u=s -type f -mtime -2）与风险判定

4. 进程与网络监控

• • top / ps 实时进程观察，异常服务识别
• • netstat -anltp 网络连接清单，异常端口/外部 IP 定位
• • crontab、/etc/cron.* 计划任务全面检查，持久化后门排查

5. Web 漏洞利用链复盘

• • 后台弱口令 → 登录 → 模板/缓存写入 → GetShell 流程还原
• • 目录扫描（gobuster 特征）与后台功能滥用（makehtml_homepage.php）关联分析
• • WebShell（加密 POST、AES128 + eval）流量特征识别

6. 应急响应与加固

• • 攻击 IP 封禁、后门账号与文件清理
• • 系统与数据库口令重置、最小权限原则
• • 安全设备（防火墙、IPS、AV）部署与策略调优建议
• • 定期基线检测与日志集中收集方案

一、事情起因

某天客户反馈：Linux 服务器存在异常连接，疑似被入侵，需要应急工程师到现场排查，并出一份应急响应报告。

二、准备工作

根据客户提供的 IP，对服务器进行初步分析。

先通过 SSH 连上目标服务器。

这次任务本质上就是 入侵排查。而这台机器上有 Web 服务，所以第一反应就是：先看有没有 WebShell。

三、先从 Web 目录排查落地文件

Tip

排查思路真实应急里，Web 根目录、临时目录、用户目录 往往都是最先看的地方。因为攻击者无论是传脚本、写后门还是放临时载荷，十有八九会碰这些路径。

以下是常用排查命令。

1）先看 24 小时内改过哪些文件

# 全盘找最近 24 小时被修改过的文件find / -type f -mtime -1 -ls 2>/dev/null

2）重点看临时目录、Web 目录和用户目录

快速定位近期在临时目录、Web 目录及用户目录中被创建或修改的文件，这些位置常被攻击者用于存放恶意脚本、后门或临时载荷。

# 优先排查高风险目录find /tmp /var/tmp /dev/shm /var/www /home -type f -mtime -1 -ls 2>/dev/null

3）扫可疑后缀文件

全盘扫描最近 24 小时内新增或修改的可疑脚本 / 库文件：

# 重点筛 php / sh / so 这类高危文件find / -type f -mtime -1 \( -name "*.php" -o -name "*.sh" -o -name "*.so" \) -ls 2>/dev/null

4）在 Web 目录里继续深挖

在 Web 目录中扫描最近 3 天内新增或修改的可疑脚本 / 库文件，并对每个文件执行 ls -lta：

# 在 Web 根目录内缩小范围排查find /var/www/html -type f -mtime -3 \( -name "*.php" -o -name "*.sh" -o -name "*.so" \) 2>/dev/null | xargs ls -lta

5）命中可疑文件：shell.php

先从 Web 目录找起，这里也是最容易有 WebShell 的地方。

使用命令找到 shell.php：

# 枚举 Web 目录中的 php / sh / so 文件，并按时间细看find /var/www/html -type f \( -name "*.php" -o -name "*.sh" -o -name "*.so" \) 2>/dev/null | xargs ls -lta

使用 stat 查看详细时间：

# 查看文件的精确时间戳stat /var/www/html/shell.php

得到时间：2025-06-29 14:30:15

第一题解出：

四、回看 Apache 日志，还原 Web 入侵过程

继续排查，中间件日志里搜一下关于 shell.php 的访问记录。

# zgrep 能同时搜普通日志和 .gz 压缩日志zgrep 'shell.php' /var/log/apache2/access.log*

• • zgrep：能搜索 普通日志 + .gz 压缩日志
• • access.log*：匹配所有 Apache 访问日志

我自己平时更喜欢这个写法，按时间排一下，顺手很多：

# 以 [时间] 字段排序，方便拉时间线zgrep 'shell.php' /var/log/apache2/access.log* | sort -t "[" -k 2

从日志里能先看出几个关键信息

• • 29/Jun/2025:13:23:26 +0800，192.168.10.145 这个 IP 在扫目录，最后扫到 shell.php
• • 29/Jun/2025:14:32:53 +0800，192.168.10.94 在通过 http://192.168.10.107/rm4u.php 去使用 shell.php，所以 rm4u.php 也不是什么好东西

已知：

• • 192.168.10.107 就是当时被攻击的服务器 IP
• • 192.168.10.145 在扫目录
• • 192.168.10.94 在连 shell.php

锁定 192.168.10.145 和 192.168.10.94，全票打飞这两只狼。

往前倒推 3 小时，看完整入侵链

从 14:30 往前推 3 个小时，分析攻击者的入侵行为，顺便看看还有没有别的 IP 混进来。

# 回看 11~14 点这个时间段的 Apache 访问日志zgrep "29/Jun/2025:1[1-4]:" /var/log/apache2/access.log* | sort -t "[" -k 2

全是爆破记录：

攻击者是用 gobuster 去爆破的。

先把 gobuster 特征排除掉，再看别的：

# 去掉明显的目录扫描流量，聚焦真实利用请求zgrep "29/Jun/2025:1[1-4]:" /var/log/apache2/access.log* | grep -v gobuster | sort -t "[" -k 2

再统计一下 IP：

# 统计这个时间段里出现过的源 IPzgrep "29/Jun/2025:1[1-4]:" /var/log/apache2/access.log* \| grep -v gobuster \| sort -t "[" -k 2 \| awk '{print $1}' \| cut -d: -f2 \| sort \| uniq -c

关键日志摘出来看

/var/log/apache2/access.log.1:192.168.10.145 - - [29/Jun/2025:13:40:05 +0800] "POST /dede/login.php HTTP/1.1" 200 1540 "http://192.168.10.107/dede/login.php" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0"/var/log/apache2/access.log.1:192.168.10.145 - - [29/Jun/2025:13:40:06 +0800] "GET /dede/index.php HTTP/1.1" 200 4359 "http://192.168.10.107/dede/login.php" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0"/var/log/apache2/access.log.1:192.168.10.145 - - [29/Jun/2025:13:40:06 +0800] "GET /dede/css/frame.css HTTP/1.1" 200 2464 "http://192.168.10.107/dede/index.php" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0"/var/log/apache2/access.log.1:192.168.10.145 - - [29/Jun/2025:14:29:19 +0800] "POST /dede/makehtml_homepage.php HTTP/1.1" 200 462 "http://192.168.10.107/dede/makehtml_homepage.php" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0"/var/log/apache2/access.log.1:192.168.10.145 - - [29/Jun/2025:14:29:21 +0800] "GET /tags.php HTTP/1.1" 200 312 "http://192.168.10.107/dede/makehtml_homepage.php" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0"/var/log/apache2/access.log.1:192.168.10.145 - - [29/Jun/2025:14:30:15 +0800] "POST /dede/makehtml_homepage.php HTTP/1.1" 200 463 "http://192.168.10.107/dede/makehtml_homepage.php" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0"/var/log/apache2/access.log.1:192.168.10.145 - - [29/Jun/2025:14:30:16 +0800] "GET /shell.php HTTP/1.1" 200 312 "http://192.168.10.107/dede/makehtml_homepage.php" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0"

这段日志基本能说明什么

192.168.10.145 在 29/Jun/2025:13:40:05 登录了 dede/login.php，随后访问 dede/index.php。到了 29/Jun/2025:14:29:19 和 14:30:15，又两次访问 makehtml_homepage.php，紧接着在 14:30:16 成功访问 /shell.php。

这里大概率就是：后台弱口令登录成功后，利用后台功能把 WebShell 写进去了。

Note

说明一下Apache access.log 默认通常只记录请求行、状态码、来源页、UA 等信息，不会直接记 POST 包体内容，所以这里能还原出“访问了哪个接口”，但拿不到当时具体提交了什么参数。

访问后台后也能发现：确实存在弱口令问题。

五、继续往内网主机上挖：排查 SSH 与本地账户

客户反馈服务器存在异常连接，那接下来就该看服务器内部了。

1）先看 SSH 登录成功和失败日志

# 查看 SSH 成功/失败登录记录grep -E "Accepted|Failed" /var/log/auth.log* | sort

/var/log/auth.log.1:Jun 30 00:42:31 web123-virtual-machine sshd[4009]: Accepted password for sysadmin from 192.168.10.145 port 59900 ssh2

发现 192.168.10.145 在 Jun 30 00:42:31 用 sysadmin 账户成功登录过。

所以，用户 sysadmin 和攻击者有强关联性。

2）继续追 sysadmin 的行为

# 追踪 sysadmin 在认证日志里的相关行为grep "sysadmin" /var/log/auth.log* | sort

从日志看：

• • sysadmin 是 00:41:32 新创建的
• • 创建后立刻改密码
• • 紧接着被加入 root 组
• • 很快又从外部 IP 成功 SSH 登录
• • 后续又被加入 sudo 组

Note

一个小提醒文中这里说“加入 root 组”，这个动作本身就已经非常异常了；而真正更关键的权限提升信号通常是被加入 sudo 组，或者拥有可直接提权的 sudoers / SUID 配置。

六、排查提权痕迹：SUID 异常文件非常扎眼

1）看 SUID 权限文件

# 列出系统中的 SUID 文件，并按时间排序看最近异常项find / -perm -4000 -type f 2>/dev/null | xargs -r stat -c "%y %n" | sort | tail -n 30

其中有一条特别扎眼：

2025-06-30 00:53:11.753845900 +0800 /usr/local/bin/rootshell

最后这个 rootshell 明显不正常。它出现在 /usr/local/bin/ 里，而且创建时间是 30 号 00:53 分，和整个入侵时间线高度吻合。

它通过 setuid + /bin/bash 获得 root shell。rootshell 基本就是提权核心程序。

七、继续查后门账户：攻击者不止留了一个人

1）找最近创建的账户

# 看 /etc/passwd 末尾新增账户tail -n 30 /etc/passwd

这里原文写的是“uuid1000 开始的才是用户”，这里顺手更正一下：应该是看 UID，通常很多 Linux 发行版里 UID >= 1000 的更可能是普通用户（具体也要结合发行版和现场环境判断）。

可以看到这里比较值得关注的是 1001 和 1002 这两个账户。

2）查看 backdoor 的创建行为

# 从 systemd/journal 日志里找创建账户、改密码、改组等动作journalctl --no-pager | grep -E "new user|useradd|chpasswd|usermod|backdoor" | tail -n 120

可以看出：

• • 6 月 30 00:41:32：创建 sysadmin
• • 6 月 30 00:41:39：设置密码
• • 6 月 30 00:41:47：加入 root 组
• • 6 月 30 00:47:44：加入 sudo 组

• • 6 月 30 00:55:04：创建 backdoor
• • 6 月 30 00:55:48：设置密码
• • 6 月 30 00:55:58：加入 sudo 组

所以，攻击者最后一次创建的后门用户名是：backdoor。

八、把整条攻击链串起来

Summary

攻击链复盘这台机器并不是“突然异常”那么简单，而是已经被攻击者一步一步打穿并做了持久化。

时间线梳理

用一个简单思维导图看更直观

最终结论

• • 攻击者通过 Web 漏洞落地并利用 shell.php
• • 在 2025-06-29 到 2025-06-30 之间持续通过 WebShell 控制主机
• • 随后创建高权限后门账户 sysadmin
• • 使用 sysadmin 从 192.168.10.145 成功 SSH 登录
• • 登录后尝试读取 /etc/shadow，并进行了提权相关操作
• • 在系统中落地异常 SUID 程序 /usr/local/bin/rootshell
• • root 历史命令中明确记录了它的编译和赋权过程
• • 后续又创建了新的后门用户 backdoor
• • 并把 backdoor 加入 sudo 组用于持久化

九、这类场景里，实战上应该怎么处置

Danger

应急处置建议如果这是实战现场，而不是靶场，下面这些动作一般都要尽快做。

1. 1. 先隔离主机：必要时从网络侧临时隔离，避免攻击继续横向或回连。
2. 2. 封禁恶意 IP：重点关注 192.168.10.145、192.168.10.94。
3. 3. 清理 WebShell 与异常文件：如 shell.php、rm4u.php、/usr/local/bin/rootshell。
4. 4. 清理后门账户：如 sysadmin、backdoor，并复核 sudoers、计划任务、SSH 公钥等持久化点。
5. 5. 重置密码：包括系统账户、后台 CMS、数据库、中间件密码。
6. 6. 回收权限与加固：最小权限、禁弱口令、关闭不必要服务、开启日志集中留存。
7. 7. 补充检测：检查 crontab、systemd service、启动项、~/.ssh/authorized_keys、临时目录残留文件等。