Tiro do desenho animado "Era uma vez um cachorro"
Portanto, as ferramentas de monitoramento padrão estão se tornando insuficientes. Vários fatores contribuem para isso:
- indicadores de comprometimento (hashes, endereços IP e nomes de domínio) costumam ser usados uma única vez, já que alterá-los é fácil para um invasor, especialmente no caso de APT;
- os invasores usam arquivos executáveis legítimos, ferramentas padrão do sistema operacional, etc.;
- na maioria dos casos, não são explorações que são usadas para navegar na rede, mas credenciais legítimas roubadas;
- na prática, é freqüentemente encontrado malware que não é detectado por antivírus ou assinaturas de rede;
- Conforme a infraestrutura cresce, torna-se problemático atualizar as assinaturas e licenças no prazo.
Mesmo se o ataque for detectado com sucesso, você não terá informações suficientes para responder inequivocamente à pergunta: o incidente atual se esgotou ou algumas outras medidas são necessárias. Afinal, muitos eventos simplesmente não são rastreados: trabalhar com o registro, criar arquivos, carregar módulos na memória, a linha de comando do processo criado e assim por diante.
O monitoramento de endpoint expande significativamente a capacidade de detectar e prevenir ataques: permite que você vá desde a detecção de hashes, IP e domínios até a detecção de artefatos, ferramentas e TTP do host (sim, a própria "pirâmide da dor").
Alguns exemplos de técnicas que são frequentemente encontradas na prática e não são detectadas sem o monitoramento do host:
- DLL Hijacking
- Vivendo da terra
- Usando Mimikatz
O monitoramento de endpoint adicional pode ser feito usando ferramentas integradas do sistema operacional (auditoria avançada), utilitários gratuitos (como Sysmon) e soluções comerciais (produtos de classe EDR). Vamos considerar as vantagens e desvantagens dessas abordagens por exemplos de detecção de várias variações das técnicas acima.
Auditoria avançada. Registro de eventos do Windows
Todos sabem sobre auditoria integrada. Como mostra a prática, ao incluir apenas uma coleção de eventos de criação de processo junto com a linha de comando, você facilitará muito o processo de monitoramento e investigação de incidentes (lei de Pareto em ação).
Com a configuração adequada, fechamos algumas lacunas na abordagem padrão e vemos:
- fatos de iniciar processos junto com a linha de comando;
- Scripts decodificados do PowerShell (registro de bloco de script)
- parcialmente - trabalhar com arquivos e o registro;
- atividade relacionada a contas (criação / exclusão de usuários e assim por diante).
Temos a oportunidade de detectar novas técnicas:
- algumas opções de sequestro de DLL para criar arquivos com caminhos específicos;
- usando LOLBin e Mimikatz por padrões na linha de comando.
No entanto, um invasor ainda tem a capacidade de escapar da detecção. No caso do LOLBin, isso pode ser copiar o arquivo para outra pasta com um nome diferente e ofuscar a linha de comando. E o Mimikatz pode ser recompilado com comandos e linhas alterados, o que não permitirá a detecção de seu uso na linha de comando. Além disso, as opções não estarão visíveis quando um arquivo binário legítimo sujeito a sequestro de DLL for colocado na máquina.
Código Mimikatz com linhas modificadas
Você pode configurar a auditoria do Windows em qualquer sistema sem pré-instalar software de terceiros, mas também existem desvantagens significativas:
1. Configuração inconveniente e pouco escalonável.
Exemplo: para monitorar uma ramificação de registro específica, você precisa configurar separadamente a ACL para ela. O próprio facto de necessitar de alguma ação, na prática, traduz-se em problemas e atrasos de tempo, especialmente no caso de grandes infraestruturas. Se isso for feito para expandir o monitoramento (por exemplo, para detectar alguma forma de desvio do UAC), o tempo não será crítico. Mas se tal necessidade surgir durante um incidente, isso complica o processo de resposta.
2. Falta de controle.
Se os eventos deixarem de ser registrados ou de entrar nos sistemas de monitoramento utilizados, muito provavelmente não será possível entender isso a tempo, uma vez que não há centralização.
3. Facilidade de oposição.
Mesmo invasores com pouca habilidade sabem como se esconder das auditorias padrão. A única questão é com que eficácia e invisibilidade o farão.
Exemplos de técnicas:
- Limpeza regular de toras. A probabilidade de recuperação de evento bem-sucedida depende de quanto tempo se passou desde a limpeza.
- Suspender threads de serviço de auditoria e, em seguida, executar ações maliciosas ou excluir eventos (por exemplo, usando a ferramenta github.com/QAX-A-Team/EventCleaner ).
- Ocultando eventos quebrando a estrutura do arquivo .evtx correspondente .
- Redirecionamento temporário de eventos para um arquivo separado. Escrevemos sobre essa técnica no artigo anterior .
4. Por si só, a criação de uma auditoria não fornecerá uma oportunidade para organizar o monitoramento. Primeiro, você terá que estabelecer uma coleção centralizada de eventos e, em seguida, usar ferramentas adicionais, por exemplo, SIEM, para analisá-los.
5. Baixo conteúdo informativo dos eventos. Não há possibilidade de obter o hash do processo iniciado, monitorar o carregamento das bibliotecas na memória do processo e assim por diante.
Semelhanças entre Sysmon e EDR
Sysmon não é uma solução EDR completa, pois não fornece a capacidade de realizar ações proativas no sistema. Mas o mecanismo de coleta de eventos é exatamente o mesmo do EDR comercial: ele funciona em duas tecnologias - callbacks do kernel e ETW. Não os descreveremos em detalhes - apenas consideraremos como os eventos aparecem e quem é o iniciador de sua criação.
• Callbacks do kernel. Por exemplo, PcreateProcessNotifyRoutine, PcreateThreadNotifyRoutine.
Onde e como esses e outros retornos de chamada são chamados pode ser visto nas funções de kernel correspondentes. Um exemplo de chamada de retorno ao criar um processo é dado abaixo:
O loop de retorno de chamada em CreateProcessW → NtCreateUserProcess → PspInsertThread. Ou seja, chama esses retornos de chamada pelo encadeamento do processo pai chamado CreateProcess.
• Janelas de rastreamento de eventos (ETW).
ETW funciona de maneira semelhante para ocorrências de eventos. Vejamos o exemplo de criação de processo novamente. Quando CreateProcessW é chamado, o encadeamento do processo pai executa as seguintes ações (diagrama simplificado):
CreateProcessW (kernel32.dll)
NtCreateUserProcess (ntdll.dll, alternar para o modo kernel)
NtCreateUserProcess (ntoskrnl.exe, então trabalhar no modo kernel)
PspInsertTh (callbacks também são chamados aqui ' i)
EtwTraceProcess
EtwpPsProvTraceProcess
EtwWrite
Portanto, o encadeamento do processo pai é o iniciador direto do evento ETW. A gravação de outros eventos, por exemplo, eventos de rede, funciona aproximadamente da mesma maneira. Abaixo está um exemplo de criação de eventos relacionados à atividade de rede:
Função principal EtwpNetProvTraceNetwork
Do acima exposto, seguem duas conclusões:
- Tanto o Sysmon quanto o EDR usam apenas recursos nativos do Windows para coletar eventos e garantir uma operação confiável.
- Um invasor pode usar técnicas de ofuscação que se aplicam ao Sysmon e ao EDR. Os retornos de chamada do kernel podem ser descartados na memória do kernel usando um driver assinado. E conhecendo o mecanismo de registro de evento descrito, você pode entender porque o Sysmon e alguns EDRs não podem detectar certas técnicas de injeção no processo (por exemplo, usando APC) ou falsificação de PPID .
Sysmon
O uso do Sysmon permite expandir os recursos de auditoria padrão. Nesse caso, os eventos são registrados em um log separado. Alguns exemplos de informações não encontradas na Auditoria do Windows, mas disponíveis no Sysmon:
- informações mais detalhadas sobre os arquivos executáveis sendo iniciados (hash, nome original, assinatura digital e assim por diante);
- carregar drivers e bibliotecas;
- alterar o status do serviço Sysmon;
- criar um thread em outro processo;
- acesso ao processo;
- hashes de arquivos criados em fluxos de dados alternativos;
- criação de tubos.
As vantagens de monitorar os processos descritos acima são óbvias (existem muitas regras e artigos sobre o tópico de detecção de várias técnicas de domínio público). Além disso, é possível detectar novas variações de técnicas bem conhecidas:
- copiar LOLBin com um nome diferente pode ser detectado pela correspondência dos campos OriginalFileName, Image e Hashes do evento de criação do processo;
- você pode detectar o carregamento de bibliotecas não assinadas, o que em alguns casos permite detectar o sequestro de DLL;
- há a possibilidade de detectar Mimikatz usando os métodos acima ou pelo evento ProcessAccess para o processo lsass.exe.
A auditoria é configurada usando um arquivo de configuração, que no caso de criação de arquivo e eventos de registro é muito mais conveniente do que a configuração ACL.
Neste caso, os seguintes pontos devem ser levados em consideração:
- A necessidade de ferramentas adicionais. Como os eventos são registrados, como no caso da auditoria avançada do Windows, o Sysmon deve ser usado em conjunto com outras ferramentas, por exemplo, SIEM.
- . , Sysmon . .
, . - -. , . , Sysmon . : , , .
Você pode ler sobre maneiras de contornar alguns dos recursos do Sysmon aqui , aqui e aqui .
Detecção e resposta de endpoint
Conforme a infraestrutura cresce em tamanho e criticidade, as falhas do Sysmon tornam-se significativas. EDRs de alta qualidade têm várias vantagens (não descreveremos recursos específicos do produto):
1) Conjunto estendido de eventos registrados
Tudo depende do produto específico. Por exemplo, há um registro de todas as entradas interativas na linha de comando, o que permite detectar técnicas que não são visíveis com a auditoria do Windows ou com o Sysmon.
Vale a pena descrever o caso de uso para Mimikatz que vimos durante uma de nossas investigações. Há um arquivo executável que contém Mimikatz criptografado em recursos. Quando a senha correta e o vetor de inicialização são passados na linha de comandos, o Mimikatz descriptografa com êxito e aceita os comandos na linha de comandos interativa. Ao mesmo tempo, nenhum comando aparece nos eventos de criação do processo.
O registro da entrada interativa, por sua vez, ajudará a detectar tal caso se o Mimikatz não for recompilado (em nosso caso, as linhas não foram alteradas).
2) Gerenciamento e configuração centralizada
Em uma grande infraestrutura, a capacidade de verificar centralmente a integridade e alterar as configurações do agente é crítica. Sem ele, a resposta pode ser atrasada por horas ou até dias.
3) Autossuficiência
Na maioria dos casos, o EDR é um produto independente com interface própria, que pode ser usado não só em conjunto com outras ferramentas, mas também separadamente.
Pode ser possível escrever suas próprias regras de detecção. Como o conjunto de dados disponíveis é maior do que o da Auditoria Avançada ou Sysmon, os analistas têm mais oportunidades de detectar diferentes padrões de ataque.
4) Possibilidade de resposta ativa
Durante uma resposta a incidentes, a necessidade de agir em vários sistemas quase sempre se torna um problema.
EDR permite que você execute muitas ações em uma forma interativa conveniente:
- trabalhar com arquivos e registro
- bloquear conexões de rede
- encerrar processos
- escanear com as regras yara
- coletar artefatos para análise posterior (por exemplo, uma imagem de memória)
- automação de todos os itens acima em um grau ou outro
- e muito mais.
Uma vez que a classe de produtos EDR foi originalmente criada para fornecer monitoramento e resposta de host, há significativamente menos desvantagens para tais soluções nesta área. Tudo depende dos recursos de um determinado produto. Também existem pontos cegos, por exemplo, não há uma análise aprofundada da atividade da rede (um problema que é resolvido com sucesso por produtos NTA / NDR).
A prática mostra que a presença de EDR na infraestrutura amplia significativamente as capacidades de identificação de ameaças, além de agilizar a resposta e facilitar a investigação de incidentes, permitindo uma reconstrução mais precisa da cronologia dos eventos. Sysmon atua como uma meia-medida e, no caso de apenas uma auditoria padrão, que é fácil de ignorar, você tem que se contentar com artefatos menos informativos, incluindo os incomuns, sobre os quais escrevemos no artigo anterior .
Postado por Asker Jamirze, Engenheiro Técnico Sênior de Investigação, Departamento de Investigação de Incidentes, JSOC CERT