Guia de análise de ameaças Sysmon, parte 1

Este artigo é a primeira parte de uma série sobre análise de ameaças Sysmon. Todas as outras partes da série:

Parte 1: Introdução à Análise de Log Sysmon (Estamos aqui)
Parte 2: Usando dados de eventos Sysmon para identificar ameaças
Parte 3. Análise aprofundada de ameaças Sysmon usando gráficos

Se você trabalha com segurança da informação, provavelmente precisará entender os ataques contínuos. Se você já tem um olhar treinado, pode procurar atividades fora do padrão nos logs “brutos” não processados ​​– digamos, um script do PowerShell em execução com o comando DownloadString ou um script VBS fingindo ser um arquivo Word - simplesmente percorrendo a atividade mais recente no log de eventos do Windows. Mas isso é uma grande dor de cabeça. Felizmente, a Microsoft criou o Sysmon, que torna a análise de ataques muito mais fácil.

Quer entender as ideias básicas por trás das ameaças exibidas no log do Sysmon? Baixe nosso guia Eventos WMI como meio de espionagem e você percebe como os insiders podem observar sub-repticiamente outros funcionários. O principal problema ao trabalhar com o log de eventos do Windows é a falta de informações sobre os processos pai, ou seja, é impossível entender a hierarquia dos processos a partir dele. As entradas de log do Sysmon, por outro lado, contêm o ID do processo pai, seu nome e a linha de comando a ser iniciada. Obrigado, Microsoft.

Na primeira parte de nossa série, veremos o que você pode fazer com as informações básicas do Sysmon. Na Parte XNUMX, aproveitaremos ao máximo as informações do processo pai para criar estruturas de conformidade mais complexas, conhecidas como gráficos de ameaças. Na terceira parte, veremos um algoritmo simples que verifica um gráfico de ameaças em busca de atividades incomuns, analisando o “peso” do gráfico. E no final, você será recompensado com um método probabilístico de detecção de ameaças simples (e compreensível).

Parte 1: Introdução à Análise de Log Sysmon

O que pode ajudá-lo a compreender as complexidades do log de eventos? Em última análise - SIEM. Normaliza eventos e simplifica sua análise posterior. Mas não precisamos ir tão longe, pelo menos não no início. No início, para compreender os princípios do SIEM, bastará experimentar o maravilhoso utilitário gratuito Sysmon. E ela é surpreendentemente fácil de trabalhar. Continue assim, Microsoft!

Quais recursos o Sysmon possui?

Resumindo - informações úteis e legíveis sobre os processos (veja as fotos abaixo). Você encontrará vários detalhes úteis que não estão no Log de Eventos do Windows, mas os mais importantes são os seguintes campos:

• ID do processo (em decimal, não hexadecimal!)
• ID do processo pai
• Linha de comando do processo
• Linha de comando do processo pai
• Hash de imagem de arquivo
• Nomes de imagens de arquivos

Sysmon é instalado como driver de dispositivo e como serviço - mais detalhes aqui. Sua principal vantagem é a capacidade de analisar logs de vários fontes, correlação de informações e saída de valores resultantes para uma pasta de log de eventos localizada ao longo do caminho Microsoft -> Windows -> Sysmon -> Operacional. Em minhas próprias investigações arrepiantes de log do Windows, tive que alternar constantemente entre, digamos, a pasta de logs do PowerShell e a pasta Segurança, folheando os logs de eventos em uma tentativa corajosa de correlacionar de alguma forma os valores entre os dois. Esta não é uma tarefa fácil e, como percebi mais tarde, era melhor estocar aspirina imediatamente.

Sysmon dá um salto quântico ao fornecer informações úteis (ou, como os fornecedores gostam de dizer, acionáveis) para ajudar a compreender os processos subjacentes. Por exemplo, iniciei uma sessão secreta wmiexec, simulando o movimento de um insider inteligente dentro da rede. Isto é o que você verá no log de eventos do Windows:

O log do Windows mostra algumas informações sobre o processo, mas são de pouca utilidade. Mais IDs de processo em hexadecimal???

Para um profissional de TI com conhecimento dos fundamentos de hacking, a linha de comando deve ser suspeita. Usar cmd.exe para executar outro comando e redirecionar a saída para um arquivo com um nome estranho é claramente semelhante às ações do software de monitoramento e controle comando e controle (C2): Desta forma, um pseudo-shell é criado usando serviços WMI.
Agora vamos dar uma olhada no equivalente da entrada Sysmon, observando quanta informação adicional ela nos fornece:

Recursos do Sysmon em uma captura de tela: informações detalhadas sobre o processo em um formato legível

Você não vê apenas a linha de comando, mas também o nome do arquivo, o caminho para o aplicativo executável, o que o Windows sabe sobre ele (“Processador de Comando do Windows”), o identificador parental processo, linha de comando o pai, que iniciou o shell cmd, bem como o nome real do arquivo do processo pai. Tudo em um só lugar, finalmente!
A partir do log do Sysmon podemos concluir que com um alto grau de probabilidade esta linha de comando suspeita que vimos nos logs “brutos” não é o resultado do trabalho normal do funcionário. Muito pelo contrário, ele foi gerado por um processo semelhante ao C2 - wmiexec, como mencionei anteriormente - e foi gerado diretamente pelo processo de serviço WMI (WmiPrvSe). Agora temos um indicador de que um invasor remoto ou interno está testando a infraestrutura corporativa.

Apresentando Get-Sysmonlogs

Claro que é ótimo quando o Sysmon coloca os logs em um só lugar. Mas provavelmente seria ainda melhor se pudéssemos acessar campos de log individuais de forma programática - por exemplo, por meio de comandos do PowerShell. Nesse caso, você poderia escrever um pequeno script do PowerShell que automatizaria a busca por ameaças potenciais!
Não fui o primeiro a ter essa ideia. E é bom que em algumas postagens do fórum e no GitHub projetos Já foi explicado como usar o PowerShell para analisar o log do Sysmon. No meu caso, eu queria evitar ter que escrever linhas separadas de script de análise para cada campo Sysmon. Então usei o princípio do homem preguiçoso e acho que descobri algo interessante como resultado.
O primeiro ponto importante é a capacidade da equipe Get-WinEvent leia os logs do Sysmon, filtre os eventos necessários e envie o resultado para a variável PS, como aqui:

$events = Get-WinEvent  -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}

Se você quiser testar o comando, exibindo o conteúdo no primeiro elemento do array $events, $events[0].Message, a saída pode ser uma série de strings de texto com um formato muito simples: o nome do Campo Sysmon, dois pontos e, em seguida, o próprio valor.

Viva! Gerando log do Sysmon em formato pronto para JSON

Você está pensando a mesma coisa que eu? Com um pouco mais de esforço, você pode converter a saída em uma string formatada em JSON e carregá-la diretamente em um objeto PS usando um comando poderoso ConverterFrom-Json .
Mostrarei o código do PowerShell para a conversão – é muito simples – na próxima parte. Por enquanto, vamos ver o que meu novo comando chamado get-sysmonlogs, que instalei como um módulo PS, pode fazer.
Em vez de nos aprofundarmos na análise de log do Sysmon por meio de uma interface de log de eventos inconveniente, podemos pesquisar facilmente atividades incrementais diretamente de uma sessão do PowerShell, bem como usar o comando PS onde (alias – “?”) para encurtar os resultados da pesquisa:

Lista de shells cmd iniciados via WMI. Análise de ameaças barata com nossa própria equipe Get-Sysmonlogs

Maravilhoso! Criei uma ferramenta para pesquisar o log do Sysmon como se fosse um banco de dados. Em nosso artigo sobre EQL notou-se que esta função será executada pelo utilitário legal descrito nela, embora formalmente ainda por meio de uma interface real semelhante a SQL. Sim, EQL elegante, mas abordaremos isso na terceira parte.

Sysmon e análise gráfica

Vamos dar um passo atrás e pensar sobre o que acabamos de criar. Essencialmente, agora temos um banco de dados de eventos do Windows acessível através do PowerShell. Como observei anteriormente, existem conexões ou relacionamentos entre registros - através do ParentProcessId - para que uma hierarquia completa de processos possa ser obtida.

Se você leu a série "As aventuras do malware indescritível" você sabe que os hackers adoram criar ataques complexos em vários estágios, nos quais cada processo desempenha seu próprio papel e prepara um trampolim para a próxima etapa. É extremamente difícil capturar essas coisas simplesmente a partir do registro “bruto”.
Mas com meu comando Get-Sysmonlogs e uma estrutura de dados adicional que veremos mais adiante no texto (um gráfico, é claro), temos uma maneira prática de detectar ameaças - o que requer apenas fazer a pesquisa correta no vértice.
Como sempre acontece com nossos projetos de blog DYI, quanto mais você trabalhar na análise dos detalhes das ameaças em pequena escala, mais perceberá o quão complexa é a detecção de ameaças no nível empresarial. E esta consciência é extremamente ponto importante.

Encontraremos as primeiras complicações interessantes na segunda parte do artigo, onde começaremos a conectar eventos Sysmon entre si em estruturas muito mais complexas.

Fonte: habr.com