事件简述:

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 rwxa
auditctl -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&timestamp=1578193483&req_id=2020010511044301001406401317DFCB2D&group_id=6777709681478468108&tt_from=copy_link&utm_source=copy_link&utm_medium=toutiao_ios&utm_campaign=client_share

服务器集体中毒事件 xmrig trace 挖矿病毒相关推荐

  1. 一键查杀linux挖矿脚本,这几个linux命令或许帮您查杀挖矿病毒

    最近受类似于比特币及区块链技术的影响,有些云服务器被攻入,植入挖矿病毒,利用你的云服务器来挖矿.本文就阐述几个常用的linux命令,假如你碰到这样的病毒,这些linux命令可能会有些帮助.这些命令并不 ...

  2. 阿里云服务器中招挖矿病毒XMrig miner解决方法

    今天阿里云的项目经理给我打电话问我的服务器是否没有使用计划,确实自从上次中毒后就没再使用.今天登录阿里云服务器 WindowsServer2012 远程桌面,发现XMrig miner.exe cpu ...

  3. Linux服务器清除xmrig挖矿病毒详细教程

    近期遇到很多小伙伴在咨询服务器CPU被占满,排查后发现中了xmrig挖矿病毒,并且通过kill 杀掉进程后,还会自动启动.这是由于只是停止了xmrig挖矿病毒的进,没有彻底删除病毒文件,导致会病毒会自 ...

  4. 记录一次服务器清除xmrig挖矿病毒,及伪装成mysql的挖矿病毒!

    突然发现服务器cpu及负载全部达到100%,不出意外应该是中病毒了,开始十万火急的排查!!!!! 1.首先执行 top 查看具体占用 果然不出所料,中了挖矿病毒,下面开始清除 2.直接杀死进程 kil ...

  5. linux服务器中毒挖矿,Linux服务器中挖矿病毒 二

    标签: 使用top命令可以看见CPU 100%,但是进程中居然cpu占用率都很低. 使用ps -aux --sort=-pcpu|head -10 这现在露出了原形.发现一个占用几百的进程 Kmmcd ...

  6. 关于linux遭受挖矿病毒,伪装为trace

    前几天两台线上的centos7遭遇了挖矿病毒  每天的cpu都是跑满的状态  进程名为:trace   实际文件名为:xmrig 捋一下处理流程: 看看一下进程号.然后 ls -l /proc/进程号 ...

  7. jenkins漏洞导致服务器中了挖矿病毒!cpu飙高351%!看我如何消灭它!

    作者:SilentBillows,资深Java工程师,架构师小秘圈特约作者!欢迎大家投稿,在后台回复投稿即可! 一, 定位问题 1.发现cpu异常,查看对应的进程信息 [root@versionlib ...

  8. linux 挖矿效率_linux 服务器发现了挖矿病毒

    1.发现病毒 近日,因为自己搭建的个人网站做了一版更新,准备去服务器做部署.连接服务器的时候明显感觉到消耗的时间比以往要久,半天才响应过来. 在测试网络没有问题之后,随即使用top命令看下进程情况,结 ...

  9. 服务器Redis实例中挖矿病毒排查及处理

    文章系转载,方便整理和归纳,源文地址 https://z.itpub.net/article/detail/E0D0607EFA91E5FA88035F74D040DD26 巧不巧的我的服务器也被挖矿 ...

最新文章

  1. 为什么要有 AtomicReference ?
  2. 吉大c 语言程序设计奥鹏作业,吉大20春学期《可编程控制器》在线作业一百分...
  3. Leetcode(11)-盛最多水的容器
  4. linux io函数,unix/Linux低级IO函数的用法有哪些? 爱问知识人
  5. Objective C 总结(十):Conventions
  6. 华为5g鸿蒙折叠,华为5G折叠概念新机:麒麟9000+鸿蒙OS 这才是华为的实力
  7. Spring Boot + Spring Data JPA项目配置多数据源
  8. intellij idea 15 万恶的光标跟随
  9. JAVA Map类compute方法详解及样例
  10. 基于路径跟随的纯跟踪算法--差速模型
  11. IP地址-子网划分详解
  12. 5855. 找出数组中的第 K 大整数
  13. java用socket解析16进制数据_浅析Java基于Socket的文件传输案例
  14. 【转】视频《经梧太极第一代传人闫芳老师收徒仪式上推手》是真实的吗?
  15. 《向着光亮那方》刘同 读书笔记
  16. Pycharm 安装 github copilot 报错:failed to initiate the github login process please try again
  17. 《小白兔到大黑牛》第十四篇Hadoop中五个进程作用
  18. JAVA中怎样把用户输入的字符串存入数组中?
  19. Codeforces Round #495 C. Sonya and Robots
  20. JMeter 调试取样器(Debug Sampler)简介

热门文章

  1. sql_数据分析之电商人货场模型分析之指标体系拆解+代码实操 (用户留存、RFM模型、 用户路径分析等)
  2. zoj 1221 Risk Flory
  3. 【基于文本相似度的论文查重系统-哔哩哔哩】 https://b23.tv/6JJBMur
  4. C++学习 2019-1-10
  5. 2022下半年各省软考报名费用汇总,不知道的看这里
  6. c语言字符串连接作用,C语言 不使用strcat函数实现连接两个字符串功能代码
  7. 《Headfirst设计模式》学习笔记
  8. 时隔十年的“五一”小长假来了,人少风景好的冷门胜地在哪里
  9. HDU 5768 Lucky7(2016 Multi-University Training Contest 4 -1005)——中国剩余定理 + 容斥原理
  10. STM32的PWM输入模式设置并用DMA接收数据