依托 Solar 安全运营响应团队的日常实战沉淀，我们会定期分享在安全运营中处置的典型应急响应事件，涵盖银狐木马、APT 攻击、勒索病毒等各类主流威胁。 作为专业的应急响应中心，Solar 致力于为复杂多变的安全事件提供从深度溯源到闭环处置的全流程支持。针对银狐、APT 等具有高隐蔽性的威胁，我们不仅聚焦于对其攻击行为的深度剖析，更致力于还原其完整的活动链路，并同步输出切实可行的清除闭环操作方案。 突发危机干预通道： 若您的核心资产正面临加密锁定或数据勒索风险，请通过文末二维码联系我们。我们提供全天候紧急介入服务，协助您快速切断攻击链路，全力挽回业务损失。
写在前面
近期，Solar应急响应团队陆续接到多位用户的求助反馈。说来也挺有意思，这些求助的共同点不是企业服务器被加密、不是核心业务中断、也不是面临天价赎金，而是桌面上弹出了一个花哨的窗口，文件后缀变成了.#WannaHammer#，窗口里循环播放着一段不堪入耳的音频，还敢留下一个QQ号让受害者去联系。
刚看到这个样本的时候，我们团队的反应是有点哭笑不得的。
这个勒索软件给自己起的名字叫 WannaHammer 3.0，直译过来大概是"想要锤子"。但在中文互联网的语境里，我们更习惯叫它"求锤"。这个名字本身就带着一种近乎挑衅的味道，仿佛攻击者在对受害者说："你来啊，求锤"
不过玩笑归玩笑，这个样本在行为设计上确实有点意思。它不像LockBit、Blackout那样主打企业级勒索、动辄索要数百万美元加密货币；也不像TellYouThePass走淘宝买密钥的"接地气"路线。WannaHammer的赎金是 5块钱人民币，支付方式直接走QQ转账。你没看错，五块钱。这个价格放在勒索软件家族里面，连白菜价都算不上。
但便宜不代表无害。
这个样本真正狠的地方不在于加密本身，而在于它对受害者心理的精准拿捏，倒计时威胁、桌面壁纸篡改、禁用任务管理器、循环播放淫秽音频。尤其是最后这个音频播放的设计，堪称"社死式勒索"的典型代表。想象一下，你的电脑突然开始大声播放不可描述的内容，而你又没法关掉它（任务管理器被禁用了），周围的人投来异样的目光……这种场景下，很多人可能宁可花五块钱买个清静。
攻击者留下的联系QQ号是 368636048。截至本文撰写时，该账号已无法被搜索到，搜索状态是异常（疑似被封禁）。
攻击者留下的QQ联系入口（该账号目前已无法搜索）
说起这个样本的整体风格，它的特征更有点复古。
这种复古感来自哪里？首先，它的加密方案用的是魔改DES，密钥硬编码在程序里，这在现代勒索软件中已经非常少见了。其次，它的勒索UI设计、倒计时机制、禁用任务管理器这些手法，都让我们想起了大约十年前Android平台上流行的那些锁机软件。
十年前安卓平台流行的锁机软件界面
当年的锁机软件多采用全屏置顶窗口覆盖系统界面，搭配倒计时和解锁码机制，与本次WannaHammer 3.0的设计思路高度相似。国内在2014年6月首次发现此类恶作剧锁屏样本（Android.TkLocker），2015年第三季度新增感染手机接近35万部，累计捕获样本7.6万余个。
那时候还没有现在这么成熟的勒索软件产业链，没有暗网博客、没有谈判门户、没有RaaS（勒索即服务）平台。攻击者的手法很直接：锁你屏幕、让你看着倒计时、给你一个QQ号或微信群让你交钱。WannaHammer 3.0的出现，某种程度上像是把当年那套"原始但有效"的玩法，重新搬回了Windows桌面端。
接下来，我们就把这个样本从外到里、从行为到原理，完整地拆开来看一看。
一、攻击流程一览
在深入技术细节之前，我们先通过一张流程图来理清WannaHammer 3.0的完整攻击链路。这张图也同步了我们Solar应急响应团队在处置此类事件时的标准流程。
WannaHammer 3.0 攻击流程示意图
上图清晰展示了整个攻击的三个阶段：
第一阶段：传播（社工钓鱼） 攻击者通过被盗的QQ等即时通讯账号，以"熟人"身份向联系人投递恶意程序。常见的话术包装包括"老同学的照片"、"刷赞工具"、"游戏外挂"等，利用熟人关系降低受害者的警惕心理。
第二阶段：感染（文件加密）
受害者执行恶意程序后，样本以桌面目录为起点，递归遍历文件系统。对符合条件的文件（小于50MB且未包含#WannaHammer#后缀）使用内置的魔改DES算法进行加密，并在文件名后追加.#WannaHammer#扩展名。加密完成后，原始文件内容被完全覆盖。
第三阶段：恐吓（勒索界面） 样本弹出全屏勒索窗口，显示倒计时（24小时）、随机码、勒索说明和联系QQ号。同时禁用任务管理器、修改桌面壁纸，并在后台循环播放内嵌的淫秽音频，制造"社死"压力迫使受害者尽快付款。
应急响应流程 如果中招了，正确的处置顺序是：
**保留现场：**不要关闭勒索窗口（倒计时即将结束前建议直接关机，否则该加密器会自动删除文件），不要删除样本文件，不要运行杀毒软件（样本会提示"暂时退出杀毒软件"，但我们不建议听从）
**联系Solar：**通过Solar应急响应团队：
应急响应.com官方渠道提交工单或直接下载解密程序（末尾有教程）**提交信息：**打包加密文件、样本文件和系统日志安全提交
**解密处理：**使用专用解密工具尝试恢复文件（由于该样本加密方案存在明显缺陷，可实现无密码批量恢复）
**恢复成功：**验证文件完整性，重建业务环境
二、样本基础信息
这个样本的整体体量不算大，基本信息如下表所示：
VT上多家引擎已能识别该样本，检测结果如下：
从检测结果可以看出，主流安全厂商普遍将其归类为勒索软件（Ransom）或文件加密型恶意程序，置信度普遍较高。
思而听沙箱运行结果
三、勒索信内容全解析
WannaHammer 3.0的勒索信写得相当有个人风格，措辞随意、口语化严重，甚至带有一种莫名其妙的亲切感。为了便于分析，我们将勒索信的完整内容摘录如下，并逐段做解读。
勒索信完整内容
我的电脑出了什么问题？
您的一些重要文件被我加密保存了。
照片、图片、文档、压缩包、音频、视频文件、exe文件等，几乎所有类型的文件都被加密了，因此不能正常打开。
这和一般文件损坏有本质上的区别，您大可在网上找找恢复文件的方法，我敢保证，没有我们的解密服务，就算老天爷来了也不能恢复这些文档。
有没有恢复这些文档的方法？
当然有可恢复的方法，只能通过我们的解密服务才能恢复，我以人格担保，能够提供安全有效的恢复服务。
但这是收费的，也不能无限期的推迟。
您点击“免费恢复”按钮可恢复一部分文件，你放心，我是绝对不会骗你的。
但想要恢复全部文档，需要付款点费用。
是否随时都可以固定金额付款，就会恢复的吗？当然不是，推迟付款时间越长对你不利。
最好3天之内付款费用，过了三天费用就会翻倍。
还有，一个礼拜之内未付款，将会永远恢复不了。
对了，忘了告诉你，对半年以上没钱付款的穷人，会有活动免费恢复，能否轮到到你，就要看您运气怎么样了。
我怎么付款？
请加我的QQ：368636048，向我发一张你电脑现在的照片（桌面），并且向我支付5元即可解锁。
要注意：付款后请将“解锁码”发给我！
收到作者给你的解锁密码后请填写在编辑框内，并且点击“解密被加密的文件”按钮，即可解密文件，解密时请耐心等待，如果您强行关闭软件可能导致部分文件永久损坏！！
最好周五晚上6点到八点或周末找我！
付款后，可立刻开始恢复工作。
怎么联系我？
如果你想解密的话请现在加我的QQ368636048
我强烈建议，为了避免不必要的麻烦，恢复工作结束之前，请不要关闭或者删除该软件，并且暂时退出杀毒软件。不管由于什么原因，万一该软件被删除了，很可能会导致付款后也不能恢复信息的情况。
关于这份勒索信，有几个值得研究的细节：
第一，定价策略的心理学。 五块钱的赎金定价非常微妙，它低到让大多数受害者不会为值不值得而犹豫，但又高到足以让攻击者在足够多的感染量下获得可观收益。这是一种典型的"薄利多销"思路，和当年锁机软件动辄索要20元、50元的定价相比，反而更符合当下互联网用户的付费心理阈值。
第二，时间压力的阶梯式设计。 三天翻倍、一周永久删除、半年"抽奖"免费恢复，这种层层递进的时间压力设计，本质上是在逼迫受害者尽快做出"花钱消灾"的决定。尤其是"半年以后抽奖免费"这个说法，更像是画饼，实际可操作性几乎为零。
第三，"周五晚上六点到八点或周末找我"。 这句话暴露了一个很有趣的信息，攻击者可能是一个需要正常上班的人又或者是在校的学生，只有下班和周末才有时间处理"业务"。这种作息规律，某种程度上也印证了该样本背后可能是一个个体攻击者或小团伙，而非成熟的组织化运营团队。
第四，"暂时退出杀毒软件"的提示。 这是典型的社会工程手法，试图让受害者在焦虑状态下主动降低系统安全防护，从而确保勒索程序能持续运行、不被查杀清除。
四、勒索界面与行为特征
当样本在受害者系统中运行后，会呈现以下行为特征：
4.1 全屏勒索窗口
WannaHammer 3.0 勒索界面
4.2 倒计时与删除机制
样本在Windows目录下创建四个状态文件（H.DDOS、M.DDOS、S.DDOS、X.DDOS），分别用于记录倒计时的小时、分钟、秒和运行状态标记。定时器每秒递减，当倒计时归零后，样本会执行桌面目录的递归删除操作，将加密后的文件全部清除。
这种设计的目的很明确，给受害者施加"倒计时炸弹"式的心理压力，迫使其在规定时间内完成付款。
4.3 禁用任务管理器
样本通过修改注册表实现任务管理器的禁用：
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System\DisableTaskMgr = 1
这意味着受害者无法通过常规的Ctrl+Shift+Esc或Ctrl+Alt+Del组合键调出任务管理器来终止勒索进程。对于普通用户来说，这几乎等同于束手无策。
4.4 桌面壁纸篡改
样本还会修改桌面壁纸，在桌面上留下明显的勒索提示信息，进一步强化心理威慑。
被篡改的桌面壁纸
4.5 音频播放，最社死的一环
样本内嵌音频资源提取信息
WannaHammer 3.0最恶毒的操作，是在勒索窗口打开后自动循环播放一段内容不堪入耳的国产淫秽音频。
这段音频并不是从外部下载的，而是以内嵌WAV资源的形式打包在程序文件中，资源标识为iext2_IDR_WAVE1。播放时通过PlaySoundA函数从程序资源区直接加载，使用0x42007标志参数，实现了不依赖外部文件、异步循环播放、失败静默的效果。
这意味着：
你在磁盘上找不到这个音频文件，它不存在于文件系统中
你无法通过删除文件来停止播放，数据在程序资源段里
它会在后台持续循环播放，直到你付款解密或强制关机
这个设计的恶毒之处不在于技术难度，而在于对社交场景的精准打击。无论是办公室、图书馆、教室还是家庭客厅，电脑突然开始大声播放不可描述的内容，受害者第一反应绝对不是"我要分析一下这个恶意样本"，而是"赶紧让它停下来"。五块钱的赎金在这种场景下，简直不能更划算了。
五、逆向分析
本节基于Solar应急响应团队对捕获样本的完整逆向分析，系统梳理WannaHammer 3.0的攻击链、技术原理及检测指标。以下所有分析结论均基于实际样本的静态分析和动态调试结果，分析环境为完全隔离的虚拟化沙箱。
5.1 样本概览
5.2 攻击链全景
WannaHammer 3.0的攻击流程可以分为九个核心阶段：
下面我们对每个阶段展开详细分析。
5.3 启动与窗口初始化链
样本入口进入GUI运行时初始化流程，创建勒索窗口并进入消息循环。业务逻辑由窗口事件驱动触发。
窗口初始化事件负责完成以下操作序列：
设置窗口标题为"WannaHammer 3.0 全新防解密系统"
创建并布局勒索说明文本、倒计时标签、随机码显示区、密码输入框、操作按钮等界面控件
生成两组9位随机码（范围100000000至999999999）
初始化或加载倒计时状态
写入注册表启动项实现持久化
以桌面目录为根启动递归加密
将勒索信写入Windows目录
按钮事件分别处理：
随机码展示
打开QQ官网联系入口（
https://im.qq.com/）完整解密（需口令校验）
免费解密（仅恢复txt文件）
定时器事件负责：
每秒刷新倒计时显示
倒计时归零后触发递归删除
窗口线程初始化阶段还安装了两类消息Hook，用于拦截按键、鼠标和窗口创建消息，使所有输入先经过样本自身的预处理流程，再决定是否放行。
窗口初始化伪代码：
void on_window_init() {
set_window_title("WannaHammer 3.0 全新防解密系统");
populate_ransom_controls();
random_code_1 = random_between(100000000, 999999999);
random_code_2 = random_between(100000000, 999999999);
init_or_load_countdown_state();
write_run_key(current_executable_path);
encrypt_tree(get_desktop_directory());
write_ransom_note_to_windows_dir();
}
WannaHammer 启动与窗口初始化链
5.4 状态文件、持久化与任务管理器限制
5.4.1 状态文件机制
样本使用Windows目录作为状态存储位置，创建了四个.DDOS后缀的文件：
初始化阶段检查X.DDOS是否存在：
如果存在，读取H/M/S三个文件恢复倒计时状态（用于程序重启后恢复勒索场景）
如果不存在，写入默认倒计时值（24小时），并创建
X.DDOS作为首次运行标记
这种设计使得即使受害者强制重启电脑，勒索程序重新运行后也能恢复之前的倒计时进度，而不是从头开始计时。
状态恢复伪代码：
void init_state_and_persistence() {
if (exists("%WinDir%\\X.DDOS")) {
hours = read_int("%WinDir%\\H.DDOS");
minutes = read_int("%WinDir%\\M.DDOS");
seconds = read_int("%WinDir%\\S.DDOS");
} else {
write_default_countdown_files(); // 默认24小时
write_file("%WinDir%\\X.DDOS", marker_bytes);
}
reg_set_run_value("我的启动项", current_executable_path);
reg_set_dword("...\\Policies\\System\\DisableTaskmgr", 1);
}
5.4.2 注册表持久化
样本通过写入注册表启动项实现开机自启动：
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\我的启动项
数据指向样本当前执行路径。启动项名称"我的启动项"也延续了样本整体"接地气"的命名风格。
5.4.3 任务管理器限制
样本在初始化阶段将DisableTaskmgr策略值设为1，禁止用户通过常规方式打开任务管理器。完整解密校验通过后，该值被恢复为0。
void update_taskmgr_policy(bool unlocked) {
if (!unlocked) {
reg_set_dword("...\\Policies\\System\\DisableTaskmgr", 1);
return;
}
reg_set_dword("...\\Policies\\System\\DisableTaskmgr", 0);
decrypt_tree(get_desktop_directory(), "*.#WannaHammer#");
}
5.5 窗口消息Hook与按键消息链
样本在窗口线程初始化阶段安装了两类线程级Hook：
Hook安装逻辑：
void init_window_hooks() {
tid = GetCurrentThreadId();
cbt_hook = SetWindowsHookExA(WH_CBT, cbt_window_hook, NULL, tid);
msg_hook = SetWindowsHookExA(WH_MSGFILTER, msg_filter_hook, NULL, tid);
}
按键消息进入预处理函数后，程序读取Ctrl、Shift、Alt三个修饰键的状态，封装成内部事件，再分发给窗口控件和按钮事件处理逻辑。
按键消息预处理逻辑：
bool pretranslate_key_message(MSG msg) {
if (msg.message < WM_KEYFIRST || msg.message > WM_KEYLAST)
return dispatch_normal_message(msg);
state = 0;
if (GetKeyState(VK_CONTROL) < 0) state |= CTRL_DOWN;
if (GetKeyState(VK_SHIFT) < 0) state |= SHIFT_DOWN;
if (GetKeyState(VK_MENU) < 0) state |= ALT_DOWN;
return dispatch_key_event(msg.wParam, state);
}
这些Hook的存在，使得样本可以监控和干预用户的键盘输入行为，阻止某些可能导致程序被终止的快捷键组合生效。
5.6 随机码生成与口令校验链
5.6.1 随机码生成
样本生成两组9位随机数，范围为100000000至999999999。两组数字都会显示在勒索界面中。
勒索界面随机码生成
5.6.2 口令校验逻辑
完整解密按钮的事件处理函数执行以下校验流程：
读取密码输入框中的文本内容
将固定前缀
"shumu"与随机码1的十进制字符串拼接
执行字符串比较
比较成功 → 进入完整解密链
- 比较失败 → 弹出错误提示
口令校验逻辑伪代码
这意味着解密口令的格式是固定的：shumu + 随机码1。攻击者只需让受害者提供勒索界面中显示的第一组随机码，就能计算出正确的解锁密码并告知对方。
这种口令生成方式非常简单直接，没有使用任何非对称加密或密钥派生机制，进一步印证了该样本在技术实现上的原始特征。
WannaHammer随机码生成与口令校验链
5.7 按钮事件链
勒索界面的四个按钮分别对应以下处理逻辑：
按钮事件分发伪代码：
void dispatch_button_event(int control_id) {
if (control_id == SHOW_CODE_BUTTON) show_random_codes();
if (control_id == CONTACT_BUTTON) open_url("https://im.qq.com/");
if (control_id == FULL_DECRYPT_BUTTON) on_full_decrypt_click();
if (control_id == FREE_DECRYPT_BUTTON) free_decrypt_txt_files();
}
免费解密按钮以*.txt.#WannaHammer#为匹配规则递归处理文件，完成后写入界面状态并弹出"已经解密txt文本文件！"的提示。这个"免费解密"功能是真实有效的，它确实能恢复所有被加密的txt文本文件，作为"你放心，我是绝对不会骗你的"的信用背书，诱导受害者相信付款后也能恢复全部文件。
5.8 目录遍历与加密调度链
样本通过系统特殊目录接口（SHGetSpecialFolderPath或同类API）取得桌面路径，将其作为递归加密的根目录。
WannaHammer目录遍历与加密调度链
5.8.1 文件筛选规则
目录遍历过程中，样本执行以下筛选逻辑：
递归加密伪代码：
void encrypt_tree(string dir) {
ensure_trailing_backslash(dir);
for (file in find_files(dir, "*.*")) {
if (contains(file.name, "#WannaHammer#")) continue;
if (file.size >= 52428800) continue;
encrypt_one_file(file.path, "DDOS");
}
for (subdir in find_directories(dir)) {
if (subdir.name == "." || subdir.name == "..") continue;
encrypt_tree(subdir.path);
}
}
5.9 单文件加密流程
单文件加密由以下步骤组成：
读取原始文件内容
**构造加密前缓冲区：**前4字节写入原始文件长度（小端序uint32），随后追加原始文件内容，尾部以
0x00补零到8字节倍数
**调用DES-like加密函数：**使用硬编码密钥
"DDOS"派生子密钥，对缓冲区逐块加密**覆盖写回原路径：**将密文写回原始文件路径，替换原始内容
- **重命名追加后缀：**在文件名后追加
.#WannaHammer#
单文件加密伪代码：
void encrypt_one_file(string path, string key_text) {
plain = read_file(path);
packed = new byte[align8(plain.length + 4)];
write_u32_le(packed, 0, plain.length);
copy(packed, 4, plain, plain.length);
cipher = des_like_crypt(packed, key_text, ENCRYPT);
write_file(path, cipher);
rename(path, path + ".#WannaHammer#");
}
加密前缓冲区结构：
+0x00 4字节 原始文件长度，小端序uint32
+0x04 N字节 原始文件内容
+0x04+N 0~7字节 0x00填充，直到总长度为8的倍数
5.10 DES-like加密算法深度解析
这是整个样本技术分析中最值得展开的部分。
WannaHammer 3.0没有采用现代勒索软件中常见的AES-256、RSA或ChaCha20等标准加密算法，而是实现了一套内置的DES-like分组算法（即魔改的des算法）。这种选择在2026年的勒索软件领域已经相当复古了。
5.10.1 算法基本特征
相同明文块在相同密钥下生成相同密文块，这种ECB-like的行为模式意味着算法不具备语义安全性，相同的明文内容会产生可辨识的密文模式。
5.10.2 密钥派生过程
密钥材料为硬编码的ASCII字符串"DDOS"。派生阶段创建一个8字节零缓冲区，将字符串字节按位置异或写入缓冲区：
密钥派生伪代码：
uint8_t key[8] = {0};
for (size_t i = 0; i < strlen("DDOS"); i++) {
key[i % 8] ^= (uint8_t)"DDOS"[i];
}
// 生成的8字节基础密钥：44 44 4F 53 00 00 00 00
build_round_keys_from_embedded_tables(key, round_keys);
最终得到的8字节基础密钥为44 44 4F 53 00 00 00 00（对应ASCII的"DDOS"后跟四个空字节）。
随后程序使用内置的置换表、轮移位表和SBox/SP表生成16轮子密钥，对每个8字节块执行Feistel结构变换。需要注意的是，这些置换表、轮函数封装和块内字节/位序均由样本自行实现定义，与标准DES的规范并不完全一致，这也是我们将其称为"DES-like"而非标准DES的原因。
5.10.3 与标准DES的关键差异
该样本在实现DES算法时做了以下自定义改动：
选位逻辑的改动：标准DES使用固定的PC-1选位表，而该样本采用了0-based选位逻辑，并对选取的密钥进行了位移操作
位读取方向的反转：标准DES中字节内的位读取是从高位到低位（MSB优先），而该样本改为了从低位向高位读取（LSB优先）
这些改动意味着，不能直接使用标准DES库来解密被加密的文件，需要对解密算法做相应的适配调整。
5.11 解密流程
WannaHammer 3.0提供了两条解密路径：
5.11.1 完整解密链
完整解密按钮在口令比较成功后执行三类动作：
恢复任务管理器策略（
DisableTaskmgr = 0）清理或隐藏倒计时相关界面状态
- 递归处理
*.#WannaHammer#匹配的全部加密文件
完整解密伪代码：
void decrypt_tree(string dir, string pattern) {
ensure_trailing_backslash(dir);
for (file in find_files(dir, pattern)) {
plain = decrypt_one_file(file.path, "DDOS");
output = remove_suffix(file.path, ".#WannaHammer#");
write_file(file.path, plain);
rename(file.path, output);
}
for (subdir in find_directories(dir))
if (subdir.name != "." && subdir.name != "..")
decrypt_tree(subdir.path, pattern);
}
单文件解密伪代码：
byte[] decrypt_one_file(string path, string key_text) {
cipher = read_file(path);
packed = des_like_crypt(cipher, key_text, DECRYPT);
original_size = read_u32_le(packed, 0);
if (original_size == 0 || original_size > packed.length - 4) fail;
if (packed.length >= original_size + 12) fail;
return slice(packed, 4, original_size);
}
解密阶段通过相同密钥和反向Feistel变换恢复加密前缓冲区，再依据前4字节的长度字段截取原始内容，去除补零数据，最终恢复原始文件。
长度字段的边界校验条件：
原始长度必须位于1到解密缓冲区长度减4之间
解密缓冲区长度必须小于原始长度加12字节
这两个条件与4字节长度字段和最多7字节补零的设计相匹配，用于防止解密过程中出现越界或异常。
5.11.2 免费解密链
免费解密入口调用与完整解密相同的递归解密函数，仅将文件匹配规则限定为*.txt.#WannaHammer#。密钥材料、分组算法、长度字段解析、写回和移除后缀逻辑与完整解密完全一致。
免费解密伪代码：
void free_decrypt_txt_files() {
for (root in get_target_roots()) {
decrypt_tree(root, "*.txt.#WannaHammer#");
}
show_message("已经解密txt文本文件！");
update_ui_state_after_free_decrypt();
}
5.12 倒计时刷新与删除链
WannaHammer倒计时刷新与删除链
5.12.1 倒计时逻辑
定时器事件每秒触发一次，执行以下递减逻辑：
倒计时伪代码：
void on_timer() {
seconds--;
if (seconds <= 0) { minutes--; seconds = 60; }
if (minutes <= 0) { hours--; minutes = 60; }
write_countdown_files(hours, minutes, seconds);
update_countdown_label(hours, minutes, seconds);
if (hours <= 0 && minutes <= 0 && seconds <= 0) {
delete_tree(get_desktop_directory());
exit_process();
}
}
每次更新后，小时、分钟、秒三个值同时写回界面显示和对应的状态文件，确保程序异常退出后能够恢复倒计时进度。
5.12.2 递归删除逻辑
当倒计时归零后，样本以桌面目录为根执行递归删除：
递归删除伪代码：
void delete_tree(string dir) {
ensure_trailing_backslash(dir);
for (file in find_files(dir, "*.*")) {
delete_file(file.path);
}
for (subdir in find_directories(dir)) {
if (subdir.name == "." || subdir.name == "..") continue;
delete_tree(subdir.path);
}
}
删除完成后弹出惩罚提示，随后进程退出。这意味着如果受害者真的拖到倒计时结束还不付款，桌面上的所有文件（包括被加密的文件）都将被彻底删除，连花钱恢复的机会都没了。
5.13 音频资源与播放链
如前文所述，样本内嵌了一段WAVE格式的音频资源，资源标识为iext2_IDR_WAVE1。
音频播放调用逻辑：
void play_ransom_window_audio() {
if (use_resource_sound) {
module = get_mfc_module_handle();
PlaySoundA("iext2_IDR_WAVE1", module, 0x42007);
return;
}
if (memory_sound != NULL)
PlaySoundA(memory_sound, NULL, 0x2007);
}
经过我们的音频内容研判，确认该音频为国产淫秽音频内容。攻击者将这段音频打包进程序资源的设计意图非常明确，它不是为了炫技，而是为了在最大程度上制造受害者的社交尴尬和心理压力，迫使其尽快支付赎金。
六、加密机制缺陷与解密方案
6.1 加密方案的四大缺陷
WannaHammer 3.0的加密方案在以下几个层面存在明显缺陷，使其不具备对抗专业逆向分析的能力：
缺陷一：硬编码密钥
加密密钥"DDOS"以明文形式硬编码在程序中，没有任何形式的密钥派生保护或混淆处理。逆向分析人员可以直接从程序二进制中提取密钥，完全绕过了"密钥获取"这个传统上最难攻克的技术环节。
缺陷二：非标准算法的可逆性
虽然攻击者对标准DES做了自定义改动（0-based选位、LSB优先位读取等），但这些改动都是确定性的、可逆向的。只要通过静态分析提取出内置的置换表、SBox表和轮函数实现，就能完整还原算法的加解密过程。
缺陷三：ECB-like模式的语义泄漏
由于相同明文块在相同密钥下生成相同密文块，加密后的文件保留了原始文件的部分结构信息。虽然这对于实际解密不是必需的（因为我们已经拿到了密钥），但这种设计本身在密码学上就是不安全的。
缺陷四：解密口令可以被获取
固定前缀"shumu"与随机码1拼接生成的字符串为解密口令，可以通过输入解密口令后让加密器自动解密被加密的数据。
6.2 解密方案
基于上述缺陷，解密的核心思路非常直接：
**提取密钥：**从样本二进制中定位硬编码的
"DDOS"字符串**还原算法：**逆向内置的置换表和Feistel轮函数，构建与样本行为一致的DES-like解密实现
**批量处理：**递归遍历所有
.#WannaHammer#后缀文件，执行解密并恢复原始文件名
由于密钥和算法均为已知，解密过程无需依赖样本程序本身、无需向攻击者支付赎金、也无需输入勒索界面中的解锁密码，可实现完全离线的批量恢复。点击查询id获取随机码1 然后输入shumu+随机码1即可解密。
WannaHammer 3.0勒索软件解密视图
- 如果电脑已经关机了（
WannaHammer 3.0全新防解密系统会消失，无法通过上述方法恢复），但可以通过访问应急响应.com获取直接解密程序。
使用方法 ：打开cmd命令行wannahamer_de.exe 文件夹路径
七、事件复盘与深度观察
7.1 攻击者画像推测
综合样本的技术特征、勒索信措辞、运营手法等多个维度，我们对此次攻击背后的攻击者做出以下推测：
技术水平评估：初级到中级
从样本的代码质量来看，攻击者具备一定的Windows GUI编程基础和密码学基础知识，能够实现完整的文件加密、窗口交互和音频播放功能。但在工程化实现上存在明显粗糙之处：
密钥硬编码，没有任何保护措施
注册表持久化逻辑存在自毁bug（加密自身导致无法自启动）
使用魔改DES而非业界成熟的加密方案
整体代码结构偏向"快速实现"而非"长期运营"
运营方式：个体或小团伙作案
赎金定价5元人民币，走的是"薄利多销"路线
使用QQ直接联系收款，而非加密货币或中间平台
工作时间提示"周五晚上六点到八点或周末"，暗示攻击者有正常职业或在校学生
勒索信措辞口语化、带个人风格，不像专业团伙的标准模板
作案动机：短期获利为主
样本整体呈现出"快速开发、快速投放、快速收割"的特征，没有建立暗网博客、没有品牌运营、没有长期维护的迹象。更可能是一个个体攻击者在尝试利用"社死式勒索"这种心理战手段快速变现。
八、附录
IOCs（入侵指标）
文件哈希
| 类型 | 值 |
|---|---|
| MD5 | ba57d2ef027df0f85ac9085ff44956ae |
| SHA1 | 367f2ec9c01578f25e99e700e8c7627472c892cc |
| SHA256 | 585579225f1a66a9b727abdddac028ad9894bc8f6e06bc1461a4b8bec35841a5 |
攻击者联系方式
加密文件扩展名
.#WannaHammer#
勒索窗口特征
窗口标题：
WannaHammer 3.0 全新防解密系统状态文件名：
H.DDOS、M.DDOS、S.DDOS、X.DDOS勒索说明文件名：
解密文件，勿删！.xxx
注册表持久化指标
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\我的启动项
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System\DisableTaskmgr = 1
本文案例由Solar应急响应团队共同完成。
参与逆向分析与文档输出：CHQ
文章输出与优化：州弟学安全
排版优化：超级油麦
在企业日常的安全运维中，突发勒索病毒往往让人措手不及。遇到这种情况，正确的应急响应流程能够最大程度控制影响范围、降低数据损失。
这里为大家准备了一张完整的《勒索病毒应急处置指南》长图，建议各位安全从业者和IT运维人员收藏备用。如遇突发情况，请保持冷静，参考本图进行快速、规范的处置
附加资料下载： 防御与响应同样重要。扫描图末的二维码，还可以直接获取完整的《2025年勒索病毒年报》以及《勒索处置一体化》等专业文件，帮助大家深入了解当前的威胁趋势，提前做好防御规划。
安全无小事，掌握科学的处置流程，是我们应对突发安全事件最有效的武器。
