服务器集体中毒事件 xmrig trace 挖矿病毒
事件简述：
2019年12月22日，我们服务的一个客户服务器大面积提示被用于“挖矿”，随即我们便进行了病毒的清理，但病毒的来源通过我们原有实施的监控和安全检测中并未能发现。事前我们在服务器的远程登录上限制了只允许VPN+堡垒机登录，对服务器的各方面性能、所有人员的风险操作以及可能通过web渗透的异常登录和执行行为均有监控和告警，但这次在服务器监控和安全监控中我们却未找到任何端倪。
发生这次事件之后，我们增加了系统安全审计，网络访问日志等相关的监控和告警。之后几天中，一切暂时归于平静，但在12月26日的时候，客户的服务器集体访问恶意下载源的情况又再次发生了。我们通过网络流量分析、增加操作文件的监控，系统操作审计，分析出“访问恶意下载源”均来自于名为aliyun-service的程序，但事实真的如此么？
下面我们对此次事件的分析进行还原：
一、环境简介
- 云平台：阿里云 华北区
- 操作系统：Centos 7.x
- 云安全中心：免费版（基线检查未启用）
二、故障描述
2019年12月22日，阿里云监控提醒通知“大部分服务器用于挖矿”，检查主机安全问题后，我们手动清理了位于/tmp目录和/home目录下的挖矿病毒。前期我们在客户服务接入的期间，已经对每个客户的服务器都进行了主机、操作记录的审计，但这样的日志并没有帮助我们排查出具体病毒攻击根源（当时怀疑可能是阿里云底层平台触发了此类的事件）。
2019年12月26日13点39分，阿里云再次提醒服务器批量访问恶意下载源（未执行挖矿程序），安全事件再次暴露，表示很头大，但我们坚信一定可以找到蛛丝马迹，为了定位到这个根本原因，我们增加了文件目录的变更监控，同时增加了网络的请求和监控，也就是通过文件的监控和网络请求的监控，帮我们分析出问题的原因。下面将整个安全事件分析的过程在此进行复盘。
三、处理过程
（1）增加操作审计
利用audit开启Linux操作审计功能，生成日志路径/var/log/audit.log
auditctl -a always,exit -F arch=b64 -S open -F auid=0启用我操作系统目录监控（前期发现这两个目录存在挖矿病毒下载的情况）
auditctl -w /tmp -p rwxaauditctl -w /home -p rwxa（2）配置网络连接监控
使用linux 自带防火墙开启日志记录
iptables -I INPUT -j LOG --log-leve 5 --log-prefix"IPTABLES"查看网络请求日志/var/log/messages可以看到详细的网络连接请求记录。
为了能第一时间发现病毒，我们将操作系统审计日志接入立维日志平台。并对关键字进行实时的监控和报警，提取审计日志文件中存在trace.tgz关键字，出现异常第一时间通知到负责人。
通过对/tmp目录的审计，发现/tmp/目录下的t-bj-5s2hkk2ajnk.sh脚本文件是由auid为4294967295的aliyun-service这个服务进行创建。
根据auid的日志分析，我们进入/usr/local/share/aliyun-assist/1.0.1.402/ 目录发现存在log文件目录，检查aliyun_assist_main.log 日志，可以判断当前commandContent 字段中的内容base64编码。
转码后内容如下：
（5）分析脚本文件
我们再去查看/tmp目录下文件，发现存在两个脚本文件。
查看文件内容发现和我们刚才base64转码后内容一致
我们登陆阿里云后台安全中心，看到系统有大量进程异常下载安全报警，我们点击其中一个安全事件，发现系统执行恶意shell代码。
通过这些分析对比，我们在心中难免出现疑问，客户主机的集体中毒，难道和阿里云有关？
为了进一步确认此事，我们又进行如下验证。
- 验证一：其他主机是否也是同样的执行方式
(1)我们登陆到mysql-test主机，在/tmp目录下看到 t-bj05top2t31reo.sh脚本文件
(2)利用同样的分析方式分析了audit系统操作审计日志：
从日志中我们可以看到/usr/local/share/aliyun-assist/1.0.1.402/aliyun-service 进程创建t-bj05top2t31reo.sh脚本且执行该脚本。查看系统应用日志可以明显看到整个脚本执行过程，
结论：到目前为止我们基本确认该病毒的下载事件源是aliyun-service 这个进程发起，能对云平台底层进行操作的，是可以获取云平台底层权限的，所以我们又进行了另外两种方式的验证。
- 验证二：是否是通过基线检查提交恶意代码进行批量执行
结论：从刚开始的阿里云安全事件告警截图中我们也可以看出，客户的“基线检查”并未开通企业版，属于免费版本，不存在自定义配置的可能性，所以该可能性排除。
- 验证三：客户的管理员级别accesskey被泄漏
我们查看云平台API接口文档，发现和之前查看的日志格式基本一致,也进一步确认有这样的API可以进行服务器批量操作和执行。我们进行了github的检索确认，的确有研发人员将Accesskey的信息暴露在了公网，紧急联系客户删除对应的代码，至此，阿里云集体中毒的安全事件处理告一段落。
最终结论：综上分析，本次阿里云集体中毒事件的根本原因是由于客户程序员安全意识不够，将accesskey泄漏在公网被利用所致。
四、总结
虽然经过了一些辛苦而曲折的排查，问题的根源总算找到，但同时也暴露出我们的一些问题
1、我们在监控体系的建设和落地方面还需要进一步加强细化，我们要做好云平台之外的监控体系，帮助客户更早的发现问题。
2、再次看到日志的重要性，全面的日志收集、保留、分析、告警是我们快速发现和定位问题的重要依据。
3、加强对云平台体系的研究学习，如果我们对云平台API功能有更多了解，可以更早的定位到问题的原因。
最后，吐个槽，期间我们还查看了阿里云平台的操作审计，但未发现任何异常，通过API对云平台相关产品的操作，建议云平台增加API操作的日志记录和审计（目前来看，黑客通过API对服务器的相关操作并未留下痕迹）
博客作者阿里云碰到相同的挖矿问题，文章转自Miao的手札
本文转自：【记一起阿里云服务器集体中毒事件的分析 - 今日头条】https://m.toutiaocdn.com/item/6777709681478468108/?app=news_article×tamp=1578193483&req_id=2020010511044301001406401317DFCB2D&group_id=6777709681478468108&tt_from=copy_link&utm_source=copy_link&utm_medium=toutiao_ios&utm_campaign=client_share