mes系統pg數據庫被Ransomware攻擊勒索BTC

背景

未被攻擊前的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占位符	常為硬編碼值或動態拼接惡意語句

一、事件時間線

初始操作（13:20-14:49 CST）
- 持續出現 PostgreSQL JDBC 驅動的連接請求（SET application_name = 'PostgreSQL JDBC Driver'），表明應用程序頻繁建立數據庫會話。
- 多次執行事務操作（BEGIN/COMMIT），但未涉及實際數據操作，疑似連接池測試或心跳檢測。
關鍵破壞階段（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"），但未立即成功（因存在活躍連接）。
數據庫不可用（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
```
后續異常行為（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），確認數據庫已被刪除。

二、攻擊特征

勒索病毒痕跡
- 文件名 勒索病毒記錄2.docx 直接表明與勒索軟件相關。
- 攻擊模式符合勒索軟件典型行為：批量刪除數據表 → 破壞數據庫完整性 → 使服務不可用。
SQL 注入痕跡
- 攻擊者通過 JDBC 驅動連接（application_name = 'PostgreSQL JDBC Driver'），可能利用應用層漏洞注入惡意 SQL。
- 重復執行 BEGIN/COMMIT 可能是為了繞過事務監控。
橫向移動嘗試
- 查詢 sys.master_files（SQL Server 系統表）表明攻擊者可能誤判數據庫類型，試圖跨平臺攻擊。

三、影響范圍

影響類型	具體內容
業務表刪除	生產跟蹤、訂單管理、物料管理、用戶權限等核心業務表被刪除（覆蓋 50+ 表）。
數據庫丟失	`mes` 數據庫被刪除，導致所有依賴該數據庫的應用服務癱瘓。
服務中斷	數據庫連接持續失敗（`FATAL` 錯誤），且后續重啟（19:22 CST）未能恢復。

四、建議措施

緊急響應
- 立即隔離受感染服務器，防止橫向擴散。
- 檢查備份可用性：優先恢復 mes 數據庫的備份（需確認備份時間點早于 17:27 CST）。
- 審計應用漏洞：重點排查 JDBC 連接池配置及 SQL 注入風險。
取證分析
- 分析日志中異常會話的進程 ID（如 [3637446]），追蹤攻擊入口。
- 檢查系統是否存在勒索信文件（如 .txt 或 .html），確認勒索團伙身份。
加固防護
- 限制數據庫權限：撤銷不必要的 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）：可能是攻擊者內部用于追蹤支付的編號，對你來說沒有實際用途，除非你決定支付贖金（不推薦）。

比特幣地址：是公開的，但接收者是匿名的。即使你支付了，也無法確保對方會履行承諾。

🛡 ?總結：

保持冷靜，不要驚慌，不要支付贖金，尋求專業幫助。