Carregamento por proxy

No post Return Address Spoofing, mostrei um método simples para contornar a regra do Elastic ao carregar uma DLL a partir de memória unbacked. Porém, ao analisarmos a stack completa, ainda era possível detectar ação maliciosa devido aos frames de memória que continuavam lá.

As informações que você encontrar neste post, técnicas, códigos, provas de conceito ou qualquer outra coisa são estritamente para fins educacionais.

Neste post, apresento um método alternativo descrito originalmente pelo Paranoid Ninja no artigo Hiding In Plain Sight. O método elimina completamente qualquer traço de unbacked na call stack ao carregar DLLs.

---

O Problema dos Callbacks Tradicionais

Funções de callback no Windows são ponteiros para funções que podem ser passados para outras funções para serem executadas dentro delas. A Microsoft oferece dezenas de callbacks para desenvolvedores (lista aqui).

Porém, como o Paranoid Ninja mencionou, todos esses callbacks compartilham um problema principal: quando um callback é executado, ele roda dentro da mesma thread que o chamou.

Isso nos leva exatamente ao dilema que mencionamos anteriormente:

LoadLibrary retorna para -> Função de Callback retorna para -> região RX/Unbacked

Para obter uma pilha "limpa", precisamos garantir que o nosso LoadLibrary seja executado em uma thread separada, independente da nossa região unbacked. Se formos utilizar callbacks, precisamos que eles consigam passar corretamente os parâmetros necessários para LoadLibraryA.

O problema é que a maioria dos callbacks no Windows ou não possui parâmetros, ou não repassa os parâmetros "como estão" para nossa função alvo LoadLibrary.

---

Thread Pool do Windows

O Paranoid Ninja escolheu usar três APIs do Windows para realizar essa operação:

• TpAllocWork - Aloca um work item

• TpPostWork - Enfileira o work item para execução

• TpReleaseWork - Libera recursos

---

Preparando o Código C++

Primeiro, vamos preparar as estruturas necessárias no nosso código:

#include <windows.h>
#include <stdio.h>

typedef VOID(NTAPI* TPALLOCWORK)(PTP_WORK*, PTP_WORK_CALLBACK, PVOID, PTP_CALLBACK_ENVIRON);
typedef VOID(NTAPI* TPPOSTWORK)(PTP_WORK);
typedef VOID(NTAPI* TPRELEASEWORK)(PTP_WORK);

Criamos typedefs para as funções do Thread Pool. Isso é necessário porque vamos chamar essas funções via GetProcAddress, então precisamos definir o tipo correto dos ponteiros.

Agora vamos criar uma variável global:

FARPROC g_pLoadLibraryA;

Por que global? Porque nosso código assembly vai precisar acessar o endereço de LoadLibraryA. Variáveis globais são compartilhadas entre C++ e assembly.

Mas o assembly não pode acessar a variável global diretamente de forma conveniente. Então criamos uma função auxiliar:

extern "C" UINT_PTR getLoadLibraryA() {
    return (UINT_PTR)g_pLoadLibraryA;
}

O assembly vai chamar essa função para obter o endereço armazenado em g_pLoadLibraryA.

Também precisamos declarar nosso callback que será implementado em assembly:

extern "C" VOID CALLBACK WorkCallback(PTP_CALLBACK_INSTANCE, PVOID, PTP_WORK);

O extern "C" desativa o name mangling do C++, permitindo que o linker encontre a função pelo nome exato.

---

Implementando a Função Principal

Agora vamos criar a função que carrega a DLL:

HMODULE LoadLibraryViaCallback(const char* libName) {
    // Pega os handles dos módulos
    HMODULE hKernel32 = GetModuleHandleA("kernel32");
    HMODULE hNtdll = GetModuleHandleA("ntdll");

Começamos obtendo os handles de kernel32 e ntdll, que é onde estão as funções que precisamos.

// Obtém os endereços das funções
    g_pLoadLibraryA = GetProcAddress(hKernel32, "LoadLibraryA");
    FARPROC pTpAllocWork = GetProcAddress(hNtdll, "TpAllocWork");
    FARPROC pTpPostWork = GetProcAddress(hNtdll, "TpPostWork");
    FARPROC pTpReleaseWork = GetProcAddress(hNtdll, "TpReleaseWork");

Usamos GetProcAddress para obter os endereços das funções. Note que g_pLoadLibraryA é a variável global que o assembly vai acessar via getLoadLibraryA().

// Aloca o work item
    PTP_WORK WorkReturn = NULL;
    ((TPALLOCWORK)pTpAllocWork)(
        &WorkReturn,
        WorkCallback,      // nosso callback em ASM
        (PVOID)libName,    // será passado como Context
        NULL
    );

Aqui está a parte mais importante:

• &WorkReturn - Ponteiro que receberá o work item alocado

• WorkCallback - Nossa função callback implementada em assembly

• (PVOID)libName - O nome da DLL que queremos carregar

O libName será repassado como segundo argumento (Context) quando o Thread Pool chamar nosso WorkCallback.

// Enfileira para execução
    ((TPPOSTWORK)pTpPostWork)(WorkReturn);
    ((TPRELEASEWORK)pTpReleaseWork)(WorkReturn);

TpReleaseWork libera os recursos associados ao work item. Note que isso não cancela a execução se ela já foi enfileirada.

Sleep(2000);

Aguardamos 2 segundos para dar tempo do Thread Pool executar nosso callback.

return GetModuleHandleA(libName);
}

Por fim, retornamos o handle da DLL carregada. Se a DLL foi carregada com sucesso, GetModuleHandleA retornará seu handle. Se falhou, retorna NULL.

---

O Código Assembly

Agora vamos para a parte crucial: o callback em assembly que manipula a stack.

.code

; Declaração externa da função C++
EXTERN getLoadLibraryA:PROC

; Exporta o callback
PUBLIC WorkCallback

Começamos declarando que getLoadLibraryA é uma função externa (definida no C++) e que WorkCallback será exportado (acessível pelo C++).

WorkCallback PROC

Iniciamos a definição da função. Lembrando que a assinatura esperada é:

VOID CALLBACK WorkCallback(
    PTP_CALLBACK_INSTANCE Instance,  // RCX
    PVOID Context,                   // RDX
    PTP_WORK Work                    // R8
);

Quando o Thread Pool chama nosso callback, os registradores estão assim:

• RCX = Ponteiro para PTP_CALLBACK_INSTANCE (estrutura interna do Thread Pool)

• RDX = Nosso Context (o libName que passamos)

• R8 = Ponteiro para PTP_WORK (o work item)

; Move Context (nome da DLL) para RCX
    mov rcx, rdx

LoadLibraryA espera o nome da DLL no primeiro argumento (RCX). Mas o Thread Pool colocou em RDX (segundo argumento). Então movemos RDX → RCX.

Após essa instrução:

• RCX = nome da DLL (nosso argumento desejado)

• RDX = ainda contém o nome da DLL (lixo)

; Limpa RDX (LoadLibraryA só tem 1 argumento)
    xor rdx, rdx

LoadLibraryA espera apenas 1 argumento. Limpamos RDX por limpar, não precisa se não quiser.

; Chama função C++ pra pegar endereço de LoadLibraryA
    call getLoadLibraryA

Chamamos a função que retorna g_pLoadLibraryA. O resultado vem em RAX (convenção x64 para valores de retorno).

Após essa instrução:

• RAX = endereço de LoadLibraryA

• RCX = nome da DLL (preparado)

; JMP (não CALL!) pra LoadLibraryA
    jmp rax

AQUI ESTÁ O TRUQUE! Usamos JMP, não CALL.

WorkCallback ENDP
END

Finalizamos a definição da função.

---

Função Main

Agora vamos juntar tudo:

int main() {
    printf("[*] Carregando wininet.dll via Thread Pool...\n");
    
    HMODULE hWininet = LoadLibraryViaCallback("wininet.dll");
    printf("[+] wininet.dll carregada em: 0x%p\n", hWininet);

    getchar();
    return 0;
}

Simples e direto. Chamamos nossa função que cuida de tudo internamente.

Existem outras formas de aplicar o método do Paranoid Ninja, e algumas delas não sujam a stack. Isso ocorre porque, nessas variantes, o threadpool chama o callback diretamente, sem um CALL vindo do nosso código em RX, então nenhum retorno para a região RX é empilhado.

---

Resultado

Aplicando o método do Paranoid Ninja, obtemos o seguinte resultado:

0:004> k
 # Child-SP          RetAddr               Call Site
00 000000a1`415ff6f8 00007ff9`76393720     KERNELBASE!LoadLibraryA
01 000000a1`415ff700 00007ff9`7637d79a     ntdll!TppWorkpExecuteCallback+0x130
02 000000a1`415ff750 00007ff9`74d37374     ntdll!TppWorkerThread+0x68a
03 000000a1`415ffa50 00007ff9`7637cc91     KERNEL32!BaseThreadInitThunk+0x14
04 000000a1`415ffa80 00000000`00000000     ntdll!RtlUserThreadStart+0x21