Process Injection é uma técnica classificada pelo MITRE pelo ID T1055 e está dentro das táticas de “Defense Evasion” e “Privilege Escalation”. Ela é usada por malwares para, de uma forma mais furtiva, inserir códigos e tarefas em processos do sistema operacional, em resumo, inserir código malicioso em um processo legitimo e contornar produtos e agentes de segurança (por exemplo, Antivírus, DLP e soluções de firewall) no host alvo. Sua função mais útil pode ser que o código arbitrário, uma vez injetado em um processo legítimo, pode herdar os privilégios desse processo ou, da mesma forma, acessar partes do sistema operacional que não deveriam estar disponíveis de outra forma, como a possibilidade de elevação de privilégios.

As Dificuldades em detectar um malware de Process Injection

Frequentemente, para evitar a detecção, o malware aproveita várias técnicas de evasão que envolvem a manipulação do processo para executar o código malicioso e, especialmente, Process Injection. Quando o malware está sendo executado na máquina infectada, seu processo pode ser facilmente detectado por analistas e programas de segurança, bastando verificar a lista de processos em execução e filtrar os processos esperados que fazem parte do sistema operacional ou pertencem aos aplicativos instalados. Para se esconder no sistema infectado, o malware pode carregar sua carga maliciosa dentro de um processo legítimo sem levantar suspeitas.

Formas mais comuns de realizar a Injeção de Processo

A injeção de processos é uma prática usadas por criminosos há muito tempo, a pratica ganhou notoriedade atingindo o sistema operacional Windows Vista desde seu lançamento em 2007, 13 anos atrás, no decorrer dos anos a mesma foi sendo aprimorada e adaptando para os mais novos sistema operacionais para ter um impacto mais preciso e confiável para aquele que o executa. Listamos aqui alguns dos mais conhecidos e usados atualmente e um exemplo detalhado de execução para que você tenha um melhor entendimento de como o mesmo funciona, e como pode ser detectado:

DLL Injection:

Os adversários podem injetar bibliotecas de vínculo dinâmico (DLLs) em processos para evitar defesas baseadas em processos, bem como, possivelmente, elevar privilégios. A injeção de DLL é um método de execução de código arbitrário no espaço de endereço de um processo ativo separado.

A injeção de DLL é normalmente executada gravando o caminho para uma DLL no espaço de endereço virtual do processo de destino antes de carregar a DLL chamando um novo thread. A gravação pode ser realizada com chamadas de API nativas do Windows, como VirtualAllocEx e WriteProcessMemory, e então invocado com CreateRemoteThread (que chama a API LoadLibrary responsável por carregar a DLL).

Portable Executable Injection:

A injeção de código em outra memória de processo não se limita apenas a códigos de shell ou DLLs. A técnica de injeção PE permite injetar e executar um módulo executável completo dentro de outra memória de processo. Essa técnica é semelhante à injeção reflexiva de DLL, uma vez que não solta nenhum arquivo no disco: a injeção reflexiva de DLL funciona criando uma DLL que se mapeia na memória quando executada, em vez de depender do carregador do Windows.

Como a injeção reflexiva de DLL, essa técnica não depende da função LoadLibrary, mas copia seu código malicioso em um processo aberto existente e faz com que ele seja executado (usando um código de shell ou chamando a função CreateRemoteThread).

O malware aloca memória em um processo host e, em vez de escrever um “caminho de DLL”, ele grava seu código malicioso chamando WriteProcessMemory.

Thread Local Storage:

Os adversários podem injetar código malicioso em processos por meio de retornos de chamada de armazenamento local de thread (TLS) para evitar defesas baseadas em processos, bem como, possivelmente, elevar privilégios.

A injeção de retorno de chamada TLS envolve a manipulação de ponteiros dentro de um executável portátil (PE) para redirecionar um processo para um código malicioso antes de atingir o ponto de entrada legítimo do código.

Retornos de chamada TLS são normalmente usados ​​pelo sistema operacional para configurar e/ou ou limpar dados usados ​​por threads. A manipulação de retornos de chamada TLS pode ser realizada alocando e escrevendo para deslocamentos específicos dentro de um espaço de memória do processo usando outras técnicas de injeção de processo, como o esvaziamento de processo. A execução de código no contexto de outro processo pode permitir o acesso à memória do processo, aos recursos do sistema/rede e, possivelmente, a privilégios elevados.

A execução por meio de injeção de retorno de chamada TLS também pode evitar a detecção de produtos de segurança, pois a execução é mascarada em um processo legítimo.

Process Hollowing

Os adversários podem injetar código malicioso em processos suspensos e vazios para evitar defesas baseadas em processos. O esvaziamento do processo é um método de execução de código arbitrário no espaço de endereço de um processo ativo separado.

O esvaziamento do processo é comumente executado criando um processo em estado suspenso e removendo o mapeamento/esvaziando sua memória, que pode ser substituída por código malicioso. Um processo de vítima pode ser criado com chamadas de API nativas do Windows, como CreateProcess, que inclui um sinalizador para suspender o thread primário do processo. Neste ponto, o processo pode ser desmapeado usando chamadas de APIs, como ZwUnmapViewOfSection ou NtUnmapViewOfSection antes de ser gravado, realinhado no código injetado e retomado via VirtualAllocEx, WriteProcessMemory, SetThreadContext e ResumeThread respectivamente.

Isso é muito semelhante ao Thread Local Storage, mas cria um novo processo em vez de direcionar um processo existente. Esse comportamento provavelmente não resultará em privilégios elevados, pois o processo injetado foi gerado (e, portanto, herda o contexto de segurança) do processo injetado. No entanto, a execução por meio de esvaziamento de processo também pode evitar a detecção de produtos de segurança, pois a execução é mascarada por um processo legítimo.

 

Usando os métodos descritos acima é possível detectar facilmente códigos prejudiciais colocados no sistema por meio da análise de memória. Será suficiente para o software de análise de memória que é usado para ler a estrutura VAD (Virtual Address Descriptors) para cada processo e encontrar as seções de memória marcadas como executáveis (Page_Execute_ReadWrite) e então verificar se os códigos nestas seções de memória possuem um correspondente resposta no disco. Você pode identificar facilmente o esvaziamento do processo por meio da imagem da memória. Para isso podemos descobrir quais processos são injetados com volatilidade ou Mandiant RedLine.

Vejamos como podemos detectá-lo a partir de uma imagem de memória de amostra. A análise começará a partir da detecção do processo injetado. Podemos detectá-los com erro de Volatilidade:

 

A injeção de processo também pode ser detectada procurando por proteção de memória suspeita. Executar o plugin malfind (que procura por proteções de memória suspeitas) mostra proteção de memória suspeita (PAGE_EXECUTE_READWRITE) no endereço 0x1000000 (que é base endereço de lsass.exe) indicando que lsass.exe não foi carregado normalmente (mas foi injetado). Qualquer executável que normalmente é carregado terá uma proteção de memória de PAGE_EXECUTE_WRITECOPY. Isso confirma ainda mais que lsass.exe (pid 868) carregado em 0x1000000 não é legítimo.

Automatizando a detecção de Injeção de Processo usando o HollowFind plugin:

Hollowfind é um plugin de Volatilidade para detectar diferentes tipos de técnicas de esvaziamento de processos usadas na natureza para contornar, confundir, desviar e desviar as técnicas de análise forense. O plugin detecta tais ataques ao encontrar discrepâncias no VAD e PEB, ele também desmonta o endereço do ponto de entrada para detectar qualquer tentativa de redirecionamento e também relata qualquer região de memória suspeita que deve ajudar na detecção de qualquer código injetado.

A captura de tela abaixo mostra o plugin hollowfind em ação. Executar o plugin hollowfind na imagem de memória infectada do stuxnet identificou ambos os processos lsass.exe (pid 1928 e pid 868) e também relata a proteção de memória exe inválida (PAGE_EXECUTE_READWRITE) e discrepância de caminho de processo entre o VAD e PEB e também desmonta o endereço do ponto de entra,observe também um salto para o endereço 0x1003121 no endereço do ponto de entrada.

 

 

Detecção

Como todo e qualquer tipo de malware a forma mais segura de se proteger é sempre manter seu sistema operacional bem como seus softwares atualizados para a versão mais recente, onde o fabricante está sempre implementando o mesmo para uma forma mais estável e corrigindo falhas de segurança. Mas tendo em vista a delicadeza que este ataque é feito, sua detecção exige formas mais minuciosas para detecção, e aqui vão algumas maneiras de se fazer:

O monitoramento de chamadas de API do Windows indicativas dos vários tipos de injeção de código pode gerar uma quantidade significativa de dados e pode não ser diretamente útil para defesa, a menos que coletado em circunstâncias específicas para sequências de chamadas incorretas conhecidas, uma vez que o uso de funções de API pode ser comum e difícil para distinguir de comportamento malicioso. Chamadas de API do Windows como CreateRemoteThread, SuspendThread / SetThreadContext / ResumeThread, QueueUserAPC / NtQueueApcThread e aquelas que podem ser usadas para modificar a memória em outro processo, como VirtualAllocEx / WriteProcessMemory, podem ser usadas para esta técnica.

Monitore eventos de arquivo DLL / PE, especificamente a criação desses arquivos binários, bem como o carregamento de DLLs nos processos. Procure DLLs que não são reconhecidas ou normalmente não carregadas em um processo.

O monitoramento de chamadas específicas do Linux, como a chamada de sistema ptrace, não deve gerar grandes quantidades de dados devido à sua natureza especializada e pode ser um método muito eficaz para detectar alguns dos métodos de injeção de processo comuns.

Monitore a criação de pipe nomeado e eventos de conexão (IDs de evento 17 e 18) para possíveis indicadores de processos infectados com módulos externos.

Analise o comportamento do processo para determinar se um processo está executando ações que normalmente não executa, como abrir conexões de rede, ler arquivos ou outras ações suspeitas que podem estar relacionadas ao comportamento pós-comprometimento.

Sugestões de Detecção:

A detecção de injeção de processo envolve a busca por processos legítimos fazendo coisas imprevisíveis. Isso pode envolver processos que fazem conexões de rede externas e gravam arquivos, ou pode envolver processos que geram argumentos de linha de comando inesperados.

Alguns bons exemplos de comportamento estranho dentro de um processo incluem:

• exe fazendo conexões de rede em tcp / 447 e tcp / 449
• exe fazendo conexões de rede externas
• exe chamando CreateRemoteThread para injetar código

Alguns bons exemplos de caminhos estranhos ou linhas de comando que podem indicar injeção:

• As execuções de processos Rundll32.exe, regasm.exe, regsvr32.exe, regsvcs.exe, svchost.exe e werfault.exe sem opções de linha de comando podem indicar que eles são alvos de injeção de processo.
• Processos da Microsoft como vbc.exe com linhas de comando incluindo / scomma, / shtml ou / stext podem indicar a injeção de ferramentas da Nirsoft para acesso de credencial
• Processos Linux com memfd: em seu caminho indicam que foram gerados a partir de código injetado em outro processo.

Em Resumo, a injeção de processo (process injection)  é um método altamente eficaz que pode trazer um risco muito grande ao ambiente uma vez que o mesmo tenha tido sucesso em sua execução, não podemos subestimar a capacidade do atacante em realizá-la com o objetivo de destruir seu negócio com métodos semelhantes.

Portanto, é importante sempre ter suas políticas de segurança atualizadas e colaboradores educados na defesa desses métodos para obter uma melhor forma de mitigação de quaisquer ataques que a sua organização venha à sofrer.

A recomendação é você possuir um EDR capaz de analisar os pontos indicados acima, ou possuir um SIEM, como o IBM QRADAR, que seja capaz de consumir logs de processos e alertem sua  equipe de monitoramento para que possam iniciar o processo adequado de resposta ao incidente.