2. Linux.do
  3. 服务器被勒索并找回数据的详细记录，供各位佬参考（刚才发布的不声不响被删掉了？）

服务器被勒索并找回数据的详细记录，供各位佬参考（刚才发布的不声不响被删掉了？）

Renzenghui 2026-08-24 10:43 1

事件日期：2026 年 8 月 21 日

时间口径：中国标准时间（UTC+8）

最终结果：未支付赎金，成功解密全部 1,310 个 PostgreSQL 文件，并通过独立数据库还原验证。



事件时间轴





































































































































时间 阶段 发生的事情
事件发生前 暴露面 服务器的 RDP 3389 端口对 0.0.0.0/0 开放，内置 Administrator 账户可以直接从公网登录。这是目前确认的主要入侵入口。
04:07:01 入侵登录 阿里云安全中心记录到 Administrator 异常 RDP 登录，来源 IP 为 101.43.112.***。现存证据无法进一步判断是密码爆破、凭据复用还是密码已经泄露。
04:08:34 恶意程序落地 勒索程序被写入 C:\PerfLogs\[email protected]。这里采用文件创建时间；样本自身携带的旧修改时间不代表实际入侵时间。
04:12:48 加密前准备 PostgreSQL 完成最后一次干净关闭和检查点。结合后续加密时间，推测攻击者主动停止了数据库服务，以便加密正在使用的数据库文件。
04:14:24 勒索程序启动 云安全中心记录到进程链：smss.exe → winlogon.exe → userinit.exe → Explorer.exe → 勒索程序。这表明程序很可能是在攻击者的 RDP 桌面中交互式启动的。
04:14:25 建立持久化 C:\Windows\svchost.com 被创建并执行。攻击者通过 SCHTASKS.exe 创建名为 Windows Update ALPHV 的开机任务，以 SYSTEM 权限运行勒索程序。系统的 EXE 文件关联也被劫持到该程序。
04:14:25—04:14:36 批量加密 项目文件、程序目录、系统日志以及 PostgreSQL 的 base、global、pg_wal 均开始出现统一的 .z12 后缀。04:14:36，勒索信 #Restore-My-Files.txt 和勒索壁纸已经落地。
发现事件后—10:46 前 初步排查 检查端口、连接、账户、服务、启动项、计划任务和恶意文件。现场没有发现仍在运行的勒索进程，但系统存在 EXE 关联劫持、Defender 异常和可疑清理脚本，已经不能继续视为可信主机。
同一阶段 尝试快照恢复 检查阿里云快照和 Windows 历史副本，没有找到事件发生前可用的快照，无法直接回滚。
同一阶段 尝试公开解密器 向公开解密服务提交勒索信和加密样本，但没有得到明确的勒索家族匹配或可用解密器。
同一阶段 尝试 Defender 扫描 执行 Defender 全盘扫描，但安全服务异常并返回错误，无法产生可信的查杀结果。
同一阶段 尝试直接导出数据库 PostgreSQL 关系文件和 WAL 均已加密，数据库服务无法正常启动，因此暂时无法使用 pg_dump 导出数据。
10:46 转入内存取证 准备 WinPmem，决定优先保全物理内存和页面文件，寻找勒索程序退出后可能残留的加密密钥。
10:50 完成内存采集 生成约 2.08 GB 的 physmem.raw，同时保存采集日志。
13:25 完成页面文件保全 生成约 2.92 GB 的 pagefile-copy.sys。它后来成为整个恢复过程最关键的证据。
15:03—15:07 找到并验证密钥 从页面文件残留中提取出一个 32 字节 AES 密钥候选，并使用 SQL、PowerShell 和 PDB 等不同类型的样本进行验证。解密后的结构、长度和 PKCS#7 填充全部正确，确认找到了本次加密实际使用的文件密钥。
15:19 开始数据库恢复 将加密的 PostgreSQL data 目录复制到隔离分析目录。原始加密数据保持不变，所有操作均在副本上进行。
15:21 第一轮批量解密 初版解密器处理 1,310 个文件，结果为 success=1303 failed=7。剩余 7 个均为大文件，并不是密钥错误，而是采用了另一种部分加密格式。
15:29 破解第二种格式 单独分析并恢复 5 个大型关系文件和 2 个 16 MB WAL 文件，确认其算法是“解密文件首尾，中间区域原样复制”。
15:31—15:44 完成全量解密 解密器升级为同时支持完整加密和部分加密。最终结果为 success=1310 failed=0 total=1310。
15:36 准备干净环境 下载并解压全新的 PostgreSQL 16.15 二进制，避免使用失陷系统中的数据库程序。
15:38 首次启动恢复库 在恢复目录的副本上，以仅监听 127.0.0.1:55432 的隔离方式启动 PostgreSQL。数据库成功进入可查询状态。
15:40 导出逻辑备份 生成 smarthome.dump、postgres.dump、globals.sql，并记录恢复库中全部 52 张表的行数。
16:01—16:04 最终独立验收 将 smarthome.dump 还原到一个全新数据库，再次统计全部表。52 张表的行数逐表一致，两份计数清单的 SHA-256 完全相同。至此确认数据恢复完成。

后台截图



最终结果


整个过程中，我们没有联系攻击者获取密钥，也没有支付赎金。


最终，我们从服务器页面文件的内存残留中找回了 AES 文件密钥，自行解析了勒索文件的两种格式，并编写了专用解密器。


恢复结果如下：



  • PostgreSQL 加密文件：1,310 个

  • 成功解密：1,310 个

  • 解密失败：0 个

  • 恢复业务表：52 张

  • 无效索引：0 个

  • 独立还原后的逐表行数：全部一致

  • 最终确认恢复完成：2026 年 8 月 21 日 16:04


使用到的工具
















































工具 用途
阿里云安全中心 查看异常 RDP 登录、恶意进程树、文件哈希和计划任务告警。
Windows PowerShell 排查端口、连接、账户、服务、计划任务、恶意文件及注册表劫持。
Windows 事件查看器 查询 RDP、Security、System 和 PowerShell 日志。
Windows Defender 尝试执行全盘扫描，但因服务异常未能完成。
公开勒索软件解密服务 提交勒索信和加密样本，但没有匹配到可用解密器。
WinPmem 采集约 2.08 GB 的物理内存镜像。
7-Zip 对约 2.92 GB 的页面文件进行分卷压缩和转移。
pagefile.sys 离线分析 从页面文件残留中寻找并提取 AES 文件密钥。
PowerShell / .NET AES API 编写专用解密器，处理完整加密和部分加密两种文件格式。

经验教训



  • 发现被勒索后首先检查服务器有没有被重启，内存以及页面文件中极大概率保存着对方加密密钥的相关信息

  • RDP不要为了图方便将所有IP开放，极易被爆破，如果没有购买安全工具的话阿里云那边不会给出告警


说明


以上时间点来自云安全中心告警、Windows 日志、文件创建时间、取证产物时间、解密日志及 PostgreSQL 控制文件。


其中，“RDP 是初始入口”属于高置信度判断；但由于部分 Windows 安全日志可能被清理或未启用完整审计，目前无法仅凭现存证据判断攻击者具体通过密码爆破、凭据复用还是已经泄露的密码完成登录。


为啥刚才发布的突然被删了，而且没有提示嘞！


最新回复 (11)
  • Yearn 08-24 10:50
    1楼

    佬的详细记录看着有点像是用 AI 整理过的，社区规定说 AI 生成的内容只能截图发送，可能是这个原因吧 ^-^

  • Renzenghui 楼主 08-24 10:52
    2楼

    啊，是这样啊，我让他给我整理的md，我直接粘贴过来的

  • have 08-24 10:53
    3楼

    涨姿势了，勒索未重启能从内存找密钥！！！


    ps：如果重启了，怎么找回呢，这个佬有方式么

  • Renzenghui 楼主 08-24 10:55
    4楼

    这个我没有自己尝试过嘞，相信总会留下什么蛛丝马迹的！

  • have 08-24 10:57
    5楼

    建议佬给帖子加个等级，避免被爬了呗。


    我之前有个项目，也是勒索，最后他们自己找安全公司解密的，勒索是好几个达不溜


    就想确认一下内存没密钥，解密思路咋样的（内存有残留学习到了）

  • Renzenghui 楼主 08-24 11:01
    6楼

    好的，内存没密钥痕迹这个我有亲身经验了第一时间分享给你。哈哈 ^-^

  • Ikuns 08-24 11:06
    7楼

    太强了佬，我去年碰到了一回也尝试过寻找残留密钥，根本没有，最后没办法交了赎金，对方是先给我提供了一个软件，让我随便选择一个加密软件然后会生成公钥，再把公钥发送给他，他那边生成私钥才能解密。

  • JennyC 08-24 11:06
    8楼

    太强了， 佬的技术水平是真的牛逼

  • Germa 08-24 11:08
    9楼

    0.0.0.0/0 这种操作，我以前在大学，刚买服务器学习的时候干过 ^-^

  • Fengshi 08-24 11:08
    10楼

    哈哈，我还得重新加一遍书签。

  • have 08-24 11:12
    11楼

    哈哈哈，那感情好啊，这块的经验还是欠缺的，靠佬来补齐了（希望数据不丢）

* 帖子来源Linux.do
附近帖子
返回
飞读
随机推荐