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

事件日期：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 安全日志可能被清理或未启用完整审计，目前无法仅凭现存证据判断攻击者具体通过密码爆破、凭据复用还是已经泄露的密码完成登录。

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