时间：2018年5月16日
起因：某公司的运维人员在绿盟的IPS上监测到有挖"门罗币"的恶意事件，受影响的机器为公司的大数据服务器以及其他Linux服务器。
我也是赶鸭子上架第一次解决运行在Linux上的挖矿病毒事件，由于当时自己没有专门的Linux挖矿的清理工具，便开始分析IPS上提供的信息。
由于当时的部门对数据的保护比较敏感，并没有对当时操作进行拍照截图，我也只能根据当时我记录的笔记和依稀的记忆来梳理整个事件。
IPS提供的信息：
1：受到影响的IP
2：受影响主机连接的地址（158.69.133.18）
3：事件名称（具体的名称忘记了，大概的意思就是，挖门罗币的恶意事件），后面跟着发生的时间
根据这些信息，并结合当时没有Linux的杀毒软件这种情况，我整理了一下自己的工作思路
1：找到挖矿的进程
2：查找相关进程
3：清理
4：整理文档
想清了思路，便开始干活
由于当时太注重“挖矿”这个词了，上来我就在那个命令行下输入top命令，准备找找那些可疑的占内存特大的进程，看着哗哗的进程不断在眼前流动，自己心里有些慌了，好多进程占用的资源都挺高的。由于那是一台云计算的服务器，上面有好多进程自己也不清楚，结果自己就在那些正常的进程上废了好多时间也没找到有问题的进程。
然后我转变入手的关键，从那个外联的地址（158.69.133.18）入手。
输入命令：netstat -anp | grep "158.69.133.18"
当时自己真的挺幸运的，还真找到了那条连接 百度上是加拿大地址的IP（158.69.133.18）。之所以说自己是幸运的，是因为后面发生了一个“奇怪”的现象。
当自己找到那个恶意进程后，身旁的那个运维人员也特高兴了，赶紧将我的那条命令发给其他出问题的部门，让他们也找一下。
就是因为她的积极也引出了接下来的“奇怪”事件。
其他部门的运维人员，用了那条命令（netstat -anp | grep "158.69.133.18"）后，有的反应说找到了，有的却说没有。
当说没有的时候，我还以为他们输入错了，结果自己重新输入那条命令时，返回来的竟然是空白。
“难道说那个病毒制作的人，发现我们在找他的恶意程序了？”，我当时自己乱想着，边翻看着IPS上的告警信息。
我忽然想到了这些×××事件上的时间，利用IPS的条件过滤，将我分析的那台Linux服务器IP地址输上去，并选择这条事件编号，回车。
看着重新刷新出来的数据，我看到了自己想知道的那条信息，受影响的主机并不是实时连接那个IP（158.69.133.18），每次的连接间隔大约是半小时。
“总不能等半个小时后再分析这个问题啊”，心里这样想着，我又在命令行下输入netstat -anp。看着大量的进程出来了，没思路看着大量的数据就困。闲着往上翻这些数据，我也在幻想着如果自己拿到一台服务器，自己要做什么，留后门！赶紧在netstat -anp 后加一条grep语句，这次grep bash。完整的命令是netstat -anp | grep bash。
果然，自己还是那么幸运，一条过滤后的结果出来了。过滤出的结果，我谨慎的百度了一下那个IP，依稀记得是美国的一个地址。让其他运维人员过滤 bash这个关键词，也都找到了那条异常的进程。
顺藤摸瓜，继续深入，免得一会这个进程又消失，输入命令：ps -ef | grep PID（那条异常的进程IP，我当时也没记录这个ID号）
然后出来了一个文件路径，当时的笔记是/tmp/.lsb/路径下的一个文件
这是当时那个文件里的文件，当时里面还存在两个文件夹(h32和h64)，当时拷到电脑上结果直接被win10的windows defender给杀了。当时指向的是h32下的一个文件。
保留病毒样本后，就将这个进程kill了，然后把这个文件夹删除。
最后在计划任务里找到一个异常的计划任务，删除掉。
最后观察了四个小时，IPS上没有这台服务器的告警信息了，在服务器上也没有找到其他异常的进程了。
自己整理了一下，清理步骤，也就是那几条命令，转发给其他中这个挖矿的病毒的运维人员了。让他们自己一起处理。
当然在这期间，还发现其他的挖矿病毒，有的真的很厉（jiao）害（hua），通过检测cpu，只要达到25%就kill掉自己。
付一张在其他服务器上发现的不同的文件
其中那两个后缀为jpg的文件其实是两个脚本，用文本编辑器查看（部分截图如下）
如果不是IPS上有告警，还真的不知道自己的服务器已经沦为别人的挖矿肉鸡了。
总结：日常的运维要经常看看有没有异常登录，要看看管理的服务器的日志。该架设的安全设备可以和老板提提，不然自己就多看看自己负责的服务器要经常看看日志，看看有没有新的进程。不然出了事情，解决不了，就准备背锅吧。
原文地址：http://blog.51cto.com/11789213/2141042