Para nossa conferência anual de hackers internos, que chamamos de SenseCon em 2023, decidi estudar a interação entre um driver do Windows e seu processo de modo de usuário.
Aqui estão alguns detalhes sobre essa jornada:
Os invasores podem usar uma primitiva de exploração de leitura/gravação do kernel do Windows para evitar a interação entre o EDR_Driver.sys e seu EDR_process.exe. Como resultado, alguns mecanismos de detecção de EDR serão desativados, tornando-o (parcialmente) cego para cargas maliciosas.
Este blog descreve uma abordagem alternativa que não remove retornos de chamada do kernel e fornece algumas recomendações para defesa contra esse ataque de "bloqueio de filtro".
Visão geral das funções EDR_process.exe e EDR_Driver.sys
A primeira pergunta que vem à mente é como o aplicativo EDR (EDR_Process.exe) se comunica com seu driver EDR (EDR_Driver.sys)?
Antes de fazermos a pesquisa, precisamos conhecer alguns princípios básicos de EDR; como o agente EDR injeta sua própria DLL no processo quando ele é criado?
Um diagrama de implementação de processos por meio de retornos de chamada, retirado das observações de EDR feitas por Christopher Vella, é um bom resumo.
Adicionei alguns comentários sobre o que está acontecendo:
EDR_Driver.sys pode assinar vários tipos de notificações de kernel. Você pode pensar nessas notificações como semelhantes a “boletins informativos” que você inscreve on-line e recebe por e-mail de um site. Por exemplo, EDR_Driver.sys pode assinar um serviço de notificação de "novo processo criado" usando uma API do Windows chamada PsSetCreateProcessNotifyRoutine, após a qual, para cada processo criado pelo sistema, o driver receberá informações sobre ele (PID pai, linha de comando, etc. .)
O usuário clica duas vezes em malware.exe
O Windows chama a API CreateProcessW para carregar malware.exe na memória
EDR_Driver.sys recebe uma notificação de que malware.exe será lançado.
EDR_Driver.sys envia um log para EDR_Process.exe com a mensagem: "Ei! Um novo processo chamado malware.exe será lançado em breve."
EDR_process.exe pode optar por agir (ou não): "Ok, vou monitorar esse processo criando ganchos em seu ntdll.dll"
Quando o malware.exe é executado, ele chama a API do Windows. Graças aos ganchos instalados, EDR_Process.exe sabe quais APIs estão sendo chamadas e pode descobrir o que o malware.exe está fazendo
Como exemplo de malware.exe, poderíamos pegar o seguinte trecho de código do site ired.team.
Depois que os ganchos são instalados, o agente EDR (EDR_process.exe) pode monitorar/analisar malware.exe. Aqui está um exemplo das ações que ele pode realizar:
EDR_Process.exe vê as seguintes chamadas de API do Windows feitas por malware.exe:
OpenProcess VirtualAllocEx WriteProcessMemory CreateRemoteThread
EDR_Process.exe classifica esta sequência de chamadas de API como "malicioso" e bloqueia (mata) o processo.
EDR_Process.exe envia um log para EDR_C2 (console de segurança) com a mensagem: “Ei, o processo malware.exe está em execução e classificado como malicioso”.
Nota: Este é um thread EDR normal e não é a única maneira de funcionar, por exemplo, EDR_Process.exe só pode enviar dados de telemetria e deixar EDR_C2 decidir se é malicioso e qual ação tomar (bloquear ou não).
Se o fornecedor de EDR ou os operadores da equipe de segurança (conhecidos como blueteam) configurarem uma regra "bloquear se mal-intencionado" no console de segurança do EDR, o processo malware.exe será eliminado por EDR_Process.exe (ou EDR_Driver.sys). Outras contramedidas também estão disponíveis, como:
O host do Windows pode ser isolado remotamente da rede
O arquivo malware.exe ou despejo de memória pode ser baixado para análise/reversão
um analista de segurança pode executar comandos em um host Windows (a partir do console de segurança) para fins investigativos
...
Este ponto é importante; Quanto mais experiente o blueteam tiver na criação de regras personalizadas, mais difícil será para os invasores escaparem da detecção ou se moverem lateralmente pela rede sem serem pegos!
Agora, antes de mergulhar na comunicação interna, quero dar um passo atrás e simplificar o comportamento do EDR. A comunicação interna (setas azuis) e a comunicação externa (setas amarelas) do EDR_Process.exe podem ser visualizadas com uma visão geral simples:
Explorando a comunicação interna do EDR
No espaço de memória do kernel do Windows, o EDR_Driver.sys pode usar várias APIs do kernel do Windows (retornos de chamada) para monitorar e bloquear atividades maliciosas do sistema.
Por exemplo, a função da API PsSetCreateProcessNotifyRoutine pode ser usada para gerar as seguintes mensagens de "log de monitoramento" graças ao mecanismo de retorno de chamada do kernel:
– Log = novo processo criado (PID 5376) com linha de comando C:\notepad.exe
Do espaço de memória do usuário, EDR_Process.exe pode enviar solicitações de ações ao driver e receber informações dele. Por exemplo, uma “Solicitação de ação” vinda do console de segurança EDR poderia ser:
– Ação = adicionar à lista negra C:\notepad.exe
Na figura abaixo, tentei exibir os retornos de chamada comuns do kernel do Windows usados para fins de monitoramento.
A questão que surge após a criação deste resumo é como evitar a interação entre EDR_process.exe e EDR_driver.sys? Cegueira de EDR usando técnicas conhecidas
As técnicas de cegamento de sensor EDR mais comuns incluem:
Removendo ganchos DLL (userspace)
Removendo retornos de chamada do kernel (espaço do kernel)
Como estamos nos concentrando apenas na parte do kernel do EDR, aqui está uma visualização do que acontece quando você remove os retornos de chamada do kernel:
ANTES de redefinir o endereço de retorno de chamada do EDR
APÓS redefinir o endereço de retorno de chamada EDR
Não entraremos em detalhes sobre este tópico, ele é abordado em Malware como uma arte - evitando a detecção comportamental de antivírus e EDR
Mas você pode notar na figura abaixo que toda vez que você redefinir o endereço de retorno de chamada do EDR, isso significa que não haverá mais notificações ( sem "transmissão") não será enviado do Windows para EDR_Driver.sys. Como resultado, nenhum log de eventos será enviado para EDR_Process.exe (e para o Security Analyst Console)!
Cegando o EDR usando uma abordagem alternativa
Durante minha pesquisa sobre este tópico, fiquei me perguntando como evitar a interação entre EDR_process.exe e EDR_driver.sys sem nenhuma alteração no retorno de chamada. Podemos evitar a troca de "mensagens" entre EDR_process.exe e EDR_Driver.sys?
Poderíamos imaginar uma abordagem diferente usando esta ilustração gráfica:
Enquanto eu tentava pesquisar usando o Windbg, Yarden Shafir escreveu um ótimo blog sobre Pesquisando portas de filtro de comunicação que realmente ajudou.
Descobri algumas estruturas de dados do Windows que são manipuladas durante a configuração da comunicação entre a aplicação e o driver.
Uma estrutura de dados chamada FLT_SERVER_PORT_OBJECT me chamou a atenção porque parecia conter alguns campos interessantes, veja se você concorda:
Quando vi isso, a primeira pergunta que me veio à mente foi: o que poderia acontecer se definissemos MaxConnections como zero?
Esta estrutura de dados é inicializada usando a API do driver do Windows chamada FltCreateCommunicationPort:
NTSTATUS FLTAPI FltCreateCommunicationPort(
[in] PFLT_FILTER Filter,
[out] PFLT_PORT *ServerPort,
[in] POBJECT_ATTRIBUTES ObjectAttributes,
[in, optional] PVOID ServerPortCookie,
[in] PFLT_CONNECT_NOTIFY ConnectNotifyCallback,
[in] PFLT_DISCONNECT_NOTIFY DisconnectNotifyCallback,
[in, optional] PFLT_MESSAGE_NOTIFY MessageNotifyCallback,
[in] LONG MaxConnections
);
Reputação8 198
12/02/2024
Adicionar um favorito
#1
1707738979550.png
Como continuação destes artigos:
ru-sfera.pw
Malware como arte - Arquitetura de sistemas antivírus e EDR
Tradução do artigo: SensePost | Sensecon 23: dos drivers do Windows a um edr quase totalmente funcional Resumo: Eu queria entender melhor o EDR (Endpoint Detection and Response), então criei um EDR fictício e falarei sobre ele aqui. EDR (Endpoint Detection and Response) é um tipo de produto...
ru-sfera.pw ru-sfera.pw
ru-sfera.pw
Malware como arte – Evitando a detecção comportamental de antivírus e EDR
Olá a todos! Este artigo examinou como o EDR pode funcionar arquitetonicamente: Malware como arte - Arquitetura de sistemas antivírus e EDR Recomendo a leitura do artigo acima primeiro. Continuando, vamos explorar como você pode ignorar a detecção associada ao comportamento em um dispositivo específico...
ru-sfera.pw ru-sfera.pw
Original: SensePost | Operação Filter-Mute: investigando a comunicação interna do edr
Para nossa conferência anual de hackers internos, que chamamos de SenseCon em 2023, decidi estudar a interação entre um driver do Windows e seu processo de modo de usuário.
Aqui estão alguns detalhes sobre essa jornada:
Os invasores podem usar uma primitiva de exploração de leitura/gravação do kernel do Windows para evitar a interação entre o EDR_Driver.sys e seu EDR_process.exe. Como resultado, alguns mecanismos de detecção de EDR serão desativados, tornando-o (parcialmente) cego para cargas maliciosas.
Este blog descreve uma abordagem alternativa que não remove retornos de chamada do kernel e fornece algumas recomendações para defesa contra esse ataque de "bloqueio de filtro".
Visão geral das funções EDR_process.exe e EDR_Driver.sys
A primeira pergunta que vem à mente é como o aplicativo EDR (EDR_Process.exe) se comunica com seu driver EDR (EDR_Driver.sys)?
Antes de fazermos a pesquisa, precisamos conhecer alguns princípios básicos de EDR; como o agente EDR injeta sua própria DLL no processo quando ele é criado?
Um diagrama de implementação de processos por meio de retornos de chamada, retirado das observações de EDR feitas por Christopher Vella, é um bom resumo.
1707739149233.png
Adicionei alguns comentários sobre o que está acontecendo:
EDR_Driver.sys pode assinar vários tipos de notificações de kernel. Você pode pensar nessas notificações como semelhantes a “boletins informativos” que você inscreve on-line e recebe por e-mail de um site. Por exemplo, EDR_Driver.sys pode assinar um serviço de notificação de "novo processo criado" usando uma API do Windows chamada PsSetCreateProcessNotifyRoutine, após a qual, para cada processo criado pelo sistema, o driver receberá informações sobre ele (PID pai, linha de comando, etc. .)
O usuário clica duas vezes em malware.exe
O Windows chama a API CreateProcessW para carregar malware.exe na memória
EDR_Driver.sys recebe uma notificação de que malware.exe será lançado.
EDR_Driver.sys envia um log para EDR_Process.exe com a mensagem: "Ei! Um novo processo chamado malware.exe será lançado em breve."
EDR_process.exe pode optar por agir (ou não): "Ok, vou monitorar esse processo criando ganchos em seu ntdll.dll"
Quando o malware.exe é executado, ele chama a API do Windows. Graças aos ganchos instalados, EDR_Process.exe sabe quais APIs estão sendo chamadas e pode descobrir o que o malware.exe está fazendo
Como exemplo de malware.exe, poderíamos pegar o seguinte trecho de código do site ired.team.
1707739290170.png
Depois que os ganchos são instalados, o agente EDR (EDR_process.exe) pode monitorar/analisar malware.exe. Aqui está um exemplo das ações que ele pode realizar:
EDR_Process.exe vê as seguintes chamadas de API do Windows feitas por malware.exe:
OpenProcess VirtualAllocEx WriteProcessMemory CreateRemoteThread
EDR_Process.exe classifica esta sequência de chamadas de API como "malicioso" e bloqueia (mata) o processo.
EDR_Process.exe envia um log para EDR_C2 (console de segurança) com a mensagem: “Ei, o processo malware.exe está em execução e classificado como malicioso”.
Nota: Este é um thread EDR normal e não é a única maneira de funcionar, por exemplo, EDR_Process.exe só pode enviar dados de telemetria e deixar EDR_C2 decidir se é malicioso e qual ação tomar (bloquear ou não).
Se o fornecedor de EDR ou os operadores da equipe de segurança (conhecidos como blueteam) configurarem uma regra "bloquear se mal-intencionado" no console de segurança do EDR, o processo malware.exe será eliminado por EDR_Process.exe (ou EDR_Driver.sys). Outras contramedidas também estão disponíveis, como:
O host do Windows pode ser isolado remotamente da rede
O arquivo malware.exe ou despejo de memória pode ser baixado para análise/reversão
um analista de segurança pode executar comandos em um host Windows (a partir do console de segurança) para fins investigativos
...
Este ponto é importante; Quanto mais experiente o blueteam tiver na criação de regras personalizadas, mais difícil será para os invasores escaparem da detecção ou se moverem lateralmente pela rede sem serem pegos!
Agora, antes de mergulhar na comunicação interna, quero dar um passo atrás e simplificar o comportamento do EDR. A comunicação interna (setas azuis) e a comunicação externa (setas amarelas) do EDR_Process.exe podem ser visualizadas com uma visão geral simples:
1707739422272.png
Explorando a comunicação interna do EDR
No espaço de memória do kernel do Windows, o EDR_Driver.sys pode usar várias APIs do kernel do Windows (retornos de chamada) para monitorar e bloquear atividades maliciosas do sistema.
Por exemplo, a função da API PsSetCreateProcessNotifyRoutine pode ser usada para gerar as seguintes mensagens de "log de monitoramento" graças ao mecanismo de retorno de chamada do kernel:
– Log = novo processo criado (PID 5376) com linha de comando C:\notepad.exe
Do espaço de memória do usuário, EDR_Process.exe pode enviar solicitações de ações ao driver e receber informações dele. Por exemplo, uma “Solicitação de ação” vinda do console de segurança EDR poderia ser:
– Ação = adicionar à lista negra C:\notepad.exe
Na figura abaixo, tentei exibir os retornos de chamada comuns do kernel do Windows usados para fins de monitoramento.
1707739616036.png
A questão que surge após a criação deste resumo é como evitar a interação entre EDR_process.exe e EDR_driver.sys? Cegueira de EDR usando técnicas conhecidas
As técnicas de cegamento de sensor EDR mais comuns incluem:
Removendo ganchos DLL (userspace)
Removendo retornos de chamada do kernel (espaço do kernel)
Como estamos nos concentrando apenas na parte do kernel do EDR, aqui está uma visualização do que acontece quando você remove os retornos de chamada do kernel:
ANTES de redefinir o endereço de retorno de chamada do EDR:
1707739707014.png
APÓS redefinir o endereço de retorno de chamada EDR:
1707739732730.png
Não entraremos em detalhes sobre este tópico, ele é abordado em Malware como uma arte - evitando a detecção comportamental de antivírus e EDR
Mas você pode notar na figura abaixo que toda vez que você redefinir o endereço de retorno de chamada do EDR, isso significa que não haverá mais notificações ( sem "transmissão") não será enviado do Windows para EDR_Driver.sys. Como resultado, nenhum log de eventos será enviado para EDR_Process.exe (e para o Security Analyst Console)!
1707739811893.png
Cegando o EDR usando uma abordagem alternativa
Durante minha pesquisa sobre este tópico, fiquei me perguntando como evitar a interação entre EDR_process.exe e EDR_driver.sys sem nenhuma alteração no retorno de chamada. Podemos evitar a troca de "mensagens" entre EDR_process.exe e EDR_Driver.sys?
Poderíamos imaginar uma abordagem diferente usando esta ilustração gráfica:
1707739920752.png
Enquanto eu tentava pesquisar usando o Windbg, Yarden Shafir escreveu um ótimo blog sobre Pesquisando portas de filtro de comunicação que realmente ajudou.
Descobri algumas estruturas de dados do Windows que são manipuladas durante a configuração da comunicação entre a aplicação e o driver.
Uma estrutura de dados chamada FLT_SERVER_PORT_OBJECT me chamou a atenção porque parecia conter alguns campos interessantes, veja se você concorda:
1707740027796.png
Quando vi isso, a primeira pergunta que me veio à mente foi: o que poderia acontecer se definissemos MaxConnections como zero?
Esta estrutura de dados é inicializada usando a API do driver do Windows chamada FltCreateCommunicationPort:
C:
Copiar para área de transferência
NTSTATUS FLTAPI FltCreateCommunicationPort(
[in] PFLT_FILTER Filter,
[out] PFLT_PORT *ServerPort,
[in] POBJECT_ATTRIBUTES ObjectAttributes,
[in, optional] PVOID ServerPortCookie,
[in] PFLT_CONNECT_NOTIFY ConnectNotifyCallback,
[in] PFLT_DISCONNECT_NOTIFY DisconnectNotifyCallback,
[in, optional] PFLT_MESSAGE_NOTIFY MessageNotifyCallback,
[in] LONG MaxConnections
);
A documentação da Microsoft diz o seguinte:
O que podemos deduzir? Se conseguirmos redefinir MaxConnections para zero, isso apenas impedirá a ocorrência de novas conexões. Vamos prosseguir com o seguinte plano de ataque:
Etapa 1: Redefinir MaxConnections
Etapa 2: Forçar a reinicialização do EDR_Process.exe (provavelmente requer privilégios elevados, provavelmente SISTEMA NT)
Etapa 3: Observar o comportamento do EDR
Etapa 1: Redefinir MaxConnections
Primeiro pré-requisito para esta etapa é ter uma primitiva de leitura/gravação no modo kernel que podemos usar para definir o valor como 0. Para isso usaremos a técnica BYOVD (Bring Your Own Vulnerable Driver) - A técnica é descrita aqui . Como segunda condição, precisamos encontrar o endereço do campo MaxConnections na memória do kernel, certo? Vamos ver como podemos conseguir esse endereço!
A estrutura fltmgr!_FLT_SERVER_PORT_OBJECT da qual falamos anteriormente pode ser alcançada através da estrutura fltmgr!_FLT_FILTER, que por sua vez pode ser alcançada através da estrutura fltmgr!_FLTP_FRAME, que pode ser alcançada através da estrutura FLTMGR!_GLOBALS, que pode ser alcançada através de FltMgr Driver .sys.
O endereço base deste módulo do kernel pode ser obtido no modo de usuário usando a API do Windows NtQuerySystemInformation.
Podemos encontrar o endereço MaxConnections percorrendo as estruturas de dados do kernel do Windows, começando pelo driver FltMgr.sys até este campo!
Esta é a aparência quando você deseja ver os detalhes sobre o driver do kernel do Windows Defender:
Com o conhecimento do layout de memória MaxConnections, podemos usar uma primitiva de leitura no modo kernel para obter o valor atual e, usando uma primitiva de gravação no modo kernel, podemos definir o valor como 0.
Etapa 2: Forçar a reinicialização do EDR
Esta fase pode ser complicada porque EDR_Process .exe faz o possível para se proteger. Normalmente este programa é executado como um serviço e será reiniciado após travar, mas isso não nos incomoda, pois nenhuma conexão é permitida pelo EDR_Driver.sys graças ao passo 1 
Pessoalmente, eu faço esta operação usando minha própria ferramenta (malicioso não assinado driver) que nos permite matar um processo mesmo que esteja protegido, mas também é possível usar Process Hacker (se não estiver na lista negra) ou, melhor ainda, qualquer "driver killer de processo" explorável.
Eu recomendo fortemente a postagem do blog de Alice Climent-Pommeret (@AliceCliment) "Encontrando e explorando drivers assassinos de processos LOL de $ 3.000", que cobre este tópico!
Etapa 3: observe o comportamento do EDR
Vamos criar um malware (código-fonte disponível em ired.team ) chamado iwanttobeflag.exe que é bloqueado pelo Windows Defender:
Podemos então testar a resposta padrão ao nosso malware, copiando a carga maliciosa da pasta compartilhada para a unidade local. Isso dispara um alarme e é bloqueado pelo Windows Defender, como esperado: ótimo!
copy z:\iwanttobeflag.exe c:\
Agora temos algo que geralmente deveria disparar um alarme e podemos usar isso para testar se nossa técnica de EDR está travando.
Implementando o Plano
Vamos juntar tudo isso em uma ferramenta e verificar se nossos passos 1 e 2 podem quebrar o alerta causado pelo passo 3.
Aqui está a ferramenta (EDRSnowblast): EDRSnowblast - nevasca em drivers EDR
Vamos seguir os passos ao vivo máquina e veja o que acontece!
1) liste os drivers (filtros) que estão carregados na memória do kernel e identifique o Windows Defender: WdFilter está na 9ª posição na figura abaixo
EDRSnowblast.exe filter-enum --kernelmode
2) obtenha detalhes sobre o WdFilter: por exemplo MaxConnections & NumberOfConnections
T4URHQHQA5XXFPQTJOSCWLZTZXKIZUKPXBSPNGUYYIWGF7RF2HZNRDQ3NI
[url=https://forumupload.ru/uploads/001b/c9/09/2/711206
.png]
[/url]
3) silenciar WdFilter: definir MaxConnections como zero
T4URHQHQA5XXFPQTJOSCWLZTZXKIZUKPXBSPNGUYYIWGF7RF2HZNRDQ3NI
4. (opcional) verifique o valor MaxConnections usando a opção --filter-enum conforme mostrado anteriormente
5. determine o PID do processo do Windows Defender no modo de usuário e elimine-o
tasklist | findstr MsMpEng.exe MsMpEng.exe 2956 Services 0 206,788 K c:\pimpmypid_clt.exe /kill 2956
T4URHQHQA5XXFPQTJOSCWLZTZXKIZUKPXBSPNGUYYIWGF7RF2HZNRDQ3NI
copy z:\iwanttobeflag.exe c:
c:\iwanttobeflag.exe
8. aproveite nosso sucesso
Se desejar, você pode assistir ao vídeo de demonstração abaixo.