惜分飞

博客园 首页 联系 订阅 管理
  141 随笔 :: 33 文章 :: 3 评论 :: 42144 阅读

有客户MySQL数据库被黑,业务库中表被删除,并创建A____Z____RECOVER____DATA库,里面有一张readme表,内容为:

mysql> select * from readme \G;
*************************** 1. row ***************************
zh_content: 请尽快与我们取得联系,否则我们将会公布你的数据库信息在网络中,联系邮件:datacenterback@keemail.me
en_content: 请尽快与我们取得联系,否则我们将会公布你的数据库信息在网络中,联系邮件:datacenterback@keemail.me
     email: datacenterback@keemail.me
1 row in set (0.00 sec)

a_z_recover_data


对于这种情况,本质就是mysql drop 库或者drop表级别的恢复,通过反删除软件恢复,可惜恢复效果很差(底层发生了大量的覆盖)
os-recovery

对于这种情况,只能采用底层block级别恢复,通过底层扫描分析
20231121211906

并解析扫描结果恢复需要数据
20231121212028

对于类似这种A____Z____RECOVER____DATA勒索恢复,建议先对系统进行镜像或者快照,然后按照先os层面恢复,在block级别恢复的方法处理,如果无法自行解决,可以联系我们进行技术支持,最大限度抢救和数据,减少损失
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com
另外建议加强系统和mysql安全加固,数据库尽量不要暴露在公网上
posted on   惜分飞  阅读(53)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· AI与.NET技术实操系列(二):开始使用ML.NET
· 单线程的Redis速度为什么快?
历史上的今天:
2020-11-21 Oracle MISSING00000文件故障恢复
点击右上角即可分享
微信分享提示