XLoader 是 FormBook 恶意软件的高级演变，作为一种高度复杂的网络威胁而脱颖而出，以其双重功能而闻名，既是信息窃取器，又是恶意有效载荷的多功能下载器。xLoader 以其弹性特性而著称，它不断适应最新和最复杂的规避技术，使其成为网络安全防御的巨大挑战。它作为商业恶意软件即服务解决方案的作用使其臭名昭著，使网络犯罪分子能够为各种恶意活动定制和部署恶意软件。该恶意软件的不断演变和逃避检测的能力凸显了对强大的网络安全措施的迫切需要，以应对其针对个人和组织的复杂和多方面的攻击。

主要发现：

• 相关视频教程

• 恶意软件开发（更新到了155节）

• 初始dropper ：Xloader 使用与 Remcos RAT 和 Agent Tesla 等其他一些信息窃取器类似的初始dropper 。初始 dropper 是一个 dotnet 可执行文件，其中包含多个嵌入式 DLL，这些 DLL 在运行时被提取和解密，以启动有效负载，即实际的恶意软件。有效负载在自身或另一个正在运行的进程中使用 Process Hollowing 启动，具体取决于初始 dropper 的配置。

• Native Assembly Paylaod：Xloader 是用原生的低级 asm/c 语言编写的。在此有效负载中找不到字符串、导入和库。与c语言相结合的原生汇编已经使其比其他信息窃取者（如Remcos，Agent Tesla，NanoCore等）更难分析和检测。

• Anti-Analysis/VM Techniques：它使用先进的技术来检测恶意软件是否在分析环境中运行。高级技术的使用可确保反 vm 检查不会像修补跳转条件或返回条件那样容易绕过。

• 自定义加密算法：它使用自定义 RC4 加密/解密算法和额外的减法运算。

• API/字符串/库哈希：Xloader 对其字符串、库和 API 使用 CRC32/BZIP2 哈希算法来隐藏其内部工作。

• 加密核心功能：Xloader 的核心恶意函数都是加密的，在运行时被解密，程序集在绕过所有反 VM 检查并生成密钥后会更新或重新生成。

• Unhooked clean ntdll：它使用手动映射到其内存中的 ntdll 的干净副本，该副本绕过了 ntdll API 的所有钩子。它使用本机 API 进行恶意活动，这些活动在 EDR 解决方案中是隐藏的。

• 权限维持：Xloader 使用运行注册表项并在 Program Files （x86） 中复制自身来添加持久性。

• 权限提升：它仅在 Program Files （x86） 中复制自身并添加持久性时才提升权限。权限提升是通过滥用 DllHost.exe 和 COM 对象来实现的。

• 进程注入：Xloader 严重依赖工艺注入。它在执行过程中感染多个进程，甚至迁移到不同的进程。

• 诱饵 C2s：它使用诱饵 C2 服务器的组合，并付出了巨大的努力来隐藏其真正的 C2。

• 表单抓取器：Xloader 不仅仅是一个信息窃取者。它还可以用作表单抓取器。内联钩子被注入到多个受害者进程中，以在执行加密之前获取信息。

概述

XLoader 是一种非常复杂的信息窃取和表单抓取恶意软件，其特点是熟练使用先进的防御规避技术来保持隐身性和弹性。除了规避操作之外，XLoader 还采用了多种反 VM 技术，战略性地避免了在分析环境中执行。该恶意软件的主要目标是数据泄露，通过窃取和捕获来自各种应用程序（包括浏览器、电子邮件客户端、FTP 客户端和即时消息应用程序）的敏感信息来实现。值得注意的是，XLoader 旨在跨各种平台无缝运行，从而放大其威胁级别。其多方面的攻击流程包含战略性和系统性方法，使其成为寻求破坏个人用户和组织系统的网络犯罪分子的有力工具。XLoader 的不断发展凸显了强大的网络安全措施的必要性，以应对其错综复杂且适应性强的本质。

威胁报告：XLoader 4.3

报告的这一部分提供了对 Xloader 4.3 恶意软件的详细技术分析。此报告的流程将按照我在分析过程中执行的步骤顺序进行。这是我分析过的最复杂的恶意软件之一，它的执行有很多阶段。我试图在给定的时间内尽可能多地报道，但如果有些事情仍未得到解答，那么我事先道歉。现在让我们深入了解 Xloader 4.3 的技术细节和内部工作原理，以前称为 Formbook 信息窃取器。

初始引爆：

从xloader的初始引爆开始。我已经在存在 procmon、wireshark 和其他此类分析工具的情况下在我的隔离分析环境中引爆了恶意软件。什么也没发生!!这可能表明恶意软件中存在反分析技术。我再次尝试引爆恶意软件，但这一次，我重命名了我的分析工具并开始执行。

·进程树显示它启动了自己的另一个实例。

·多个DNS和HTTP请求被发送到不同的域。

·删除了自身

·请求通过explorer.exe发送

下面列出了几个已解析的域：

• hxxp：\www.twin68s.online

• hxxp：\www.cicreception2023.org

• hxxp：\www.morubixaba.com

• hxxp：\www.gestionamostualquiler.org

• hxxp：\www.superios.info

• hxxp：\www.bocahkota.xyz

• hxxp：\www.lolisex77.top

• hxxp：\www.fhsbfjbsljsdfsd.xyz

• hxxp：\www.mifurgoentuangar.fun

• hxxp：\www.necessarymusthave.shop

• hxxp：\www.abk-importexport.com

• hxxp：\www.adoniadou.com

• hxxp：\www.delret.tech

• hxxp：\www.humidlandscaping.com

• hxxp：\www.wlkwinn.net

• hxxp：\www.8ai.ooo

• hxxp：\www.minevisn.com

• hxxp：\www.moheganmart.com

• hxxp：\www.jacksonmoddy.com

第 1 阶段：dropper 

初始 dropper 是 dotnet 可执行文件。它类似于其他信息窃取者或 RAT 用于丢弃其有效载荷的方法，例如 Agent Tesla 或 Remcos RAT。第一步始终是静态分析，它为我提取可疑字符串并提供对恶意软件的见解。

提取的字符串建议 3 个要点：

• Dropper 经过混淆处理，可在运行时加载其他程序集

• 其他资源被反转以避免基于签名的检测

• 必须具有 1 个以上的程序集

在最初的 dropper 中，添加了大量垃圾代码以转移分析师的注意力。几行恶意代码散布在整个代码中。

相关代码行显示恶意软件正在从 3 个不同的资源加载二进制文件：

· Quartz which is also reversed

· Versa

· Zinc

这 3 个是在运行时组合并加载以进一步执行的恶意资源。在经历了大量垃圾代码之后，我遇到了在运行时解析此程序集并创建资源实例的代码行，然后使用 System.Activator 类加载第一个方法。

由于 stage1 恶意软件在运行时解析程序集并从已解析的程序集激活方法，因此在此步骤之前无法进行静态分析，因此我转向动态分析。

• 在模块窗口中可以看到已加载的运行时二进制文件。

• 运行时生成的二进制文件的名称是 pendulum。在代码中，恶意软件调用 GetExportedTypes 返回的第一个成员，这意味着将执行导出的第一个成员。

• 我们可以在摆锤二进制文件中找到第一个函数，并提前设置断点以停止并调试它。

从第一个加载的 DLL 的资源（即 Pendulum）中解析了进一步的二进制文件。在模块选项卡中，我们可以跟踪正在添加的 dll 并继续跟进。

• 另一个在运行时从 pendulum 资源加载的二进制文件是可以在模块窗口中看到的cruiser.dll。此二进制文件经过 gzip 解压缩并使用 Activator 类加载。

• 此二进制文件包含一些名为“CausalitySource 和 SearchResult”的方法，这些方法对另一个也将在运行时加载的第三个资源执行某种解密。

• 最后一个已解密并加载的资源称为 Discompard.dll。

• 在 ParsingState 的方法中，可以看出正在调用此程序集中的方法来进一步执行恶意软件。

• 我们还可以在局部变量中看到从此程序集中调用的类和方法的名称。使用此信息，我们可以在 Discompard.dll 方法中设置另一个断点，并继续调试第三个资源。

• 同样，我们可以探索第三个二进制文件，并在它尝试调用的函数上设置断点。

我们现在已经输入了上一个dll调用的方法。这个二进制文件被随机变量和类名高度混淆。通常，我所做的是检查像 de4dot 或其他工具这样的反混淆器是否能够对这样的二进制文件进行反混淆。如果可能的话，我会修补资源，然后使用反混淆版本继续调试。但在这种情况下，这是非常棘手的，因为这个资源依赖于另外两个首先被调用的二进制文件，修补所有这些文件将是一件令人头疼的事情。因此，我决定继续使用混淆版本，看看我是否能从局部变量和返回值中理解它在做什么。

• 我不停地跨过并检查变量和函数返回。

• 它跳过了大部分标志，但后来我单步执行了一个函数，返回值显示已返回另一个二进制文件。在数组中可以看到 MZ 字节 （4D 5A）。

• 它确认此恶意软件可能会执行某种注入或将二进制文件转储到文件中，并将其作为第二阶段恶意软件执行。

• 我进入了一个被混淆的函数，但它看起来像是在执行进程空心化，因为恶意软件以挂起状态打开自身并准备注入该进程的地址空间。

• 在检查进程的 RWX 内存区域时单步执行了一些功能

• 在某一时刻，它保留了内存，然后开始将 shellcode 以块的形式写入该内存中

• 它将基础映像的执行更改为注入的 shellcode，最后使用 ResumeThread API 恢复该过程。

• 这就是工艺挖空的确切行为。

• 我转储了这个 shellcode 以单独分析恶意软件作为第二阶段有效负载。

• stage2 恶意软件是真正的 xloader 有效负载。

第 2 阶段：Xloader 4.3

Xloader 是一种信息窃取恶意软件，是 Formbook 恶意软件的更新版本。它以低廉的价格在暗网上出售，采用 MaaS 架构（恶意软件即服务）。该恶意软件的作者在添加最新的防御规避技术方面付出了巨大的努力。

• Xloader 又名 Formbook 是用纯本机汇编编写的，结合了 c 语言

• 熵非常高，这表明存在嵌入式代码或可能被打包

• 在此有效负载中找到 0 个库、导入和字符串

• 除 DOS 消息外，没有有效的字符串

• 恶意软件的启动相当简单，它会在进入恶意代码之前加载一些必要的库

• 它还执行一些其他类型的计算，可能会解压缩一些恶意代码

• 计算后，我遇到了对 edx 的调用，这导致了一个无法识别的代码

• “call edx”指令将程序流移动到一组本机程序集，IDA 目前无法识别该程序集

• 这意味着，IDA 无法理解 edx 寄存器现在指向的代码，这表明它最初可能被加密

• 从那里开始执行真正的表单有效负载

• IDA 在运行时解析此程序集块，以继续调试此转储。

• 这是 xloader 有效负载中添加的众多反分析技术之一。

在浏览了新解析的代码块后，我的程序没有执行任何其他操作就退出了。我知道这个恶意软件涉及反分析技术。因此，我的战斗从击败下一节中提供的反分析技术开始。

去掉检测：

采取#1：FAILED

• 在第一次拍摄中，我只是更改了跳转条件，以转移程序退出恶意软件以继续实际的程序流

• 将零标志从 1 更改为 0，这适当地设置条件以允许程序继续

• 它继续程序，但是在单步执行一些函数后立即通过异常。

• 此补丁将不起作用

• 恶意软件取决于此标志在某处设置的值

采取#2：FAILED

配置对象：

• Xloader 有效负载初始化一个配置对象，它的大部分执行流都基于该对象

• 配置 obj 使用 FFFFFFFF 值初始化，之后每个函数都为它做出贡献。

• 一些加密值被推送到此配置对象上。

• 第一个函数，保存大量加密字符串或哈希码。这些目的将在稍后的执行中明确

• 在 FF 值旁边，保存执行恶意软件的基址

• 在第三行存储另一个地址，该地址实际上是来自ntdll的LdrLoadDll函数的地址。这将用于存储更多的图书馆

• 我跨过了每个功能，并并排监视内存的变化。

• 每个函数都有助于 conf obj。

• 下面屏幕截图中的函数在内存中加载一个干净的 ntdll，并将其地址保存在 conf obj 上

• 此外，它还在 anti-vm 标志中设置值，该值从 conf obj 的第 45 个元素开始。

• 内存中注入的ntdll的地址从0x1950000开始，同样，在第24个元素之后的4个字节中，我们保存了注入的ntdll的地址。

• 标志值 1 也在反 vm 标志中设置。

• 继续执行。

• 它检查其他反 VM 检查

• 例如拍摄正在运行的进程的快照，并过滤掉恶意软件是否列出了这些进程中的任何一个

• 在屏幕截图中，我们可以看到它在正在运行的进程中检测到了 procmon

• 执行一些反 vm 检查后，它更新了反分析字节上的标志，如下面的屏幕截图所示：

• 最后一个函数是将反 vm 标志与它所需的进度顺序相匹配。

• 从屏幕截图中可以看出，我的序列与应有的序列不匹配，

• 这意味着恶意软件已检测到调试器或 procmon 等工具或其他参数

• 因此，程序将退出。

• 因此，在击败反逆向工程或反 vm 技术的 #2 中，我只是将内存中这些标志的序列修补为所需的序列。

• 修补内存并进入执行应该可以工作，因为这些标志在程序的前面的某个地方被使用。因此，简单地更改条件跳转总是会使程序崩溃。

• 但是，在内存修补的情况下，这些值将在程序中继续存在，并且应修复此问题。

• 修补了内存，现在它又回到了正确的状态

• 但是，这里有些不对劲。

• 因为被搜索的dll的名称非常奇怪。

• 现在我明白了，这些字节序列在解密算法中被用于解密库和 API 的名称。

• 但是由于我修补了内存中的字节，它应该能够准确地解密，但事实并非如此。这意味着在执行反分析检查之前，该序列在其他地方使用。

• 我让恶意软件继续存在，它再次崩溃，因为它无法解密其配置，因此无法查找加密的 dll 名称。

• 这意味着，我可能会错过一些重要的功能，并且因为它正在检测调试器，所以它会跳过一些重要的功能。

采取#3：通过

• 在第三次拍摄中，我调试了很多代码，最后，找到了由于未满足单个标志条件而跳过程序的函数。

• 因此，我更改了 condition 的值以允许它执行，并更改了被推送到 conf obj 的寄存器的值。

• 在我的环境中，总是有 3 个标志被更改。第三个元素的值为 0，但应为 1，两个元素位于第 11,12 位。

• 我也知道这两个是因为 procmon 和其他此类分析工具而改变的。因此，只需更改 procmon 的名称并继续会更容易。

• 我没有应用内存补丁，而是在运行时更改了值，然后将它们推送到内存堆栈上，瞧，恶意软件完美执行，没有任何例外。

• 现在这一次，我跨过了加载库的函数，而不是加密名称，库的全名已被看到并成功加载，如在 procmon 中看到的那样。

• 我让程序在没有任何其他交互的情况下继续，调试器退出时状态代码为 0，这意味着现在没有异常。

• 但是，它仍然没有执行所有功能，这表明未来还有更多的反分析技术。

我找到了一个非常好的资源，它解释了以前的表单版本在其分析中寻找的所有标志。幸运的是，在最新的 xloader 中，它仍然使用类似的方法，我们可以很容易地映射这些标志。下滑显示了 xloader 在其配置中使用的所有反分析标志。

编号： https://www.botconf.eu/botconf-presentation-or-article/in-depth-formbook-malware-analysis/

解密/反混淆例程：

Xloader 严重依赖加密和混淆来避免被 EDR 解决方案检测到。对其代码执行多层加密。API 都是哈希值，字符串和库也是哈希值。甚至哈希值也在 conf obj 中加密。xloader 的核心功能都是在反分析检查清除后，在运行时进行加密和解密的。

解密库名称：

• 解密例程启动，在清除反 vm 检查后，我逐步执行了下一个函数，看起来反 vm 标志字节被用作解密种子值。

• 库名称正在逐个解密。

• 然后，本机函数 LdrLoadDll 加载这些库

解密 API 名称：

• 一些正在解密的 API 表明它正在寻找进一步的进程注入

• 1. LookupPrivilegeValueW

• 2. SeDebugPrivilege

• 3. AdjustPrivilegeToken

计算字符串哈希：

• 有一种用于字符串、API 等的哈希算法。

• 它加载所有字符串哈希并将正在运行的进程与每个哈希值进行比较，如果发现任何此类进程，它会在 conf obj 的 anti-vm 标志上添加所需的值。

• 在下面的屏幕截图中，它正在检查进程名称哈希值以及它存储的预定义哈希集的值。

• 它所比较的哈希值是 23 E0 C7 CD，十六进制为 （0xCDC7E023）。

• 我通过计算 procmon 的哈希值检查了 32 位哈希算法，并找到了它使用的哈希算法。

• 它对其字符串使用 CRC-32/BZIP2 哈希

下面列出了它检查的所有哈希值：

计算 API 哈希：

• 与strings hashes相似

• 从注入的 ntdll 加载的 API 也由哈希而不是名称调用

• 这种方法使得检测变得非常困难，即使手动分析恶意软件也是如此。

• 恶意软件逐个加载 ntdll 的所有导出，并计算这些 API 的 CRC-32/BZIP2 哈希值，然后将其与解密的哈希值进行比较。

• 如果找到匹配项，则它会检索地址并调用函数，从而绕过所有 API 挂钩。

• 我写了一个小脚本来做同样的事情，我提供哈希值，它在常用字符串、api、路径等列表中搜索，计算它们的哈希值，然后与提供的哈希值进行比较，以检查是否找到了匹配项。

• 在本例中，哈希值在 NtResumeThread API 调用上匹配，因此恶意软件将退出循环并继续检索地址，然后调用 api。

• 它手动搜索所需 API 的地址并调用它，这样调试器也无法检测到正在调用哪个 API。

• 在下面的屏幕截图中，我在 IDA 中打开了带有符号的同一 dll 的另一个实例，我们可以看到推送到 eax 寄存器上的十六进制值是相同的。

• 我知道哈希函数，所以我没有单步执行这个循环中数百个函数的本机程序集，而是通过编写 IDA python 脚本并一次又一次地继续查看解密的 API 来设置该函数的断点

• 我找到的 API 列表如下：

解密核心恶意函数：

• 恶意软件在运行时解密其核心功能，然后跳转到这些功能，继续执行流程。

• Xloader 通过push  ebp 和 mov ebp、esp 和其他启动指令来设置函数，但在这些指令之下，所有字节都被加密。

• 在以前的表单版本中，核心恶意函数可以通过48909090、49909090等的魔术字节来识别。

• 但是，在最新的 xloader 4.3 中，这些起始字节是随机的。

• 在反 vm 检查并建立 RC4 解密密钥后。这些函数在运行时被解密，执行流跳转到解密的程序集。

• IDA 解析解密的字节并重新创建汇编指令以继续。

了解解密这些加密和混淆技术的详细技术方法。zscaler 的以下博客是一个很好的资源。

Xloader 4.3 版本代码混淆的技术分析

分析 Xloader 信息窃取恶意软件的新变种，该恶意软件将自己标识为 4.3 版，发布于 ...

www.zscaler.com

https://www.zscaler.com/blogs/security-research/technical-analysis-xloader-s-code-obfuscation-version-4-3

部分解密的 shellcode：

• 单步执行了一些函数，看起来它读取了自己，并且很可能试图在其他进程中注入自己

• 该恶意软件现在正准备进一步注入另一个二进制文件。从我在内存中找到的转储的屏幕截图中可以看出

• 这个内存转储本身就是 RWX 内存区域，从进程检测工具中中可以看出

• 我在监控内存区域时跳过了一些功能。

• 恶意软件正在从二进制文件中解密 shellcode

• 只剩下普通的 shellcode 而没有 MZ 标头

• 这是部分解密的第三阶段 xloader

• 我从内存中转储了二进制文件，并对其运行了 FLOSS 字符串搜索，这提供了一些有用的见解

进程枚举：

• XLoader 使用 NtQuerySystemInformation 获取系统中所有正在运行的进程的信息，然后逐个枚举哈希值，并将其与存储在 conf obj 中的自己的哈希值进行匹配。

进程注入：

Xloader 注入概述：

Xloader stage2 执行两个过程注入：

• 注入#1：在随机运行的进程中启动处于挂起状态的 win32 受害者进程

• 注入#2：将自身迁移到 win32 挂起的进程中并恢复

注射#1

• 在具有 RWX 内存区域的恶意软件中保留了另一个内存。

• 我已经转储了这个新区域并提取了字符串

• 它有一个静态字符串，其中包含目标进程的名称

• 这意味着此 shellcode 用于启动进程chkdsk.exe该进程在每次执行时都是随机的。

• Xloader 从 SysWOW64 目录中选择这些二进制文件，这些二进制文件是 32 位进程

• 它将此 shellcode 注入到上面枚举的运行进程之一中，在我的情况下，它是我与调试器一起打开的 64 位 IDA。

• 这也是 xloader 使用的反分析技术之一。它不会直接打开进程本身，而是在某个随机进程中注入 shellcode，这反过来又在挂起状态下打开 SysWOW64 随机二进制文件，然后检索其进程信息并继续执行。

• 在 Ida64 中，注入 shellcode 以启动进程并将进程信息返回给 xloader 的 stage2 恶意软件。

• RWX 内存区域可以在 IDA64 中看到。

• 这只是在挂起状态下打开目标进程后的死代码。

注射#2：

• 第二次进样在chkdsk.exe（随机 SysWOW64 二进制）中进行

• chkdsk.exe中注入了两个缓冲液。

• 1 个 180KB 缓冲区和其他 40KB 缓冲区

• 由于该恶意软件正在执行如此多的注入，因此很难跟踪所有内容，因此我们想到了创建一个用于检测过程注入的工具。

• 我要特别感谢 Osama Ellahi 在短时间内创建了这个工具，该工具在检测此类恶意软件的注入方面非常有用。

• 较小的缓冲区包含原始的 chkdsk.exe 字节。

• 我还找到了在 180KB 空缓冲区中写入 shellcode 的函数。

• 这也是表单有效负载和chkdsk.exe的受害者进程之间的共享内存区域

• 因为缓冲区在两个进程中同时写入。

• 在 xloader 有效负载中，内存区域也同时写入

• 这与我上面显示的部分解密的 shellcode 相同，其中包含大多数解密的字符串。

• 从这里开始，将执行表格手册的第 3 阶段。

• 最后，在 chkdsk.exe 年恢复暂停的进程后

• 它使用 ExitProcess API 退出

第 3 阶段：部分解密的 Xloader 4.3

在注入进程上恢复线程之前。我已将 x32dbg 附加到受害者进程以继续进一步调试。在 EAX 寄存器中，xloader 注入代码的地址已由 stage2 恶意软件设置。所以，我只是跳到反汇编中的地址，并在其上添加了断点。然后从 stage2 恶意软件开始，我允许恶意软件继续，从而恢复 stage3 上的线程。Stage2 恶意软件已退出，我们将调试器附加到 stage3 恶意软件的入口点，我将从这里继续。整个执行流程与 stage2 恶意软件非常相似。因此，我将只在本节中介绍关键细节：

去掉检测：

• Xloader 已经解密了它的一些功能，现在迁移到进程msiexec.exe（在前面的示例中chkdsk.exe）

• 在恢复线程之前，我已将调试器附加到注入的进程，并从那里继续我的分析。

• 这是首先重复的相同循环。

• 我必须再次打败反分析技术

• 与 stage2 类似，我再次绕过了反分析技术，并生成了正确的字节序列，如下所示

解密/反混淆：

• 此注入的 stage3 有效负载执行相同的初始步骤。

• 它执行反 VM 技术和检查

• 解密进一步的库名称并使用 LdrLoadDll 加载

• 解密 API 名称并匹配哈希值。最后，从注入的 ntdll 新副本加载这些 API

• 解析了用于进程注入的一些 API：

• 1. LookupPrivilegeValue

• 2. SeDebugPrivilege

• 3. NtAdjustPrivilegeToken

指标移除：

• 它将使用以下 API 序列删除 stage2 恶意软件

• 1. NtCreateFile

• 2. NtQueryInformationFile

• 3. NtReadFile

• 4. NtClose

• 5. ZwDeleteFile

工艺注入：

• 正在使用的下一系列 API 包括：

• 1. NtCreateSection

• 2. NtMapViewOfSection

• 3. NtAllocateVirtualMemory

• 4. NtOpenProcessToken

• 5. NtQueryInformationToken

• 6. ConvertSidToStringW

• 7. NtAllocateVirtualMemory

• 它正在准备另一个 shellcode 以在某个过程中进一步注入。在受感染进程的内存中还创建了几个 RWX 部分

系统信息发现：

• 它从注册表中检索系统信息，例如操作系统的“产品名称”、“CurrentBuild”等

• 1. NtCreateKey

• 2. NtQueryValueKey

动态库/API 解析：

• 使用 LdrLoadDll 加载库wininet.dll

进程枚举和注入：

• 看起来下一次注射将在“explorer.exe”中。

• 它通过循环遍历“NtQuerySystemInformation”返回的进程列表来枚举所有进程

• 2. NtCreateMutant

• 3. NtCreateSection

• 4. NtMapViewOfSection

• 5. NtDelayExecution

• 6. NtAllocateVirtualMemory

机器人注册：

• 它在第一个请求中收集和发送的数据如下：

• 神奇的词：XLNG

• 机器人ID：202293EF

• Xloader 版本：4.3

• 操作系统：Windows 10 Enterprise x64

• 用户名：base64_encoded

Stealer：

• Xloader 是一个信息窃取器和表单抓取器。

• 注册设备后，它会查找可能从受害者那里窃取的所有东西

• 有大量的电子邮件客户端、浏览器、ftp 客户端、消息传递应用程序，它试图在不同的路径中寻找来获取和窃取数据

• 如果它发现任何东西，它就会尝试窃取该数据

• Like in case of chrome, it founds login data and it will fetch the data using sqlite3 queries

• It uses winsqlite3.dll to extract passwords

• The query is “SELECT origin_url, username_value, password_value FROM logins”

• 它使用 crypt32 解密该数据。CryptUnprotectedData 来自在本地状态中找到的密钥

• 如果找到任何内容，它会在临时文件夹中创建一个静态名称为“3r9Pk-75”的文件

• 如果文件已存在，则首先删除前一个文件，然后使用更新的日期写入新文件。

• 按以下 API 序列读取文件

• 1. NtCreateFile

• 2. NtQueryInformationFile

• 3. NtReadFile

• 4. NtWriteFile

解密函数：

• 由于加密功能，许多数据一开始是隐藏的

• 与 stage2 恶意软件类似，stage3 版本也具有加密功能

• 这些是在运行时解密的

• 这些函数还包含用于目标进程的基于十六进制的加密字符串

• 目标应用程序和路径的字符串在运行时被推送到堆栈上。

权限提升：

• 通过滥用 dllhost.exe 和 COM 对象来提升权限

• 它一直尝试在 Program Files 中复制 stage2 恶意软件

• 如果未提供适当的权限，则它会使用资源管理器在临时中编写 stage2 恶意软件，并通过滥用 dllhost 将恶意软件复制到 Program Files

权限维持：

• 将恶意软件复制到 Program Files 中后

• 它通过添加运行注册表项来实现持久性

• 它使用 API NtCreateKey

设置内联钩子：

• Xloader 还可以用作表单抓取器

• 它在目标进程中设置内联钩子，以从函数的参数中窃取明文数据

• 从受害者进程中窃取的数据保存在 3 个进程之间的共享内存中

• 1. Victim Process

• 2. Stage3 Malware

• 3. Explorer

  xloader 在这里陷入了循环，在每个循环中，它执行以下操作：

• 1. 枚举所有正在运行的进程

• 2. 如果发现，在目标进程中设置内联钩子（通过注入代码）

• 3.窃取剪贴板数据

• 4. 尝试在程序文件中创建文件

• 5. 在 RunKeys 中添加注册表

• 6. 通过explorer.exe在已解析的 c2 服务器之一上发送 POST & GET 请求。 它在explorer.exe中注入了有效载荷，用于泄露被盗数据。

引用：

• https://www.fortinet.com/blog/threat-research/deep-analysis-formbook-new-variant-delivered-phishing-campaign-part-ii

• https://www.zscaler.com/blogs/security-research/technical-analysis-xloader-s-code-obfuscation-version-4-3

• https://www.zscaler.com/blogs/security-research/analysis-xloader-s-c2-network-encryption

• https://www.botconf.eu/botconf-presentation-or-article/in-depth-formbook-malware-analysis/

• 二进制漏洞课程(更新中)

• windows网络安全防火墙与虚拟网卡（更新完成）

• windows文件过滤(更新完成)

• USB过滤(更新完成)

• 游戏安全(更新中)

• ios逆向

• windbg

• 还有很多免费教程(限学员)

• 更多详细内容添加作者微信