APIs comuns usadas em Malware

Reading time: 9 minutes

Genérico

Rede

TLS pinning and chunked transport

Muitos loaders encapsulam seu stream TCP em SslStream e pin the server’s leaf certificate against an embedded copy (certificate pinning). Bot info/tasks são comprimidos (por exemplo, GZip). Quando respostas excedem um limiar (~1 MB), os dados são fragmentados em pequenos chunks (por exemplo, segmentos de 16 KB) para evitar heurísticas baseadas em tamanho e reduzir picos de memória durante a desserialização.

Persistência

Criptografia

Anti-Analysis/VM

Guarda de execução baseada em locale/teclado

Muitos stealers/loaders abortam em certos locales para evadir pesquisadores e cumprir restrições de threat-actor. Verificações típicas:

• GetKeyboardLayout para enumerar layouts instalados (por thread/usuário)
• GetLocaleInfoA/W para resolver códigos de país/região
• GetSystemDefaultLangID / GetUserDefaultLangID

Se algum corresponder a uma lista bloqueada (comum em países da CIS), o loader sai imediatamente antes de IOCs de rede ou injeção.

Defesa/hunting

• Sinalizar processos que consultam múltiplas APIs de locale/teclado no início da execução e então saem sem atividade observável.
• Correlacionar com checagens anti-VM (strings do BIOS, dispositivos PnP, modelo de disco, serviços) reaproveitadas de projetos open-source (por exemplo, VMDetector) para detectar execução condicionada.

Emulator API fingerprinting & sleep evasion

Malware frequentemente fingerprinta emuladores de sandbox procurando pelas exports virtualizadas do Defender (visto no Malware Protection Emulator). Se algum desses símbolos estiver presente (scan case-insensitive do processo), a execução é atrasada por 10–30 minutos e re-verificada para desperdiçar tempo de análise.

Exemplos de nomes de API usados como canários:

• MpVmp32Entry, MpVmp32FastEnter, MpCallPreEntryPointCode, MpCallPostEntryPointCode, MpFinalize, MpReportEvent*, MpSwitchToNextThread*
• VFS_* family: VFS_Open, VFS_Read, VFS_MapViewOfFile, VFS_UnmapViewOfFile, VFS_FindFirstFile/FindNextFile, VFS_CopyFile, VFS_DeleteFile, VFS_MoveFile
• ThrdMgr_*: ThrdMgr_GetCurrentThreadHandle, ThrdMgr_SaveTEB, ThrdMgr_SwitchThreads

Primitiva de delay típica (user-land):

cmd /c timeout /t %RANDOM_IN_[600,1800]% > nul

Bloqueio por argumento

• Operadores às vezes exigem que uma opção de CLI com aparência benign seja presente antes de executar o payload (por exemplo, /i:--type=renderer para mimetizar processos filhos do Chromium). Se a opção estiver ausente, o loader encerra imediatamente, impedindo execuções ingênuas em sandbox.

Furtividade

Execução

Diversos

• GetAsyncKeyState() -- Key logging
• SetWindowsHookEx -- Key logging
• GetForeGroundWindow -- Obter nome da janela em execução (ou o site de um browser)
• LoadLibrary() -- Import library
• GetProcAddress() -- Import library
• CreateToolhelp32Snapshot() -- Listar processos em execução
• GetDC() -- Captura de tela
• BitBlt() -- Captura de tela
• InternetOpen(), InternetOpenUrl(), InternetReadFile(), InternetWriteFile() -- Acessar a Internet
• FindResource(), LoadResource(), LockResource() -- Acessar recursos do executável

Técnicas de Malware

DLL Injection

Execute an arbitrary DLL inside another process

1. Locate the process to inject the malicious DLL: CreateToolhelp32Snapshot, Process32First, Process32Next
2. Open the process: GetModuleHandle, GetProcAddress, OpenProcess
3. Write the path to the DLL inside the process: VirtualAllocEx, WriteProcessMemory
4. Create a thread in the process that will load the malicious DLL: CreateRemoteThread, LoadLibrary

Other functions to use: NTCreateThreadEx, RtlCreateUserThread

Reflective DLL Injection

Load a malicious DLL without calling normal Windows API calls.
The DLL is mapped inside a process, it will resolve the import addresses, fix the relocations and call the DllMain function.

Thread Hijacking

Find a thread from a process and make it load a malicious DLL

1. Find a target thread: CreateToolhelp32Snapshot, Thread32First, Thread32Next
2. Open the thread: OpenThread
3. Suspend the thread: SuspendThread
4. Write the path to the malicious DLL inside the victim process: VirtualAllocEx, WriteProcessMemory
5. Resume the thread loading the library: ResumeThread

PE Injection

Portable Execution Injection: O executável será escrito na memória do processo vítima e será executado a partir daí.

Process Hollowing (a.k.a RunPE)

Process Hollowing é um dos truques favoritos de defence-evasion / execution usados por malware no Windows. A ideia é lançar um processo legítimo no estado suspenso, remover (hollow) sua imagem original da memória e copiar um PE arbitrário em seu lugar. Quando a thread primária for finalmente retomada, o entry-point malicioso executa-se sob o disfarce de um binário confiável (frequentemente assinado pela Microsoft).

Fluxo típico:

1. Spawn um host benigno (ex.: RegAsm.exe, rundll32.exe, msbuild.exe) suspended de forma que nenhuma instrução seja executada ainda.

STARTUPINFOA  si = { sizeof(si) };
PROCESS_INFORMATION pi;
CreateProcessA("C:\\Windows\\Microsoft.NET\\Framework32\\v4.0.30319\\RegAsm.exe",
NULL, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &si, &pi);

2. Ler o payload malicioso na memória e parsear seus cabeçalhos PE para obter SizeOfImage, seções e o novo EntryPoint.
3. NtUnmapViewOfSection / ZwUnmapViewOfSection – desmapear a base da imagem original do processo suspenso.
4. VirtualAllocEx – reservar memória RWX de SizeOfImage dentro do processo remoto.
5. WriteProcessMemory – copiar primeiro os Headers, depois iterar sobre as seções copiando seus dados brutos.
6. SetThreadContext – patch no valor de EAX/RAX (RCX on x64) ou Rip na estrutura de contexto para que o EIP aponte para o EntryPoint do payload.
7. ResumeThread – a thread continua, executando o código fornecido pelo atacante.

Minimal proof-of-concept (x86) skeleton:

void RunPE(LPCSTR host, LPVOID payload, DWORD payloadSize){
// 1. create suspended process
STARTUPINFOA si = {sizeof(si)}; PROCESS_INFORMATION pi;
CreateProcessA(host, NULL,NULL,NULL,FALSE,CREATE_SUSPENDED,NULL,NULL,&si,&pi);

// 2. read remote PEB to get ImageBaseAddress
CONTEXT ctx; ctx.ContextFlags = CONTEXT_FULL;
GetThreadContext(pi.hThread,&ctx);
PVOID baseAddr;
ReadProcessMemory(pi.hProcess,(PVOID)(ctx.Ebx+8),&baseAddr,4,NULL);

// 3. unmap original image & allocate new region at same base
NtUnmapViewOfSection(pi.hProcess,baseAddr);
PVOID newBase = VirtualAllocEx(pi.hProcess,baseAddr,pHdr->OptionalHeader.SizeOfImage,
MEM_COMMIT|MEM_RESERVE,PAGE_EXECUTE_READWRITE);
// 4-5. copy headers & sections …
// 6. write new image base into PEB and set Eip
WriteProcessMemory(pi.hProcess,(PVOID)(ctx.Ebx+8),&baseAddr,4,NULL);
ctx.Eax = (DWORD)(newBase) + pHdr->OptionalHeader.AddressOfEntryPoint;
SetThreadContext(pi.hThread,&ctx);
// 7. run!
ResumeThread(pi.hThread);
}

Notas práticas observadas na campanha DarkCloud Stealer:

• O loader escolheu RegAsm.exe (parte do .NET Framework) como host – um binário assinado improvável de chamar atenção.
• O stealer VB6 decriptado (holographies.exe) não é gravado no disco; ele existe apenas dentro do hollowed process, dificultando a detecção estática.
• Strings sensíveis (regexes, paths, credenciais do Telegram) são RC4-encrypted por-string e só são decriptadas em tempo de execução, complicando ainda mais a varredura de memória.

Ideias de detecção:

• Alertar sobre processos CREATE_SUSPENDED que nunca criam janelas GUI/console antes de uma região de memória ser alocada como RWX (raro para código benigno).
• Procurar por uma sequência de chamadas NtUnmapViewOfSection ➜ VirtualAllocEx ➜ WriteProcessMemory entre processos diferentes.
• Uso incomum de utilitários de desenvolvedor confiáveis como hosts de hollowing, especialmente MSBuild.exe, RegAsm.exe, rundll32.exe, quando parentados por loaders de curta duração.
• Caçar msbuild.exe spawnado de caminhos graváveis pelo usuário ou sem o contexto .sln/.proj correspondente e que então façam conexões de saída (ATT&CK T1127.001 + T1055.012).

Common host processes and path resolution

• MSBuild.exe is frequently chosen as a hollowing host to blend with developer tooling. Loaders often search architecture-appropriate locations:
• C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
• C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
• C:\Windows\System32\MSBuild.exe
• C:\Windows\SysWOW64\MSBuild.exe
• Select the host matching the current payload/OS architecture before calling CreateProcess(..., CREATE_SUSPENDED, ...).

Hooking

• The SSDT (System Service Descriptor Table) aponta para funções do kernel (ntoskrnl.exe) ou driver GUI (win32k.sys) para que processos do usuário possam chamar essas funções.
• Um rootkit pode modificar esses ponteiros para endereços que ele controla
• IRP (I/O Request Packets) transmitem pedaços de dados de um componente para outro. Quase tudo no kernel usa IRPs e cada objeto de dispositivo tem sua própria tabela de funções que pode ser hookada: DKOM (Direct Kernel Object Manipulation)
• The IAT (Import Address Table) is useful to resolve dependencies. It's possible to hook this table in order to hijack the code that will be called.
• EAT (Export Address Table) Hooks. This hooks can be done from userland. The goal is to hook exported functions by DLLs.
• Inline Hooks: This type are difficult to achieve. This involve modifying the code of the functions itself. Maybe by putting a jump at the beginning of this.

Referências

• Unit42 – New Infection Chain and ConfuserEx-Based Obfuscation for DarkCloud Stealer
• Check Point Research – Under the Pure Curtain: From RAT to Builder to Coder
• Unit 42 – PhantomVAI Loader Delivers a Range of Infostealers
• MITRE ATT&CK – Trusted Developer Utilities Proxy Execution: MSBuild (T1127.001)
• VMDetector – virtualization checks (open-source)