PayBreak防勒索系统简析

本文整理翻译自PayBreak : Defense Against Cryptographic Ransomware

简介

PayBreak基于假设：文件加密依赖于混合加密（译者注：详见我的另一篇文章），其中在受害计算机上使用对称密钥。 PayBreak检测到这些密钥的使用，将它们保存在托管中，因此可以解密文件，否则这些文件只能通过支付赎金才能恢复。

我们认为应对勒索软件威胁的现有技术存在不足（译者注：该文发表自2017年）， 取而代之的是，我们提出了一种系统，允许有安全意识的用户主动防御勒索软件攻击。，它可以使受害者从勒索软件感染中恢复而无需支付赎金。 为此，我们提出了一种密钥托管机制，该机制可将加密密钥安全地存储在密钥库中。

第一步，用户必须生成一个非对称密钥对，并将公钥添加到系统中。 此公共密钥用于加密放置在密钥库中的密钥。 在正常运行期间，我们的系统监视在系统上执行的程序，并拦截对实现密码原语的函数的调用。 此外，系统会捕获对称加密密钥，并使用公钥对其进行加密，然后将结果存储在密钥库中。 一旦用户感染了勒索软件并得知必须支付赎金才能访问文件，其可以简单地用私钥解密密钥库并解密文件而无需支付任何费用。

经测试，PayBreak系统运行了107种勒索病毒样本（12个家族），成功的恢复了所有加密文件。

贡献

  • 对基于现代加密技术的勒索软件进行了特征分析

  • 提出了一种密钥库机制，该机制可以主动防御基于加密的勒索软件

  • 在Windows 7操作系统下实现了PayBreak系统

  • 通过在受控环境中运行107个勒索软件样本来评估PayBreak，并成功恢复了十二个常见勒索软件家族的任何一个加密的所有文件

  • 测试了PayBreak对操作系统和日常使用的性能影响

背景

在本节中，我们将讨论现代勒索软件的典型加密流程以及影响勒索软件的实际限制，同时简单介绍PayBreak系统基于的威胁模型。

Practical considerations for ransomware

勒索软件的目标是阻止受害者访问其数据并勒索赎金。现代勒索软件借鉴了完善的良性密码套件（例如OpenPGP或S/MIME）中的技术，并采用了所谓的混合密码系统。

在混合密码系统中，发送者为每个消息（例如，为每个需要加密的文件）选择一个随机对称密钥，并在该密钥下加密每个消息（或文件）。该一次对称密钥通常称为会话密钥。随后，混合密码系统将使用接收者的（非对称）公钥对对称消息专用密钥进行加密。因此，无论加密内容的大小如何，仅需要高性能的非对称对称加密操作即可加密小的对称密钥。然后，将加密的对称密钥与加密的内容组合并发送到服务器。为了解密数据，接收者首先使用其私钥解密加密的对称密钥。有了对称密钥，接收者便可以简单地将数据的密文解密为原始的纯文本。[1]

在勒索软件攻击中，攻击者在其攻击服务器上生成了非对称密钥对。 在受害者的机器上，恶意软件会为每个加密的文件生成唯一的对称会话密钥。 会话密钥使用攻击者的公共密钥加密，并与加密的文件内容一起存储。 然后，攻击者向受害者索要赎金以获取指定的私钥解密文件。

Hybrid Cryptography

如前所述，对称密钥由非对称公钥保护（加密）。在勒索软件的攻击链中，混合加密系统下加密的消息是受害者计算机上的文件。因此，最终勒索软件攻击的强度就等价于混合密码系统的安全性。基于此事实，被加密的用户文件的后验救援尝试是很具有挑战性的。因此，我们提供了一种保护机制，可以绕过现代勒索软件样本所采用的强密码原语的挑战，而不是简单地检测到受害者计算机是否已感染了勒索软件。

尽管以上讨论似乎是理论性的，但现代勒索软件系列恰恰利用了这种混合密码系统。许多操作系统发行版和平台都包含经过实践检验的加密算法。例如， 在Windows上，一种这样的实现是Microsoft的CryptoAPI。 CryptoAPI是用于加密功能的安全接口，可以确保在每个Windows操作系统中都存在该接口，因此对于勒索软件作者而言，利用现有的加密功能非常简单。

Ransomware Pseudocode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
c2 = ConnectToCommandAndControl();
// Private key kept secret on C2
pubkey = c2.ReceivePubKey();
hPubkey = CryptImport(pubkey);
hCsp = CryptAcquireContext();
while (filename = FindNextFile()) {
	// Read
	ptFile = ReadFile(filename);
	// Generate random session key per file
	hSymkey = CryptGenKey(hCsp);
	// Then encrypt
	ctFile = CryptEncrypt(hSymkey, ptFile);
	keyblob = CryptExportKey(hPubkey, hSymkey);
	DeleteFile(filename);
	// Write encrypted session key
	WriteFile(filename, keyblob);
	// Append the encrypted file
	AppendFile(filename, ctFile);
}

Threat model

本节介绍了我们提出的系统的威胁模型和假设。关于这些假设的详细讨论以及我们为什么认为它们是现实的，请参见后文第6节的讨论部分。我们的威胁模型基于常见且成功的勒索软件，因此，威胁模型考虑已在受害者计算机上成功安装且可运行恶意软件的攻击者。此外，我们的威胁模型中的操作系统是可信和经常维护更新的，即我们假设恶意软件不能提权，因为这也会破坏任何现有的计算机保护机制（如反恶意软件解决方案）。即使我们假设勒索软件仅以用户级特权执行，但大多数现代恶意软件都是被加壳过的。因此，我们的威胁模型假设恶意软件仅由普通的软件加壳。更准确地说，威胁模型只考虑可以运行时脱壳的二进制文件，而不考虑那些应用高级策略或基于仿真的加壳软件（如Themida）。

我们承认，更复杂的壳和混淆技术可能会破坏我们提出的系统。尽管此类技术已广为人知，但这些技术在整个恶意软件社区中并未受到广泛应用，而且至少我们提出的方法大大提高了恶意软件作者绕过保护的门槛（即攻击者必须克服这些难题）。

最后，我们假设用户可以创建一个非对称密钥对来使用我们的系统，并且在感染勒索软件之前就完成了系统设置（即勒索软件的加密操作发生在系统构建完成之后）。

概述

PayBreak系统由三个不同的组件构成，该系统能够恢复由混合密码系统勒索软件加密的文件。 在本节中，我们将简单介绍这些组件及其在系统中的作用。 下图概述了PayBreak的工作方案。 用户使用非对称密钥对（pku，sku）的公钥（pku）配置PayBreak，而私钥（sku）存储在可信设备上。

Overview of PayBreak

系统将计算机上使用的所有加密会话密钥连续存储在安全密钥库中，当用户的计算机不幸感染勒索软件时，则可以使用私钥sku访问系统的密钥库，然后使用存储在密钥库中的数据解密文件。

该系统利用了以下事实：在混合密码系统中，攻击者必须在对称加密期间使用会话密钥。 在实际的勒索软件攻击中，这种加密必须在用户的计算机上进行。 基于这一特征，我们可以绕过对现代勒索软件所采用的强大加密技术的破解。

Crypto Function Hooking

勒索软件的作者需要安全可靠的现代加密技术，因此，当今的恶意软件作者可以选择动态链接（系统提供的）密码库，也可以将外部库静态链接到他们的代码中。

PayBreak支持两种类型的链接方式，并通过它们的名称和地址识别动态链接库中的加密过程，而静态链接过程则基于模糊字节签名（译者注：疑似模糊哈希算法的应用）进行标识。然后在这些过程的位置生成hook。Hook从这些加密过程改变程序控制流，并导出会话密钥以及对称加密方案的其他任何参数。导出数据后，系统将控制权返回到原始加密过程，程序继续正常进行。

Key Vault

用于恢复对称加密数据的密钥材料和算法详细信息（如上所述，从hook过程中恢复并提取导出）存储在安全加密的密钥库中。由于勒索软件可能以密钥库为目标，我们的实现将获取的密钥存储到一个Append-Only的文件中，且该文件受管理员权限保护。在我们的测试中，这种完整性机制已经足够。但是，我们在第六节中讨论了进一步的关键库完整性改进。 密钥库的内容使用用户的公共密钥安全地加密，由于在存储之前已对其进行过加密，我们确保密钥库对用户而言是安全的。

File Recovery

假如用户不幸感染了勒索软件且文件都被加密，则可以使用用户的私钥sku访问密钥库。 PayBreak用于访问加密被勒索的文件时的密钥和算法信息。算法详细信息用于配置与加密时相同的对称加密方案，并且使用保存的密钥与该配置一起尝试恢复文件。 因为勒索软件通常会存储元数据，例如原始文件长度，加密日期和加密密钥数据等信息，所以在加密开始时，实际的加密文件数据通常会在该元数据的固定偏移处。在解密之前，PayBreak将通过测试确定加密文件的正确偏移。

详细实现

我们在Windows7上实现了原型系统PayBreak，主要部分为Hook由Microsoft的Crypto API和Crypto++库执行的加密。该实现还使用了微软CryptoAPI中的加密技术来安全地存储勒索软件使用的会话密钥。

Crypto Function Hooking

Hooking是一种通过使用任意新函数修改原始函数来改变应用程序行为的技术。在Windows中，可以通过多种方式来hook函数，范围从修改进程的“Import Address Table”到注入DLL。我们的原型系统使用Microsoft Research的Detours库进行hooking。Detours首先从原始函数的内存地址的开头至少保存5个字节（x86汇编中无条件的JMP指令的大小）来hook函数。由于x86体系结构中的指令长度可变，保存的字节数可能超过5个字节。Hook函数还会包含需要添加的新代码，对PayBreak而言，就是将会话密钥和算法参数导出到密钥库。在新创建的hook函数末尾，Detours会创建一条无条件跳转指令，将控制权移回原始函数并跳过hook函数。即在每个函数的前5个字节（可能更多）放一个jmp，跳到hook函数，hook函数结尾再jmp回原控制流处。

为了激活hook并将程序控制流从原始函数重定向到hook函数，对hook函数的jmp将覆盖原始函数中的前五个字节。这样就完成了hooking，并且对原始函数的所有调用现在都将重定向到hook。我们的系统采用此方案进行hooking，并将其自身插入Windows 7计算机上启动的每个新进程中。

勒索软件作者一般通过动态链接到系统提供的加密库或静态链接外部库以将加密技术纳入其恶意软件中，这两种链接方式给系统的hooking带来了不同的困难。

Hooking in dynamically linked libraries

几十年来，Windows一直将功能丰富的加密库作为其平台的一部分，从而使得恶意软件很容易动态链接到Windows上的加密库。微软的CryptoAPI只允许通过一组具有特殊访问权限的子例程进行操作，从而隐藏密钥及其在内存中的位置等敏感信息。CryptoAPI的安全性、平台一致性和API完整性使其成为勒索软件作者进行本地文件加密的常用选择。微软的CNG库是经典CryptoAPI的可选替代品（两者都包含在windows7中），但使用方式基本相同，PayBreak也能无缝切换处理。

由于CryptoAPI抽象和不透明的设计，会话密钥的使用和导出只能通过特定的CryptoAPI过程来完成。通过CryptoAPI进行的所有加密都必须通过CryptEncrypt函数执行，或者必须通过CryptExport函数导出（供外部使用）。基于CryptoAPI的勒索软件使用CryptoAPI的CryptEncrypt函数来执行文件的本地加密。因为CryptoAPI是动态链接的，所以添加hook完全独立于调用过程，并且恶意软件的混淆不会影响此功能。利用在CryptEncrypt中配置的hook，PayBreak可以使用CryptExport API函数安全地导出会话密钥。

虽然CryptEncrypt中的hook函数成功导出了会话密钥，但并未包含诸如加密模式和初始化向量之类的算法详细信息。为了获得这些参数，然后重新恢复相同的加密配置，我们的系统挂接了CryptAcquireContext和CryptSetKeyParam函数。CryptAcquireContext的hook函数为PayBreak提供了用于加密的算法信息，包括默认参数。对这些参数的更改是使用CryptSetKeyParam函数执行的，同样的此API函数也已被hooking。

除了使用CryptoAPI进行加密之外，用户可能希望使用API来生成安全的加密用随机数，而该随机数可用于导出另一个加密功能的会话密钥。就Window而言，生成随机数的受支持的API是CryptGenRandom，许多加密库（如OpenSSL，NaCl，LibTomCrypt等）都利用此API来实现其加密安全的伪随机数生成器（CSPRNG）。通过动态hooking并记录此系统函数，PayBreak存储用于生成许多会话密钥的基础信息，这些会话密钥将在勒索软件动态或静态链接这些库时所使用。

Hooking in statically linked libraries

静态链接加密库的勒索软件迫使PayBreak采用稍微不同的方法。静态链接的库嵌入在应用程序的可执行代码中，会受到混淆的影响。因此，PayBreak会在运行时从进程的内存中识别加密过程，然后hooking。为此，我们的系统使用32字节的 fuzzy function signatures 来标识静态链接的库函数。这种方法类似于IDA的快速库识别和识别技术（FLIRT）。

签名由已知加密过程的前32个字节组成，当在内存中连续识别到这32个字节且超过阈值百分比时，系统将标识该进程。因为通常恶意软件会被加壳，所以PayBreak会扫描所有已执行进程的可执行内存，以查找函数签名。我们的原型系统将在每个进程第一次调用NtReadFile之后执行扫描，因为恶意软件必须先读取数据才能加密用户文件。识别到函数签名后，通过使用Detours去hook并导出会话密钥和加密算法的详细信息。尽管我们当前的原型系统可以有效抵御当代勒索软件，但高级加壳技术和混淆仍然可以绕过保护系统。可以利用对加密功能的语义检测加强对勒索软件的识别[2]。

我们的原型系统实现带有Crypto++静态链接库的签名，由Crypto++的SetKey，CipherModeBase和SymmetricCipherBase类方法的前32个字节组成，并通过CryptoAPI的CryptExport API函数导出Crypto++会话密钥和算法详细信息。

Key Vault

我们假设Microsoft CryptoAPI和Crypto++使用的对称密钥和有关对称加密方案的详细信息使用安全的方法存储，只有在必要时才能由勒索软件的受害者访问。我们可以发现PayBreak的密钥库系统的设计与勒索软件部署的混合密码系统极其相似，都使用系统安装过程中生成的用户公共密钥（pku）对会话密钥进行加密和导出。我们的实现为此步骤使用的是2048位RSA密钥，可确保对小于或等于密钥大小的数据进行安全的加密-对于一般的256位对称密钥而言已经足够。

如前一节所述，CryptExcrypt函数的行为增加了对CryptEncrypt的调用。CryptExport调用会将传递给CryptEncrypt函数的会话密钥的句柄以及我们系统的交换密钥（即用户的pku）作为参数以安全地导出会话密钥，同时CryptEncrypt也会导出使用密钥的算法（即AES，3DES，RC4等）信息。

此外，为了重建勒索软件感染所使用的对称加密配置，我们必须保存算法参数，例如初始化向量（IV）和使用的分组密码模式等，这些信息都是从hook中提取的。Hook对传递给CryptAcquireContext和CryptSetKeyParam函数的参数进行记录。与加密消息语法[3]相似，因为它们的公开不会影响现代密码系统的安全性，所以这些参数以明文形式连接到会话密钥信息。此串联的“blob”被附加到PayBreak的密钥库中。此外，如前所述，我们的原型实现将传递给Crypto++函数的加密密钥信息（简单字节数组）存储到密钥库中。系统还存储从CryptGenRandom函数调用的可用于逆向勒索软件以重新创建用于加密文件的会话密钥输出的随机字节。

为安全起见，防止文件库本身被勒索软件加密，文件库配置为append-only，并且仅允许Windows Administrator组进行所有其他访问。如果密钥库需要访问，则使用在安装PayBreak期间设置的私钥（sku）来解密存储的密钥材料，从而访问各个会话密钥和加密方案的参数。

File Recovery

PayBreak的最后一个组成部分是勒索软件感染期间加密的文件的恢复。文件恢复分三个阶段进行。首先使用存放的私钥访问密钥库，然后将保管库中的数据解析为对称密钥和相应的加密方案参数，例如块密码模式和初始化向量，最后把检索到的会话密钥用于解密受害者的文件。通常，由勒索软件加密的每个文件都与元数据（例如勒索软件版本和加密文件的原始大小）连接在一起。由于这种元数据，实际的加密文件数据通常会在为赎金而保留的文件中发生偏移。在不了解每个勒索软件的单独元数据结构的情况下，我们的系统被迫对保存在勒索文件中的每个可能偏移量进行测试。我们的系统利用动态编译来降低后续文件解密所需的工作量，一旦找到成功的偏移量，以后将在先前成功的偏移量处尝试文件解密。

PayBreak迭代尝试使用每个托管密钥和每个偏移量解密文件，直到达到解密状态（libmagic[4]未将其识别为“data”）为止。 一旦将解密状态标识为常见的Office文档文件类型，例如Microsoft Word文档，JPEG图像或PDF文件，该状态将另存为实际的解密文件。 当然，如果生成的文件被错误地标记为已解密，则用户可以指示系统继续搜索，直到标识了正确的键和偏移量为止。此外，尽管我们可以改进这种未优化的暴力破解方法，但至少它成功地恢复了测试的加密用户文件，有用就行不是吗。

测试评估

如上一节所示，我们在Windows 7上实现了PayBreak。 基于此原型实现，我们对系统进行了测试评估并回答了以下问题：

  • RQ1 PayBreak可以保护用户免受真实的勒索软件的威胁吗？（即PayBreak是否可以还原由市面上流通的勒索软件加密的文件）
  • RQ2 是否需要对软件进行特定的修改才能还原不同勒索软件采用的加密？
  • RQ3 将PayBreak作为一种实时的在线保护机制运行会对性能产生什么影响？

这些问题旨在回答所提出技术的实用性问题。 RQ1着重该技术是否有效。 显然，一个不能完成预定功能的系统在对抗勒索软件方面的帮助有限。 RQ2探索了所提出系统的多功能性。 在这种情况下，通用方法比需要不断完善以解决以前未知的勒索软件系列所面临的挑战的技术更为可取。 最后，RQ3解决了一个实际的部署问题。 与流行的防病毒解决方案类似，我们将PayBreak设计为一种在线保护机制，因此，对常见用例和工作负载的高性能影响将对在工作环境采用这种机制构成重大障碍。

Dataset

为了测试PayBreak的功能和有效性，我们需要获取主动加密勒索软件的样本。 为了收集这些样本，我们开发了实时自动化的发现，检测和警告勒索软件（RADDAR）系统。 该项目将被开源，以帮助进一步研究勒索软件。 RADDAR会在各个位置抓取恶意软件样本。 更准确地说，我们从VirusTotal Intelligence获得了样本，该样本提供了针对恶意软件样本的高级搜索功能和下载功能。 我们搜索了新提交的样本（即在分析后一周内提交的样本），这些样本也被至少两个反病毒供应商标记，并且包含在List of Known Ransomware Families中。除了这些流行的勒索软件系列之外，我们还下载了基于通用搜索词的示例：勒索，加密或锁定。除VirusTotal外，我们还对各种恶意软件存储库进行了爬取，包括Malc0de和VXVault。

RADDAR一旦发现恶意软件样本，就会检测该恶意软件样本是否为基于加密的勒索软件，以及是否正在执行其恶意行为。 为此，我们利用了Cuckoo Sandbox动态分析框架，其中每个样本运行20分钟。 我们使用Cuckoo通过在KVM8中运行的受监视Windows 7虚拟机（VM）中执行每个样本来分析并输出每个样本的行为报告。此外，除了在纯净的Windows 7安装包中找到的默认文件之外，我们还通常在计算机上的各个目录中放置经过重新封装的文件类型（PDF，图像，源代码和Word文档）。 最后，我们在虚拟机中添加了PayBreak，这使我们能够执行此评估中介绍的测试。 我们拍摄了文件系统的快照，并将在感染之前在系统上找到的这些文件称为“honey files”（蜜罐）。

在由Cuckoo分析恶意软件样本之后，RADDAR会对Cuckoo结果进行分析，以生成包含各种指标的报告，其中包括样本是否处于活动状态以及PayBreak是否提取了加密期间使用的密钥。 基于以下特征，我们认为勒索软件样本处于活动状态： 1. 覆盖，删除或重新创建至少一个honey file

  1. 新文件被libmagic标识为数据。

需要注意的是，libmagic已经成功标识了原始状态下honey files的真实内容，因此，如果类型更改为数据，则样本必须已对其进行了修改。

为了确定勒索软件的家族，我们对AV标签进行了多数表决（即采用与Kharraz等人相同的方法[5]）。我们让RADDAR运行了4个月，以收集和生成有关1,691个恶意软件样本的报告，其中713个与AV公司使用的勒索软件标签匹配。 下图给出了该分析的详细分类。

Summary of analysis results. Sample count for each category is in parentheses

与之前的恶意软件研究一致，我们数据集中的许多样本由于各种原因没有显示任何恶意功能（即，它们处于非活动状态）。因此，我们进行了以下两步分析。首先，识别活动样本，然后尝试推断非活动样本未显示任何恶意行为的原因。如前所述，安全使用混合加密的勒索软件必须从命令和控制结构（C&C）检索公钥pk。因此，如果恶意软件不产生任何网络流量，就无法安全地应用混合加密。如果所有观察到的TCP和UDP流量都专门针对Windows附属的域（例如用于计时和更新的域），则我们将样本分类为“无网络”。

此外，如果所有DNS查询（针对Microsoft域的查询除外）都返回否，或者所有HTTP请求均生成404状态代码，则将样本分类为“已禁用C＆C”。在分析的非活动样本中，那些报告为具有禁用的C＆C的样本都是由于DNS查询返回错误。但是，我们没有对由恶意软件生成的受HTTPS保护的网络流量进行分析。最后，即使C＆C可操作且可访问，但如果检测到环境敏感型恶意软件在沙盒环境中运行，它也将避免执行。 “Environment”表示恶意软件可能正在分析其环境以检测其是否在虚拟环境（例如KVM或VirtualBox）中运行。 如果Cuckoo的内置检测程序将样本标识为“Environment”，则该样本将被标记为“Environment”。

至于无法确定其余样品没有运行的原因，以前的经验表明，这可能是由于更高级的环境指纹识别，对用户活动的依赖性或逻辑（定时）炸弹的使用而导致执行延迟超过我们的20分钟评估阈值。最后，我们针对20个活跃的勒索软件系列评估了我们的系统，这是我们所知道的最大的勒索软件研究。

PayBreak Effectiveness

在本部分中，我们回答RQ1，PayBreak可以还原真实勒索软件执行的加密吗？和RQ2一样，是否需要对恶意软件家族进行特定的修改才能还原不同勒索软件家族采用的加密？

PayBreak能够从具有已知加密签名的所有勒索软件系列中恢复被勒索的文件。我们的结果证实，我们能够成功融入现实勒索软件样本的加密功能并提取会话密钥以及用于文件恢复的所有必要材料。更具体地说，PayBreak击败了20个活跃勒索软件家族中的12个，据我们所知，其中9个以前从未被击败。如果存在可以完全恢复被勒索文件的方法或技术，那么这个勒索软件就是失败的。PayBreak成功恢复了由CryptoWall和Locky加密的文件，Locky是2016年在经济上最成功的三个勒索软件系列中的两个，而仅CryptoWall便获得了超过3.25亿美元的收入。

下表中显示了活跃勒索软件系列的摘要。给定系列的活跃勒索软件数量在Samples列中指定。对于以前被勒索的勒索软件样本，该列中包含相应的参考。我们不认为泄漏的加密密钥（例如从攻击者的服务器获得）是失败的，因为这是针对勒索软件的活动，并不意味着勒索软件系列的实施不力。PayBreak展示了使用多种加密库（包括Microsoft CryptoAPI和Crypto++）击败勒索软件的能力。

Active Ransomware Samples

PayBreak在运行时为PayBreak成功的样本提取了用于加密的加密算法，并在“算法”列中列出。对于未成功的样本，该列包含其他研究人员研究的信息，这些信息是我们尽可能收集的，并提供了相应的参考。此外，“击败”列还标识了通过先前技术或PayBreak被击败的所有软件。

在我们的样本库中的20个活跃家庭中，PayBreak失败了8个。其中的三个DXXD，PokemonGo和VirLock先前被击败，其使用琐碎的常量密钥进行加密，即它们未使用混合加密。另外两个家庭，MarsJokes和Troldesh，也先前被击败。与流行的方式相反，这些系列使用了自己的伪随机数生成器，而不是使用经过了实战测试的CryptGenRandom API。其余没有成功的软件家族，Androm，Razy和TeslaCrypt使用一个密码库，而我们的原型实现并未设置为可hook的。 PayBreak可以扩展，以通过hooking它们各自的静态链接的加密功能，然后将其恒定密钥（对于琐碎的家族）导出，或将其会话密钥导出到密钥库中，从而击败其余八个家族。 接下来，我们讨论系统所使用签名的鲁棒性。

Signature Robustness

为了识别静态链接的加密库，PayBreak依赖于签名。因此，一个明显的问题是这些签名对混淆的鲁棒性。与所有实用的在线反恶意软件免杀方案一样，足够级别的混淆和欺骗可以规避PayBreak提供的保护。但是，请注意，运行时脱壳的二进制文件不会对PayBreak造成问题。为了评估签名的鲁棒性，我们根据不同编译器和优化级别引入的语法更改来评估它们，因为攻击者可以轻松更改这些特征。为此，我们编译了12个程序，这些程序使用具有不同编译器和优化设置的Crypto++加密库。更准确地说，我们的示例程序静态链接了Crypto++版本5.6.3、5.6.2和5.6.1，包含了这个流行的Windows加密库开发的五年时间。此外，我们使用tdm-gcc和mingw32-gcc编译器编译了程序，每个编译器都具有禁用的优化功能和最大优化级别。要识别加密功能的所有12个变体，我们必须开发两个签名。原因是，使用不同的编译器时，工件之间的差异很大，但对于不同的优化级别，差异就较小。本质上，我们必须为每个编译器创建一个签名，并且每个签名在所有经过测试的优化级别和库版本中都是可靠的。

File Recovery

PayBreak能够从十二个软件中完全恢复加密文件。由于我们正在处理大量样本，因此我们的RADDAR系统只会执行每个样本20分钟。但是，为了评估性能和恢复整个文件系统的能力，我们在可重置的测试环境中执行了四个勒索软件系列，每个系列运行了四个小时。为了开发此测试环境，首先，我们在整个虚拟机的整个文件系统中随机分布于标准化文档库Govdocs1线程。文档语料库包含9,876个文件，这些文件主要是常见的办公类型，例如.xls，.docx和.pdf。对于每个文件，我们记录其原始SHA1文件哈希。通过比较这些文件哈希，我们可以确定我们恢复的文件是否为原始文件。然后，我们执行了一个勒索软件家族，并在没有干预的情况下运行了四个小时。感染完成后，我们将系统上的所有文件提取到安全的环境中。 PayBreak尝试使用从系统中提取的密钥保险库恢复这些文件。然后，我们重置虚拟机，并对每个系列重复此过程。

在对文件系统进行勒索软件加密之后，我们执行了PayBreak解密。我们的系统能够从每种攻击中恢复100％的原始加密文件。与先前生成的原始文件哈希值进行比较对于恢复不是必需的，使用先前生成的文件哈希值仅可作为成功文件恢复的确认。 Locky样本对9,821个文件进行了加密，并在360m40s内恢复了文件。 Cryptowall样本对文档语料库中的204个文件进行了加密，并在86s内恢复了文件。AlmaLocker样本对我们文档语料库中的271个文件进行了加密，而受影响的文件在26s内被恢复。Cryptowall和Alma Locker样本对少量文件进行了加密，可能是由于恶意软件的不稳定性所致，即它们在执行过程中崩溃了；但是，尽管如此，这些测试证明PayBreak能够在短时间内，即整个文件系统几小时的规模内，从勒索软件攻击中完全恢复所有文件。

Performance Impacts

在本节中，我们回答RQ3，它评估了PayBreak对性能的影响。 对于这个问题，我们对两个特征感兴趣。PayBreak对单个调用加密API（即微型基准）会造成何种放缓，以及在常规办公室工作负载（即宏基准）期间对加密API的调用频率如何。 我们评估了运行Windows 7 32位虚拟机，2GB RAM和2个2.20GHz CPU内核的一般笔记本电脑的性能。

Micro benchmark

为了衡量使用Detours hook的CryptoAPI函数的系统开销，我们在1KB文件上执行了1000万次CryptEncrypt API调用的微基准测试。我们发现在没有hook的情况下花费了4.02s。启用PayBreak，将会话密钥和加密方案信息导出到密钥库后，加密循环花费了1,242s。 因此，平均一次对CryptEncrypt API的调用要花费124µs（即速度降低310倍）。但是，大多数性能影响来自写入密钥库的I / O操作。 从测量中省略磁盘I / O可使速度降低到1.5倍。因此，PayBreak的简单性能优化可以是在专用 I/O 线程中执行对密钥库的写入操作，实际的工作负载比上面讨论的综合最坏情况基准遭受的性能影响要小得多。

Macro benchmark

尽管对加密API的单个调用的相对性能影响很大，但是在常规办公室工作负载中这种操作极为罕见。 对于我们的宏基准测试，我们在配备PayBreak的虚拟机上使用了常见的Windows软件。 我们执行的Windows软件包括：7zip，AVG，Dropbox，Firefox，Gimp 2，Google Chrome，Google Drive，Internet Explorer（IE），iTunes，KeePass 2，LibreOffice，Microsoft Excel，Microsoft Powerpoint，Microsoft Word，Pidgin，Putty， RealVNC，Skype，SumatraPDF，WinSCP，WinZip。

由于篇幅所限，我们无法针对我们测试的每个应用程序完整分析我们的测试程序。但是，我们提供了对五个应用程序分析的报告。我们发现任何应用程序都没有明显的速度下降，并且常规应用程序使用期间平均少于100个加密API调用。每个应用程序名称后面的括号中的数字是我们在测试期间从应用程序记录的CryptoAPI调用的数量。

KeePass 2 (28)

我们创建了一个新的密码数据库，并使用该应用程序随机生成了3个密码。 我们删除了该数据库，并创建了一个新的空数据库。 然后，我们导入了一个旧数据库。 我们注意到任何这些操作都没有变慢，并且该应用程序完全正常工作。 KeePass 2似乎是CryptoAPI的不同用户，因为我们观察到CryptoAPI被调用的六个不同功能。

Dropbox (127)

我们使用该程序登录了一个Dropbox帐户。然后，我们将该帐户中先前存放在本地计算机上的3个文件同步。然后，通过将文件拖到Dropbox文件夹中，将5个文件从本地计算机同步到云中。 我们注意到同步期间没有速度下降，也没有程序崩溃。在我们的测试期间，Dropbox进行的大多数CryptoAPI调用都是针对CryptGenRandom的。

Putty (2)

我们连接了远程SSH服务器并执行了几个命令，随后与服务器断开连接。 此应用程序并不频繁调用CryptoAPI，我们没有发现速度变慢或程序不稳定的情况。

Skype (19,418)

我们创建了一个Skype帐户， 添加了2个联系人并发送了消息。 然后，我们给这些联系人中的1个打电话。 Skype频繁调用CryptoAPI，比我们观察到的任何其他程序都要多。 但是，即使使用率如此之高，也远远超过任何其他程序，我们也没有发现速度减慢或程序不稳定。

Internet Explorer (3,328)

我们使用AutoIt程序来实现IE自动化，从而在其HTTPS主页上访问Alexa最受欢迎的100个网站。我们在每个页面上停留5秒钟以让页面完全加载。我们发现每个网页（包括所有资源）平均对CryptoAPI调用33次。因此，即使每次加密操作未优化的减慢速度为124µs，这也导致页面加载的开销仅为4.1ms，明显低于人类的感知阈值。

讨论和系统限制

在本节中，我们将讨论尽管我们的系统存在或由于我们的系统而存在的挑战、开放性问题和限制。一个微不足道的，看似有效的防御勒索软件是一个可靠的备份。有了这样一个备份，用户就不用担心勒索软件的攻击了，恢复所需的只是擦除并重新安装受感染的计算机，并从备份中恢复数据。虽然很简单，但显然过去成为勒索软件受害者并支付赎金的用户并没有这种简单的机制。不幸的是，让所有用户全面使用备份似乎是不现实的。

此外，据报道，一些最近的勒索软件系列（例如RansomWeb或CryptoWall）在感染后立即加密文件，并通过在访问时透明地解密数据来在有限的时间段（例如几个月）内提供对数据的访问权限。 一旦此初始期限到期，恶意软件就会破坏解密所需的密钥，并要求勒索。在这一点上，自感染以来（假如只有几个月）进行的所有备份仅包含加密数据，因此无法从感染中恢复。

PayBreak的核心是一个关键托管系统。政府提出并强制要求的密钥代管制度一直受到研究界和隐私权倡导者的批判。我们完全赞同这一观点，并强烈反对政府规定的密钥代管制度。但是，此类政府强制性提案与PayBreak之间存在根本差异。在PayBreak中，仅存在一个有权访问保存在密钥库中的密钥的实体-合法用户自己。也就是说，除了用户本人之外，没有可信任的第三方。

我们的PayBreak原型实现使用多个动态或静态链接的库来击败勒索软件。勒索软件的作者可能会为了破解PayBreak而尝试推出自己的密码库。但是，这通常会导致软件的失败（例如，僵尸网络管理员使用的简单加密使他们的C＆C协议易于逆向），因此勒索软件作者更倾向于利用安全的第三方库。但是，安全的加密库很少，只有有限的一些可供选择。而对于我们的系统来说，为第三方库或自定义库创建签名并没有难度。我们使用三种不同的库的测试经验表明，可以轻松快速地添加对更多库的支持。例如，我们开发了在一天之内检测Crypto++所需的签名。此外，我们的原型还hook了Windows标准的CSPRNG函数 CryptGenRandom。通过动态hooking并记录该系统功能，PayBreak可以利用任何其他勒索软件库存储任何勒索软件使用的会话密钥的基础资料。无论使用什么代码，恶意软件分析人员只需识别一次加密实现，并将其添加到PayBreak即可添加支持。识别密码不必是手工的，相反，可以通过多种方式使该过程自动化。一旦识别出密码，便存在大量有助于识别相似代码的工作。为了完全避开对称密钥的使用，勒索软件的作者可能会倾向于使用完全非对称的原语来加密数据。尽管这种策略是可行的，但可以通过监视这些方面的启发式方法来解决高资源需求和非对称加密异常频繁地使用的问题。尽管PayBreak表现出了对当代加密勒索软件的有效性，但实际部署仍必须解决本文未涉及的几个问题。这些问题包括，例如，用户如何保护私钥的安全，或为密钥库实施安全的轮转系统，以防止库的无限增长。

如前所述，PayBreak能够在几小时内从勒索软件攻击中恢复，通过详尽搜索，文件恢复独立于勒索软件。这种详尽的搜索是一种并行的工作负载，因此可以使用其他计算资源（例如云部署）几乎任意地进行优化。此外，需要从勒索软件感染中恢复应该是一种罕见的特定情况。 我们认为，对于常规的勒索软件受害者而言，与可恢复加密文件的速度相比，重新获得对加密数据的访问更为重要。

我们承认，与大部分实用的在线保护系统一样，混淆和加壳可以破坏PayBreak提供的保护。但是，混淆只是静态链接到加密库的恶意软件的关注点。由于使用PayBreak会在未混淆的系统DLL中挂钩API函数的实现，因此不会受到使用系统提供的CryptoAPI的恶意软件的绕过。此外，正如我们的评估所示，PayBreak完全能够保护用户免受静态链接加密库的恶意软件的侵害，只要该恶意软件被现代加壳程序所混淆即可。实际上，所有用于评估的恶意软件样本都已加壳，而且来自Tox家族的样本静态链接了Crypto++库。多年来，学术文献和商业资源已提供了高级混淆器。但是，这些先进技术并未在整个恶意软件生态系统中广泛使用。例如，Sun[6]报告说，在103,392个分析的样本中，有91％仅使用简单的加壳软件（例如UPX或ASPack），这些壳不会绕过PayBreak提供的保护。不幸的是，我们不知道阻止恶意软件作者广泛使用更高级的混淆技术的原因，因此，PayBreak提高了恶意软件作者的门槛，并迫使他们使用迄今为止他们一直拒绝采用的绕过技术。

恶意软件可以实施的另一种绕过PayBreak的方法即检测到受害者的计算机中是否正在运行PayBreak，并因此跳过插入的hook。但是，没有理由PayBreak必须在目标加密功能的开头安装hook。只要相关数据结构（例如密钥和加密方案参数）仍在使用范围内，我们可以修改PayBreak以将hook插入函数中的任意点。与混淆情形类似，PayBreak无法提供针对专门旨在绕过PayBreak的恶意软件的保证，但是PayBreak可以大大减少攻击者成功的几率。

最后，发现PayBreak存在的勒索软件可以通过破坏用于在保管库中保管数据的公钥或简单地用无意义的信息填充保管库来发起DOS攻击。可以将PayBreak修改为具有附加到Vault的特权（如以SYSTEM身份运行）进程，从而保护公钥的完整性。在对受害者的文件进行加密之前，使文件库充满垃圾的攻击只能增加恢复加密文件所需的时间，上面提到的特权进程也可以检测到这种攻击的进行，并向用户发出警报，或者终止有问题的过程。即使这种攻击没有引起警报，请回想一下，感染勒索软件是一种罕见的情况，而识别正确的密钥和加密偏移量则很尴尬。因此，即使使用大型保管库（一个1TB的保管库可以容纳大约170亿个条目），恢复也只会被延迟，而不能阻止。

总结

PayBreak是一种创新的保护机制，可以解决基于加密的勒索软件的威胁。早期的勒索软件系列由于未正确配置加密模式而失败，因而成功的软件转而使用正确的加密方法——混合加密。我们研究确定了大部分的勒索软件都必须在受害者的主机上使用对称会话密钥来执行文件加密，因此PayBreak实现了密钥托管机制，将会话密钥存储在密钥库中并使用用户的公共密钥加密，只有用户的私钥才能解锁该密钥库。与政府强制的密钥托管系统相反，PayBreak确保只有合法用户才能访问托管的密钥。我们对107个勒索软件样本进行了测试，并证明PayBreak可以成功地从十二种不同勒索软件系列所造成的损害中恢复，同时其运行时开销远远低于人类的感知阈值，因此可以在日常工作环境钟使用PayBreak。最后，PayBreak将作为一个公开可用的开源项目发布[7]。

参考

  1. 勒索软件结构与加密模式研究 ↩︎
  2. P. Lestringant, F. Guih´ery, and P.-A. Fouque. Automated identification of cryptographic primitives in binary code with data flow graph isomorphism. In Proceedings of the 10th ACM Symposium on Information, Computer and Communications Security, ASIA CCS ’15, 2015. ↩︎
  3. Cryptographic Message Syntax (CMS) ↩︎
  4. Fine Free File Command ↩︎
  5. A. Kharraz, W. Robertson, D. Balzarotti, L. Bilge, and E. Kirda. Cutting the Gordian Knot: A Look Under the Hood of Ransomware Attacks. In Proceedings of the International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (DIMVA), volume 9148 of Lecture Notes in Computer Science, Milan, Italy, July 2015. Springer International Publishing. ↩︎
  6. L. Sun. Reform: A framework for malware packer analysis using information theory and statistical methods, 2010. ↩︎
  7. https://github.com/BUseclab/paybreak ↩︎
#勒索软件 #恶意软件 #密钥存储库 #Hybrid Cryptosystem #Windows Hooking
PayBreak防勒索系统简析
https://mundi-xu.github.io/2021/01/01/A-brief-analysis-of-PayBreak-anti-ransomware-system/
Author
寒雨
Posted on
January 1, 2021
Licensed under