背景

未被攻击前的pg数据库

pg数据库被攻击后

具体的勒索内容

All your data is backed up. You must pay 0.0041 BTC to bc1qtvk8jvsyy5a896u6944kp8hvfytd7pwxpdlpvy In 48 hours, your data will be publicly disclosed and deleted. (more information: go to http://2info.win/psg)

您的所有數據都已備份。您必須向 bc1qtvk8jvsyy5a896u6944kp8hvfytd7pwxpdlpvy 支付 0.0041 BTC 在 48 小時內，您的數據將被公開披露和刪除。（更多資訊：轉到 http://2info.win/psg）

After paying send mail to us: rambler+32b7k@onionmail.org and we will provide a link for you to download your data. Your DBCODE is: 32B7K

付款后，請向我們發送郵件：rambler 32b7k@onionmail.org，我們將為您提供一個連結供您下載數據。您的 DBCODE 為：32B7K

攻击过程分析

攻击者先查询readme表，然后立即删除该表并提交事务。紧接着执行了危险操作——尝试终止所有非系统数据库连接，甚至试图删除postgres系统库（因当前连接失败）。随后创建了名为readme_to_recover的新库，并在其中新建readme勒索表。

攻击者留下了比特币勒索信息，要求支付0.0041 BTC到指定地址，并威胁48小时内公开数据。第二条记录提供了联系 邮箱 和数据库代号32B7K。这里需要完整保留勒索信息的所有细节，包括网址和邮箱。

开始反复查询数据库元数据、表结构， 特别关注 readme表及其内容。数据库重启后，攻击者再次连接并持续探查系统目录，仍有活动痕迹。协议不兼容错误，可能是攻击工具特征；有"mes"库不存在的报错，可能是攻击者尝试连接其他数据库。整个过程中攻击者表现出对PG系统表的熟悉，使用了大量JOIN查询获取元数据。

关键时间线

时间	事件
20:58:26	攻击开始：查询并删除mes表，终止非系统连接。
20:58:34	植入勒索信息到readme_to_recover库。
21:03-22:05	系统静默期(可能为攻击者潜伏或加密操作)。
22:05:03	攻击者返回：系统侦察与元数据扫描。
22:39:21	数据库异常重启。
22:39:44	再次查询public.readme表内容(确认勒索信息)。
22:45:47	最后一次配置重载。

🔍  内容解析：

支付要求：

要求支付 0.0041 比特币（BTC） 到指定比特币地址：

bc1qtvk8jvsyy5a896u6944kp8hvfytd7pwxpdlpvy

支付截止时间：

48 小时内，否则威胁公开和删除你的数据。

联系方式：

要求支付后发送邮件至：rambler+32b7k@onionmail.org

提供了一个 DBCODE（可能是交易编号或用户标识）：32B7K

数据威胁：

声称已备份你的所有数据，如果不支付，将公开并删除这些数据。

更多信息链接：

提供了一个网址： paste.sh · encrypted pastebin

（注意：不要轻易访问该链接，可能含有恶意软件或钓鱼内容）

PostgreSQL 日志分析总结（2025-07-04 18:47:10 至 18:52:33）

行为模式 

COMMIT → BEGIN → 查询表结构 → 读取数据 → 立即删除表及依赖对象 → COMMIT

• 侦察与破坏连贯性：在极短时间内完成表结构探查、数据抽样和删除操作，符合勒索病毒“快速破坏数据”的特征。
• CASCADE 选项：强制删除所有依赖对象（如视图、外键），最大化破坏范围。
• 事务封装：操作封装在 BEGIN-COMMIT 事务中，试图伪装成合法操作。

 DROP TABLE ... CASCADE 操作具有勒索病毒典型行为特征

• 隔离：立即隔离受影响数据库服务器。
• 取证：保留完整日志及磁盘快照。
• 恢复：从离线备份还原数据，验证备份完整性。

特征分析

特征	当前操作	勒索病毒典型行为
SQL类型	SELECT查询	DROP TABLE/DELETE/加密操作
数据访问模式	条件过滤（WHERE name=$1）	全表扫描或批量破坏
事务完整性	短事务（毫秒级）	可能无事务或长破坏性事务
对象操作	读取业务表（非系统表）	删除/加密用户表或系统对象
参数化查询	使用$1/$2占位符	常为硬编码值或动态拼接恶意语句

---

一、事件时间线

1. 初始操作（13:20-14:49 CST）

   • 持续出现 PostgreSQL JDBC 驱动的连接请求（SET application_name = 'PostgreSQL JDBC Driver'），表明应用程序频繁建立数据库会话。
   • 多次执行事务操作（BEGIN/COMMIT），但未涉及实际数据操作，疑似连接池测试或心跳检测。

2. 关键破坏阶段（17:27-17:30 CST）

   • 大规模数据删除：
     通过 DROP TABLE IF EXISTS ... CASCADE 命令删除了至少 50+ 业务表，涉及核心模块：
     • 生产跟踪表（advancedgenealogy_trackingrecord）
     • 订单主数据表（masterorders_masterorder）
     • 物料流资源表（materialflowresources_storagelocation）
     • 用户权限表（qcadoosecurity_user）
     • 基础配置表（basic_company, basic_shift）
   • 数据库破坏：
     尝试删除数据库 mes（DROP DATABASE "mes"），但未立即成功（因存在活跃连接）。

3. 数据库不可用（17:30 后）

   • 出现大量 FATAL: database "mes" does not exist 错误（18:33-19:24 CST），表明数据库已被移除或损坏。
   • 多次尝试重建连接均失败，例如：

     2025-07-04 18:33:40.564 CST [3639466] FATAL: database "mes" does not exist
     

4. 后续异常行为（18:46-19:27 CST）

   • 攻击者尝试查询 SQL Server 系统表（sys.master_files），但 PostgreSQL 不支持该语法，报错 relation "sys.master_files" does not exist。
   • 反复执行 DROP DATABASE "mes"（19:10, 19:22, 19:24 CST），确认数据库已被删除。

---

二、攻击特征

1. 勒索病毒痕迹

   • 文件名 勒索病毒记录2.docx 直接表明与勒索软件相关。
   • 攻击模式符合勒索软件典型行为：批量删除数据表 → 破坏数据库完整性 → 使服务不可用。

2. SQL 注入痕迹

   • 攻击者通过 JDBC 驱动连接（application_name = 'PostgreSQL JDBC Driver'），可能利用应用层漏洞注入恶意 SQL。
   • 重复执行 BEGIN/COMMIT 可能是为了绕过事务监控。

3. 横向移动尝试

   • 查询 sys.master_files（SQL Server 系统表）表明攻击者可能误判数据库类型，试图跨平台攻击。

---

三、影响范围

影响类型	具体内容
业务表删除	生产跟踪、订单管理、物料管理、用户权限等核心业务表被删除（覆盖 50+ 表）。
数据库丢失	mes 数据库被删除，导致所有依赖该数据库的应用服务瘫痪。
服务中断	数据库连接持续失败（FATAL 错误），且后续重启（19:22 CST）未能恢复。

---

四、建议措施

1. 紧急响应

   • 立即隔离受感染服务器，防止横向扩散。
   • 检查备份可用性：优先恢复 mes 数据库的备份（需确认备份时间点早于 17:27 CST）。
   • 审计应用漏洞：重点排查 JDBC 连接池配置及 SQL 注入风险。

2. 取证分析

   • 分析日志中异常会话的进程 ID（如 [3637446]），追踪攻击入口。
   • 检查系统是否存在勒索信文件（如 .txt 或 .html），确认勒索团伙身份。

3. 加固防护

   • 限制数据库权限：撤销不必要的 DROP 权限。
   • 启用 SQL 操作审计（如 PostgreSQL 的 pg_audit 插件）。
   • 部署数据库防火墙，拦截批量删除操作。

---

关键时间点摘要

• 17:27 CST：攻击开始，大规模删除表。
• 17:28 CST：首次出现 database "mes" does not exist，表明破坏完成。
• 19:22 CST：数据库服务重启，但 mes 库已不可恢复。

💡 提示：该日志显示攻击者具备数据库高权限，建议优先排查应用服务账号的权限滥用问题。

⚠️ 注意：若同时存在其他可疑操作（如异常文件加密、网络外连），需结合系统日志进一步确认攻击链。

---

事务与连接管理

• 高频事务操作：
  多个进程（如2968、2975、2984等）频繁执行短事务，流程均为：

  BEGIN → SET extra_float_digits=3 → SET application_name='PostgreSQL JDBC Driver' → COMMIT
  

  • 目的：疑似JDBC驱动初始化连接时的标准配置，用于优化浮点数精度和标识应用来源。
  • 持续时间：每个事务耗时约10-30毫秒，表明连接池管理高效，资源释放及时。

---

元数据查询活动

• 系统表查询：
  进程3479、3489等在18:50后集中查询数据库元数据，涉及以下关键表：

  • pg_database：获取数据库列表及属性（如编码、表空间、所有者）。
  • pg_class/pg_namespace：分析表结构、模式及存储信息。
  • pg_extension：检查已安装扩展及其可用版本。
  • information_schema：提取列定义、约束、索引等详细信息。

  典型查询示例：

  SELECT * FROM pg_database;  -- 获取所有数据库信息
  SELECT n.nspname, c.relname FROM pg_class c JOIN pg_namespace n ON ...;  -- 遍历表结构
  

• 目标推测：
  可能为数据库监控工具、健康检查脚本或自动化运维任务，用于收集状态数据或生成文档（如SELECT * FROM "public"."readme" LIMIT 0）。

---

数据库删除冲突

• 失败操作：
  进程3512在18:52:12尝试删除数据库readme_to_recover，但触发错误：

  ERROR: database "readme_to_recover" is being accessed by other users
  DETAIL: There are 2 other sessions using the database.
  

  • 原因：仍有2个活跃会话（如进程3491、3489）未释放连接，导致删除失败。

• 后续影响：
  客户端连接意外中断（Connection reset by peer），可能因超时或服务端主动终止异常连接。

---

关键时间线

时间	事件
18:47:10-18:47:11	多进程初始化连接，配置JDBC参数并提交事务。
18:50:07	执行检查点（Checkpoint），写入0.0%缓冲区，耗时0.124秒。
18:50:52-18:51:18	高频元数据查询，覆盖数据库、表、列、索引、外键等全量结构信息。
18:52:12	尝试删除readme_to_recover失败，因存在活跃会话。
18:52:33	客户端连接重置，服务端终止异常会话。

---

潜在问题与建议

• 连接泄漏风险：
  长时间未关闭的会话可能导致数据库资源耗尽。需检查应用层连接池配置，确保空闲连接及时回收。

• 元数据查询优化：
  高频全表扫描可能影响性能。建议：

  • 缓存元数据结果，定期刷新。
  • 使用pg_stat_user_tables等系统视图替代部分查询。

• 删除数据库前检查：
  执行DROP DATABASE前，通过以下命令终止相关会话：

  SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'readme_to_recover';
  

---

日志反映了一个典型的数据库运维场景：连接初始化、健康检查、元数据采集与清理操作。冲突源于并发控制不足，需加强会话生命周期管理和删除操作前的资源释放机制。

⚠  这是勒索软件攻击的典型特征：

攻击者通过恶意软件加密你的文件或窃取敏感数据。

然后通过邮件等方式联系你，要求支付赎金以恢复数据或防止泄露。

使用比特币等 加密货币 作为支付方式，以隐藏身份。

✅  建议你采取的行动：

1. 不要立即支付赎金！

支付赎金不能保证你的数据会被恢复或不被泄露。

这还会鼓励犯罪分子继续作案。

2. 断开网络连接

立即将受影响的设备从网络中断开，防止恶意软件扩散到其他设备或继续窃取数据。

3. 不要访问提供的链接或回复邮件

邮件中的链接可能含有恶意软件或钓鱼陷阱，不要点击。

不要回复邮件或按照其指示操作。

4. 检查是否真的被加密或数据泄露

查看你的文件是否真的被加密，是否无法打开。

如果你使用了云备份（如 Google Drive、OneDrive、百度网盘等），检查是否有备份可以恢复。

5. 联系专业网络安全团队或公司

如果你是在公司或组织环境中，请立即通知 IT 安全团队。

如果是个人设备，建议联系专业的网络安全公司或当地网络安全机构寻求帮助。

6. 向当地执法机构报告

在中国，你可以向公安机关网安部门或**国家互联网应急中心（CNCERT）**举报此类网络犯罪行为。在国际上，可向当地网络安全机构或类似 FBI 的 IC3（Internet Crime Complaint Center）举报。

❓  关于 DBCODE 和比特币地址：

DBCODE（如 32B7K）：可能是攻击者内部用于追踪支付的编号，对你来说没有实际用途，除非你决定支付赎金（不推荐）。

比特币地址：是公开的，但接收者是匿名的。即使你支付了，也无法确保对方会履行承诺。

🛡  总结：

保持冷静，不要惊慌，不要支付赎金，寻求专业帮助。