项目地址

https://github.com/knight0x07/BumbleCrypt

BumbleCrypt

受Bumblebee启发的 Crypter

背景

BumbleCrypt 的灵感来自 Bumblebee 的加密器，在 Bumblebee 的情况下，主要的 Bumblebee DLL 被加载到内存中并按以下方式执行：

• 解密并写入堆中的有效载荷
• 挂钩三个 NtApi - NtOpenFile、NtCreateSection 和 NtMapViewOfSection
• 调用 LoadLibraryW("gdiplus.dll") 触发内联挂钩，因为 LoadLibrary() 使用上述三个 API 来加载任何库。
• 内联挂钩和 LoadLibrary 本身然后加载主 Bumblebee DLL 代替“gdiplus.dll”
• 最后，控制权被转移到主 Bumblebee DLL 的导出函数“SetPath”

BumbleCrypt 的工作

在分析 BumbleBee 的 crypter 时，我意识到解密的 DLL 可以通过“NtMapViewOfSection”上的一个内联挂钩加载，而不是 Bumblebee 的 Crypter 中使用的三个内联挂钩。 因此开发了“BumbleCrypt”。

BumbleCrypt：

• BumbleCrypt 首先从 .rsrc 部分加载加密资源，然后解密最终的 DLL 负载：加密 res -> Base64 解码 -> Rc4 解密 -> xor 解密
• Crypter 利用堆来存储解密的 DLL 负载，就像 Bumblebee 的加密器一样
• 一旦最终的有效负载被解密，BumbleCrypt 就会挂钩 NtApi“NtMapViewOfSection”，该映射用于将部分视图映射到虚拟地址空间。
• 然后 BumbleCrypt 调用 LoadLibraryW("msimg32.dll")。 现在让我们了解内联钩子是如何被触发的：
  • LoadLibraryW() 首先调用 NtOpenFile 来检索作为参数传递的模块句柄
  • 然后它使用 NtCreateSection 创建一个带有模块句柄的 section 对象
  • 现在，一旦创建了该部分，LoadLibrary 就会调用 NtMapViewOfSection 以将部分的视图映射到内存
  • 这里 我们在 NtMapViewOfSection 上的挂钩被触发，代理函数执行以下操作：
    • 首先解开 NtMapViewOfSection
    • 使用 NtCreateSection() 创建所需大小的部分
    • 然后使用 NtMapViewOfSection（之前未挂钩）将创建的部分的视图映射到虚拟地址空间
    • 最后手动将之前解密的final DLL映射到内存映射段的基地址，然后返回NTSTATUS_SUCCESS给LoadLibraryW，退出代理函数
  • LoadLibraryW 然后收到 NTSTATUS_SUCCESS 作为对 NtMapViewOfSection 的响应以及解密的恶意 DLL 位于内存中的内存映射部分的基地址。进一步 LoadLibrary 根据返回值加载 DLL，结果是 msimg32.dll可以在加载的模块中看到，但指向解密的有效负载。 此外，Crypter 通过执行导出函数“CallPath”将控制权转移到解密的 DLL。
• 现在，如果我们看一下 BumbleCrypt 加载模块的屏幕截图，我们可以看到它包含“msimg32.dll”，但基地址指向解密的恶意负载。

截屏

 

 

概念验证——BumbleCrypter

 

太感谢了！ 希望你喜欢它 =D 再见。

如果您有任何反馈或意见，可以在 Twitter 上与我联系

推特： https ://twitter.com/knight0x07

笔记

仅用于教育目的。 这是一个个人周末项目 =)

标签：工具分享, 主机安全