Frenchy shellcode分析-安全客

在这篇文章中，我分析了一个名为“Frenchy shellcode”的shellcode，因为它创建了互斥锁（其中一些版本有互斥锁）。这个shellcode通过不同的packers加载了不同种类的恶意软件。因此，我决定研究一下这个shellcode并在这里分享我的详细分析。另外，我分享一个PoC，一个用于加载Frenchy shellcode的python脚本，使用它可以通过Hollow Process注入，替换notepad.exe实际执行的可执行部分，最终调用执行calc.exe。

我分析的大多数样本都装有一个基于AutoIt的packers解密并加载shellcode。Frenchy shellcode的第一个样本是Emotet，而packers是基于AutoIt的，我建议阅读这个twitter帖子(https://twitter.com/P3pperP0tts/status/1135976656751996928?s=20) 。过了一段时间，有另一名安全研究员分析了加载Frenchy shellcode的混淆自动脚本的变体。这个变体加载了Formbook Stealer。之后，在我的研究中，我通过在Cape Sandbox中搜索字符串“frenchy_shellcode_003” 发现了另一个样本，而该样本的packers是基于.Net的。

1 Packers

在本文的研究中，我不会过多的分析Frenchy shellcode的不同的packers，只会稍微提一下相应的注意事项。

1.1 基于AutoIt的Packer

这个packer执行一个高度混淆的自动脚本，解密并加载Frenchy shellcode。以下是这些脚本的几个例子：

frenchy_shellcode_01： https://pastebin.com/raw/xsUqCdRj
frenchy_shellcode_002： https://pastebin.com/raw/Knk2iJPF

我推荐阅读这篇关于加载Frenchy shellcode的AutoIt脚本的帖子。(https://tccontre.blogspot.com/2019/07/autoit-compiled-formbook-malware.html)

1.2 基于.Net的Packer

对于样本 21c1d45977877018568e8073c3Acf7c5，它的packer是.Net。要检查.Net packer 否正在加载Frenchy shellcode，我们在CreateMutexW上设置了一个bp，我们等待其创建frenchy_shellcode_03互斥锁：

现在我们知道当前线程正在执行Frenchy shellcode，所以我们显示调用堆栈来检查调用Frenchy shellcode的线程是否来自.Net：

2 Frenchy Shellcode

2.1 Frenchy Shellcode V3

我把重点放在了我从样本 21c1d45977877018568e8073c3Acf7c5 获得的v3 shellcode上（可以从这里下载https://www.hybrid-analysis.com/sample/0c9da7a0e3d3b2a6345bf69a22f577855f476d645cb71cd8a18123787e75a75a/ ）。

这个shellcode的主要目的是通过使用Hollow Process注入方法将PE注入新进程。

2.1.1 EP和参数

Shellcode的入口点位于偏移0处，shellcode跳转到main函数：

shellcode的第一个参数是用于被注入hollow进程的应用程序exe的路径，第二个参数是要注入的内容（PE）

2.1.2 重复的系统库

shellcode加载每一个它要使用的系统库：

如果我们枚举地址空间的区域，我们可以检查其中是否有一些重复的dll：

该操作可能会使shellcode更难调试， API钩子将不起作用（例如由cuckoo框架插入的钩子）。如果在通常由恶意软件（CreateProcessW，WriteProcessMemory，SetThreadContext等等）执行的公共API上设置断点以捕获此时的恶意软件执行，则它将无法工作，因为你需要在重复的位置设置断点dll文件。

2.1.3 使用的API

shellcode获取指向许多API的指针，但它只使用它们的一个子集。我觉得这是一个可以高度自定义的shellcode，它总是加载所有的API指针，但根据配置和它添加到shellcode的特定版本的代码，将使用一些API指针，其他指针不会使用。

以下是shellcode加载的API的完整列表：

BeginPaint
CoCreateInstance
CoInitializeEx
CreateMutexW
CreateProcessW
CreateWindowExW
CryptAcquireContextW
CryptCreateHash
CryptDecrypt
CryptDeriveKey
CryptDestroyHash
CryptDestroyKey
CryptHashData
CryptReleaseContext
DefWindowProcW
EndPaint
ExpandEnvironmentStringsW
FillRect
FindResourceW
FreeResource
GetModuleFileNameA
GetProcAddress_
GetSystemInfo
IsWow64Process
LdrGetProcedureAddress
LdrLoadDll
LoadLibraryA
LoadResource
LockResource
MessageBoxA
NtAdjustPrivilegesToken
NtAllocateVirtualMemory
NtClose
NtContinue
NtCreateFile
NtCreateMutant
NtCreateSection
NtCreateThreadEx
NtCreateUserProcess
NtDelayExecution
NtEnumerateKey
NtFreeVirtualMemory
NtGetContextThread
NtMapViewOfSection
NtOpenFile
NtOpenKey
NtOpenMutant
NtOpenProcess
NtOpenSection
NtProtectVirtualMemory
NtQueryInformationFile
NtQueryInformationProcess
NtQuerySection
NtQuerySystemInformation
NtQueryValueKey
NtReadFile
NtReadVirtualMemory
NtResumeThread
NtSetContextThread
NtSetValueKey
NtTerminateProcess
NtWriteFile
NtWriteVirtualMemory
PostQuitMessage
RegisterClassW
RtlCreateProcessParameters
RtlCreateUserProcess
RtlCreateUserThread
RtlFormatCurrentUserKeyPath
RtlSetCurrentTransaction
RtlZeroMemory
ShowWindow
SizeofResource
TerminateProcess
ZwCreateTransaction
ZwRollbackTransaction
ZwUnmapViewOfSection
lstrlenW
mbstowcs
memcpy
memset
strlen
wcscat
wcscmp
wcscpy
wcslen
wcstombs

有时shellcode会获取指向最初加载的dll上的API的指针。例如，样本中的cryptoapi库，如下图所示。我想这是因为当通过dll的辅助副本调用它们时它们不能正常工作。

2.1.4 Process Hollowing

恶意软件根据给定的路径参数创建新的挂起进程（路径为给定的可执行文件），然后使用Hollow Process注入方法将给定的PE注入该进程的地址空间，替换其实际执行的可执行部分，它使用一组本机API来执行此操作。

在下图中，我们可以看到恶意软件如何创建新进程并取消进程与其自身主模块的映射。此外，它通过调用NtCreateSection + NtMapViewOfSection来映射要注入的PE（以获取此PE的映射副本）：

一旦取消进程与其自身主模块的映射后，我们可以进行Hollow Process注入，获得要注入的PE的映射视图后，它就会在目标进程地址空间中创建一个新部分，以复制要在其中注入的PE。它将使用NtCreateSection + NtMapViewOfSection + NtWriteProcessMemory来执行此操作：

最后，它更改注入进程的主线程的上下文（即修改该进程的实际执行部分代码），以设置EIP =注入代码的起始地址，并恢复线程，到此注入成功。

2.2 应用Frenchy Shellcode

说实话，我认为这个shellcode写得很好，它运行正常。我决定写一个小的PoC，一个加载并调用它的python脚本，将notepad.exe作为被hollow注入进程，calc.exe的内容作为被注入的内容，完成操作后，我们将可以看到执行notepad.exe实际出来的应用程序却是计算器。

在这里你可以找到PoC和Frenchy shellcode v3：

https://github.com/p3pperp0tts/PoC_FrenchyShellcode

from ctypes import *
import struct

f = open("frenchyshellcode.bin", "rb")
frenchy = f.read()
f.close()
f = open("c:\windows\system32\calc.exe", "rb")
calc = f.read()
f.close()
hollowpath = "c:\windows\notepad.exex00"
#to test, full shellcode = frenchy + arguments for frenchy + code to jmp
lenshellcode = len(frenchy) + len(calc) + len(hollowpath) + len("x68x00x00x00x00x68x78x56x34x12x68x78x56x34x12x68x78x56x34x12xc3")
ptr = windll.kernel32.VirtualAlloc(None, lenshellcode, 0x3000, 0x40)
shellcode = frenchy
shellcode += calc
shellcode += hollowpath
shellcode += "x68" + struct.pack("<L", ptr + len(frenchy)) #push path to process to hollow
shellcode += "x68" + struct.pack("<L", ptr + len(frenchy)+len(calc)) #push address of pe to inject
shellcode += "x68x00x00x00x00" #fake ret addr
shellcode += "x68" + struct.pack("<L", ptr) #push address of frenchy shellcode entry point
shellcode += "xc3" #jmp to frenchy
hproc = windll.kernel32.OpenProcess(0x1F0FFF,False,windll.kernel32.GetCurrentProcessId())
windll.kernel32.WriteProcessMemory(hproc, ptr, shellcode, len(shellcode), byref(c_int(0)))
windll.kernel32.CreateThread(0,0,ptr+len(frenchy)+len(calc)+len(hollowpath),0,0,0)
windll.kernel32.WaitForSingleObject(c_int(-1), c_int(-1))