DEZ TÉCNICAS DE INJEÇÃO DE PROCESSO (PROCESS INJECTION): UM LEVANTAMENTO TÉCNICO DE TÉCNICAS COMUNS DE PROCESS INJECTION E TENDÊNCIA

A injeção de processos (Process Injection) é uma técnica de evasão de defesa ampla empregada muitas vezes dentro de malware e tradecraft adversário sem arquivos, e implica executar código personalizado dentro do espaço de endereço de outro processo. A injeção de processos melhora a discrição, e algumas técnicas também alcançam persistência. Embora existam inúmeras técnicas de injeção de processos, neste blog apresento dez técnicas vistas na natureza que executam código de malware em nome de outro processo. Além disso, forneci capturas de tela para muitas dessas técnicas para facilitar a engenharia reversa e a análise de malware, auxiliando na detecção e defesa contra essas técnicas comuns.

1. INJEÇÃO CLÁSSICA DE DLL VIA CREATEREMOTETHREAD E LOADLIBRARY

Essa técnica é uma das técnicas mais comuns usadas para injetar malware em outro processo. O malware escreve o caminho para sua biblioteca de links dinâmicos maliciosos (DLL) no espaço de endereço virtual de outro processo e garante que o processo remoto o carregue criando um segmento remoto no processo de destino.

O malware primeiro precisa direcionar um processo de injeção (por exemplo, svchost.exe). Isso geralmente é feito pesquisando através de processos ligando para um trio de APIs (Application Program Interfaces): CreateToolhelp32Snapshot, Process32First e Process32Next. CreateToolhelp32Snapshot é uma API usada para enumerar os estados de pilha ou módulo de um processo especificado ou de todos os processos, e retorna um snapshot. Process32First recupera informações sobre o primeiro processo no snapshot e, em seguida, process32Next é usado em um loop para iterar através deles. Depois de encontrar o processo de destino, o malware obtém a alça do processo de destino chamando OpenProcess.

Como mostrado na Figura 1, o malware chama o VirtualAllocEx de ter um espaço para escrever o caminho para seu DLL. O malware então chama WriteProcessMemory para escrever o caminho na memória alocada. Finalmente, para ter o código executado em outro processo, o malware chama APIs como CreateRemoteThread, NtCreateThreadEx ou RtlCreateUserThread. Os dois últimos estão indocumentados. No entanto, a ideia geral é passar o endereço do LoadLibrary para uma dessas APIs para que um processo remoto tenha que executar o DLL em nome do malware.

O CreateRemoteThread é rastreado e sinalizado por muitos produtos de segurança. Além disso, requer um DLL malicioso no disco que poderia ser detectado. Considerando que os atacantes são mais comumente injetando código para escapar das defesas, atacantes sofisticados provavelmente não usarão essa abordagem. A captura de tela abaixo exibe um malware chamado Rebhip executando essa técnica.

Figura 1: Rebhip worm realizando uma injeção típica de DLL
Sha256: 07b8f25e7b536f6f686c12d04edc37e11347c8acd5c53f98a174723078c365

2. INJEÇÃO EXECUTÁVEL PORTÁTIL (INJEÇÃO DE PE)

Em vez de passar o endereço do LoadLibrary, o malware pode copiar seu código malicioso em um processo aberto existente e fazê-lo ser executado (seja através de um pequeno código de shell, ou chamando CreateRemoteThread). Uma vantagem da injeção de PE sobre a técnica LoadLibrary é que o malware não precisa deixar cair um DLL malicioso no disco. Semelhante à primeira técnica, o malware aloca memória em um processo de host (por exemplo, VirtualAllocEx) e, em vez de escrever um “caminho DLL”, ele escreve seu código malicioso chamando WriteProcessMemory. No entanto, o obstáculo com essa abordagem é a mudança do endereço base da imagem copiada. Quando um malware injeta seu PE em outro processo, ele terá um novo endereço base que é imprevisível, exigindo que ele recomputa dinamicamente os endereços fixos de seu PE. Para superar isso, o malware precisa encontrar seu endereço de tabela de realocação no processo host e resolver os endereços absolutos da imagem copiada, looping através de seus descritores de realocação.

Esta técnica é semelhante a outras técnicas, como injeção de DLL reflexiva e módulo de memória, já que eles não deixam cair nenhum arquivo para o disco. No entanto, o módulo de memória e as abordagens reflexivas de injeção DLL são ainda mais furtivas. Eles não dependem de nenhuma APIs extra do Windows (por exemplo, CreateRemoteThread ou LoadLibrary), porque eles carregam e executam-se na memória. A injeção de DLL reflexiva funciona criando um DLL que se mapeia na memória quando executado, em vez de depender do carregador da janela. O Módulo de Memória é semelhante à injeção de DLL reflexiva, exceto que o injetor ou carregador é responsável por mapear o DLL alvo na memória em vez do próprio mapeamento DLL. Em um post anterior no blog, esses dois em abordagens de memória foram amplamente discutidos.

Ao analisar a injeção de PE, é muito comum ver loops (geralmente dois loops “para” , um aninhado no outro), antes de uma chamada para CreateRemoteThread. Essa técnica é bastante popular entre os criptografias (softwares que criptografam e ofuscam malware). Na Figura 2, o teste da unidade amostral está aproveitando essa técnica. O código tem dois loops aninhados para ajustar sua tabela de realocação que pode ser vista antes das chamadas para WriteProcessMemory e CreateRemoteThread. A instrução “e 0x0fff” também é outro bom indicador, mostrando que os primeiros 12 bits são usados para obter o deslocamento no endereço virtual do bloco de realocação contendo. Agora que o malware recomutou todos os endereços necessários, tudo o que precisa fazer é passar seu endereço inicial para CreateRemoteThread e executá-lo.

Figura 2: Estrutura de exemplo dos loops para injeção de PE antes das chamadas para CreateRemoteThread
Sha256: ce8d7590182db2e51372a4a04d6a0927a65b2640739f9ec01cfd6c143b1110da

3. PROCESS HOLLOWING (TAMBÉM CONHECIDO COMO SUBSTITUIÇÃO DE PROCESSO E RUNPE)

Em vez de injetar código em um programa de host (por exemplo, injeção de DLL), o malware pode executar uma técnica conhecida como Process Hollowing. O esvaziamento do processo ocorre quando um malware desmascara (esvazia) o código legítimo da memória do processo de destino e sobregrava o espaço de memória do processo de destino (por exemplo, svchost.exe) com um executável malicioso.

O malware cria primeiro um novo processo para hospedar o código malicioso no modo suspenso. Como mostrado na Figura 3, isso é feito chamando CreateProcess e definindo o Sinalizador de Criação de Processos para CREATE_SUSPENDED (0x000000004). O segmento principal do novo processo é criado em um estado suspenso e não é executado até que a função ResumeThread seja chamada. Em seguida, o malware precisa trocar o conteúdo do arquivo legítimo com sua carga maliciosa. Isso é feito desmamasmando a memória do processo de destino, chamando zwUnmapViewOfSection ou NtUnmapViewOfSection. Essas duas APIs basicamente liberam toda a memória apontada por uma seção. Agora que a memória não foi mapeada, o carregador executa o VirtualAllocEx para alocar uma nova memória para o malware e usa o WriteProcessMemory para escrever cada uma das seções do malware para o espaço do processo de destino. O malware chama SetThreadContext para apontar o ponto de entrada para uma nova seção de código que ele escreveu. No final, o malware retoma o segmento suspenso ligando para o ResumeThread para tirar o processo do estado suspenso.

Figura 3: Ransom.Cryak realizando processo de esvaziamento
Sha256: eae72d803bf67df2526f50fc7ab84d838efb2865c27aef1a61592b1c520d144

4. THREAD EXECUTION HIJACKING (TAMBÉM CONHECIDO COMO SUSPENDER, INJETAR E RETOMAR (SIR))

Esta técnica tem algumas semelhanças com a técnica de oco de processo previamente discutida. No sequestro de execução de thread, o malware tem como alvo um segmento existente de um processo e evita qualquer processo barulhento ou operações de criações de thread. Portanto, durante a análise, você provavelmente verá chamadas para CreateToolhelp32Snapshot e Thread32First seguidos pelo OpenThread.

Depois de obter uma alça para o segmento de destino, o malware coloca o segmento no modo suspenso, chamando suspendThread para executar sua injeção. O malware chama VirtualAllocEx e WriteProcessMemory para alocar memória e executar a injeção de código. O código pode conter shellcode, o caminho para o DLL malicioso e o endereço do LoadLibrary.

A Figura 4 ilustra um trojan genérico usando esta técnica. Para sequestrar a execução do segmento, o malware modifica o registro EIP (um registro que contém o endereço da próxima instrução) do segmento alvo, chamando SetThreadContext. Depois disso, o malware retoma o segmento para executar o shellcode que ele escreveu para o processo host. Do ponto de vista do invasor, a abordagem SIR pode ser problemática porque suspender e retomar um segmento no meio de uma chamada de sistema pode causar a falha do sistema. Para evitar isso, um malware mais sofisticado seria retomado e tentaria novamente mais tarde se o registro EIP estiver dentro do alcance do NTDLL.dll.

Figura 4: Um trojan genérico está realizando execução de thread sequestrando
Sha256: 787cbc8a6d1bc58ea169e1ad029a637f2256060cc129ab8a099a745bd50e

5. HOOK INJECTION VIA SETWINDOWSHOOKEX

Hooking é uma técnica usada para interceptar chamadas de função. O malware pode aproveitar a funcionalidade de gancho para ter seu DLL malicioso carregado após um evento ser acionado em um segmento específico. Isso geralmente é feito chamando SetWindowsHookEx para instalar uma rotina de gancho na cadeia de ganchos. A função SetWindowsHookEx tem quatro argumentos. O primeiro argumento é o tipo de evento. Os eventos refletem a gama de tipos de ganchos, e variam de teclas prensadas no teclado (WH_KEYBOARD) até entradas para o mouse (WH_MOUSE), TCC, etc. O segundo argumento é um ponteiro para a função que o malware deseja invocar após a execução do evento. O terceiro argumento é um módulo que contém a função. Assim, é muito comum ver chamadas para LoadLibrary e GetProcAddress antes de ligar para SetWindowsHookEx. O último argumento para esta função é o fio com o qual o procedimento do gancho deve ser associado. Se esse valor for definido como zero, todos os segmentos realizarão a ação quando o evento for acionado. No entanto, o malware geralmente tem como alvo um segmento para menos ruído, portanto também é possível ver as chamadas CreateToolhelp32Snapshot e Thread32Next antes de SetWindowsHookEx para encontrar e segmentar um único segmento. Uma vez que o DLL é injetado, o malware executa seu código malicioso em nome do processo que seu threadId foi passado para a função SetWindowsHookEx. Na Figura 5, o Locky Ransomware implementa essa técnica.

Figura 5: Locky Ransomware usando injeção de gancho
Sha256: 5d6ddb8458ee5ab99f3e7d9a21490ff4e5bc9808e18b9e20b6dc2c5b27927ba1

6. INJEÇÃO E PERSISTÊNCIA VIA MODIFICAÇÃO DE REGISTRO (POR EXEMPLO, APPINIT_DLLS, APPCERTDLLS, IFEO)

Appinit_DLL, AppCertDlls e IFEO (Image File Execution Options) são todas as chaves de registro que o malware usa para injeção e persistência. As entradas estão localizadas nos seguintes locais:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\Appinit_Dlls HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows\Appinit_Dlls HKLM\System\CurrentControlSet\Control\Session Manager\AppCertDlls HKLM\Software\Microsoft\Windows NT\currentversion\image file execution options

Appinit_DLLs

O malware pode inserir a localização de sua biblioteca maliciosa sob a chave de registro Appinit_DLLs para que outro processo carregue sua biblioteca. Cada biblioteca sob esta chave de registro é carregada em todos os processos que carregam o User32.dll. User32.dll é uma biblioteca muito comum usada para armazenar elementos gráficos, como caixas de diálogo. Assim, quando um malware modifica esse subtítico, a maioria dos processos carregará a biblioteca maliciosa. A Figura 6 demonstra que o trojan Ginwui confia nesta abordagem para injeção e persistência. Ele simplesmente abre a chave de registro de Appinit_DLLs ligando para RegCreateKeyEx e modifica seus valores chamando RegSetValueEx.

Figura 6: Ginwui modificando a chave de registro AppIniti_DLLs
Sha256: 9f10ec2786a10971eddc919a5e87a927c652e1655ddbbae72d376856d30fa27c

AppCertDlls

Essa abordagem é muito semelhante à abordagem Appinit_DLLs, exceto que os DLLs sob esta chave de registro são carregados em todos os processos que chama as funções de API Win32 CreateProcess, CreateProcessAsUser, CreateProcessWithLogonW, CreateProcessWithTokenW e WinExec.

Opções de execução de arquivos de imagem (IFEO – Image File Execution Options)

IFEO é normalmente usado para fins de depuração. Os desenvolvedores podem definir o “Valor do Depurador” sob esta chave de registro para anexar um programa a outro executável para depuração. Portanto, sempre que o executável for lançado o programa que estiver ligado a ele será lançado. Para usar este recurso, você pode simplesmente dar o caminho para o depurador e anexá-lo ao executável que deseja analisar. O malware pode modificar essa chave de registro para injetar-se no executável do alvo. Na Figura 7, o trojan Diztakun implementa essa técnica modificando o valor de depuração do Gerenciador de Tarefas.

Figura 7: Diztakun trojan modificando chave de registro IFEO
Sha256: f0089056fc6a314777773c5910f87813fa750f801dfca4ae7e9d7578a148

7. INJEÇÃO DE APC E ATOMBOMBING

O malware pode aproveitar as Chamadas de Procedimento Assíncronso (APC) para forçar outro segmento a executar seu código personalizado, anexando-o à fila APC do segmento de destino. Cada segmento tem uma fila de APCs que estão esperando a execução no segmento de destino entrando em estado alterável. Um segmento entra em um estado alertável se ele chamar de SleepEx, SignalObjectAndWait, MsgWaitForMultipleObjectsEx, WaitForMultipleObjectsEx ou WaitForSingleObjectEx. O malware geralmente procura qualquer segmento que esteja em um estado alterável e, em seguida, chama OpenThread e QueueUserAPC para enfileirar um APC para um segmento. QueueUserAPC leva três argumentos: 1) uma alça para o segmento de destino; 2) um ponteiro para a função que o malware quer executar; 3) e o parâmetro que é passado para o ponteiro de função. Na Figura 8, o malware Amanahe primeiro chama o OpenThread para adquirir uma alça de outro segmento e, em seguida, chama o QueueUserAPC com LoadLibraryA como o ponteiro de função para injetar seu DLL malicioso em outro segmento.

AtomBombing é uma técnica que foi introduzida pela primeira vez pela pesquisa enSilo , e depois usada em Dridex V4. Como discutimos em detalhes em um post anterior, a técnica também conta com injeção de APC. No entanto, ele usa tabelas atômicas para escrever na memória de outro processo.

Figura 8: Almanahe executando injeção APC
Sha256: f74399cc0be275376dad23151e3d0c2a1c966e6db6a695a05ec1a30551c0ad

8. INJEÇÃO EXTRA DE MEMÓRIA DE JANELA (EWMI) VIA SETWINDOWLONG

O EWMI se baseia em injetar na memória extra da janela da bandeja do Explorer, e tem sido usado algumas vezes entre famílias de malware, como Gapz e PowerLoader. Ao registrar uma classe de janela, um aplicativo pode especificar um número de bytes adicionais de memória, chamado memória de janela extra (EWM). No entanto, não há muito espaço na EWM. Para contornar essa limitação, o malware grava o código em uma seção compartilhada do explorer.exe e usa SetWindowLong e SendNotifyMessage para ter um ponteiro de função para apontar para o shellcode e executá-lo.

O malware tem duas opções quando se trata de escrever em uma seção compartilhada. Ele pode criar uma seção compartilhada e mapeá-la tanto para si mesma quanto para outro processo (por exemplo, explorer.exe), ou pode simplesmente abrir uma seção compartilhada que já existe. O primeiro tem a sobrecarga de alocar espaço de pilha e chamar NTMapViewOfSection, além de algumas outras chamadas de API, de modo que a última abordagem é usada com mais frequência. Depois que o malware grava seu shellcode em uma seção compartilhada, ele usa GetWindowLong e SetWindowLong para acessar e modificar a memória de janela extra de “Shell_TrayWnd“. GetWindowLong é uma API usada para recuperar o valor de 32 bits no deslocamento especificado na memória de janela extra de um objeto de classe de janela, e SetWindowLong é usado para alterar valores no deslocamento especificado. Ao fazer isso, o malware pode simplesmente alterar o deslocamento de um ponteiro de função na classe da janela e apontá-lo para o shellcode escrito para a seção compartilhada.

Como a maioria das outras técnicas mencionadas acima, o malware precisa acionar o código que ele escreveu. Em técnicas discutidas anteriormente, o malware conseguiu isso chamando APIs como CreateRemoteThread, QueueUserAPC ou SetThreadContext. Com essa abordagem, o malware, em vez disso, aciona o código injetado chamando SendNotifyMessage. Após a execução do SendNotifyMessage, Shell_TrayWnd recebe e transfere o controle para o endereço apontado pelo valor anteriormente definido pelo SetWindowLong. Na Figura 9, um malware chamado Carregador de Energia usa essa técnica.

Figura 9: PowerLoader injetando em memória de janela extra da janela da bandeja
sha256: 5e56a3c4d4c304ee6278df0b32afb62bd0d01e2a9894ad007f4cc5f873ab5cf

9. INJEÇÃO USANDO SHIM

A Microsoft fornece Shims aos desenvolvedores principalmente para compatibilidade retrógrada. Os shims permitem que os desenvolvedores apliquem correções em seus programas sem a necessidade de reescrever o código. Ao aproveitar os shims, os desenvolvedores podem dizer ao sistema operacional como lidar com seu aplicativo. Os calços são essencialmente uma maneira de se conectar em APIs e mirar executáveis específicos. O malware pode aproveitar os calços para atingir um executável tanto para persistência quanto para injeção. O Windows executa o Motor Shim quando carrega um binário para verificar se há bancos de dados para aplicar as correções apropriadas.

Existem muitas correções que podem ser aplicadas, mas os favoritos do malware são os que estão um pouco relacionados à segurança (por exemplo, DisableNX, DisableSEH, InjectDLL, etc). Para instalar um banco de dados de shimming, o malware pode implantar várias abordagens. Por exemplo, uma abordagem comum é simplesmente executar sdbinst.exe e apontá-lo para o arquivo sdb malicioso. Na Figura 10, um adware, “Search Protect by Conduit“, usa um calço para persistência e injeção. Ele executa um shim “InjectDLL” no Google Chrome para carregar vc32loader.dll. Existem algumas ferramentas existentes para analisar arquivos sdb, mas para a análise do sdb listado abaixo, usei python-sdb.

Figura 10: SDB usado por Search Protect para fins de injeção
Sha256: 6d5048baf2c3bba85adc9ac5ffd96b21c9a27d76003c4aa657157978d7437a20

10. GANCHO DE IAT E GANCHOS INLINE (TAMBÉM CONHECIDOS COMO ROOTKITS DO USERLAND)

Ganchos IAT e ganchos inline são geralmente conhecidos como rootkits userland. O gancho IAT é uma técnica que o malware usa para alterar a tabela de endereços de importação. Quando um aplicativo legítimo chama uma API localizada em um DLL, a função substituída é executada em vez da original. Em contraste, com o gancho inline, o malware modifica a própria função API. Na Figura 11, o malware FinFisher, executa o gancho IAT modificando onde o CreateWindowEx aponta.

Figura 11: FinFisher realizando gancho iAT mudando onde CreateWindowEx aponta para
Sha256: f827c92fbe832db3f09f47fe0dcaafd89b40c7064ab90833a1f418f2d1e75e8e8e

Conclusão

Neste post, cobri dez técnicas diferentes que o malware usa para ocultar sua atividade em outro processo. Em geral, o malware injeta diretamente seu shellcode em outro processo ou força outro processo a carregar sua biblioteca maliciosa. Na Tabela 1, classificei as diversas técnicas e fornenciei amostras para servir de referência para observar cada técnica de injeção abordada neste post. Os números incluídos ao longo do post ajudarão o pesquisador a reconhecer as várias técnicas ao reverter o malware.

Tabela1: A injeção de processo pode ser feita injetando código diretamente em outro processo, ou forçando uma DLL a ser carregada em outro processo.

Atacantes e pesquisadores descobrem regularmente novas técnicas para alcançar a injeção e fornecer furtividade. Este post detalhou dez técnicas comuns e emergentes, mas existem outras, como o sequestro do COM. Os defensores nunca serão “feitos” em sua missão de detectar e prevenir a injeção de processos furtivos porque os adversários nunca deixarão de inovar.

Na Endgame, pesquisamos constantemente técnicas avançadas de furtividade e trazemos proteções para o nosso produto. Nós colocamos recursos que detectam DLLs maliciosos que carregam em alguma persistência (como AppInit DLLs, COM Hijacks e muito mais), evitamos muitas formas de injeção de código em tempo real através de nossa proteção patenteada de injeção de shellcode e detectamos cargas injetáveis maliciosas em execução na memória fornecidas através de qualquer uma das técnicas acima através de nossas técnicas de detecção de ataque sem arquivo pendentes de patente. Essa abordagem permite que nossa plataforma seja mais eficaz do que qualquer outro produto no mercado na proteção contra injeção de código, ao mesmo tempo em que maximiza a resiliência contra o bypass devido às técnicas emergentes de injeção de código.

Traduzido e adaptado de: https://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process

Curso - Engenharia Reversa na Forense Digital

Aqui você compreenderá a utilização da Engenharia Reversa aplicada em Forense Digital, bem como a Análise de Malware.

O curso aborda diversos conceitos de forma prática. O estudo é baseado, em sua maioria, no .NET e .NET Core, pois é uma tecnologia que está sempre em evolução, sendo adicionada inclusive em Linux e MAC, ou seja, com o .NET Core, agora é multiplataforma.

Analisando este ambiente, podemos entender que é de extrema importância e urgente necessidade aprender a dissecar malwares desenvolvidos em alguma linguagem do .NET e .NET Core, com C#, VB, etc…