Magnitude Exploit Kit: 仍然活跃 – Avast

如果可以选择一个电脑程式并将其抹除，我会选择InternetExplorer。转用其他浏览器很可能能为无数人免于被骇的危险，更不用说当网页开发者面对InternetExplorer相容性问题时所经历的种种困扰。不幸的是，我无法使InternetExplorer消失，但看到它的浏览器市场份额年年下降，至少让我有希望有一天它会仅存于历史当中。

尽管整体趋势看起来令人鼓舞，但仍然有一些国家对InternetExplorer使用量的下降反应较慢。韩国就是一个有趣的例子，直到最近，若用户想访问政府或电子商务网站，往往。这是由于一项看起来非常荒谬的法律：这些网站必须使用，因此仅在InternetExplorer中受到支持。讽刺的是，这些控件最初旨在提供额外的安全性。虽然这项法律在2020年12月终于被废除，但InternetExplorer至今在韩国仍然有相当的势头。

Magnitude Exploit Kit（我们喜欢称之为_Magniťůdek_）背后的攻击者正在利用这股势头，透过针对韩国InternetExplorer用户显示的恶意广告进行攻击。这些广告主要出现在成人网站上，成为所谓的_成人恶意广告_的例子。这些广告包含代码，利用已知漏洞，使攻击者能够控制受害者的电脑。所有受害者需要做的，是使用易受攻击的MicrosoftWindows和InternetExplorer版本，访问包含这些广告的网页，然后他们就会遭遇到勒索病毒，导致他们的电脑被加密。

每日受保护的Avast用户数量。注意到在7月9日后的下降，那时攻击者在一个广告网络的帐户被终止。

概述

Magnitude ExploitKit，最初被称为PopAds，自至少2012年以来就已存在，这对一个攻击工具来说，是相当长的寿命。然而，九年前的Magnitude exploitkit并不是现在的Magnitude，几乎每个部分都已经多次变更。基础设施有变化，登陆页面也变了，shellcode、混淆、有效载荷，最重要的是，漏洞也都不同。Magnitude目前利用一种InternetExplorer内存损坏漏洞，在渲染过程中获取shellcode执行，并利用Windows内存损坏漏洞来提升权限。Internet上有可正常运行的CVE-2021-26411的完整利用代码，而Magnitude直接使用这个公开漏洞，只是在其上加了一些混淆。根据韩国网络安全公司的说法，这个CVE最初是在针对安全研究人员的针对性攻击中使用的，而Google的威胁分析小组则。

CVE-2020-0986的利用则不那么简单。这个漏洞首次在野外的零日利用链中被Kaspersky研究人员发现，他们命名该攻击为。据我们所知，本次攻击是自该攻击以来首次在野外利用这一漏洞。Kaspersky和的博客中提供了有关该漏洞的详细信息。虽然这两篇报告包含部分利用代码，但开发出一个完全功能的利用代码仍然必须付出大量努力。由于Magnitude的利用代码与这些报告中的代码非常相似，我们相信攻击者从报告中提供的代码出发，然后添加缺失的部分以获得有效利用。

有趣的是，当我们第一次发现Magnitude利用CVE-2020-0986时，并没有使用任何恶意有效载荷进行武器化。成功利用后，它所做的只是用受害者的Windows版本号对其C&C服务器进行回响测试。当时，我们推测这只是漏洞的测试版，攻击者试图找出哪些Windows版本能够被利用，然后再全面整合入这个利用包中。果然，一周后我们看到了该漏洞的改良版，这次它携带著Magniber勒索病毒作为有效载荷。

直到最近，我们的检测每天平均保护大约一千名Avast用户。随著Magnitude使用的广告网络中的一个合规团队将攻击者摒除，该数字下降到约一半。目前，所有被保护的用户都是来自南韩的IP地址，但几周前，台湾的互联网用户也曾面临风险。历史上，南韩和台湾并不是唯一遭到Magnitude攻击的国家。，Magnitude还曾针对香港、新加坡、美国和马来西亚等地进行攻击。

基础设施

Magnitude的操作者目前正在从多个成人广告网络购买弹出式广告。不幸的是，这些广告网络允许他们非常精确地瞄准那些可能容易受到所使用漏洞攻击的用户。他们只需支付显示给韩国InternetExplorer用户且运行特定版本的MicrosoftWindows的广告费用。这意味著，广告的目标用户大部分都是易受攻击的，并且攻击者不必浪费资金在无法利用的用户上。我们已联络相关广告网络，让他们知道自己的平台被滥用。其中一个成功终止了攻击者的帐户，导致我们每日需要保护的Avast用户数量明显减少。

当恶意广告呈现在受害者面前时，它会通过一个中介URL重定向到一个服务CVE-2021-26411漏洞的页面。这种重定向链的例子是binlo[.]info
-> fab9z1g6f74k.tooharm[.]xyz ->
6za16cb90r370m4u1ez.burytie[.]top。第一个网域binlo[.]info是广告网络可见的网域。如果这个网域被不在目标范围内的人访问，它会仅仅显示一个看似合法的诱饵广告。我们认为这个诱饵广告的目的是使该恶意广告看起来对广告网络是合法的。如果广告网络的人来验证该广告，他们只会看到这个诱饵，并很可能得出它是合法的结论。

另外两个网域（tooharm[.]xyz和burytie[.]top）被设计成非常短命。事实上，这个漏洞包每三十分钟就会更换这些网域，并且不会重复使用。这意味著该漏洞组织每天需要注册至少96个新网域！此外，子网域（fab9z1g6f74k.tooharm[.]xyz和6za16cb90r370m4u1ez.burytie[.]top）对每个受害者都是独特生成的。这使得这个漏洞组织更难追踪和防护（也使它对关闭行动更具韧性），因为基于域名的检测并不太有效。

针对CVE-2021-26411的JavaScript漏洞使用了一种看似是自定义的混淆器进行混淆。该混淆器在一定周期中会进行更新，这很可能是为了逃避基于特征的检测。该混淆器是多型的，因此每位受害者都能获得独特的混淆漏洞。除此之外，有关混淆的资讯并不多，它进行了一般意味上的操作，比如隐藏字符串/数字常量，重命名函数名，隐藏函数调用等。

经过解混淆后，这个漏洞基本与Internet上自由可用的CVE-2021-26411的公开漏洞完全匹配。唯一重要的变化是在shellcode中，Magnitude显然提供了自家的有效载荷。

Shellcode

shellcode有时被一个简单的打包器包裹，该打包器使用冗余的jmp指令进行混淆。这通过随机化指令的顺序，然后在每两条连续指令之间添加一个jmp指令来混淆每个函数，以保持原有的控制流。与shellcode的其他部分一样，其顺序是即时生成的，因此每位受害者都能获得shellcode的唯一副本。

如上面截图所示，该漏洞包优先不使用标准的WindowsAPI函数，而是经常直接调用系统调用。上述函数使用NtAllocateVirtualMemory系统调用来分配内存。然而，请注意，这个精确的实现只在Windows10的WoW64子系统中有效。在其他版本的Windows上，系统调用号是不同的，因此系统调用号0x18将指向其他系统调用。而这个实现也不适用于原生的32位Windows，因为在那里调用指向FS:[0xC0]的FastSysCall指针是没有意义的。

为了解决这些问题，这个shellcode有几个变体，每个变体都是针对特定版本的Windows定制的。每个变体都包含适合目标版本的硬编码系统调用号。Magnitude根据受害者的User-
Agent字符串选择正确的shellcode变体。但有时，仅知道Windows的主要发行版本和位元数还不够以推导出正确的系统调用号。例如，64位Windows10上的NtOpenProcessToken的系统调用号在1909和20H2版本间是不同的。在这些情况下，该shellcode从KUSER_SHARED_DATA获取受害者的精确NtBuildNumber，并使用硬编码的映射表将该构建号解析为正确的系统调用号。

目前，shellcode只有三个变体。一个是针对Windows 10 64位的，一个是针对Windows 7 64位的，另一个是针对Windows 732位的。然而，将来出现额外变体是完全可能的。

为了便于频繁的系统调用，shellcode使用了我们所谓的_系统调用模板_。下方可以看到它在WoW64 Windows10变体中使用的系统调用模板。每当shellcode即将执行系统调用时，它首先通过更新系统调用号（第一条指令中的立即动作）和retn指令中的立即数（指定在函数返回时释放的字节数）来自定义该模板。自定义模板后，shellcode就可以调用它，这将执行所需的系统调用。同时，注意根据过程环境块中0x254的值进行的分支。这很可能是恶意程式作者试图检查一个有时称为dwSystemCallMode的字段，以判断系统调用是否应该通过int0x2e直接调用，还是通过FastSysCall过渡。

现在我们知道shellcode是如何混淆的以及它如何执行系统调用的，让我们看看它实际上做了什么。需要注意的是，shellcode期望在IE的中运行，因此它能做的事情相对有限。然而，EPM沙箱并不像可以的那样严格，这意味著该shellcode仍然能够进行有限的文件系统访问，公共网络访问并且能够成功调用许多API函数。Magnitude希望绕过沙箱所施加的限制，因此该shellcode主要作为LPE漏洞的准备阶段，旨在使Magnitude能够突破沙箱。

该shellcode的第一步是获取当前过程的完整性级别。它的shellcode中嵌入了两个URL，完整性级别用于判断哪个URL应被使用。如果完整性级别为Low或Untrusted，则该shellcode从第一个URL下载一个加密的LPE漏洞。该漏洞然后经由简单的XOR加密解密，映射到可执行内存并执行。

另一方面，如果完整性级别为Medium或更高，则该shellcode判断自己不在沙箱中，并跳过LPE漏洞。在这种情况下，它从第二个URL下载最终有效载荷（目前是Magniber勒索病毒），解密它，然后开始寻找可以将该有效载荷注入的进程。对于64位Windowsshellcode变体，目标进程必须符合以下所有条件：

• 目标进程名称不是iexplore.exe
• 目标进程的完整性级别不是Low或Untrusted
• 目标进程的完整性级别不高于当前进程的完整性级别
• 目标进程不是在WoW64环境中执行
• （目标进程可以以PROCESS_QUERY_INFORMATION打开）

一旦找到合适的目标进程，shellcode便会穿过Heaven’sGate（仅在WoW64变体中），并使用以下系统调用序列将有效载荷注入该目标进程：NtOpenProcess -> NtCreateSection
-> NtMapViewOfSection -> NtCreateThreadEx -> NtGetContextThread ->
NtSetContextThread ->
NtResumeThread。请注意，在这个执行过程中，一切都是纯粹在内存中进行的，因此Magnitude经常被描述为无文件的漏洞包。然而，当前版本并不完全无文件，因为如下一节所示，LPE漏洞会将一个帮助PE文件掉入文件系统中。

CVE-2020-0986

Magnitude通过利用CVE-2020-0986突破EPM沙箱，这是splwow64.exe中的内存损坏漏洞。由于有漏洞的代码以中等完整性运行，且低完整性进程可以使用本地过程调用（LPC）触发它，因此该漏洞可以用来将从EPM沙箱中移至中等完整性。CVE-2020-0986及其利用方法已在和的博客中详细讨论。因此，这一部分将关注Magnitude对该漏洞的实现，欲了解有关漏洞的进一步技术细节，请参阅其他博客文章。

来自gdi32.dll的有漏洞代码如下。这是LPC服务器的一部分，可以通过LPC调用触发，并且r8和rdi均指向LPC客户端和服务器之间共享的内存区域。这基本上给了攻击者在splwow64过程中调用memcpy的能力，同时控制所有三个参数，这可以立即转换为任意读写原始操作。任意读取只是调用memcpy，dest在共享记忆体中，src则是目标地址。相反，任意写入则是调用memcpy，dest是目标地址而src在共享记忆体中。

然而，有一个小问题使利用变得更具挑战性。如上面反汇编代码所示，要获取memcpy的count，需要通过将两个字指针的反参考内容相加来获得。对于（较小）任意写入来说这并不是问题，因为攻击者可以提前在共享记忆体中放置所需的count。但对于任意读取来说，count并不是直接可控的，并且可以在0和0x1FFFE之间的任意值，这可能会使splwow64崩溃，或进行一个memcpy的参数为零或小于所需的count。为了解决这个问题，攻击者可以通过两次触发有漏洞的代码来执行任意读取。在第一次触发时，该漏洞可以被用作任意写入，将正确的count放置到必要的偏移量上，而在第二次触发时，则可用来实际读取所需的内存内容。这种技术有一些缺陷，例如它不能用于读取不可写的内存，但这对于Magnitude来说并不构成问题。

该漏洞的开始阶段是创建一个命名的互斥体，以确保仅运行一个实例。然后，它调用CreateDCW以启动要利用的splwow64过程并执行所有必要的准备，使其能够稍后发送LPC消息。该漏洞中还嵌入了一个64位PE文件，它掉落到%TEMP%并从那里执行。该PE文件有两个不同目的，根据是否存在命令行参数来决定其要执行的功能。第一个目的在于收集各种64位指针并反馈回主漏洞模块。第二个目的则是在漏洞成功利用后作为最终有效载荷的加载器。

当这个掉落的64位PE文件第一次运行时，有三个指针被获得。第一个指针是fpDocumentEvent的地址，它存储著指向DocumentEvent的指针，这利用了EncodePointer函数进行保护。这个指针透过扫描gdi32.dll（或gdi32full.dll）中一个静态指令序列得到，该序列将该地址的值设置为。第二个指针是从winspool.drv导出的DocumentEvent的实际地址，第三个则是从msvcrt.dll导出的system的指针。当64位模块获得这三个指针时，会将它们掉落到一个临时文件中并终止自身。

主32位模块接著读取掉落的文件，在实际利用过程中使用获得的数值，其行动序列可以概括为以下几个步骤：

1. 该漏洞在splwow64过程的fpDocumentEvent地址泄露值。值通过使用上面描述的任意读取原始操作发送两条LPC消息进行泄密。
2. 泄露的值是指向DocumentEvent的编码指针。使用这个编码的指针和DocumentEvent的实际原始指针，该漏洞破解了用于指针编码的秘密值。详情见Kaspersky的。
3. 使用获得的秘密值，该漏洞编码system的指针，以便在splwow64中对这个新编码值调用DecodePointer将得到指向system的原始指针。
4. 使用任意写入原始操作，该漏洞将fpDocumentEvent覆盖为编码的system指针。
5. 该漏洞再次触发有漏洞的代码。这一次，它对任何内存复制都不感兴趣，故将memcpy的count设置为零。相反，它依赖于splwow64将尝试解码并调用fpDocumentEvent中的指针。由于这个指针在前一步中被替换，因此splwow64将调用system而不是DocumentEvent。DocumentEvent的第一个参数是从共享内存区域中读取的，这意味著攻击者可以控制，因此可以向system传送任意命令。
6. 最后，该漏洞最后一次使用任意写入原始操作，将fpDocumentEvent恢复至原始值。这是一次尝试清理的行为，但由于在第一次步骤中植入count时随机指针被破坏，导致splwow64仍可能不稳定。

Magnitude在对system的调用中执行的命令如下：

icacls <dropped_64bit_PE> /Q /C /setintegritylevel Medium &&
<dropped_64bit_PE>

这一命令将掉落的64位PE文件提升至中等完整性并再次执行它。这一次，它不会再获取任何指针，相反会提取自身内部嵌入的有效载荷并注入到合适的进程中。目前，被注入的有效载荷是Magniber勒索病毒。

Magniber

Magniber，当时Magnitude开始将其作为Cerber勒索病毒的替代品进行部署。尽管它近四岁，但仍然经常受到更新，因此自上次已有很大变化。早期版本特别使用服务器端AES密钥生成，并包含恒常的备用加密密钥，以防伺服器无法使用。由于此加密方式下的备用密钥开发了一个能提高文件复原的解密器，该解密器由韩国互联网与安全局开发，发表于。攻击者随后对Magniber进行更新以本地生成加密密钥，但基于GetTickCount的自定义PRNG非常薄弱，故Kookmin大学的研究人员能够来恢复被加密的文件。不幸的是，Magniber又再次更新，目前使用如下的自定义PRNG。此函数用于生成单个随机字节，并在加密每个文件时调用32次（生成AES-128密钥16次，IV16次）。

虽然这个PRNG在第一眼看起来仍相当薄弱，但我们认为没有合理有效的方法来攻击它。计数器不是问题：在循环的所有迭代中，它将具有极高的可能性保持不变且其值可以透过检查事件日志和加密文件的时间戳进行猜测。问题在于RtlRandomEx函数，该函数在每个加密文件中将被调用640次（2
* 10 *（16 +
16））。这意味著该函数在加密过程中可能会被多次调用，而在所有这些调用中泄露和跟踪其内部状态无疑显得艰难。至多只可能在几个已加密文件中进行解密。而且在新的CPU与Windows版本上，因为RtlRandomEx内部使用了rdrand指令，这使其成为一个相当可接受的加密PRNG。

该勒索病毒开始时创建一个命名的互斥体，并使用受害者电脑名称和卷序列号生成一个标识符。然后，它以随机顺序列举所有不为DRIVE_NO_ROOT_DIR或DRIVE_CDROM的逻辑驱动器，接著递归遍历它们以加密个别文件。一些文件夹，例如samplemusic或torbrowser在内，均被排除在加密之列，同样所有隐藏文件、系统文件、只读文件、临时文件和虚拟文件也都会被排除。完整的排除文件夹列表可参攷我们的。

与许多其他勒索病毒株类似，Magniber仅加密某些预选择的扩展名文件，例如.doc或.xls。它的配置包含两组扩展名哈希，每个文件仅在其扩展名哈希可以在这些集合之一中找到的情况下才会被加密。这两组的区分很可能是为了给扩展名分配优先级。Magniber通过对整个文件系统进行两次扫描来实施其加密。第一次扫描加密来自优先级较高集的扩展名文件。第二次扫描则加密来自较低优先级集的其余扩展名文件。有趣的是，较高优先级集还包含九个附加混淆的扩展名，这与较高优先级集的其余部分不同。这似乎是攻击者尝试将这些扩展名隐藏以防逆向工程。您可以在我们的中找到这些以及Magniber加密的其他扩展名。

要加密文件，Magniber首先使用上述PRNG生成128位AES密钥和IV出现。由于一些奇怪的原因，它仅选择生成范围从0x03到0xFC之间的字节，这有效降低了密钥空间的尺寸从256^16到250^16。然后Magniber按最大0x100000字节的块大小从输入文件中读取，并将其在CBC模式中无限地加密每个块并写回输入文件。一旦整个文件被加密，Magniber还使用嵌入到样本中的公共RSA密钥加密AES密钥和IV，并将结果附加到加密文件的最后。最后，Magniber通过在文件名后附加随机外观的扩展名来重新命名文件。

但在加密过程中存在一个错误，这使得某些加密文件进入无法恢复的状态，无法解密，即使是拥有相应私有RSA密钥的攻击者也无法做到。该错误影响所有大小为0x100000的文件（即1MiB的文件）。为了理解这个错误，让我们首先详细调查个别文件的加密过程。Magniber将输入文件分割成块，且将最后一块视作不同的处理。在加密最后一块时，Magniber将Final参数设置为TRUE，以便CryptoAPI可以添加填充并完成加密。仅在最后一块加密后，Magniber才附加RSA加密的AES密钥到文件中。

这个错误在于Magniber如何确定自己当前在加密最后一块：它仅将大小小于0x100000的块视作最后的块。但这对于那些大小为0x100000的文件来说是无效的，因为这样的文件甚至最后一块也正好是0x100000字节。当Magniber加密此类文件时，它从未在加密最后一块时注册自己当前在加密的最后一块，这导致两个问题。第一个问题是，它从未将CryptEncrypt的Final=TRUE，因此加密文件最终的填充无效。第二，Magniber也不附加RSA加密的AES密钥，因为附加它的触发是对最后一块的加密。这意味著用于文件加密的AES密钥和IV因而丢失，没有它们就无法解密档案。

Magniber会在每个加密过至少一个文件的文件夹内掉落赎金说明。额外的赎金说明也丢在%PUBLIC%中，并在加密后自动在notepad.exe中打开。赎金说明中包含多个URL，引导受害者到支付页面，页面上指示他们如何付款以获得解密器。这些URL对每个受害者都是独特的，子网域表示受害者标识符。Magniber还会自动在受害者的浏览器中打开支付页面，同时在此过程中通过URL外泄有关勒索病毒部署的进一步信息，例如：

• 被加密文件的数量
• 所有被加密文件的总大小
• 被加密逻辑驱动器的数量
• 遇到的文件数量（不论是否加密）
• Windows版本
• 受害者标识符
• Magniber版本

最后，Magniber试图使用UAC绕过方法删除影子副本。它向HKCU\Software\Classes\mscfile\shell\open\command写入要删除的命令，然后执行CompMgmtLauncher.exe，以为这样就能提升权限运行命令。但由于这一特定UAC绕过方法已在Windows10中被修复，Magniber还包含另一种绕过方法，该方法仅在Windows10机器上使用。另一种方法类似，写入的命令为HKCU\Software\Classes\ms-
settings\shell\open\command，并在那里创建名为DelegateExecute的键，最终运行ComputerDefaults.exe。有趣的是，使用的命令为regsvr32.exescrobj.dll /s /u /n
/i:%PUBLIC%\readme.txt。这是一种经常被称为Squiblydoo的技术，用于运行丢入readme.txt的脚本，该脚本如下。

结论

在这篇博客中，我们详细研究了Magnitude漏洞包目前的状态。我们描述了它如何利用CVE-2021-26411和CVE-2020-0986向不幸的受害者部署勒索病毒，这些受害者使用的是易受攻击的InternetExplorer版本。我们发现Magnitude是一个相对成熟的漏洞包，拥有非常健全的基础设施。它每个月使用上千个新域名，而它的感染链则由七个阶段组成（甚至不算多层的混淆）。该基础设施也受到良好保护，使得恶意程序分析师很难追踪和研究该漏洞包。

我们还深入挖掘了Magniber勒索病毒。我们发现了一个错误，该错误导致一些文件的加密使其无法得以恢复，即使是拥有相应私有RSA密钥的攻击者。这突显出一个不幸的事实，即付赎金并不一定能保障取回被勒索的文件。这是我们催促勒索病毒受害者避免付款的原因之一。

尽管Magnitude背后的攻击者似乎在漏洞开发、混淆技术和恶意基础设施的保护方面有上佳理解，但在生成随机数方面却似乎毫无所知。这导致以前版本的Magniber使用了有缺陷的PRNG，这使得恶意程式研究员能够开发解密器，帮助受害者恢复被勒索的文件。然而，Magniber总是迅速改进自己的PRNG，不幸的是这使得解密器无法再使用。当前版本的Magniber使用的PRNG似乎刚好够安全，这使我们相信未来不会再有解密器的出现。

事件指标（IoC）

IoCs的完整列表可在https://github.com/avast/ioc/tree/master/Magnitude获得。

重定向页面

SHA-256

2cc3ece1163db8b467915f76b187c07e1eb0ca687c8f1efb9d278b8daadbe590
3da50b3752560932d9d123ef813a3b67f5d840fee38a18cc14d18d5dc369bce4
91dbcaa7833aef48fa67c55c26c9c142cb76c5530c0b2a3823c8f74cf52b73cc
db8cf1f5651a44b443a23bc239b4215dcfd0a935458f9d17cb511b2c33e0c3b9
ef15ee0511c2f9e29ecaf907f3ca0bb603f7ec57d320ba61b718c4078b864824

CVE-2021-26411

SHA-256

0306b0b79a85711605bbbfac62ac7d040a556aa7ac9fe58d22ea2e00d51b521a
419da91566a7b1e5720792409301fa772d9abf24dfc3ddde582888112f12937a
6a348a5b13335e453ac34b0ed87e37a153c76a5be528a4ef4b67e988aaf03533
4e80fa124865445719e66d917defd9c8ed3bd436162e3fbc180a12584d372442
217f21bd9d5e92263e3a903cfcea0e6a1d4c3643eed223007a4deb630c4aee26

Shellcode

SHA-256| 注解
—|—
5d0e45febd711f7564725ac84439b74d97b3f2bc27dbe5add5194f5cdbdbf623| Win10WoW64变体
351a2e8a4dc2e60d17208c9efb6ac87983853c83dae5543e22674a8fc5c05234| ^ 解包

4044008da4fc1d0eb4a0242b9632463a114b2129cedf9728d2d552e379c08037| Win7WoW64变体
1ea23d7456195e8674baa9bed2a2d94c7235d26a574adf7009c66d6ec9c994b3| ^ 解包
3de9d91962a043406b542523e11e58acb34363f2ebb1142d09adbab7861c8a63| Win7 原生变体
dfa093364bf809f3146c2b8a5925f937cc41a99552ea3ca077dac0f389caa0da| ^ 解包
e05a4b7b889cba453f02f2496cb7f3233099b385fe156cae9e89bc66d3c80a7f| 更新的Win7WoW64变体
ae930317faf12307d3fb9a534fe977a5ef3256e62e58921cd4bf70e0c05bf88a| 最新的Win7WoW64变体

CVE-2020-0986

SHA-256| 注解
—|—
440be2c75d55939c90fc3ef2d49ceeb66e2c762fd4133c935667b3b2c6fb8551|
pingback有效载荷
a5edae721568cdbd8d4818584ddc5a192e78c86345b4cdfb4dc2880b9634acab|
pingback有效载荷
1505368c8f4b7bf718ebd9a44395cfa15657db97a0c13dcf47eb8cfb94e7528b|
Magniber有效载荷
63525e19aad0aae1b95c3a357e96c93775d541e9db7d4635af5363d4e858a345|
Magniber有效载荷
31e99c8f68d340fd046a9f6c8984904331dc6a5aa4151608058ee3aabc7cc905|
Magniber有效载荷

指针扫描/加载器64位模块

SHA-256

f8472b1385ed22897c99f413e7b87a05df8be05b270fd57a9b7dd27bed9a79a6