Método batizado de console named-pipe injection entrega payload pela entrada padrão redirecionada de um processo filho de console e reutiliza memória já populada pelo próprio Windows, rompendo a cadeia clássica de alocação e escrita remota monitorada pelas ferramentas de detecção.
| Componente | Técnica de injeção de processo em Windows denominada console named-pipe injection, que abusa de processos filho de console como nslookup.exe e netsh.exe com entrada padrão redirecionada |
| Vetor | Criação de processo de console interativo com handles de entrada padrão redirecionados para um pipe, escrita do payload com WriteFile e localização do buffer na memória do processo filho a partir de um marcador distintivo |
| Impacto | Execução de código arbitrário no contexto de um processo legítimo sem acionar VirtualAllocEx ou WriteProcessMemory, contornando detecções baseadas na sequência alocar-escrever-executar; a mudança de proteção remota e a manipulação de contexto de thread permanecem detectáveis |
| Prioridade | Correlacionar comportamento completo em vez de alertas de API isolada: monitorar criação de processos de console com handles redirecionados, escritas de entrada padrão em formato binário, varredura de memória, transição de VirtualProtectEx para permissão executável e redirecionamento de SetThreadContext |
| Artefatos | Prova de conceito localizou 368 bytes dentro de região de nslookup.exe com proteção alterada de leitura-escrita para executável-leitura-escrita; telemetria relevante nos Event IDs 17 e 18 do Sysmon para pipes nomeados |
Uma nova técnica de injeção de processo divulgada pelo pesquisador que assina como Two Seven One Three demonstra que é possível executar código arbitrário dentro de um processo legítimo do Windows sem recorrer às duas APIs mais associadas a esse tipo de abuso: VirtualAllocEx e WriteProcessMemory. O método, chamado de console named-pipe injection, explora a comunicação interprocessual nativa do sistema operacional para entregar os bytes do payload por meio da entrada padrão redirecionada de um processo filho de console, em vez de realizar uma escrita direta e remota na memória de outro processo.
A abordagem tem relevância direta para equipes de detecção porque a maioria das regras de EDR correlaciona a cadeia clássica de injeção: abrir ou criar um processo alvo, alocar memória remota, copiar o código malicioso com WriteProcessMemory e então iniciar ou sequestrar uma thread para execução. Ao eliminar as etapas de alocação e de escrita remota, a variação rompe a sequência esperada por esses detectores e reaproveita páginas de memória que o próprio Windows já preencheu com os dados enviados pelo pipe, reduzindo a superfície de sinais tradicionais. O MITRE ATT&CK cataloga o comportamento genérico como T1055, e a técnica reforça que mapear APIs isoladas é insuficiente diante de implementações criativas.
O funcionamento começa quando o processo injetor cria um processo filho de console interativo, como nslookup.exe ou netsh.exe, configurando handles herdáveis na estrutura STARTUPINFO e redirecionando seus fluxos padrão. A documentação da Microsoft registra que um processo pai pode atribuir a ponta de leitura de um pipe como handle de entrada padrão do filho e manter a ponta oposta para escrita. O injetor então envia o payload com a função WriteFile, e os bytes passam a existir no espaço de endereçamento do programa de console conforme ele processa a entrada recebida, eliminando a necessidade de qualquer cópia explícita entre processos.
Na sequência, a prova de conceito prefixa o payload com um marcador distintivo, varre a memória acessível do processo filho em busca dessa assinatura e calcula o ponto de entrada do shellcode imediatamente após o marcador. Com o buffer localizado, o injetor invoca VirtualProtectEx para tornar executáveis as páginas já comprometidas na memória do alvo — alteração que, segundo a Microsoft, exige o privilégio PROCESS_VM_OPERATION. Por fim, o código suspende uma thread, altera seu ponteiro de instrução para o endereço do shellcode e retoma a execução, concluindo o desvio do fluxo de controle sem nunca ter chamado as APIs de escrita remota clássicas.
A demonstração publicada mostra a localização de 368 bytes dentro de uma região de nslookup.exe, a transição da proteção da página de leitura-escrita para executável-leitura-escrita e o redirecionamento da thread principal para esse endereço. A técnica traz restrições operacionais relevantes: o payload precisa evitar bytes de retorno de carro, avanço de linha e o substituto de Ctrl+Z, porque o parsing do console pode interpretá-los como terminadores de comando ou fim de arquivo, truncando a entrega. Além disso, as etapas de descoberta de memória, alteração remota de proteção e manipulação de contexto de thread continuam gerando sinais observáveis, o que preserva espaço para detecção comportamental.
- O injetor cria um filho de console com STARTUPINFO e CreateProcess com fluxos redirecionados
- O payload é entregue via WriteFile no pipe conectado à entrada padrão do processo filho
- Um marcador distintivo permite localizar o buffer e calcular o ponto de entrada do shellcode
- VirtualProtectEx torna as páginas executáveis; a thread é suspensa, tem o ponteiro de instrução alterado e é retomada
Diferentemente de pesquisas relacionadas sobre envenenamento de parâmetros de processo, essa abordagem não exige que o processo filho seja iniciado em estado suspenso nem que dados com formatação incomum sejam inseridos em campos de linha de comando ou de variáveis de ambiente, o que amplia o conjunto de cenários em que pode ser aplicada. Pesquisadores da SensePost, Max Hirschberger e Ogulcan Ugur, demonstraram anteriormente uma técnica separada que contornou quatro produtos líderes de EDR, mas esse resultado não valida a implementação mais recente, e a avaliação defensiva deve se basear nos sinais descritos na própria análise.
Qualquer ambiente Windows que permita a execução de binários de console está teoricamente exposto ao padrão de abuso, uma vez que a técnica depende apenas de primitivas documentadas de criação de processo, herança de handles e manipulação de memória. O impacto prático se concentra em ferramentas de detecção cuja lógica correlaciona principalmente a alocação remota e a escrita remota: cadeias que não passam por esses pontos podem atravessar controles que não cobrem o restante do comportamento, especialmente em ambientes com uso legítimo intenso de automação de console.
- Detecções construídas sobre a sequência VirtualAllocEx, WriteProcessMemory e execução de thread
- Binários de console interativos como nslookup.exe e netsh.exe usados como hospedeiros do payload
- Payloads com restrições de bytes de controle impostas pelo parsing do console
- Ambientes com automação legítima de console, onde o sinal isolado de pipe gera ruído elevado
A resposta defensiva recomendada é mover o foco de alertas de API isolada para a correlação do comportamento completo. Os sinais de maior valor incluem um processo pai incomum iniciando um binário de console interativo com handles redirecionados, escritas de entrada padrão com conteúdo em formato binário, varredura de memória no processo filho, a transição remota de VirtualProtectEx para permissões executáveis e a sequência de SetThreadContext seguida de retomada da thread. A combinação desses eventos em uma única linhagem de processo é muito mais discriminante do que qualquer um deles tomado individualmente.
Os Event IDs 17 e 18 do Sysmon fornecem telemetria de pipes nomeados, mas a análise alerta que pipes anônimos de entrada padrão podem exigir visibilidade mais rica em nível de endpoint e de handles para serem acompanhados. Por isso, equipes devem estabelecer uma linha de base de automação de console no ambiente e caçar combinações raras desses sinais, em vez de sinalizar toda ocorrência de conhost.exe, nslookup.exe ou operação de pipe, o que geraria volume insustentável de falsos positivos.
- Processo pai incomum criando binário de console interativo com handles redirecionados
- Escritas de entrada padrão com conteúdo binário seguidas de varredura de memória no processo filho
- VirtualProtectEx remoto alterando página para executável em processo de console
- SetThreadContext seguido de retomada de thread na mesma linhagem de processo
- Event IDs 17 e 18 do Sysmon para pipes nomeados, complementados por visibilidade de handles
A primeira ação para times de segurança é revisar as regras de detecção existentes e verificar se elas dependem exclusivamente de VirtualAllocEx e WriteProcessMemory como gatilhos de injeção. Regras construídas sobre a sequência alocar-escrever-executar devem ser ampliadas para cobrir o caminho alternativo: criação de processo de console com herança e redirecionamento de handles, escrita de bytes pela entrada padrão, alteração de permissão de página já comprometida e manipulação de contexto de thread. A análise reforça que detecção confiável exige observar como os processos são criados, como os handles são compartilhados, como a memória é protegida e como o fluxo de controle muda, nunca confiando em um único método.
Em paralelo, a contenção passa por reduzir a exposição de binários de console em estações e servidores onde não são necessários, aplicar princípio de privilégio mínimo sobre o direito PROCESS_VM_OPERATION e monitorar combinações raras de eventos em vez de ocorrências isoladas. A validação das novas regras deve usar a própria prova de conceito descrita — localização de buffer com marcador, mudança de proteção para executável e redirecionamento de thread — como roteiro de teste, confirmando que a cadeia completa gera alerta correlacionado antes de considerar a cobertura adequada.
- Ampliar regras de injeção para além de VirtualAllocEx e WriteProcessMemory
- Correlacionar criação de console com handles redirecionados, escrita binária na entrada padrão e manipulação de thread
- Restringir PROCESS_VM_OPERATION e binários de console desnecessários nos hosts
- Estabelecer linha de base de automação de console e caçar combinações raras de sinais
0 Comentários