【成功案例】揭秘盗版LockBit 5.0连环骗局：黑客诈骗、中介跑路，我们如何逆风翻盘成功拯救企业数据？

摘要
近期，Solar安全团队介入了一起极为复杂的勒索病毒救援案件。受害企业核心ERP系统遭遇加密，勒索信自称“LockBit 5.0”。
案件背后不仅涉及技术对抗，更牵扯出一场黑吃黑的连环骗局。在初期委托的第三方中介因违规操作导致谈判崩盘、黑客断联的绝境下，我们通过恶意代码逆向定性、MDF底层页级修复双位一体的手段，在无密钥状态下实现了核心数据的完整恢复。同时我们的应急响应小队也完整还原了黑客的入侵路线，及时的进行了应急响应，以及客户部署了我们SAR勒索防护设备进行防护，最终收获客户感谢信。

一、 Lockbit家族前世今生

在深入案情之前，我们有必要先认清对手的底细。依托 Solar威胁情报中心 的长期追踪数据，我们深知 LockBit 绝非泛泛之辈，它是当前全球活跃度最高、破坏力最强的勒索软件家族之一。

1.1 全球头号勒索家族的演变

LockBit家族最早出现于2019年9月（当时称为ABCD勒索软件），随后迅速通过RaaS（勒索软件即服务）模式扩张。

LockBit 2.0 (RED)： 2021年发布，引入了专门的数据窃取工具StealBit，确立了双重勒索模式。
LockBit 3.0 (Black)： 2022年发布，这是该家族最成熟的版本，甚至推出了首个勒索软件漏洞赏金计划，技术实力不容小觑。
LockBit 4.0 & 5.0： 2024年后，虽然官方宣称发布了新版本，但由于2022年LockBit 3.0构建器（Builder）的泄露，导致网络上出现了大量利用泄露代码魔改的盗版变种。

关于Lockbit家族和历代加密器的逆向分析，可参考我们往期的深度报告：

【病毒分析】LockBit 4.0 vs 3.0：技术升级还是品牌续命？最新LockBit 4.0分析报告

【独家揭秘】LockBit 4.0 解密器失效真相｜首发谈判日志＋万字深剖：发展脉络 · TTP 演进 · 2025最新 IOC

本案中，虽然勒索信声称是LockBit 5.0，但其行事风格与正规军大相径庭，这引起了我们的高度警觉。

二、谈判复盘：一场注定崩盘的黑吃黑

案件的转折点并非病毒爆发，而是一场业余的救援。客户在事发后病急乱投医，委托了某数据恢复中介公司。我们通过梳理9月16日至9月25日的邮件往来，还原了这场被搞砸的谈判全过程。

2.1 黑客的心理博弈：并非普通的勒索者

正规LockBit家族严格依赖Tor网络（暗网）面板进行私密谈判，绝不会使用普通邮箱。而本案的中介公司因不熟悉 LockBit 家族历史情况，试图通过邮件讨价还价。更值得注意的是黑客在沟通中暴露出的细节：

时间点：2025年9月16日 17:34 黑客首次向受害者发送勒索邮件。值得注意的是，邮件正文使用的是中文，且附件中包含了一个受害企业中IT主管“X先生”的个人专业技能证书。

图1 黑客发送的中文威胁邮件，并附高管技能证书

Solar团队分析：

1.熟悉环境： 附带正常文件说明黑客已在内网潜伏多时，对客户环境了如指掌，这是为后续索要高额赎金做心理铺垫。

2.国人嫌疑： 熟练使用中文沟通，结合后续溯源到的向日葵工具使用习惯，极有可能是境内的黑客团伙披着LockBit的外衣在作案。

3.匿名邮箱：我们尝试追踪邮件客户端IP，并没有发现x-originating-ip相关字段，因为cock.li 是一个注重隐私的邮件服务商，它在邮件头中隐藏了原始发件人的真实IP地址（没有 X-Originating-IP 这样的字段）。

*图2 邮件头无x-originating-ip字段*

在我们今年接触了几百起勒索案例后总结：目前勒索家族逐渐呈现出APT趋势，不仅加密文件，还会长期潜伏及窃取数据。具备三大特性：高持续性、高隐秘性、高威胁性

2.2 谈判崩盘：黑客两头吃的贪婪行为

时间点：2025年9月20日 - 9月25日 中介公司（G公司）介入后，声称已经支付了赎金，要求黑客解密。黑客的回复揭开了其两头吃贪婪的想法。

图3 中介G公司与黑客的谈判记录

2.3 中介的业余操作与客户的恐慌

时间点：2025年9月22日 09:12 受害者因急于恢复业务，告知黑客“已委托第三方公司联系”。这种表述直接暴露了客户“病急乱投医”的心理，让黑客意识到这是一只待宰的肥羊。

直到9月25日，黑客发出了最后通牒，戳穿了中介的老底：“我发现了你和代理公司的合同。那个代理公司之前坑过我们，害我们损失了好几个客户。”

图4 中介"已付款，未收到解密器"，黑客表示"已发送加密器"，后得知黑客想要两头吃

行为动机剖析： 黑客之所以表现出不讲信用，本质上是在黑吃黑。通过索要合同，黑客摸清了客户的预算底线；通过拒绝中介，黑客试图绕过中介直接对客户进行二次勒索。这再次印证了我们的观点：向黑客支付赎金是极高风险的行为，尤其是面对这种毫无信誉的散户时，往往是肉包子打狗。

类似的被骗案例我们也曾处理过，详情可见：

【成功案例】lockbit家族百万赎金不必付！技术手段修复被加密的数据库，附溯源分析报告

三、资金链路追踪：触目惊心的地下金流

既然中介声称“已付款”，钱到底去哪了？Solar团队利用 MistTrack（慢雾）dashboard.misttrack.io等链上追踪平台，对涉案的比特币地址进行了深度穿透分析，结果令人咋舌。

3.1 锁定交易链路

根据受害者描述，当时付款给中介公司(30万元人民币)，而后我们通过链上追踪中介公司的转账记录，他们在9月20日向黑客地址转账了约 0.1315BTC(10万元人民币含手续费、资金波动等)。我们锁定了两个关键地址：

中介控制的钱包地址：bc1qy28sl3s**********************pwujag7
黑客接收地址：3JP5D4Xy****************M6za4B

*图5 MistTrack平台显示的资金流向图，确证了资金从中间人流向黑客地址*

截止目前黑客钱包内的BTC仍然没有转出记录，推测等待风声过后转出，我们也在持续进行链上监控。

3.2 惊人的交易规模

通过对中介钱包地址的逆向溯源，我们发现这并非个例。该地址在短短一年内，资金流水异常频繁且巨大。

交易笔数： 超过 700 笔
资金规模： 累计转出 84.4759 BTC(约56096559元人民币)

*图6 中介钱包对外转账链路追踪(部分数据)*

*图7 中介钱包地址的年度交易概览*

*图8 按当前汇率计算，该地址经手的赎金总额高达 5600万+ 人民币*

数据背后的真相： 仅仅这一个中介的一个钱包地址，一年内就涉及了700多个受害客户，经手了数千万的赎金。按照客户描述付30万元给中介公司，中介公司付赎金10万元来计算(赎金*3)中介公司经手金额达上亿元，这足以证明国内勒索软件攻击的泛滥程度，以及地下“代付/恢复”产业的畸形繁荣。大量企业在遭受攻击后选择忍气吞声交钱，助长了黑产的嚣张气焰。

而后中介公司在购买密钥无望后(中介公司倒亏10万元)选择直接跑路，留下一地鸡毛，客户难过又气愤，于是将整个过程还原以警示大众，下文来自客户的梳理

我们是一家国内的企业，最近企业服务器感染了勒索病毒，数据都被加密了，然后找到了一家公司名叫“XX文化有限公司”的企业，然后他们宣传自己包解密，我们又去看了一下他们的官网很正规，24小时服务等，然后我们就信任了他们的技术，让他们帮我们恢复数据，并支付了30万元的费用。我们最后发现他们是支付比特币赎金给黑客团伙购买解密工具帮我们解密，他们根本没有这样的技术去恢复数据，他们只是在中间赚取大额的赎金差价，他们这样的业务行为是纵容犯罪份子更容易得到金钱，也成为了黑客团伙犯罪份子的收取企业钱财的助手，而且国家明令禁止比特币交易，国家现在严令禁止炒作虚拟币，为什么会有比特币业务？如果他们没有支付比特币，他们是支付什么给黑客？他们是不是跟黑客团伙有利益来往输送，黑客团伙负责加密，他们负责收企业的客户钱，他们还打着网络安全溯源的旗号帮客户溯源，实质上就是帮助黑客勒索敲诈企业。

四、样本定性：李逵还是李鬼

在确认谈判无望、资金被骗后，我们回归技术本源。受害者通过我司官网：http://应急响应.com联系到我们，了解事情经过后，Solar应急响团队线下溯源处置及对被勒索机器提取到的样本svchost.exe进行了逆向分析。

通过对恶意代码的静态与动态分析，我们确认该样本实际上是利用LockBit 3.0泄露构建器生成的盗版变种。攻击者将其伪装成LockBit 5.0以制造恐慌，但其技术细节暴露了其真实身份。

4.1 静态特征：国产壳与伪装

提取到的样本伪装成系统服务文件 svchost.exe，文件大小为 1,094,656 字节。初次使用 IDA 分析时，我们发现程序入口点存在大量垃圾指令填充，且无法识别有效逻辑。

通过 DIE（Detect It Easy）工具查壳，发现样本被加了 Safengine Shielden 壳。这是一个在国内灰产圈非常流行的加壳保护工具，这进一步印证了攻击者可能具备国内背景或习惯使用中文黑产工具的猜想。

*图9 DIE查壳发现Safengine保护*

在脱壳处理后，样本体积恢复正常，代码结构清晰显露。我们发现该样本虽然套用了 LockBit 5.0 的勒索信模板，但内核逻辑完全基于 LockBit 3.0 的泄露源码进行二次开发。

4.2 初始化与反分析：API Hashing

攻击者为了对抗安全人员的分析，采用了动态获取 API 地址的技术。样本中没有直接调用 Windows API，而是通过自定义 Hash 算法计算函数名摘要，再遍历 DLL 导出表进行比对。

除非进行动态调试，否则静态分析工具无法直接看到其调用的函数名。这种 API Hashing 手法极大地增加了分析难度。

*图10 API Hash混淆逻辑*

4.3 核心加密逻辑：Salsa20 + 自定义算法

与官方 LockBit 家族常用的标准 RSA+AES 模式不同，该样本在加密逻辑上进行了修改。逆向结果显示，其文件加密采用了 Salsa20 流加密算法，而用于保护 Salsa20 密钥的 Key 则使用了一种自定义的非对称加密算法。

这种自定义算法基于硬件随机数生成密钥，我们提取了部分解密逻辑的 Python 复现代码，足以看出其算法的独特性：

# 样本中的自定义密钥加密算法复现（非伪码，可运行）
def func1(a, b, c):
    m = 0
    d = int.from_bytes(bytes([0xff]*128), "little")
    for i in range(1024):
        m = m << 1if m >= c:
            m -= c
            m &= d
        q = a >> (1023 - i)
        q &= 1if q == 1:
            m += b
            m &= d
        if m >= c:
            m -= c
            m &= d
    return m

def enc_ctx_key_by_pub_key(ctx_key, public_key):# 此样本中的共享密钥加密算法核心逻辑
    tmp = func2(1, ctx_key, public_key)
    tmp = func2(tmp, ctx_key, None)
    tmp = func2(tmp, ctx_key, public_key)
    return tmp

*图11 文件尾部数据结构图*

加密器使用公钥加密随机生成的 ctx 密钥并写入文件尾部。虽然是盗版，但这种非对称加密结构意味着：如果没有攻击者手中的私钥，暴力破解加密文件的可能性几乎为零。

4.4 权限提升与横向移动

为了确保能加密更多系统核心文件，样本集成了多种提权手段。

1.令牌检测与 UAC 绕过： 样本会检测当前用户令牌是否属于管理员组（SID: S-1-5-32-544）。如果权限不足，会尝试通过 COM 接口绕过 UAC 进行提权。

2.进程注入： 逆向中发现，如果当前权限不为 System，样本会寻找系统进程 svchost.exe，并利用远程线程注入技术将恶意代码注入其中，从而获取 System 级权限。

// 注入 svchost.exe 的关键逻辑片段
if ( !dword_42516C_system_process && func_40B438_check_token_stub )
{
    // 如果不是System权限，则执行注入
    dword_42516C_system_process = func_40AE44_inject_svchost;
}

*图12 注入svchost逻辑*

若权限不为system而为管理员,则注入svchost.exe实现获取system权限

4.5 身份证伪造：为何是“盗版LockBit 5.0”？

虽然代码内核是LockBit 3.0，但勒索信却被攻击者自定义为LockBit 5.0。这种拙劣的伪装通过以下对比一目了然：

沟通方式：正版只用 .onion 链接；本案留下了 lock*****@cock.li 邮箱。
受害者ID：本案提供的ID在LockBit官方后台查询显示为Invalid ID。
勒索信文件名：本案为 TgOamlRBF.README.txt（带随机后缀），与正版命名规则不同。

特征维度	正版 LockBit 3.0/4.0	本案“盗版” LockBit 5.0
沟通方式	仅通过 .onion 暗网链接	电子邮箱 (lock*****@cock.li)
受害者ID	唯一且有效的Hash值，可在后台查询	无效ID (官方后台显示 Invalid)
勒索信文件名	id.README.txt	TgOamlRBF.README.txt (包含随机后缀)

*图13 左侧为正版勒索信（引导访问暗网），右侧为本案盗版勒索信（引导发邮件）*

结论： 这是一个利用泄露工具进行二改的散户团伙。他们没有能力维护暗网基础设施，只能通过邮件诈骗。这也解释了为何中介与其沟通会如此混乱，且极易发生跑路。

五、MDF底层页级修复实战

既然确定了黑客是无信用的散户且密钥不可得，常规解密路径彻底堵死。但逆向分析带来了一个好消息：该样本为了追求加密速度，采用了**部分加密（Intermittent Encryption）**策略。对于大于 0x20000 字节的文件，它只加密头部或每隔一段距离加密一部分。

这意味着，SQL Server数据库文件（MDF）中，存储实际业务数据的**数据页（Data Pages）**在物理层面上大概率是完好的。

5.1 方案原理：越过头部，获取数据

SQL Server的MDF文件由一个个 8KB 的页组成。虽然文件头被加密导致数据库无法 Attach，但我们可以绕过文件系统，直接扫描底层十六进制数据，提取出有效的数据页。

5.2 恢复实操步骤

Step 1：构建参照系

由于加密彻底损坏了原文件的头部结构（Metadata），我们需要构建一个结构一致的空库作为容器来承载恢复的数据。我们提取了客户半年前的一个冷备文件，将其作为参照。

*图14 利用同构的MDF文件重构数据表结构*

Step 2：底层扫描与页提取

工程师对被加密的MDF文件进行了全盘底层扫描。工具通过特征码识别出未损坏的数据页（Data Page）和索引页（Index Page）。

扫描结果： 核心业务表 TimeSeriesData 被成功识别。
数据量级： 扫描出记录条数 25,600,059 条。

*图15 工具成功解析出被加密文件内部的表结构，核心业务表数据清晰可见*

Step 3：数据清洗与校验

由于部分数据页正好处于病毒的加密步长上（例如每隔10MB加密1MB），导致极少量记录出现乱码。Solar技术团队编写了SQL校验脚本，剔除了坏死数据。

Step 4：回写与验证

将清洗后的数据导入新建的健康数据库中。最终比对结果如下：

原始正常数据库记录数： 26,501,904 条
成功恢复记录数： 25,600,059 条
**恢复率：**96.6%

*图16 核心财务与业务数据完整性校验通过，业务系统成功挂载并启动*

六、全链路攻击溯源

在恢复数据的同时，Solar安全团队对攻击者的入侵路径进行了全盘复盘。通过分析服务器残留的日志、WebShell及系统事件，我们绘制出了完整的攻击路线图，并成功锁定了攻击源。

*图17 攻击者从外网Web服务器突破，逐步渗透至域控及核心备份服务器*

6.1 第一阶段：溯源漏洞（2025年4月10日）

攻击者首先扫描到了暴露在公网的某虚拟化系统。

手段： 利用简单的弱口令 admin / admin123 成功爆破管理员账号。
建立立足点： 攻击者上传了恶意WebShell文件 info.xgi 和 editor.php，HTTP状态码返回200，标志着后门部署成功。

# Web日志记录
2025-04-10 13:15:28 | IP: 52.**.**.** | Login Success (admin/admin123)
2025-04-10 13:38:14 | IP: 52.**.**.** | Access /**/info.xgi | Status: 200

*图18 攻击者IP登录成功*

*图19 攻击者上传的info.xgi*

*图20 攻击者上传的editor.php木马*

*图21 攻击者访问webshell成功*

6.2 第二阶段：潜伏与权限维持（2025年7月-9月）

攻击者并没有急于加密，而是进行了长达数月的潜伏，期间多次通过WebShell回连内网。

键盘记录： 攻击者部署了键盘记录器 KeyPro.exe，并伪装成 KeyProtect.exe 运行，持续窃取内网用户的敏感凭据。
日志证据： 溯源报告显示，攻击者在7月至9月期间，多次使用不同IP（如 147.**.**.**）访问 key.dat 文件，窃取记录下的数据。

*图22 攻击者持续访问键盘记录文件，窃取内网凭据*

6.3 第三阶段：批量投毒与加密（2025年9月15日-16日）

在掌握了足够的内网权限后，攻击者没有使用高级的域控漏洞（如Zerologon），而是采用了更为简单粗暴的国产远程控制软件——向日葵（Sunlogin） 进行批量投毒。这也印证了攻击者国内散户的身份特征。

横向移动： 攻击者利用之前窃取的凭据或向日葵的漏洞/弱口令，成功连接了多台核心服务器（包括财务服务器、应用服务器）。
投毒执行： 日志显示，攻击者通过向日葵的文件传输功能，将加密器 svchost.exe 传输到目标主机的 C:\** 等目录下，并手动执行。

2025-09-16 00:55:19 | 远程文件传输 | 传入 svchost.exe (C:\**)
2025-09-16 01:01:23 | 开始远程控制

图23 向日葵日志记录

这一操作直接导致了包括WIN-*** (10...**) 在内的10余台核心服务器在短时间内被集中加密，业务全面停摆。

七、总结与警示

这起案件是一起典型的盗版勒索与不专业救援交织的悲剧，但最终通过底层技术得以挽回。

1.切勿盲目支付赎金： 尤其是面对这种“盗版”家族，支付赎金往往意味着肉包子打狗。本案中介支付了10万元人民币却颗粒无收就是血淋淋的教训。如果您正遭遇勒索不知所措，请务必阅读我们发布的【首发科普】来自专业团队的忠告！遇到勒索病毒应如何自救，避免像本案客户一样陷入二次危机。

2.警惕“包解密”骗局：任何声称能100%解密且不通过官方渠道的中介，大概率都是在进行二次博弈或诈骗。

3.变“被动救援”为“主动免疫”： 本案最大的痛点在于密钥控制权完全掌握在失信的黑客手中。为了彻底扭转这种被动局面，Solar团队推出了 防勒索AI疫苗（SAR）。

与传统杀毒软件不同，SAR 具备国内首创的密钥拦截技术。当勒索病毒（无论是正版还是盗版）在系统内启动加密程序的毫秒级瞬间，SAR能直接在内核层捕获其生成的加密密钥（如AES/RSA会话密钥）并安全存储。

这意味着，即便遭遇本案这种“黑客失联”或“中介跑路”的极端情况，企业依然拥有解密密钥的主权，无需支付赎金即可通过SAR的 无损数据回滚引擎 将数据恢复至加密前状态，彻底斩断勒索交易链条。

图24 SAR防护全景图

4.数据恢复是最后防线：在没有密钥的情况下，通过底层页级提取技术依然有极大概率抢救回核心数据库。

5.安全基线是根本：弱口令（admin123）和未修补的漏洞是导致内网全线崩溃的罪魁祸首。建议企业部署防勒索模拟演练平台，定期进行实战化攻防演练，提前发现并封堵安全死角。

Solar团队提示： 当危机发生时，请第一时间联系具备攻防实战经验的专业安全团队。止损、取证、精准恢复，这才是应对勒索攻击的正确解法。