记数据库应急响应
2019-11-18 16:13:30 Author: www.secpulse.com(查看原文) 阅读量:348 收藏

事件描述

接到通知,某客户 数据库服务器遭到黑客入侵,需要做应急处理。服务器位于某运营商机房内。自己之前做的基本上是web和系统方面的应急响应,数据库应急响应也是第一次接触。

事前准备

事先通过搜索客户ip信息,发现在10月份被某高校列入攻击黑名单,攻击端口为1433。

图片1.png

进一步跟踪发现,服务器在几个月前就可能已经被入侵。

图片2.png

开始排查

通过远程连接到服务器,首先查看下服务器的基本情况

查看日志记录并未异常情况

图片3.png

查看端口发现存在大量外连1433端口(由于cmd程序报错异常,所以使用powershell进行查看)

图片5.png

服务器上安装了杀毒软件,此时发现杀毒软件报毒信息,进一步查看所在路径但并未发现存在此文件。

图片6.png

查看系统关键路径发现存在两个后缀名为dvr的可疑文件

图片7.png

图片8.png

继续查看系统关键路径,发现wbem目录下存在可疑的文件123.bat

图片9.png

查看文件内容,发现存在创建文件行为,并通过resgsvr 32 注册dll文件

图片10.png

数据库方面,客户告知数据库被植入后门账号,找到后门账号dbhelp

图片11.png

通过排查,发现存在另一个可疑后门账号mssqla

图片12.png

通过查看数据库日志,发现存在被爆破的痕迹

图片13.png

查看数据库作业发现存在大量任务计划

截屏2019-11-14下午11.19.03.png

具体操作内容

截屏2019-11-14下午11.19.27.png

截屏2019-11-14下午11.19.47.png

通过查阅网上相关技术资料和文章,结合客户描述的开机CPU占用率100%,基本确定与挖矿有关。

总结 

最后通过和管理员沟通发现,根本原因是由于数据库弱口令被黑客爆破。所以在这里提醒广大管理员不要设置弱口令!!!不要为了给自己提供一时方便,也给黑客提供了机会,给自己以后的工作造成麻烦。记得上次phpstudy后门应急响应,我提醒开发人员生产环境要用安全的中间件,结果他问我最新版的phpstudy可不可以。。。只能说图一时方便,只能会花更多时间填坑。

本文作者:秦萧

本文为安全脉搏专栏作者发布,转载请注明:https://www.secpulse.com/archives/118356.html


文章来源: https://www.secpulse.com/archives/118356.html
如有侵权请联系:admin#unsafe.sh