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占位符

常为硬编码值或动态拼接恶意语句


一、事件时间线

  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
    • 数据库破坏
      尝试删除数据库 mesDROP 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):可能是攻击者内部用于追踪支付的编号,对你来说没有实际用途,除非你决定支付赎金(不推荐)。

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

🛡  总结:

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

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.pswp.cn/pingmian/87439.shtml
繁体地址,请注明出处:http://hk.pswp.cn/pingmian/87439.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

多种方法实现golang中实现对http的响应内容生成图片

多种方法实现golang中实现对http的响应内容生成图片。 Golang 中实现将 HTTP 响应内容生成图片 在 Golang 中将 HTTP 响应内容生成图片主要有两种常见场景: 将文本/HTML 内容渲染为图片(如网页截图)将响应内容作为原始数据直接生成图像&am…

AI领域新趋势:从提示(Prompt)工程到上下文(Context)工程

AI领域新趋势:从提示(Prompt)工程到上下文(Context)工程 在人工智能领域,尤其是与大型语言模型(LLM)相关的应用开发中,一个新兴的概念正在逐渐取代传统的提示工程(Prompt Engineering)&#xf…

K8S数据平台部署指南

🔥🔥 AllData大数据产品是可定义数据中台,以数据平台为底座,以数据中台为桥梁,以机器学习平台为中层框架,以大模型应用为上游产品,提供全链路数字化解决方案。 ✨杭州奥零数据科技官网&#xf…

Perforce QAC 与 Klocwork 重磅升级:质量突破+许可降本

在当今快节奏的软件开发领域,每一次工具的升级都可能成为企业提升竞争力的关键契机。Perforce旗下备受瞩目的两款静态分析工具Perforce QAC 和 Klocwork 在2025年推出的新版本中,不仅带来了令人振奋的功能革新,许可证体系的重大变化更是为企业…

结合指纹防护技术,释放Web3去中心化的潜力

随着互联网技术的飞速发展,Web3的概念逐渐成为人们关注的焦点。Web3代表着一个更加去中心化、安全和用户友好的网络环境。在这一背景下,指纹防护技术的应用显得尤为重要,它不仅能够保护用户的隐私,还能进一步推动Web3去中心化潜力…

数学建模_熵权法确定权重

笔记整理自bilibili 模型作用intuition:确定权重问题背景简单介绍(可忽略)定义 step1.指标正向化处理极小型/成本型指标中间型指标:集中在某个值附近最好区间型指标:落在某个区间最好 step2.标准化处理比重矩阵 step3…

基于 SpringBoot+Vue.js+ElementUI 的个人健康档案管理系统设计与实现7000字论文实现

摘要 本论文设计并实现了一个基于 SpringBoot、Vue.js 和 ElementUI 的个人健康档案管理系统。该系统旨在为用户提供一个便捷、高效的个人健康信息管理平台,实现个人健康档案的电子化管理,支持健康数据的记录、查询、分析和预警等功能。论文首先分析了个…

爬虫反爬策略实战:UserAgent代理池简明指南

一、为什么需要UserAgent代理池? 当你在编写爬虫程序时,是否遇到过以下情况? 刚开始能爬取数据,突然就返回403错误 网站返回"检测到异常流量"的提示 IP地址被暂时封禁 这些问题大多源于网站的反爬机制,…

核心配置详解:mybatis-config.xml

前言:配置文件的重要性 在MyBatis江湖中,mybatis-config.xml就是整个框架的"总指挥部"。这个配置文件虽然体积不大,却掌管着数据源、事务、类型转换等核心命脉。今天我们就来扒一扒这个XML文件的十八般武艺,从青铜到王…

推动自动化管理闭环 —— 让报表“长出手脚”

在企业数字化转型的进程中,报表作为数据呈现的重要载体,却常因功能局限,沦为数据展示的 “静态展板”。传统报表仅能完成数据收集与呈现工作,无法将数据洞察转化为实际行动,导致管理流程断裂,难以形成闭环。…

深入理解JVM垃圾回收机制:引用计数法与可达性分析算法

Java虚拟机(JVM)的自动内存管理机制,特别是垃圾回收(Garbage Collection, GC),极大地简化了开发者的工作,避免了手动内存管理带来的诸多问题,如内存泄漏和野指针。本文将探讨两种判断…

【AI落地应用实战】AIGC赋能职场PPT汇报:从效率工具到辅助优化

目录 一、AIGC:职场生产力范式的重构1.1 报告撰写:从人工堆砌到智能生成1.2 演示文稿制作:设计美学与信息架构的融合 二、AIGC驱动的思维拓展与逻辑优化三、AIGC在演示文稿设计与数据可视化中的深层应用3.1 演示文稿设计精髓:AI驱…

Java 大视界 -- Java 大数据实战:智能安防入侵检测的特征工程与模型融合全解析

Java 大视界 -- Java 大数据实战:智能安防入侵检测的特征工程与模型融合全解析 引言:正文:一、Java 驱动的多源特征工程体系1.1 异构安防数据特征提取系统1.2 复杂场景特征增强技术1.3 特征重要性评估与筛选 二、Java 构建的动态模型融合策略…

设计模式系列(10):结构型模式 - 桥接模式(Bridge)

系列导读:在学习了接口适配后,我们来看如何处理抽象与实现的分离问题。桥接模式解决的是"多维度变化"的设计难题。 解决什么问题:将抽象部分与实现部分分离,使它们都可以独立变化。避免在多个维度上变化时出现类爆炸问题…

容器基础5-Helm 与 K8s 的关系

一、Helm 是什么?为什么需要它? K8s 是强大的容器编排平台,但部署复杂应用时(如包含 Web 服务、数据库、缓存等多个组件的系统),需要编写大量 YAML 文件,管理成本高。Helm 就是为简化 K8s 应用…

靠机器学习+组合优化就发了CCF-A

这两年机器学习求解组合优化问题领域取得了显著的进展。ICLR、ICML、NeurIPS等顶会都有多篇成果发表。 组合优化:它是一种寻找一组变量的最佳组合的方法,以最小化或最大化一个目标函数。组合优化问题通常具有大量的状态和选择,需要在有限的…

UI评审时应该注意哪些方面才能有效保障交付质量

需从​​评审准备、设计评估、用户体验优化、技术实现验证​​四大维度展开,并结合具体实践经验 一、评审前的充分准备 ​​明确评审目标与范围​​ 确定评审核心目标,如验证设计是否符合产品需求、评估视觉与交互表现等。划定评审范围,聚焦核心页面与关键功能模块,避免分散…

分块矩阵怎么取逆?

目录 一、特殊分块矩阵取逆 1. 对角分块矩阵取逆​ 2. 副对角分块矩阵取逆​ 3. 三角分块矩阵 上三角:​ 下三角:​ 4. 任意二阶矩阵​ 二、一般分块矩阵 一、特殊分块矩阵取逆 1. 对角分块矩阵取逆 2. 副对角分块矩阵取逆 3. 三角分块矩阵…

2025微信小程序wxapkg解包全攻略

好的,以下是优化后的微信小程序 wxapkg 解包工具使用说明,纯文本格式,结构清晰,便于直接复制使用: --- 微信小程序 wxapkg 解包工具使用说明 一、查找 __APP__.wxapkg 文件 1. 按 WinR,输入 cmd&#xff0c…

标签体系设计与管理:从理论基础到智能化实践的综合指南

这类文章可以直接给大模型做上下文,主页有更多。 文章目录 一、标签体系的理论基础与概念框架1.1 标签的本体论定位1.2 逻辑学视角的标签形式化1.3 语言符号学的标签机制1.4 信息学的知识组织原理 二、标签的语义原子化设计原理2.1 语义原子性的理论基础2.2 语义分解…