前段时间，Github上的ShellcodeLoader被投毒
工具地址为: https://github.com/ByPassAVTeam/ShellcodeLoader
目前已经失效了，经过样本hash在各大平台上找到了这个样本
编译时间为2022.10.8
在LoaderMaker.exe的打印函数中插入了一个恶意函数，这个函数嵌套了许多层
sub_401930→sub_401910→sub_4018F0→sub_4018D0→sub_4018B0→sub_401890→sub_401870→sub_401850→sub_401830→sub_401800
全局变量dword_41B870初始化为0，调用一次打印函数就自增1，调用六次后就会执行恶意函数sub_401710，正常使用这个工具时，开头会调用六次打印函数，所以这个恶意函数一定会被执行
分析sub_401710函数
首先解密字符串，解密后的字符串为"explorer"，接着调用GetPidByProcessName函数获取explorer.exe的pid
GetPidByProcessName如下，创建进程快照，遍历进程，判断进程名从而获取PID
获取完进程PID后，开始执行sub_401290函数，该函数中首先获取kernel32.dll的基址，然后调用OpenProcess打开explorer.exe进程，接着获取VirtualAllocExA地址
判断操作系统是否为64位，如果不是64位就退出恶意函数
IsSystem64函数中调用了GetNativeSystemInfo函数获取操作系统基本信息，然后判断是否位64位操作系统
如果操作系统是64位，接着解密shellcode，在explorer.exe中分配一段可读可写可执行的内存，将shellcode写入
接下来在explorer.exe进程中创建一个远程线程执行这个shellcode即可，但是使用32位的CreateRemoteThread或NtCreateThreadEx在64位进程中创建远线程会直接失败，这时候需要使用64位的远线程函数，所以首先要从WOW64转换到64位，接着获取ntdll的NtCreateThreadEx函数地址，获取方法可以参考DLL/PIC Injection on Windows from Wow64 process | modexp (wordpress.com)
- 在x64下的进程，不管是32位或者是64位，实际上都映射了两个地址空间，一个是32位，一个是64位。相当于一个进程的两种工作模式，而且这两种工作模式是可以进行切换的
- Wow64进程中的r12寄存器指向64位的TEB结构(TEB64)
- 每个32位进程都会加重ntdll32.dll和ntdll.dll模块。其中ntdll.dll是64位模块，我们可以将进程的32位模式改为64位模式，然后再去操作64位进程
检测32位还是64位
利用REX指令前缀，0x31 0xC0 0x48 0xF7 0xD8 0xC3
; 32位
31 C0 xor eax, eax ; eax = 0, ZF = 1
48 dec eax ; eax = -1, ZF = 0
F7 D8 neg eax ; eax = 1, ZF = 0
C3 retn
; 64位
31 C0 xor eax, eax ; eax = 0, ZF = 1
48 F7 D8 neg rax ; eax = 0, ZF = 1
C3 retn
同一串硬编码, 在32位模式下ZF = 0, 在64位模式下ZF = 1, 可以通过这个差异来判断是否位WOW64
模式转换
32位转64位
首先向堆栈中依次压入0x33和返回地址，然后利用retf指令将CS寄存器修改为0x33
64位转32位
首先向堆栈中依次压入0x23和返回地址，然后利用retf指令将CS寄存器修改为0x23
切换模式之后，利用GS寄存器获取PEB，进而遍历模块，对比函数名HASH，最终获取NtCreateThreadEx地址，调用NtCreateThreadEx在explorer.exe中创建远程线程执行shellcode，之后切换为32位并返回
shellcode分析
首先获取LoadLibrary地址，加载wininet.dll
然后利用wininet.dll的库函数请求http://www2.jquery.ink:2087/maps/overlayBfpr获取恶意shellcode
申请空间存储恶意代码，最终跳转至恶意代码中执行
总结
通过分析这个样本，学会了32位程序注入64位程序的方法
[复制链接]
发表于 2022-11-3 19:41
|
发表于 2022-11-6 12:55
