我现在所在的公司负责的一个项目，使用的是阿里云ecs服务器，4核8G。近期阿里云提醒有安全漏洞，登录阿里云账号之后，根据提示删除了相应的文件。但是比较奇怪的是服务器内存一直升高，一度达到了80%以上，开始怀疑是由于用户激增导致，也没有太过于放在心上。
但是连续几天持续发生这种情况，而且跑的一些定时任务进程也被无故杀死，才引起了我的注意。当然这个时候还是没有太当回事，只是随手重启了服务器，又重启了定时任务。查看了一下ecs内存使用率，降到了10%以下，定时任务也正常。但是短短一分钟以后，内存开始持续升高，定时任务再次被杀死。
进入到ecs远程登录界面，通过命令top查看进程信息，确实存在一个高耗进程，达到200%，果断将它kill掉。但是没过一会，这个进程再次出现，只不过是换了一个PIDE而已。到了现在，我已经彻底肯定是被挂马，我管理的这台服务器被当成肉鸡了。
输入命令：crontab -l 进行排查
/root/.systemd-service.sh 这个基本已经确定是问题脚本！
进入到root目录查看这个脚本，是被base64编码
通过百度base64解码将命令解析出来发现这个脚本在目录 /tmp/.X11-unix/ 下。
进入到这个目录下：
现在挨个看看这几个文件内容：
从截图的内容很容易得到两个进程异常PID，kill掉也不能彻底解决。
谨慎起见，我查看了一下 /etc/hosts文件是否正常，好在我这里是比较正常的。
继续查看/etc/cron.d/
发现了一个异常文件：0systemd-service，打开查看一下
cat 0systemd-service
发现在opt目录下有一个脚本 systemd-service.sh。。。。原来你藏在这里！！！
打开这个罪恶的文件看了一下没看懂，哈哈，还是去解码看的
最后终于找到了所有问题所在
存在两个问题进程PID:1847和4719
两个问题文件：分别是 /root/.systemd-service.sh 、/opt/systemd-service.sh
这两个定时任务分布在crontab和/etc/cron.d/0systemd-service
最终我的解决办法是：
1.首先清理crontab
2.删除 /etc/cron.d/0systemd-service
3.删除两个脚本： /root/.systemd-service.sh 、/opt/systemd-service.sh
4.kill两个进程1847和4719
5.最后重启服务器，查看内存是否降低（别忘了重启定时任务哦）
终于彻底搞定了吗？其实表面上确实是解决了。这样才是给大家提个醒，还是要看一下服务器是否存在漏洞。希望能够给大家带来帮助！