实时识别和威慑勒索软件攻击

大家读完觉得有帮助记得关注和点赞！！！

抽象

勒索软件 （RW） 在数字领域构成了重大且广泛的威胁，需要采取有效的对策。主动网络欺骗是一种很有前途的策略，可以通过用虚假信息误导 RW 并揭示其真实行为来阻止 RW 并限制其传播。此外，RW 通常充当攻击者和防御者之间的通信渠道，允许欺骗将虚假数据返回给攻击者并耗尽他们的资源。本文介绍了 ranDecepter，这是一种将主动网络欺骗与实时分析相结合的新方法，以增强对 RW 攻击的防御。ranDecepter 实时识别 RW 并将其隔离在欺骗性环境中，自主识别 RW 代码中的关键元素以创建循环机制。通过反复重启恶意软件并向攻击者传输伪造的加密信息和密钥，它迫使攻击者为每个受害者存储这些捏造的详细信息，从而耗尽他们的资源。我们使用 1,134 个真实世界的恶意软件样本和 12 个良性应用程序对 ranDecepter 进行了全面评估，表明 RW 识别准确率高达 100%，没有误报，对响应时间的影响最小。此外，在 24 小时内，ranDecepter 使用 9,223 个代理在攻击者的数据库中生成多达 50K 个条目，展示了其破坏攻击者资源的潜力。

第一介绍

勒索软件 （RW） 已成为最具破坏性和持久性的网络犯罪形式之一。与通常优先考虑隐身的传统恶意软件不同，RW 公开加密用户数据或锁定系统，要求付费恢复。这些出于经济动机的攻击不分青红皂白地针对医疗保健、执法和关键基础设施等行业，旨在快速破坏和高影响力的勒索。臭名昭著的 WannaCry 爆发利用了 EternalBlue 漏洞，感染了全球超过 200,000 个系统[1].RW 代码的简单性与盈利能力相结合，推动了其快速扩散和日益复杂。

对抗 RW 的努力涵盖了广泛的防御策略。静态分析，包括签名和基于 ML 的技术[18,6]，可以识别已知的恶意软件，但很容易通过多态性、打包或代码混淆来绕过。动态分析通过在真实系统上执行和监控恶意软件来提高泛化能力[27,3]，但取决于运行时指示器（例如文件加密或删除），这些指示器会引入延迟并允许部分损坏。机器学习增强的动态方法[16,3]训练行为痕迹来模拟恶意模式，但它们仍然依赖于事后观察并遭受误报。其他方法试图遏制或从 RW 效应中恢复。沙盒隔离执行环境以观察恶意软件部署前的情况[2]，但 RW 可以在重定向之前执行作或检测沙盒条件。基于恢复的解决方案，例如 PayBreak[19]和基于缓存的方法[11]尝试恢复加密数据，但无法防止初始文件损坏，并且经常遇到系统开销。

基于欺骗的防御工厂诱饵或蜂蜜文件在整个文件系统中，在访问时触发警报。虽然这些系统轻量级且易于部署，但通常难以管理且容易出现误报。保持蜜文件和合法用户活动之间的分离并非易事，尤其是在动态环境中，意外访问或重叠可能会触发虚假警报。此外，RW 可以绕过这些技术，选择性地针对用户特定文件。ML 驱动的诱饵生成[14]使用文件系统元数据增强真实感，但仍依赖于被动观察，并且通常需要在触发干预之前进行部分加密（参见第 IV-C 节）。

这种不对称的威胁形势促使人们探索传统监控之外的防御措施。网络欺骗提供了一种主动的替代方案，通过误导性数据、纵的响应和虚假伪影来破坏攻击者的作。就 RW 而言，欺骗可以在执行过程中进行干预，防止伤害而不是事后做出反应。为了有效，它需要两种能力：对恶意进程进行准确的运行时识别，以及在损害发生之前及时、精确地进行干预。现有的防御措施往往在两条战线上都失败，行动太晚或错误地对良性活动进行分类。我们的系统通过零误报识别和通过 API 级欺骗进行实时遏制来解决这些限制。与依赖于被动监控、部分观察而不遏制恶意行为或感染后修复的先前防御不同，我们的系统直接在生产系统上运行——在加密或删除任何文件之前在 API 级别拦截和遏制 RW 行为。RW 行为始终遵循可识别的模式 - 文件枚举、访问、加密和删除。通过在运行时纵这些作，我们可以在不影响良性应用程序的情况下使恶意作无效。这种方法对混淆具有鲁棒性，并且不需要事先了解特定的 RW 变体。它还消除了对静态工件或基于元数据的启发式方法的依赖;通过利用跨 RW 系列一致的 API 级行为，它可以有效地泛化，而不会暴露敏感文件。除了识别和预防之外，我们还证明欺骗可以被武器化以增加对抗成本。大多数 RW 系列在每次感染时生成并传输唯一的受害者 ID 和加密密钥。通过在 RW 二进制文件中注入循环机制，我们迫使恶意软件反复重新生成和传输密钥，从而使攻击者基础设施过载并耗尽运营资源。本文做出了以下贡献：

• 我们提出了一个主动的主机内欺骗框架，该框架在早期执行期间对 RW 执行准确、零误报的识别，从而在发生任何加密或删除之前实现实时遏制和预防恶意行为。
• 我们开发了一种二进制检测技术，可以定位和修改 RW 二进制文件中的关键控制流区域，注入循环机制，强制连续生成和传输密钥，有效消耗攻击方资源。
• 我们使用真实世界的 RW 样本评估我们的系统，以可以忽略不计的开销实现 100% 的识别准确率。只需 50 个代理，我们的系统每天在攻击者方面生成多达 9223k 个数据库条目。

第二勒索软件威胁模型和系统范围

二-1攻击媒介和执行

勒索软件 （RW） 通常通过网络钓鱼电子邮件、恶意下载和社会工程渗透到系统中。一旦绕过初始防御，RW 通常会加密文件并将相关密钥泄露到远程命令和控制 （C2） 服务器，为赎金要求做准备。尽管有进程注入和多进程执行等潜在的高级策略，但 RW 仍然依赖于文件枚举、数据加密或删除以及网络功能等标准作进行泄露。实证研究[7,10]表明大约 93% 的 RW 利用广泛使用的加密 API（例如 Windows CryptoAPI、OpenSSL、Crypto++）。这种流行源于三个主要因素：（a） 标准算法（例如 AES、RSA、Blowfish、RC4）经过验证的安全性，它们抵抗简单的密码分析，（b） 自定义加密实现的高风险，历史上证明了 Apocalypse 和 GPCode 等威胁的弱点被迅速消除，以及 （c） 通过利用常见加密 API 融入良性进程的能力。

二-2平台注意事项

Windows 是我们方法的最初重点，因为它具有很高的市场份额 （81.91%），并且 95% 的 RW 攻击针对 Windows 系统[24].尽管如此，我们的方法本质上并不局限于 Windows。通过调整其他平台上等效系统调用（例如 Linux 上的 POSIX API）的拦截和作，并利用我们独立于平台的标准加密库签名检测，我们的框架可以通用化，以在广泛的作环境中检测和破坏 RW。我们的方法针对用户空间勒索软件;绕过此类机制的内核模式变体超出了范围，留待将来的工作。

 

图 1：整体系统和数据流 [LEA：执法机构]

我们假设 RW 已经绕过了传统防御并在受害计算机上运行。我们的系统已预先部署，可以实时拦截 Windows 加密 API 调用，并基于签名检测标准加密库的使用情况。最后，我们假设攻击者必须维护每个感染的密钥和受害者 ID，这使得他们很容易因重复生成和存储密钥而耗尽资源。

第三Randecepter：系统概述

本节概述了我们的系统架构（图 1），其中包括三个模块：离线阶段、实时勒索软件 （RW） 识别阶段和二进制重置阶段。为了解决法律和道德问题，我们提供了两种部署模型。在第一种选择中，离线和重置阶段在由授权机构（例如国防部、HSI、CISA）管理的安全基础设施或服务器上运行，这些机构拥有采取对策的合法权限，而实时 RW 识别则在用户系统上运行。在第二种情况下，执法部门管理整个系统，在蜜罐或故意暴露的系统上部署实时模块，以确保采取法律认可的对策。

III-A离线阶段：勒索软件分析和用于识别的欺骗工具

此阶段建立对勒索软件 （RW） 的行为理解，并实施欺骗策略以进行主动遏制和识别。它涉及两个组成部分：（1） 构建行为知识库和 （2） 部署欺骗机制，将 RW 的 API 调用挂在实时阶段。RW 通常与系统 API 交互以进行加密和文件作。文件作通常调用 WinAPI 调用，如 CreateFile 和 WriteFile，而加密功能是通过三种主要方法实现的：（1） 标准库的动态链接（例如 Windows CryptoAPI、OpenSSL），（2） 静态链接库（例如，嵌入式 OpenSSL 或 Crypto++），或 （3） 自定义加密例程。根据之前的调查[7,10]，93% 的 RW 依赖于标准或静态链接的加密库。

构建知识库：我们在定制的 Cuckoo Sandbox 中收集并执行了来自 30 个家族（来源：VirusTotal 和 any.run）的 521 个 RW 样本，以监控行为。从这些执行中，我们提取了两个基本工件：恶意子图 （MSG） 和加密函数签名 （CFS）。MSG 是数据流图，其中节点表示 API 调用，边缘编码依赖项。与之前的努力不同[25,26]我们的 MSG 仅专注于 WinAPI，还包括来自标准加密库（如“CryptEncrypt”或“AES_encrypt”）的加密函数调用，以及文件作（如“CreateFile”和“DeleteFile”），捕获完整的加密工作流程。与 MSG 并行，我们提取 CFS 以检测静态链接二进制文件中的加密活动。CFS 是紧凑的功能级指纹（32 字节），源自加密常量（例如 AES S-box）、指令序列（例如 aesenc）和控制流模式等独特功能。这些签名通过在不依赖标准库引用的情况下实现高效匹配来增强离线和运行时识别。对于采用专有加密例程的 RW 来说，静态分析是不够的。在这种情况下，我们使用 ent 和 Volatility 等工具应用基于熵的运行时启发式方法，这些工具可以检测内存和文件 I/O 中的异常熵模式——加密活动的可靠指标。

我们的系统通过支持以下内容来推广所有加密实现策略：（1） 动态链接的库，通过 API 挂钩拦截;（2）静态链接的文库，通过CFS识别;（3） 自定义加密例程，使用熵启发式方法进行识别。此外，RW 必须调用通用文件相关 API来与文件系统交互，我们的系统可以可靠地拦截文件系统。

RW行为类型	代表性味精	欺骗反应
文件加密（写入新文件）	CreateFile（O） → CreateFile（D） → Encrypt（CO） → WriteFile（D） → CloseHandle（O， D） → DeleteFile（O）	跟踪文件句柄。拦截 'DeleteFile（O）' 并返回成功而不删除。保留原始 （O）。D 被标记为延迟清理。
文件加密（覆盖原始文件）	CreateFile（O） → ReadFile（O） → Encrypt（CO） → SetFilePointer（O） → WriteFile（O） → CloseHandle（O）	标识“SetFilePointer（O）”，后跟“WriteFile（O）”。丢弃写入并返回成功以模拟覆盖，同时保留 O。

表一：跨加密和删除模式的欺骗策略规划（O：原始文件，D：目标文件，CO：原始内容）。

欺骗策略计划：我们的系统使用 FakeSuccess 策略，通过模拟加密、删除和覆盖等成功作来欺骗 RW，同时静默地保留原始文件。表 I 总结了在 RW 中观察到的两种常见行为模式，并概述了我们部署的相应 MSG 和欺骗反应。

遵循 Write-to-New-File 模式的 RW 变体首先调用 CreateFile（D） 来分配新的加密输出文件，使用 CryptEncrypt、AES_encrypt 或 AES：：Encryption 等加密例程来加密内容，并使用 WriteFile（D） 写入结果。这些作之后通常会调用 DeleteFile（O） 以删除原始文件。我们的系统允许继续进行与加密相关的 API 调用，跟踪文件句柄元数据，并使用虚假的成功策略拦截 DeleteFile（O） 以保留原始文件。这些加密的目标文件被标记为延迟清理，如第 III-B 节中所述。使用“覆盖原始”策略的 RW 变体会跳过目标文件的创建。相反，它通过 SetFilePointer（O） 倒回文件指针，并通过 WriteFile（O） 直接覆盖内容。由于目标是替换原始文件，因此不会进行显式删除调用。一旦 ranDecepter 识别出针对原始文件的加密活动和写入，它就会删除写入作并返回成功，确保原始文件保持不变。虽然表 I 提供了使用基于 WinAPI 的 RW 样本的代表性 MSG，但在其他库中也观察到了类似的行为流。对于 OpenSSL 和 Crypto++，CryptEncrypt（CO） 调用分别替换为 AES_encrypt（CO） 和 AES：：Encryption（CO）。我们的系统通过关注整体行为模式（例如加密之后是文件覆盖还是删除，而不是特定的加密 API）来统一处理所有这些变化。

图2：详细的插图展示了我们系统的各个阶段和组件，描述了它们的数据流和决策过程。[CFR：密码函数识别器;LEA：执法机构]

欺骗策略实现 （Deception DLL）：为了实施我们的欺骗策略，我们实现了一个运行时组件——欺骗 DLL。它挂钩关键 API 并将欺骗性响应直接注入 RW。如图 2 所示，该 DLL 在执行过程中被部署到实时 RW 进程中，以实时拦截加密、删除和覆盖尝试。我们利用 EasyHook 库，这是一个灵活的开源引擎，支持用户和内核级挂钩。对于概念验证，我们专注于用户模式 API 挂钩，因为大多数 RW 使用用户级 WinAPI 调用进行加密和文件作。尽管只有一小部分 RW 直接调用内核级 API 来进行与文件相关的作，但将我们的系统扩展到内核级别仍然很简单。这是由于用户级和内核级文件作 API 之间的清晰映射，结合 EasyHook 对内核级挂钩的内置支持。这样的扩展将进一步增强我们方法的稳健性，确保全面覆盖先进的 RW 技术。

III-B实时阶段：使用挂钩进行 RW 识别

进程启动后，我们的实时阶段从利用 Windows Defender 的WdFilter.sys开始[23]回调将 Deception DLL 注入新进程（图 2 中的步骤 1 和 2）。这确保了立即拦截系统 API 调用，使我们能够从第一条指令开始监控和纵勒索软件 （RW） 行为。我们的系统提供两种运行时策略：白名单和应用程序重启控制 （ARC），用于在执行过程中管理未经验证的进程。白名单确定流程是否应绕过重复分析;用户可以手动添加受信任的应用程序，或者让系统在进程运行后自动将其列入白名单，而不会触发 RW 识别n连续处决。阈值n可调以平衡灵敏度和性能，并且所有白名单元数据都经过加密和密码保护以防止篡改。ARC 控制遏制攻击性，并以两种模式运行：部分遏制和完全遏制。在这两种模式下，通过在文件指针重置后（例如，通过 SetFilePointer（0））监控 WriteFile 调用来拦截使用加密内容覆盖现有文件的尝试。这确保了无论应用程序最终是良性还是恶意，原始文件都会被保留。由于这些覆盖作不可恢复，因此良性应用程序可能需要重新启动才能恢复正常功能。在部分遏制中，允许对新文件进行加密，同时阻止和延迟删除作。如果该过程后来被认为是良性的，则会自动应用延迟删除。在完全遏制中，加密和删除都会被阻止以获得最大程度的保护，如果稍后验证，则必须重新启动良性应用程序。然后，用户可以选择将它们列入白名单以避免将来中断。为了实现精确和自适应的响应，该系统采用分阶段拦截和欺骗策略，在执行过程中通过识别、遏制和误导 RW 来动态激活，而不会破坏良性软件。

第一阶段：系统首先通过 CreateFile API 上的挂钩检查所有文件创建作。具体而言，它检查 dwCreationDisposition 标志中是否有 CREATE_ALWAYS 或 CREATE_NEW 等值，这些值建议创建新文件。同时，解析 lpFileName 参数以提取文件名和扩展名，然后根据已知 RW 文件扩展名的精选列表进行交叉检查[13].如果找到匹配项，则该过程将立即终止并过渡到二进制复位阶段（步骤3，图2）。虽然这种基于扩展名的方法对于识别已知的 RW 变体非常有效，但我们的系统超越了简单的文件扩展名检查，以解决指示零日 RW 的行为，这些行为可能会通过避免可识别的扩展名来逃避检测。我们还挂钩了 MoveFile 和 MoveFileWithProgress，RW 通常使用它们来重命名加密文件。检查这些 API 是否存在可疑的重命名行为，尤其是涉及可疑文件扩展名或模式的行为，从而能够及早识别规避 RW 活动。

第二阶段：如果未检测到可疑文件创建，系统将进入第 2 阶段。在这里，系统评估进程是否具有加密能力。这是使用第 III-A 节中介绍的三种正交技术确定的：（1） 检测对标准加密 API 的调用，如 CryptEncrypt、AES_encrypt 或 AES：：Encryption;（2） 调用 WriteFile 时对加密函数签名 （CFS） 进行运行时内存扫描;（3） 使用 ent 和 Volatility 等工具的基于熵的启发式方法。

当标准加密 API 调用被拦截时，系统会打开加密标志。对于嵌入式加密例程，CFS 检查在 WriteFile 期间触发，在数据刷新到磁盘之前针对内存缓冲区，加密例程通常会在磁盘完成。这种精度避免了全内存扫描并确保轻量级作。如果确认加密功能并启用了 ARC，则系统会从此时起将所有敏感作的 FakeSuccess 响应返回给 RW。如果禁用 ARC，则允许继续加密，并在以下阶段激活其他保护措施。

第三阶段：此阶段侧重于拦截进程如何以及在何处写入加密内容。解决了两个主要方案。在第一个新文件加密中，该进程创建一个新的目标文件（例如，使用 CreateFile（D））并通过 WriteFile（D） 写入加密数据。在这种情况下，将记录作并允许继续。系统跟踪目标文件 （） 并使用 CloseHandle （D） 将其与其句柄相关联，在 RW 确认或进程终止时将文件标记为延迟删除。在第二种方案中，就地覆盖，如表 I 的案例 #2 所示，RW 在原始文件 （SetFilePointer（O）） 上倒回文件指针，并尝试通过 WriteFile（O） 覆盖它。如果加密标志处于活动状态并启用了 ARC，则写入将被阻止并返回 FakeSuccess 响应以保留原始内容，而不会提醒 RW。如果禁用 ARC，则系统会在允许覆盖之前创建原始文件的临时卷影副本。如果该进程稍后被验证为良性，则删除该副本;否则，保留的备份会保护用户的数据免受破坏性更改的影响。

第四阶段：在新文件加密模型的最后阶段，RW 通常会在将加密输出写入新文件后调用 DeleteFile（O） 来删除原始的未加密文件。检测到此调用后，我们的系统会拦截它并返回“True”，模拟删除成功。实际上，原始文件保持不变，而新创建的加密文件被标记为延迟清理。如果该进程稍后被验证为良性，则系统将安全地重新执行此删除请求以恢复应用程序一致性。整个阶段取决于设置的加密标志，确保这些作仅由可能造成伤害的进程触发。

第五阶段：在最后阶段，系统确定该过程是否可以最终标记为 RW。一个关键信号是勒索字条的存在，许多 RW 变体都会生成勒索字条来要求付款并完成其攻击生命周期。为了识别这一点，我们挂接了 CreateFile API 并监控敏感用户目录（如桌面、文档和下载）中的文件创建。新创建的文件会扫描高风险关键字，例如“赎金”、“加密”、“解密”、“付款”、“比特币”、“删除”或“丢失”。如果检测到此类术语，系统会通知用户查看文件并验证其意图。除了文本检测之外，我们还通过捕获背景图像变化来监控视觉勒索字条提示。当检测到变化时，图像会通过 Google Cloud Vision API 进行光学字符识别 （OCR） 处理，以提取相关关键字。为了进一步提高识别准确性，我们结合了 UNVEIL 等先前工作中的基于行为的技术[18]，我们计划采用潜在语义分析（LSA）[20]在未来的版本中，以语义分析关键字匹配之外的文件内容。

阶段	触发	系统作
1	扩展名为 RW 的 CreateFile，或通过 MoveFile 进行可疑重命名	如果检测到 RW 扩展，则终止进程并过渡到复位阶段。否则，请继续监控。
2	加密 API 调用、CFS 匹配或高熵检测	引发加密标志。如果启用了 ARC，则返回 FakeSuccess 以阻止加密;否则，允许它。
3	面向新文件或原始文件的 WriteFile	对于新文件：允许写入并标记删除。对于覆盖：如果 ARC 打开，则 intercept 和 FakeSuccess;否则复制原件。
4	加密后调用的 DeleteFile（O）	拦截删除并返回 True。如果确认了 RW，请稍后删除;否则，保留原件。
5	观察到勒索字条或壁纸更改	确认 RW，启动加密文件的清理，并完成分类。

表二：用于识别的分阶段 RW 拦截和欺骗逻辑

虽然 RW 可以通过多种渠道（包括浏览器弹出窗口、锁屏和电子邮件内容）发送勒索消息，但对 176 个 RW 样本的研究表明，所有这些样本仍然实施了基于文件的勒索字条（例如.txt、.html）或锁屏修改[20]以及其他渠道，加强了我们当前方法的有效性。如果检测到勒索字条，则该进程被归类为 RW，并将其二进制文件上传到安全的欺骗性环境以进行分析和重置循环激活。如果没有找到赎金票据，但该进程表现出加密或删除行为（例如，7zip 等合法工具），则不会立即标记它;相反，监控会持续到进程终止，以捕获延迟的赎金票据创建。由于删除和覆盖在第 4 阶段已经被拦截，因此最后阶段安全地解决了流程结果：如果分类为 RW，系统将删除以前创建的加密文件;如果是良性的，则所有延迟删除作都将按最初预期执行。此最后阶段可实现可靠的分类，同时最大限度地减少误报并在整个执行过程中保留用户数据。表 II 中总结了这五个阶段描述的逻辑，其中概述了关键触发器和相应的系统作。此表可作为我们分阶段拦截策略的快速参考，有助于阐明 ranDecepter 如何在整个 RW 执行生命周期中实现精确识别和响应。

三丙重置阶段：耗尽攻击者的资源

此阶段展示了 ranDecepter 的重置机制如何通过迫使勒索软件 （RW） 反复将自己的工件（例如加密密钥和受害者 ID）泄露回给攻击者来支持反攻工作。通过自动化此循环，ranDecepter 增加了对手的运营负担，符合国防部、CISA 和 HSI 等组织领导的国家网络安全工作的目标。虽然攻击者可能拥有可扩展的存储，但我们的目标不仅仅是空间消耗，而是显着增加他们的运营负担。

 

图 3：常见的 RW 执行链（EC1 和 EC2）。在左侧，我们展示了用于执行“传输密钥”的 MSG RW。红色 API 表示其各自 MSG 的结束。

 

图4：二进制编排的工作流（对于执行顺序 EC1）。

要实现这种循环机制，ranDecepter 必须首先确定恶意软件在何处完成其“传输密钥”例程，即将加密密钥和系统特定标识符发送给攻击者的阶段。这是通过定制的动态分析模块，即符号二进制分析器 （SBA） 来实现的。建立在 gExtractor 之上[4]，SBA 使用选择性符号执行来记录用户空间 API 调用（超过 390 个受支持的 API 函数），记录参数值，并捕获每个函数的调用堆栈状态，包括调用者的地址和 API 的返回目标。它还标识二进制文件的入口点地址，这对于循环重定向至关重要。

使用这些跟踪，Actuating Agent 通过分析关键作的顺序（例如信息收集、加密和网络传输）来重建恶意软件的执行链。在先前提取的恶意子图 （MSG） 和加密函数签名 （CFS） 的帮助下，ranDecepter 将 RW 行为分为两个主要执行顺序：EC1 和 EC2（图 3）。在 EC1 中，恶意软件在启动文件加密之前传输密钥。在 EC2 中，密钥传输发生在文件作之后。识别此结构可以精确放置复位逻辑。为了创建持久循环，ranDecepter 在最终“传输密钥”API 的返回地址（在图 3 中以红色突出显示）插入自定义 JMP 指令，将执行重定向到恶意软件的入口点。为确保稳定性，系统会恢复原始堆栈状态，即在进程最初以挂起模式启动时和重新进入之前记录。这包括重置堆栈库和限制，以防止在重新执行时崩溃或行为不一致。这种修补和控制重定向是使用 EasyHook 自动执行的。此业务流程是使用 Deceptor DLL 完成的，该 DLL 在恶意软件执行恢复之前注入。它有两个关键职责。首先，它包含通用绕行函数，这些函数钩住通常用于生成受害者指纹的数据收集 API（例如 MAC 地址、系统时间戳、随机数生成器）。这些函数配置为返回随机或误导性数据，确保每次循环迭代都会为攻击者生成唯一且无用的标识符。其次，DLL 管理控制流重定向。根据 SBA 分析生成的配置文件，它确定了将重置 JMP 插入的位置以及如何在循环之前正确恢复调用堆栈。

完整的工作流程如图 4 所示。SBA 完成分析后，系统会解析执行跟踪日志以定位密钥传输逻辑的末尾。根据这些地址，它会生成一个配置文件，该文件指定随机数据挂钩、堆栈恢复详细信息和重置跳转放置（步骤 3-6）。然后，恶意软件以挂起模式启动（步骤 7），注入 Deceptor DLL（步骤 8），并开始修补（步骤 9-10）。最后，恶意软件通过修改后的控制流恢复（步骤 11-12），进入一个循环，继续“感染”同一系统并反复发送虚假标识符。在 EC1 中，循环排除了加密和删除阶段，因为它们发生在“传输密钥”步骤之后。但是，在 EC2 中，RW 在泄露之前完成文件加密。为了处理这个问题，ranDecepter 插入了一个辅助旁路。它识别一个重复序列（从“FindFirstFile”开始，到“DeleteFile”结束），并从“FindFirstFile”条目插入一个JMP，到返回“DeleteFile”，从而有效地跳过加密-删除循环。

家庭	#	家庭	#	家庭	#	家庭	#
Bl00dy的	8	康迪	19	公主储物柜	13	迪亚沃尔	14
锈	16	明	34	阿纳托娃	6	洛伦兹	3
卡兹储物柜	8	不佩蒂亚	38	无逃生	11	贾夫	9
迷宫	108	拉格纳	46	美杜莎储物柜	52	加密混合	6
AvosLocker（阿沃斯储物柜）	4	坏兔子	6	JSWORM的	4	洛克山	3
加密墙	93	WannaCry	121	佛法	98	球柏	107
锁位	97	机器人	38	土星	34	甘德蟹	110
特斯拉地crypt	25	异构主义者	3			总	1134

表三：我们数据集中的代表性 RW 样本

四评估

为了评估稳健性和普遍性，我们整理了来自 30 个家族的 1,134 个勒索软件 （RW） 样本，这些样本仅限于过去五年（详见表 III）。该数据集与第 III-A 节中使用的数据集不同，用于评估实时识别和编排。所有样本都在受控测试台中执行，其中 API 级拦截始终实现零误报和最小的文件丢失。为了验证资源耗尽，我们运行了四个开源 RW 示例，其中包含可访问的 C&C 代码[5]，确认攻击者后端中虚增的受害者 ID 和关键条目。

IV-A针对 RW 的准确性和有效性评估

我们使用数据集中的 1,134 个 RW 样本评估了 ranDecepter 的检测准确性和整体有效性。其中，204 个样本是在 CreateFile作期间通过匹配已知的 RW 文件扩展名而早期检测到的，从而可以在任何损坏之前立即终止。大多数 （895 个示例） 使用 MoveFile 或 MoveFileWithProgress 将重命名延迟到加密后。对于这些，ranDecepter 利用 MSG 和 CFS 知识来标记可疑的加密行为，通过 FakeSuccess 策略拦截和伪造后续的 DeleteFile 和 WriteFile作以保留原始文件。勒索字条创建确认了 RW 行为，触发了零数据丢失的警报。在其余 35 个样本中，有 19 个打开了网络端口，但由于缺少 C&C 触发器而保持不活动状态，而 16 个样本采用了自定义的嵌入式加密例程。这些最终被基于熵的启发式方法标记出来，尽管平均丢失了七个文件。总体而言，ranDecepter 实现了 100% 的识别准确率，使用静态、动态和自定义加密技术有效检测 RW。结果汇总于表四（a）。

IV-B针对良性应用的评估

为了评估 ranDecepter 的误报率和响应延迟，我们针对 45 个广泛使用的良性应用程序进行了测试，包括那些表现出与 RW 类似行为的应用程序，例如加密和文件删除。该套装包括流行的程序，如 Mozilla Firefox、MS Word、7Zip、WinSCP、VeraCrypt 和 MySQL Workbench（请参阅[5]).每个应用程序都使用具有代表性的工作负载执行;例如，使用 125Zip 压缩 7 MB 文件夹。

在评估过程中，我们执行了良性应用程序并监控误报，特别注意涉及加密和文件删除或重命名的行为。正如预期的那样，在 CreateFile 阶段没有应用程序被错误分类为 RW。虽然多个应用程序执行了加密或文件作，但它们没有被标记为恶意，因为它们没有创建具有已知 RW 扩展名的文件或生成勒索字条。为了评估性能影响，我们测量了每个应用程序在有和没有系统 API 挂钩的情况下的响应时间。所有测量均使用 WinAppDriver 进行，以确保一致性和自动化。如表 IV（b） 所示，7Zip 观察到的最大开销为 5.73%，其次是 Mozilla Firefox 的 5.44%、WinSCP 的 4.61%、Opera 的 3.79% 和 MySQL Workbench 的 3.69%。由于空间限制，显示了开销最高的前五个应用程序;所有 45 种应用的完整评估结果可在以下网址获得[5].其余应用程序的开销从 0.40% 到 2.99% 不等，这表明 ranDecepter 在实践中对性能下降的影响最小。

IV-C与现有同类作品的比较

我们将 ranDecepter 与领先的基于欺骗的 RW 防御措施 RWGuard 进行了比较[21]， R-哨兵[28]和 R-Trap[14]——同样利用诱饵和行为监测进行识别。我们排除了静态、基于签名和沙盒技术，因为它们具有固有的局限性，如第一节和第五节所述。我们的方法与直接部署在受害计算机上的动态运行时监控系统更加紧密地结合。这些先前的动态方法通常存在延迟检测和误报，通常仅在部分文件损坏后才做出反应。虽然诱饵旨在限制影响，但它们可能会被良性进程无意中访问，从而触发错误警报。ranDecepter 通过无诱饵、无 ML 的设计结合了三种互补技术来解决这些问题：（1） MSG 的运行时提取以通过 API 依赖项捕获加密工作流程，（2） 静态 CFS 以检测嵌入式加密例程，以及 （3） 基于熵的启发式方法来检测自定义加密逻辑。它进一步采用两阶段验证策略，先发制人地拦截 WriteFile/DeleteFile 等破坏性调用，并通过分阶段指标（例如勒索字条创建）确认 RW 意图。这种分层设计确保了稳健、实时的遏制，即使在激进的良性活动下也不会出现误报。我们根据文件丢失、误报和运营成本评估所有系统。

系统	误报	验证	ML/启发式成本	诱饵管理	文件丢失
ranDecepter	没有	勒索字条检查	没有	不需要	0 个文件 （98.5%），≤7 个文件 （1.5%）
R-哨兵	可能	没有	没有	必填	最多 10 个文件
R-疏水阀	可能	没有	ML + 再生	必填	平均 18 个文件
R-储物柜	可能	没有	没有	必填	部分，未报告
RW格拉德	可能	CryptoAPI + 行为	随机森林机器学习	必填	平均 288 个文件

表五：ranDecepter 与现有 RW 防御的比较

RWGuard 使用诱饵文件监视、CryptoAPI 挂钩和基于 I/O 活动的进程级异常检测器。然而，它对标准 API 和粗略行为指标的依赖导致了严重的文件丢失，在检测到之前平均加密了 288 个合法文件。相比之下，ranDecepter 在 98.5% 的情况下可以防止文件丢失，并在其余 1.5% 的情况下将其限制为仅 7 个文件，而无需模型训练或流程分析。R-Sentry 和 R-Trap 都使用诱饵文件。R-Sentry 根据假设的目录遍历放置蜜文件，而 R-Trap 使用机器学习自适应克隆用户文件。尽管比静态诱饵更具弹性，但当良性应用程序访问诱饵时，两者都会出现误报。R-Sentry 允许在发出警报之前丢失多达 10 个文件，而 R-Trap 平均为 18 个。R-Trap 还会因持续的诱饵再生和 ML 驱动的选择而产生适度的开销。相比之下，ranDecepter 不需要诱饵或 ML 基础设施，避免误报，并通过轻量级作实现接近零的文件丢失。R-Locker 在用户目录中引入了基于 FIFO 的陷阱文件，终止访问它的任何进程。这假设 RW 遵循广度优先遍历并尽早遇到 FIFO，这可能不适用于目标 RW。与其他诱饵触发系统一样，它缺乏确认逻辑，增加了良性干扰的风险。表 V 总结了这些系统的关键部署指标：误报、运营开销和文件丢失。

IV-D复位阶段二进制编排的准确性和性能分析

为了评估我们的二进制编排策略的有效性，我们在四个具有可访问服务器端组件的开源 RW 示例上对其进行了测试：NekRos、Cryptonite、Jasmin 和 POC Windows 加密 RW（表示为 r1–r4）[5].这些示例支持对重置机制进行端到端验证。

每个样本都在我们的符号二进制分析器 （SBA） 中进行编译和分析，以提取与加密相关的 API 地址。然后，Actuating Agent 生成相应的 Deceptor DLL 配置，并将其注入恶意软件进程中。当二进制文件执行时，服务器日志确认重复收到唯一的受害者 ID 和加密密钥，从而确认二进制编排的准确性为 100%。为了进行性能评估，我们在 24 小时内监控了攻击者的数据库，以评估资源耗尽情况。我们的系统生成了 3,081K 到 9,223K 条目，消耗 385 MB 到 1.1 GB 的内存。使用 VPN/代理可以通过屏蔽流量来源来进一步增强这一点。结果汇总于表四（c）。

V相关工作

勒索软件 （RW） 防御分为两大类：基于非欺骗的防御和基于欺骗的防御，每种防御都有显着的局限性，ranDecepter 通过实时 API 级遏制和对抗性破坏克服了这些局限性。

非基于欺骗的方法：静态和基于 ML 的检测方法匹配恶意软件签名或学习代码级功能[18,6]，但很容易通过打包、多态性或混淆来规避。已经提出了动态方法来监控运行时行为，例如 I/O 活动或加密模式[27,9]，但是这些系统需要可观察到的损坏（例如，文件修改或删除）才能触发警报，从而导致检测延迟和文件丢失。应用于动态跟踪的 ML 模型[16]提高了可推广性，但继续依赖于加密后项目，并且在良性工作负载下经常会产生误报。沙盒技术[2]旨在在部署前隔离恶意样本;然而，许多 RW 菌株现在都包含沙箱规避功能，并且它们对隔离执行的依赖使得它们在实时、就地场景中不切实际。PayBreak 等事后工具[19]或基于缓存的方法[11]尝试恢复而不是预防，使文件部分加密并增加存储开销。

基于欺骗的方法：欺骗技术通过用诱饵填充文件系统来引诱 RW 活动，试图及早发现[21,28].这些方法虽然在概念上是积极主动的，但也面临着一些挑战。首先，它们需要广泛部署合成工件，这可能与合法的用户工作流程重叠，从而引入误报其次，自适应 RW 可以选择性地避开诱饵，针对特定文件。 为了解决这些限制，R-Trap 等最新系统[14]结合元数据感知克隆和机器学习驱动的诱饵放置，以增强真实感。但是，这些仍然是被动的，因为只有在部分加密发生后才会触发作。例如，RWGuard、R-Sentry 和 R-Trap 在缓解之前总共允许 10 到 288 个文件丢失.此外，所有这些技术都依赖于文件系统级指标，限制了可扩展性，并使它们暴露在元数据作的规避之下。

我们的方法：与之前的努力不同，ranDecepter 旨在通过在 API 级别运行来解决这些限制，在发生任何文件访问之前拦截 RW 行为。它通过识别常见的 API 使用模式（例如 CreateFile、WriteFile、DeleteFile）来泛化各种变体，并实时应用欺骗来抑制加密或删除尝试，而不会影响良性活动。与依赖诱饵的系统不同，我们不需要合成文件、加密后指示器和用户元数据。这可确保从第一次交互开始实现零误报和完全遏制。此外，我们还引入了一种二进制编排机制，该机制通过循环检测实时 RW 二进制文件，迫使它们重复重新生成和传输加密密钥。这不仅消除了威胁，而且还主动给攻击者的基础设施带来了负担——这是之前工作中所缺乏的功能。因此，我们的 API 级方法比现有的 RW 防御更具可扩展性、抗规避性和运营破坏性。

六讨论与结论

这项工作提出了 ranDecepter，这是一个基于主动欺骗的 RW 防御框架，无需依赖静态签名、沙盒隔离或基于恢复的方法即可实现实时识别和遏制。通过在运行时拦截和纵关键的 API 级作，ranDecepter 让 RW 在不影响系统文件的情况下揭示其行为。我们的评估表明，来自 30 个家庭的 1,134 个真实世界 RW 样本的识别准确率为 100%，零误报。以 API 为中心的设计确保了可扩展性和低开销。ranDecepter 的架构与特定的 RW 变体或文件结构无关，使其适合实际部署。ranDecepter 的一个新颖贡献是它的重置阶段，它利用欺骗进行进攻。通过分析 RW 二进制文件并插入控制流重定向循环，它迫使恶意软件反复传输虚假的加密密钥和受害者 ID。该系统仅使用 50 个代理，在 24 小时内在攻击者的后端生成了超过 900 万个条目，从而显着增加了对抗成本。这将 ranDecepter 从预防提升为主动反击，与 CISA、DoD 和 HSI 破坏攻击者基础设施的使命保持一致。

虽然我们的方法显示出有希望的结果，但必须承认某些局限性。高级 RW 可以通过验证或取消挂钩 IAT/EAT 条目来绕过用户空间 API 挂钩。为了解决这个问题，我们计划采用更具弹性的技术，例如运行时混淆、内核级钩子（例如 SSDT、回调）[17]，以及使用扩展页表 （EPT） 的仅执行内存保护。这些方法使钩子检测更加困难，但需要仔细调整以避免性能开销。尽管我们的资源耗尽策略会提高攻击者的运营成本，但老练的对手可能会适应。尽管如此，该目标不仅限于存储耗尽，还通过启用信标等主动措施来揭示 C&C 基础设施、自动天坑和恶意软件中毒。这些策略为执法部门提供破坏和可作的情报。我们还承认可能产生意想不到的后果，例如，如果攻击者基础设施在付款后被拆除，受害者将失去访问权限。然而，我们的重点是破坏活跃的 RW 活动，这与僵尸网络删除策略保持一致。此外，ranDecepter 目前强调父子流程监控。这种流程内的关注可能会忽略跨独立流程的 RW 协调。未来的工作将探索进程间关联技术，例如基于策略的进程关联[8]和谱系分析，以增强对分布式 RW 行为的检测。

总之，ranDecepter 通过将早期识别与主动欺骗相结合，推进了 RW 防御状态。它可以在损害发生之前消除威胁，并随着时间的推移耗尽攻击者的资源。这种主动范式将防御态势从被动缓解转变为对手破坏。随着 RW 威胁的发展，像 ranDecepter 这样的解决方案对于在日益恶劣的网络环境中保护数字资产、关键基础设施和组织弹性至关重要。