被攻击后检查定时任务是第一要务，服务器被植入挖矿脚本、木马后门时，攻击者为了维持权限，九成以上会把恶意脚本写进Crontab等计划任务里，先检查定时任务能最快锁定后门入口,而不是盲目杀进程。
为什么攻击者偏爱在定时任务里植入恶意脚本
定时任务对攻击者来说就是一台服务器上的“自动打卡机”，他们不需要一直盯着控制端，只要把恶意脚本挂进Cron规则，系统就会按设定时间自动执行,这种机制天然适合持久化驻留。
从攻击者的视角看,定时任务有三个长期优势：
- 自动运行不依赖入口权限：Webshell被删、反弹shell断连之后，只要Cron里还有一条恶意记录，系统到点就会重新拉取或执行脚本，相当于攻防拉锯中的“复活甲”。
- 隐蔽性远高于启动项：大多数运维排查习惯集中在
/etc/init.d、开机自启动目录，定时任务分散在多个目录、多个用户下,很容易被忽略。 - 适合批量控制肉鸡：攻击者通过Cron定时从远端服务器下载最新DDoS攻击命令或挖矿配置,比逐台手动执行高效得多。
据国家互联网应急中心此前的安全通报，近年来国内企业服务器失陷事件中，相当一部分都与计划任务被恶意利用有关，行业共识认为,定时任务目录是应对入侵排查时优先级最高的检查项之一。
被攻击后检查定时任务：三步定位可疑脚本
第一步：全量比对当前定时任务
先别急着删任何记录，第一步是把所有定时任务完整导出来存档，这是后续判断“哪些是攻击者加的，哪些是原本就有的”的唯一依据。
普通用户和Root用户的Cron位置不同,需要分头排查：
- 查看当前用户任务：
crontab -l - 查看Root任务：
sudo crontab -l - 查看系统级任务：
cat /etc/crontab - 查看Cron目录：
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.weekly/ /etc/cron.monthly/ - 查看所有用户的任务文件：
ls -la /var/spool/cron/crontabs/
导出后注意检查每条任务的实际执行脚本路径，恶意任务通常具备几个明显特征：指向
/tmp、/var/tmp、/dev/shm这类临时目录；执行命令包含wget、curl、base64、eval等下载解码关键字；或者出现随机命名的.sh文件。
第二步：检查隐藏执行痕迹
攻击者为了防被发现，常对任务做时间戳篡改或权限伪装，排查时需要找到“被动过手脚”的文件。
一条命令看文件真实修改时间：
stat /var/spool/cron/crontabs/root stat /etc/cron.d/nginx
对比stat输出中的Modify时间与当前入侵事件发现时间,就能判断任务是不是在事发节点前后被写入的。
再检查任务日志，大多数Linux发行版的Cron执行记录在/var/log/cron或/var/log/syslog中：
grep -i cron /var/log/syslog | tail -n 100
如果日志中频繁出现相同的脚本路径，且执行频率远高于正常业务需求，这条任务基本可以判定为恶意，部分攻击者还会清空日志规避追踪，此时检查/var/log/cron是否存在异常截断,也是有用的判断依据。
第三步：结合进程与网络连接倒查来源
定时任务排查不能只停留在规则层面，找到可疑任务后，先别急着删除，要利用它反过来追踪攻击者的控制服务器和恶意脚本来源，但这个追踪环节通常已经超出普通站长能力范围，涉及网络取证与样本逆向分析，尚未失陷数据的服务器应优先做好隔离,不要随意执行可疑脚本。
在隔离环境下，通过lsof -p 进程ID查看恶意进程打开的连接，再通过netstat -antlp | grep 恶意进程ID找到C2服务器地址，对于无进程、纯定时下载型任务，可先备份脚本内容，再用沙箱或隔离网下载分析，避免直接在业务服务器上运行，攻击者常将恶意地址硬编码在脚本中,这些信息对后续加固和安全通报有重要价值。
服务器定时任务被篡改后，如何恢复与加固
确认定时任务被篡改后，很多人的第一反应是“都删了”，但直接删除会导致正在运行的恶意进程失去上游控制，个别变种会触发自我保护机制，反噬系统文件,按照顺序操作更稳妥：
恢复正确流程
- 全面备份当前所有定时任务到本地文件，
crontab -l > /backup/恶意任务备份_日期.txt cp -r /var/spool/cron /backup/
- 停掉与恶意任务相关的进程：先通过
ps aux | grep 脚本名找到PID，执行kill -9 PID前确认进程确实由恶意任务拉起,避免误杀业务进程。 - 使用
crontab -r清除当前用户任务，然后清理/etc/cron.d/和/var/spool/cron/crontabs/下的可疑条目，保留原有合法任务,不建议整目录清空。 - 从之前导出的备份中,还原正常任务。
- 清理脚本本身：根据任务路径删除恶意脚本文件，同时对
/tmp、/var/tmp进行检查。 - 修改服务器Root密码、数据库密码、面板管理密码,压缩攻击者后续可利用的凭据。
两三台服务器的排查手工操作即可，但大量服务器场景下，可以用自动化脚本批量检查，对比线上所有服务器Cron文件的哈希值，不同服务器间若出现高度一致的异常任务,基本可确定是同一批次攻击失陷。
防止二次被植入的加固策略
清理任务只是第一步，如果不堵住后门，攻击者随时可以重新写入，修复漏洞后,需要做几件实事：
- 锁定定时任务文件：为
/etc/crontab和Cron目录设置不可变属性，防止被再次修改，执行chattr +i /etc/crontab和chattr +i /etc/cron.d/，需要修改任务时先执行chattr -i解除锁。 - 限制高危命令写入：在
/etc/cron.deny中添加非授权用户名单，禁止普通用户创建计划任务，这个文件的优先级高于cron.allow,配置时要注意先后顺序。 - 对关键目录加审计监控：使用
auditd设置对/etc/cron.d/、/var/spool/cron/crontabs/的写入监控，一旦任务被篡改,日志会记录下完整操作者信息。 - 定期做基线校验：保存一份正常状态的Cron配置清单，每周自动对比一次，发现差异立即告警，开源工具有Tripwire、AIDE，功能类似的商业产品也很多,选择适合自己业务体量的即可。
无论使用简米云、酷番云还是自建机房，建议把所有业务服务器的定时任务统一纳入运维管理平台，集中审计比逐台登录检查的覆盖率高得多，云环境中小规模服务器也可以直接用云厂商安全组自带的“基线检查”功能，自动扫描Cron异常项,相比纯手工核查更全面。
Q&A：定时任务被植入恶意脚本的高频问题
服务器没有安装宝塔面板时怎么排查定时任务？
没有面板工具就需要走纯命令行路径，登录服务器后依次执行前文第一到第三步的命令，在/var/spool/cron/目录下按用户逐一查看，若服务器是Windows系统，排查方向不同，需要使用schtasks命令列举计划任务，重点检查指向C:UsersPublic或C:ProgramData下不明.bat和.vbs文件的计划项,这两类路径是Windows恶意计划任务的高发区域。
定时任务被植入恶意脚本，但找不到攻击来源怎么办？
排查攻击源时，优先看/root/.bash_history、/var/log/secure、/var/log/auth.log，攻击者通常通过SSH弱口令或Web漏洞进入系统，在登录日志中能查到爆破痕迹，如果日志都被清除，则侧重检查Web目录上传点，重点扫描runtime、uploads、static目录下新增的.php、.jsp、.aspx文件，找到WebShell后，攻击路径就追溯到了，如果自身技术力量不足，可以联系云厂商安全团队或专业应急响应服务商接管溯源，别在未确认攻击路径时直接重装系统,重装后再次被入侵的可能性很高。
清理完定时任务后，需要重装系统吗？
取决于后门是否被彻底清除，如果恶意脚本只存在于Cron和/tmp目录，且系统核心文件哈希校验无异常，清理加固后无需重装系统，如果发现系统内核模块被替换、SSH公钥被篡改或存在未知Rootkit，直接重装更安全，重装前先备份业务数据和配置，注意备份文件本身也要单独扫描确认干净,避免带着后门数据上新的服务器。