注意:PostgreSQL库出现readme_to_recover勒索

惜分飞 — Thu, 22 Jan 2026 13:30:25 +0000

以前恢复过不少mysql库被删除的勒索case,比如:
read_me_recover_tn勒索恢复
 A_H_README_TO_RECOVER勒索恢复
 A____Z____RECOVER____DATA勒索恢复
今天在PostgreSQL库中也简单了类似的勒索案例

[postgres@xifenfei database]$ psql 
psql (12.8)
Type "help" for help.

postgres=> \l
                                     List of databases
       Name        |  Owner   | Encoding |  Collate   |   Ctype    |   Access privileges   
-------------------+----------+----------+------------+------------+-----------------------
 ldar-test         | postgres | UTF8     | en_US.utf8 | en_US.utf8 | 
 postgres          | postgres | UTF8     | en_US.utf8 | en_US.utf8 | 
 readme_to_recover | postgres | UTF8     | en_US.utf8 | en_US.utf8 | 
 template0         | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
                   |          |          |            |            | postgres=CTc/postgres
 template1         | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
                   |          |          |            |            | postgres=CTc/postgres
(5 rows)

postgres=> \c readme_to_recover
You are now connected to database "readme_to_recover" as user "postgres".
readme_to_recover=> \d
         List of relations
 Schema |  Name  | Type  |  Owner   
--------+--------+-------+----------
 public | readme | table | postgres
(1 row)

readme_to_recover=> select * from readme;
                                                                                                   
                                 text_field                                              
-------------------------------------------------------------------------------------------------------
-------------------------------------------------
 All your data is backed up. You must pay 0.0051 BTC to bc1q9p333xxxxxxxxxxxxxj2z5fs27pu3u In 48 hours, 
  your data will be publicly disclosed and deleted . (more information: go to http://2info.win/psg)
 After paying send mail to us: rambler+3d2l7@onionmail.org and we will provide a link for 
   you to download your data. Your DBCODE is: xxxxx
(2 rows)

readme_to_recover=> select oid,relname from pg_class;
   oid   |                    relname                    
---------+-----------------------------------------------
 2196735 | readme
    2619 | pg_statistic
    1247 | pg_type
    4159 | pg_toast_2600
    4160 | pg_toast_2600_index
    2830 | pg_toast_2604
    2831 | pg_toast_2604_index
    4161 | pg_toast_3456
    4162 | pg_toast_3456_index
    2832 | pg_toast_2606
    2833 | pg_toast_2606_index
………………
   13373 | _pg_foreign_tables
   13377 | foreign_table_options
   13383 | _pg_user_mappings
   13391 | user_mappings
   13387 | user_mapping_options
(396 rows)

根据这里的readme的oid值，初步怀疑是drop所有业务表,然后创建了readme表,并且插入了勒索信息.

我做的各种数据库恢复比较多，说实话一直对pg这个特点非常不满意：
1. pg的数据存储本身依赖文件系统，通过oid(来表示库，表示表以及其他各种对象，和很多商业化数据库不一样，对于文件系统过于依赖，这样的情况如果发生了drop/truncate表等操作，表从文件系统中被删除，恢复难度较大
2. pg的表对应本身没有在每个数据块的block记录表的id信息，这样使得无法很好的进行底层基于block的扫描恢复数据，目前我知道的pdu一定的这样的功能，但是那是依赖列匹配，原则上来说对于一个稍微复杂一点的系统，这个恢复思路基本上不可行（因为列相似的数据表可能很多，导致恢复的数据过于混乱）
基于上述的两个特点，如果整个业务库被这种勒索破坏，如果没有备份，想比较好的恢复效果基本上很难（除非你运气非常好，os层面反删除恢复效果特别好，这要取决被删除的表在os上没有覆盖，文件系统元数据没有回收，系统没有识别是ssd环境等因素决定）

基于这种故障在没有备份的情况下很难恢复，那我们要做的就是：
1）有有效的备份或者容灾不被破坏;
1> 数据需要有效的备份,有条件的建议异机或者离线
2> 如果有条件可以部署延迟同步的备库,避免发生故障备库同步被破坏

2）尽可能不让这种故障发生:
1>数据库不要暴露在公网上,减少被攻击和入侵的风险
2>数据库不要使用弱口令,减少被暴力攻破密码的风险
3>注意应用漏洞，减少通过sql注入进行数据库进行破坏
4>注意已知的数据库安全漏洞,防止被利用进行攻击
5>注意操作系统安全,因为登录了数据库服务器对于数据库来说就没有安全可言

惜分飞 » readme_to_recover

注意:PostgreSQL库出现readme_to_recover勒索