Get best of the week

Windows vs Sysmon


Na última conferência do ZeroNights, no curso da comunicação informal com nossos colegas no sistema de monitoramento, nos fizeram uma pergunta simples à primeira vista - acreditava-se amplamente que o Sysmon deveria ser usado para monitorar completamente o endpoint no sistema operacional Windows, é isso? E se sim, por que motivos específicos (olá Seryozha!)? Não conseguimos encontrar uma resposta abrangente e inequívoca em nossa bagagem de conhecimento ou uma comparação correspondente na Internet; portanto, antes de tudo, para nós mesmos e não menos importante, para que no futuro tal fonte ainda estivesse disponível na comunidade, decidimos explorar este tópico. e compare os eventos presenciais do Windows e do Sysmon. Como diz o ditado, "1 ... 2 ... 3 ... Lute!".


Introdução


Qualquer especialista no campo da segurança da informação é forçado a trabalhar dentro de uma determinada estrutura. Por exemplo, dentro de um orçamento limitado, a segurança, com raras exceções, não é a principal maneira de uma organização obter lucro ou executar outras funções em seu negócio principal. Portanto, em condições de recursos limitados que a organização possui, apenas uma pequena parte deles é frequentemente alocada ao setor de segurança, a fim de manter essa direção no nível mínimo suficiente (de acordo com certos requisitos). Mesmo com recursos ilimitados, sempre haverá outras restrições que não permitem elevar o nível de segurança ao absoluto. Essas são as vulnerabilidades notórias do dia zero ou normal (gerenciamento sem fim de patches) e a corrida armamentista constante de hackers e seguranças,e o dinamismo do desenvolvimento da infraestrutura de TI e muito, muito mais.

Sob esse prisma, mais do que nunca, a questão de priorizar os meios e métodos de proteção é urgente, inclusive na direção do monitoramento. Nesta área, de acordo com estatísticas baseadas nos dados da matriz MITRE ATT & CK , que já escrevemos sobre a última vez, as prioridades são as seguintes: o primeiro lugar incondicional é tomado por uma fonte de eventos de segurança como pontos de extremidade.


Essa fonte leva ao número de técnicas de matriz que podem ser identificadas com base nos eventos registrados nela. O sistema operacional mais comum para terminais continua sendo o Microsoft Windows. A coleta exata de seus logs na maioria das infra-estruturas corporativas fornecerá o melhor resultado na proporção de todos os tipos de custos para a cobertura de dispositivos de rede e a cobertura de técnicas maliciosas. Isso é confirmado pelas estatísticas dos mesmos autores. Os lugares 1-3, 5, 7, 8, 10 e parte 4 ocupam apenas os chamados eventos básicos.


Mas, como na famosa piada, há uma ressalva. Nos últimos anos, tornou-se amplamente aceito que os logs do Windows precisam ser complementados, se não substituídos, pelos eventos Sysmon - eles dizem que são mais completos, melhores e mais adaptados como uma ferramenta de monitoramento do ponto de vista da segurança da informação.

Além disso, essa abordagem atende de alguma forma ao conceito de minimalismo. Cada produto de software que você está tentando adicionar aos seus ou voluntariamente dado a você por um cliente corporativo é um aumento na área de ataque, custos de administração e atualização e pontos de falha. E muitas vezes - e apenas o tempo antes da implementação do seu sistema de monitoramento, enquanto sua abordagem passa na aprovação.

O Sysmon foi desenvolvido por especialistas da Microsoft e recentemente absorvido por esta corporação, o que fornece um certo nível de confiança por parte da TI. Além disso, os logs são gravados na forma de um log .evtx, que permite coletá-los e processá-los usando as mesmas ferramentas e métodos que os logs regulares do Windows.

Faça imediatamente uma reserva de que o artigo acabou sendo grande, embora tentemos duplicar e compactar o material minimamente. O leitor, é claro, pode dizer, nos referindo à piada sobre Lenin: "Mas ele poderia ter cortado ...". Ou que "a publicação pode ser dividida em duas ou três partes para maior legibilidade". Mas pareceu-nos que, apesar do volume do material preparado, devemos fornecer uma resposta completa à pergunta de nossos colegas da loja, e a pesquisa será mais conveniente. Portanto, para não perder nada, recomendamos que você leia o artigo 1 completamente, talvez faça anotações para si mesmo e só depois retorne a grupos específicos de eventos e os examine detalhadamente.

Por conveniência, nós adicionamos uma tabela de conteúdo:
Introdução
Índice
formato Comparação
criar um processo
Conexões de rede
Terminar um processo de
baixar um driver
de acesso a um processo de
criação de um arquivo de
ações de registro
WMI configuração
consultas DNS
exclusivo SYSMON
eventos Filtrando Eventos
Outros provedores de eventos base livre
de saída Geral

Formato de comparação


Por que e o que foi comparado, parece claro. E como isso foi feito e por que exatamente?

Decidimos fazer uma comparação na forma de uma tabela para cada um dos grupos de eventos que refletem uma determinada atividade no sistema. Por exemplo, eventos com o ID (ID do evento, EID) 12, 13 e 14 no Sysmon, refletindo a atividade com o registro, nem sequer são filtrados separadamente, embora falem de ações atômicas diferentes. Pela mesma lógica, o restante do agrupamento foi feito.

Esses grupos incluíram apenas eventos semelhantes. Por exemplo, um análogo do evento Sysmon EID 6 é o evento Windows EID 6. Ao mesmo tempo, existem pelo menos 219 e 7036 eventos do Windows sobre o carregamento de drivers. Mas eles surgem em caso de falha. Essa. não carregam a mesma carga semântica e, se necessário, podem complementar os eventos do Sysmon ou Windows, dependendo do que decidimos coletar.

Para grupos de eventos refletidos na tabela, os campos informativos (que usamos para fins de monitoramento) contidos nos eventos são apresentados na forma de cadeias. Para cada um desses campos, seu nome é indicado. No Windows, são possíveis 2 opções, para visualizações em XML e em revistas (quem pensaria que corresponderiam?) Se diferirem mais do que por espaços. Isso é feito porque o nome do campo que cairá no sistema de monitoramento pode depender do método de coleta. As linhas também contêm dados do evento (para entender seu formato) e um comentário (se em nossa opinião isso for necessário).

Os campos com a mesma carga semântica para ambas as fontes são combinados em uma linha. Na ausência de um campo com carga semântica semelhante para uma das fontes, traços ("-") são indicados nos campos correspondentes a ele.

Linhas contendo informações sobre uma entidade específica, por exemplo, o sujeito que está executando a ação, são combinadas em um grupo semântico.

A comparação foi feita para versões do Windows Kernel 6.3 (Windows 2012R2) e 10.0 (Windows 10, 2016, 2019). As versões anteriores não foram consideradas, pois, embora ainda sejam difundidas, estão desaparecendo gradualmente. Se os eventos para diferentes versões do kernel não diferirem, as colunas foram combinadas em uma para reduzir a duplicação.

Como a taxa é de tempo integral, as colunas são organizadas na seguinte ordem, do centro às bordas: dados, nome do campo, comentário. Isso torna a comparação mais visual. Para a separação visual das colunas de acordo com as fontes às quais elas se referem, são usadas cores.

Exclusivo do Sysmon EID (uma vez que, neste caso, é uma ferramenta complementar, a gravação de logs do SO está incluída na funcionalidade básica do SO) é fornecida em uma seção separada.

A seção com a tabela mostra as configurações de GPO que devem ser feitas para habilitar a gravação no log de eventos do grupo, como o número de opções possíveis de auditoria é geralmente bastante grande. Para Sysmon, essas configurações não são mostradas porque todos eles estão contidos em um único arquivo de configuração.

Criação de processo


Paradoxalmente, eles decidiram começar do começo. E eles também não eram originais e estavam em ordem - aumentando o EID Sysmon.

O registro de dados do evento no Windows é ativado da seguinte maneira:

• Configuração do computador - Diretivas - Configurações do Windows - Configurações de segurança - Configuração avançada da diretiva de auditoria - Diretivas de auditoria - Acompanhamento detalhado - Criação do processo de auditoria - O êxito permite o registro do próprio evento;

• Configuração do computador - Diretivas - Modelos administrativos - Sistema - Criação de processos de auditoria - Incluir linha de comando nos eventos de criação de processo - adiciona a linha de comando do processo iniciado ao evento, o que geralmente possibilita distinguir uma partida legítima de uma partida ilegítima.

A comparação no formato descrito acima é apresentada na tabela a seguir.


A seguir, todas as tabelas são representadas por figuras e são clicáveis. Como, em primeiro lugar, não encontramos uma boa maneira de transferir tabelas para Markdown ou HTML, preservando a largura ou hifenização da coluna de acordo com a versão existente no Excel. E segundo, o conteúdo deles não é muito valioso para indexação, exceto para comentários. Muito mais valioso nas tabelas é a composição dos campos discutidos neste artigo e o formato de dados com o qual você precisará trabalhar se essas fontes de eventos forem usadas.

Considere-o em ordem, mas não linha por linha - cada um fará uma análise detalhada por si mesmo. Nesta seção e abaixo, abordaremos apenas as informações encontradas pela primeira vez. Comece imediatamente com um exemplo desse comportamento. Os campos da seção Sistema estão presentes em todos os eventos que caem no log, independentemente da origem - Sysmon ou Windows. Eles incluem informações gerais:

  • O nome do provedor de eventos.
  • EID
  • A hora em que o evento foi registrado.
  • O nome da revista de onde recebemos esse evento.
  • O host no qual o evento ocorreu.

O nome do provedor e o log após a conexão geralmente não são usados ​​pelo analista. Mas eles possibilitam entender onde e quem grava os logs, o que é importante se o processo de coleta ainda não tiver sido iniciado. Tempo, host e EID são os principais beacons pelos quais a filtragem primária de eventos é realizada.

Além disso, entre os campos que eu particularmente gostaria de observar - o GUID da sessão do usuário e dos processos filho e pai existe apenas nos logs do Sysmon. E para o mesmo cofrinho, por esquisitices - o ID do processo (novo e pai) nos eventos do Windows é gravado em hexadecimal, embora seja exibido em notação decimal no mesmo Gerenciador de Tarefas. Como diz o ditado, depuração feliz ("-Quer melhorar? -Github") ...

A linha de comando ao iniciar um processo nos eventos do Windows tem um formato diferente, dependendo do utilitário usado para iniciá-lo. Mas em Sysmon, os autores queriam e podiam - o formato não depende de outras informações. Não vou julgar os motivos, mas os criadores do conteúdo do SIEM não escreverão graças a Microsoft sobre isso, com certeza.

O principal recurso distintivo do Sysmon para isso, assim como para outros eventos que contêm esse campo, eu chamaria o hash do arquivo executável. O formato hash é selecionado na configuração do Sysmon.

Novamente, dos bônus adicionais interessantes de Sysmon - o campo Nome da regra. Essa é, de fato, uma tag que é conveniente para marcar certos filtros no arquivo de configuração e usá-la na análise de eventos. Por exemplo, podemos dizer que o processo inicial X se refere às táticas Y ou técnica Z. Essa abordagem é interessante tanto do ponto de vista do analista quanto do desenvolvedor de conteúdo SIEM ou Sysmon - nos permite entender o motivo pelo qual decidimos coletar esse evento.

Conclusão


Sysmon é muito melhor para corrigir esse grupo de eventos:

  • GUID , , , , ID ( ). , , . . ID , , SIEM, . GUID, — .
  • — — , , . — Sysmon , SIEM ( ). - — , . , SIEM . , , IBM QRadar. , - . , , — Windows , , .
  • Rule Name .
  • A aplicabilidade dos campos exclusivos restantes, nos eventos do Windows e nos eventos Sysmon, desempenha um papel, como se costuma dizer em inglês, caso a caso. Portanto, para decidir sobre a escolha de um log específico, ou em geral combiná-los, também é necessário caso a caso.

Conexões de rede


Gravando esses eventos no Windows: Configuração do computador - Diretivas - Configurações do Windows - Configurações de segurança - Configuração avançada da diretiva de auditoria - Diretivas de auditoria - Acesso a objetos - Conexão da plataforma de filtragem de auditoria

Por que você decidiu se concentrar nos eventos da Plataforma de Filtragem do Windows (WFP), e não no Firewall do Windows? A resposta é simples. Com base em nossa prática, os pontos de extremidade na forma de antivírus já estão nos hosts de qualquer maneira. Embora eles não sejam projetados para monitorar os eventos básicos do sistema (é por isso que não são adequados para nossos propósitos), no entanto, nas realidades modernas, eles sempre incluem um firewall de host. Por esse motivo, para evitar duplicação, o Firewall do Windows geralmente é simplesmente cancelado. Dessa forma, ninguém escreve para o coronel ... no entanto, embora ele possa filtrar o tráfego, nós o usamos apenas para monitoramento. Portanto, a duplicação está ausente.


A tabela mostra que, se tentarmos confiar nos eventos do Windows, o ultrassom do usuário e o FQDN dos hosts em interação precisarão ser restaurados pelo enriquecimento do evento. Embora, se você pensar bem, é mais importante sabermos qual processo estabeleceu a conexão e não qual usuário. Por exemplo, o malware vai para o seu centro de C&C. De qualquer forma, queremos descobrir quem iniciou o processo ou criar um incidente com base no entendimento de que o bloco de notas não vai para a própria Internet (ou seja, com base nas informações disponíveis no evento).

E com o FQDN é ainda mais simples - todos os sistemas modernos incluem o componente CMDB como uma funcionalidade básica ou adicional. Se não, definitivamente vale a pena estocar uma solução de terceiros. Conhecer sua infraestrutura é a base da segurança da informação em geral. Portanto, as informações estão disponíveis por meio de enriquecimento ou por meio de um cartão de ativos, o que permitirá seu uso em correlação. O principal é, se possível, não esquecer de conectar os logs do DHCP para que as informações estejam atualizadas.

Todos os outros campos exclusivos não são tão significativos, por exemplo:

  • Portos famosos. Não confiaríamos nesse campo - não é em vão que existem meios para detectar anomalias no tráfego quando, por exemplo, o túnel ssh passa pela porta 80 em vez de HTTP.
  • Direção de tráfego. Conhecendo o ID do host (IP ou FQDN) e a origem \ destino da conexão, você pode calcular facilmente a direção.

Conclusão


E, nesse caso, o Sysmon vence, mas menos significativamente - o GUID, o FQDN, o usuário fornece uma conveniência que é bem possível de se obter usando SIEM ou soluções de terceiros. No entanto, pequenos esforços não significam zero.

Conclusão do processo


Em geral, o evento, como já mencionado acima, não é muito usado, mas ...


Se for necessário, há uma vitória clara do lado do Windows. Nós adicionamos apenas como habilitar o log e vamos direto às conclusões.

Configuração do computador - Políticas - Configurações do Windows - Configurações de segurança - Configuração avançada da política de auditoria - Políticas de auditoria - Rastreamento detalhado - Encerramento do processo de auditoria - Sucesso

Conclusão


Nesse caso, a vantagem do log do SO nativo é obtida por:

  • Exibe o usuário que concluiu o processo.
  • A presença do código de saída, que pode falar sobre a conclusão regular do processo, bem como erros.

Download do driver


Esse evento do Windows, diferente dos outros, é ativado por padrão e entra no log do sistema. Não há muitos campos informativos nesses eventos.


E, novamente, imediatamente para as conclusões.

Conclusão


Nesse grupo, os eventos Sysmon fornecem ao analista informações muito mais úteis. Por exemplo, de acordo com os eventos do Windows, ainda não está claro qual arquivo de driver foi usado. Portanto, neste grupo de Windows em estranhos explícitos.

Acesso ao processo


Não classificamos esse grupo de eventos como básico, mas como um nível ligeiramente avançado. Do ponto de vista da segurança, o evento pode ser de grande interesse. Há muitas maneiras pelas quais um processo malicioso pode tornar seu legítimo pouco "melhor". Obviamente, não pelo altruísmo, mas por ações maliciosas. E os eventos em consideração nos ajudarão a descobrir muitas opções para essa criatividade. Esses logs são ativados em Configuração do Computador - Diretivas - Configurações do Windows - Configurações de Segurança - Configuração Avançada da Política de Auditoria - Diretivas de Auditoria - Acesso a Objetos - Objeto do Kernel de Auditoria - Sucesso


O Windows tem duas vantagens. Primeiramente, o mapeamento do usuário do qual o processo de origem está trabalhando. Como observamos acima, a vantagem é geralmente insignificante. E, em segundo lugar, HandleID e direitos de acesso.

Se o interesse nos direitos de acesso for claro, o HandleID será útil apenas para pesquisar eventos relacionados. É necessário organizar a interação do usuário por meio de processos com objetos do SO - os mesmos processos (seus encadeamentos), arquivos etc. Consequentemente, eventos adicionais podem mostrar como, como resultado, e para quem foi emitido e quando o identificador necessário para o acesso foi revogado.

Tocando pela primeira vez nos tópicos de objetos e manuseio, além de registrar ações com eles, é importante observar duas coisas.

Primeiro, para registrar as etapas adicionais acima, é importante habilitar configurações adicionais para políticas de auditoria, em particular Configuração do Computador - Políticas - Configurações do Windows - Configurações de Segurança - Configuração Avançada da Política de Auditoria - Políticas de Auditoria - Acesso a Objetos - Manipulação de Identificador de Auditoria - Sucesso. Vale lembrar que o volume desses eventos pode ser muito grande. O identificador é emitido após o recebimento de uma solicitação, respectivamente, reflete os direitos reivindicados. Mas por que não podemos esperar o mesmo volume de eventos diretamente da auditoria de acesso a objetos?

Isso ocorre porque, em segundo lugar, é necessário ativar a SACL no objeto planejado para ser controlado. De fato, esta é uma lista semelhante à lista de direitos de acesso DACL, que determina se o assunto ou objeto criado com seu token receberá êxito ou falha ao tentar acessar o objeto. Mas a SACL determina aproximadamente da mesma forma não os direitos de interagir com o objeto, mas se os eventos de segurança serão gerados ao solicitar e exercer determinados direitos. Esses eventos incluirão ainda não solicitados, mas realmente usaram direitos de acesso.

Como resultado, obtemos um filtro que permite registrar apenas o acesso a objetos críticos para nós e apenas os tipos de acesso que são importantes para nós. Mas, em troca, devemos anexar uma SACL diretamente a cada objeto ou indicar que a SACL é herdada do objeto pai. Obviamente, isso pode ser automatizado por vários métodos. Porém, é improvável que seja conveniente manter a configuração dessas ferramentas de automação. Ao contrário de uma lista Sysmon simples, que também pode incluir caracteres curinga, embora sejam peculiares. Falaremos sobre a filtragem no Sysmon em uma seção separada.

Felizmente, para objetos do tipo, um processo SACL já existe por padrão para a versão 6.3 e superior do kernel. Se alguém puder especificar uma maneira de receber essa SACL (recomendações deste artigofalhamos em cumprir), será interessante ouvir / discutir.

No lado do Sysmon, além dos GUIDs e nomes de regras já discutidos, existem vários campos mais interessantes. Primeiro, o PID do processo de destino. Isso permitirá que você monitore a atividade subseqüente do objeto infectado, porque pode haver várias instâncias de um arquivo executável. Em segundo lugar, o campo CallTrace, que captura as ações da fonte de eventos no destino. Olhe para isso e perceba que "truque de mão e nenhuma fraude" não são apenas palavras. Por outro lado, uma análise tão detalhada já é o destino da perícia. E quem tem um forense dedicado provavelmente não está no início do caminho para a construção de um sistema de monitoramento.

Conclusão


Nesse grupo, os eventos diferem em um número bastante grande de campos. Porém, se nos eventos do Windows essas informações provavelmente fornecerem a conveniência da análise inicial, o Sysmon captura dados exclusivos que são difíceis de obter de qualquer outra maneira. Portanto, a vantagem permanece com o Sysmon.

Criação de arquivo


Esta categoria está incluída no Windows da seguinte maneira: Configuração do computador - Diretivas - Configurações do Windows - Configurações de segurança - Configuração avançada da diretiva de auditoria - Diretivas de auditoria - Acesso a objetos - Sistema de arquivos de auditoria - Sucesso


Como pode ser visto na tabela, todos os prós e contras desse grupo são semelhantes aos já descritos acima. A inclusão de prós e contras da SACL (para arquivos e pastas para todos os usuários), inclui Propriedades - Segurança - Avançado - Auditoria - Adicionar - Todos - Sucesso - Gravação (para arquivos) ou Modificação (para um diretório)).

Você também pode definir SACL em arquivos globalmente, definindo-o em Configuração do computador - Diretivas - Configurações do Windows - Configurações de segurança - Configuração avançada da diretiva de auditoria - Diretivas de auditoria - Acesso a objetos - Auditoria global de acesso a objetos - Sistema de arquivos. Mas o número de eventos, especialmente com arquivos temporários, aumentará proporcionalmente ao volume de operações. Eu não diria que esta é uma abordagem eficaz, só é possível para uma pequena parte das operações.

Gostaria de observar as peculiaridades dos registros que começam aqui. Para este grupo não é fixo de eventos do Windows quando um arquivo é criado através do PowerShell, por exemplo, o New-Item C: \ FORTEST \ test.t . Ao mesmo tempo, a mesma ação é exibida perfeitamente nos logs do Sysmon.

Conclusão


Esse grupo de eventos é melhor gravado usando o Sysmon.

Ações do Registro


Até agora, falando do grupo, incluímos apenas um evento nele. Esta tendência vai mudar aqui.


O log desses eventos é configurado da seguinte maneira: Configuração do computador - diretivas - configurações do Windows - configurações de segurança - configuração avançada da diretiva de auditoria - diretivas de auditoria - acesso a objetos - registro de auditoria - êxito.

A SACL para todos os usuários (Todos) é definida da seguinte forma: regedit.exe - ramificação do registro - Permissões - Avançado - Auditoria - Todos - Sucesso - Permissões avançadas - Controle total ou Valor definido, Criar subchave, Criar link, Excluir link, Excluir DAC de gravação.

Você também pode definir SACL em arquivos globalmente, definindo-o em Configuração do computador - Diretivas - Configurações do Windows - Configurações de segurança - Configuração avançada da diretiva de auditoria - Diretivas de auditoria - Acesso a objetos - Auditoria global de acesso a objetos - Registro. Os contras da abordagem são semelhantes às mesmas operações de arquivo.

Concentre-se imediatamente nas limitações. Para Sysmon, todas as operações (criar, modificar, excluir) com eventos de valor ou aumento de chave (exceto para renomear valor). Para Windows:

  • Todas as operações com valor aumentam eventos.
  • Criar uma chave não gera eventos.
  • Renomear chave gera apenas o evento Access, o novo nome da chave não é exibido; os direitos solicitados especificados no evento não têm uma correspondência intuitivamente inequívoca com a operação. Assim, a operação de renomeação só pode ser determinada pelo método de exceção - não há evento de exclusão 4660 com este HandleID.
  • A remoção da chave gera o evento 4663 seguido por 4660.

Além dos campos discutidos nas seções anteriores, é importante observar que os eventos do Windows contêm dados antigos e novos de nomes e valores de chave e valor, que durante a investigação podem ajudar a entender o motivo do invasor. Especialmente se os valores iniciais não forem padrão ou típicos, e a configuração, incluindo os dados do registro da máquina sob investigação, não for armazenada em nenhum lugar fora do host.

Conclusão


Como podemos ver, existem restrições mais rigorosas no log do Windows. E para corrigir alguns fatos, é necessária uma "correlação", embora a mais simples. No entanto, é capaz de fornecer uma quantidade maior de informações realmente úteis. É difícil dar preferência a um dos participantes para este grupo de eventos.

Configuração WMI


Passamos ao penúltimo grupo de eventos. Estes são eventos WMI. Um invasor pode criar um filtro (filtro) que recebe eventos sobre uma alteração no estado do sistema; em nosso exemplo, uma alteração no estado de um serviço. E realizar determinadas ações com base nos eventos recebidos desse filtro, criando um consumidor. No nosso caso, esta é uma entrada no arquivo de log. Em seguida, ele deve conectar a saída do filtro à entrada do consumidor, criando uma ligação entre o filtro e o consumidor. Ele resultará em um sistema que funciona sob determinadas condições. Geralmente usado para táticas de persistência . É precisamente na ordem descrita que os eventos 19-21 Sysmon são registrados.

É importante entender que a criação de um filtro ou consumidor por si só não representa uma ameaça, mas, é claro, pode fazer parte de um ataque. Além disso, para atividades maliciosas, um filtro existente, um consumidor ou ambos podem ser usados. Aqui é como com uma faca, ou, mais perto do tópico do recurso, com mensageiros criptografados. A questão não está na ferramenta, mas em seu uso.

Vamos dar uma olhada mais de perto na mesa.


Um ponto importante que deve ser observado antes de tudo - o evento 5861 é gerado no log especificado apenas no fato da criação ou modificação subsequente (incluindo em termos de filtro e consumidor) do pacote configurável. Por um lado, isso facilita o rastreamento de atividades supostamente maliciosas (não é necessária nenhuma correlação entre dois ou três eventos) se não apenas um grupo for criado dentro dela. Por outro lado, perdemos o horário de início dessa atividade se o filtro ou consumidor for criado precisamente dentro da estrutura dele e antes do tempo.

Isso é crítico? Caso a caso. Se começarmos a desenrolar a sequência de um incidente e vermos que um filtro ou consumidor atípico e supostamente malicioso foi criado há dois anos, percebemos imediatamente que os atacantes estão em casa conosco há mais de dois anos. E traços do ataque devem ser procurados pelo menos até essa profundidade. Quantas vezes isso acontece? Esta é a questão principal.

Porém, se forem feitas alterações no filtro ou no consumidor do pacote existente, veremos a imagem inteira em um único evento. Enquanto Sysmon refletirá apenas as alterações (esse objeto) que foram feitas.

Entre outras diferenças: nos eventos Sysmon, os dados são refletidos de uma forma mais estruturada e em um formato mais conveniente. Por exemplo, em vez do SID em um formato atípico, o logon do usuário é apresentado imediatamente. Mas os dados são um pouco menos. Talvez isso seja crítico para o seu caso.

Concluímos com restrições. Em primeiro lugar, apesar de esta revista estar presente desde o Windows 2012 (kernel 6.2), não conseguimos obter esses eventos nem para o kernel 6.3 (2012R2), que é estudado no artigo. Talvez isso se deva à ausência de quaisquer correções.

Segundo, de acordo com o autor desteartigos, o filtro para eventos de timer não é corrigido pelo Sysmon. Seria possível não tomar uma palavra, mas verificar. Além disso, a versão do Sysmon é antiga. Mas aqui um precedente é importante - não existem alguns tipos de filtros e consumidores de WMI. A partir desse estudo, complementado por detalhes, um artigo separado poderia ser elaborado. Apenas teste os tipos de destino para entender exatamente o que eles serão registrados.

Conclusão


Nesse caso, estamos mais confortáveis ​​com o uso de eventos do Windows. Do ponto de vista da conveniência: mais dados, não há necessidade de correlação primária. Portanto, do ponto de vista da definição de objetivos - ele corrige a criação de um mecanismo (baseado em partes novas, modificadas ou existentes), e não em suas partes individuais.

Consultas DNS


Então, passamos para o grupo final sendo comparado, mas ainda longe da conclusão de nosso artigo. Esse tipo e o conjunto de eventos correspondente são recentes não apenas pela aparência em nosso artigo, mas também pela adição de Sysmon ao kit de ferramentas.

Nos últimos anos, o tópico de usar o DNS para outros fins, por exemplo, para receber comandos da C&C ou roubar informações por esse canal, tornou-se popular. Provavelmente não por si só - remeteríamos as histórias sobre esse uso dos canais ICMP e DNS a zero. Naquela época, estudantes familiares eram sofisticados no encapsulamento do tráfego de brinquedos, a fim de alcançar os servidores de jogos cobiçados da rede do instituto pelos únicos canais permitidos (Olá, Zhenyatumbochko!). Isso tornou possível, de alguma forma, passar o tempo chato ou dominar rapidamente seus laboratórios. E dificilmente foi ideia deles.

Mas há pouco tempo, um conceito como DoH foi adicionado a esse canal de vazamento, o que complicou a detecção de tráfego DNS suspeito no nível da rede.

Ou talvez tenha sido apenas uma jogada de marketing - vender uma nova, que também é antiga. Ou o início da ocorrência generalizada desses canais em atividades maliciosas detectáveis. Não nos aprofundamos nessa questão, preparados para coletar grãos - de repente, um dos leitores decide deixar um pouco de sabedoria nos comentários.

Então, mais perto do assunto. Ative o Visualizador de Eventos - Logs de Aplicativos e Serviços - Microsoft - Windows - Eventos de Cliente DNS - Operacional - Menu de contexto - Ativar Log.


Tudo o mesmo que já discutido. Quanto às informações sobre o assunto, prestamos atenção à indicação explícita da imagem do arquivo executável que executou a solicitação no evento Sysmon.

Se falamos sobre o objeto - há muito mais informações nos logs do Windows. Mas existem vários "buts" importantes. Em primeiro lugar, a informação é distribuída por vários eventos com todas as consequências.

Em segundo lugar, as informações são apresentadas de maneira não intuitiva. Decifrar a maior parte do conhecimento requer conhecimento de como os campos do pacote são formados e a capacidade de transformar esses dados novamente em fatos que facilitam a decisão do analista. Podemos dizer que, de fato, o analista não é em vão recebendo um salário e por que não sentar e descobrir isso. Sim está certo. Mas deixe-me lembrá-lo, estamos falando de uma pequena equipe sem especialistas de perfil restrito, antes da qual não há fim para as tarefas de segurança da informação. E se para cada evento analisado pelo SIEM essa tarefa incumbir a ele, ele não os alcançará em alguns anos.

Conclusão


Para este grupo, o vencedor é difícil de determinar. O Sysmon oferece uma versão lacônica, da qual você pode facilmente extrair uma boa porção de informações úteis. O Windows oferece uma opção avançada. Resta costurá-lo, lidar com o conteúdo e se perguntar se era hora de apresentar o NTA?

Eventos Sysmon exclusivos


Atribuímos o seguinte aos eventos únicos de Sysmon:

  • EID 4, 16. Embora possa ser rastreado através dos logs do Windows, eles apenas nos informam sobre os eventos no próprio Sysmon. Consequentemente, na sua ausência, eles não fazem sentido.
  • O EID 2 - EID 4663 pode ser considerado um análogo, mas mesmo levando em consideração as listas de direitos de acesso fornecidas, o evento não é tão granular quanto o EID2 e não é enriquecido para esse estado com outros eventos do Windows.
  • EID 7-9, 17 — . ETW. , , .
  • EID 15 — , ETW. , — .
  • EID 18 — (named pipes) . , -, . -, , . ETW.


Existem três opções para filtrar eventos no lado da fonte.

O primeiro está disponível apenas para eventos do Windows e apenas para monitorar o acesso e as operações com objetos. Implementado usando SACL. Entre as desvantagens dessa abordagem está a complexidade das configurações granulares (por exemplo, você não pode monitorar apenas arquivos existentes ou criados com a extensão .exe). Entre as vantagens está a capacidade de limitar a lista de usuários para quem as operações com o objeto são registradas.

O segundo está disponível para eventos do Windows e Sysmon: usando o Xpath, levando em conta as restrições impostas pela grande Microsoft. Como o método está disponível para as duas fontes, a descrição está além do escopo deste artigo.

E o terceiro é a configuração do Sysmon. Existem muitas opções:

  • Emulação curinga - contém (qualquer | tudo), exclui (qualquer | tudo), termina com, começa com. O uso de contains | exclui all permite que você emule expressões como "C: \ Windows \ *. Exe".
  • Correspondência exata - é, não é, imagem.
  • Aritmética - menos que, mais que.

Note-se que essa filtragem não está disponível para todos os campos. Por exemplo, você não pode colocar na lista branca os hashes de software padrão, a criação de processos pelos quais não estamos interessados. Um exemplo de nossa experiência - o processo legítimo git.exe criou dezenas de milhares de eventos de inicialização por dia nos hosts de nossos desenvolvedores. Talvez, especificamente neste caso, seu comportamento possa ser mais rígido, reduzindo assim esse eixo de eventos. Mas excluir arquivos executáveis ​​pelo nome da imagem não é uma boa ideia. Bem, talvez apenas um antivírus com autodefesa ativada.

O Sysmon também está apenas a caminho de uma filtragem sofisticada, combinando condições de diferentes campos. Você pode criar apenas um grupo de regras para cada EID combinado por relacionamentos AND e apenas um com relacionamentos OR. Consequentemente, as condições do formulário (A e B) ou (C e D) não podem mais ser escritas. Dependendo do fluxo filtrado, esse fato pode não oferecer nenhuma vantagem significativa, mas também um resultado tangível.

Outros provedores de eventos gratuitos


Nesta seção, antes de tudo, gostaria de falar sobre o mecanismo ETW (Event Trace for Windows). Os logs internos do Windows e do Sysmon registram eventos usando esse mecanismo. De fato, para cada ação no sistema, podemos obter um evento. A maneira mais fácil de analisar o volume potencial de tais eventos é ativando a opção Visualizador de Eventos - Exibir - Mostrar Análise e Depuração. Para que os eventos não preencham seu sistema imediatamente, cada log é ativado separadamente em seu menu de contexto. Você olha para essa bondade e involuntariamente se faz uma pergunta - por que precisamos do Sysmon com um volume tão grande de eventos?

O fato é que, primeiramente, esses logs foram originalmente projetados para depuração e não para fins de segurança. Portanto, sua coleção centralizada não é fornecida. Em particular, você não encontrará o FQDN do host no qual eles foram criados em nenhum lugar. A questão, é claro, pode ser resolvida por utilitários de terceiros, de pequenos a grandes, de scripts a serviços de registro de pleno direito. Mas é preciso lembrar que esse é um software adicional em uma grande empresa e, portanto, uma tarefa separada. Deixe-me lembrá-lo que, na introdução, partimos do princípio do minimalismo em atividades adicionais para a instalação de software.

Em segundo lugar, esses logs relatam com tantos detalhes sobre cada espirro que eles também precisam selecionar as informações pouco a pouco. Os lançamentos no diário são realmente atômicos e exigirão correlação ou enriquecimento prévio para o analista trabalhar produtivamente. Afinal, um programador que depura sua criação usando esses eventos sabe como tudo deve funcionar. E um guarda de segurança, especialmente de perfil amplo, pensa em níveis muito mais altos de abstração. Sim, além disso, ele procura atividades ilegítimas desconhecidas. Essa declaração do problema leva a um módulo de software adicional que realizará o pré-processamento. Isso novamente complicará nosso conceito.

Embora não tenhamos ido muito longe do log usando o Windows, não esqueceremos de mencionar o WMI. Essa ferramenta basicamente captura alterações de estado sem exibir sua fonte. Como exemplo de uma exceção, carregar uma DLL: exibe o próprio módulo DLL e o processo que está sendo carregado. Mas, por questões de segurança, esse evento também requer enriquecimento, pois é onde suas informações são esgotadas. Em geral, ausência de peixe e câncer são peixes. Mas a ferramenta só pode ser usada como um extra.

Outra opção popular, mas não abordada no artigo, é a osquery.. Os dois principais motivos pelos quais não consideramos essa solução aqui são a baixa frequência de atualizações do produto (menos em termos de segurança e funcionalidade) e o aumento do uso dos recursos do sistema em comparação com outras opções (um banco de dados completo está incluído). Presumivelmente, a solução é adequada para servidores para os quais foi desenvolvida. Mas para estações de trabalho, possivelmente com hardware desatualizado - dificilmente.

Recentemente, surgiram várias outras ferramentas que não são tão difundidas quanto as consideradas. Isso inclui o Velociraptor e o SilkETW. Eles não inventam uma bicicleta e também trabalham em cima do padrão do Windows - ETW. Em vista do volume de material já citado, decidiu-se separar essas ferramentas em uma publicação separada (conforme tempo e esforço disponíveis, bem como um senso de demanda).

Conclusão geral


No decorrer da comparação, foi mostrado que os eventos Sysmon, tendo análogos, geralmente superam os eventos do Windows em suas características funcionais. Alguns eventos de Sysmon simplesmente não têm alternativas.

No entanto, não esqueça que, em primeiro lugar, a solução deve ser escolhida com base nas suas tarefas. Se você está apenas criando um sistema de monitoramento e, no primeiro ano, planeja implementar métodos para detectar sete a dez incidentes, como o Gartner legou, então você deve ter eventos suficientes no Windows. E talvez muito mais que um ano.

Em segundo lugar, o sistema de log de eventos do Windows também é atualizado constantemente e, durante a redação deste artigo, apareceram os EIDs do Windows, como 4798 e 4799. Também é possível que o conjunto de campos seja complementado. Portanto, essa comparação, embora seja a mais completa, com base nas informações que possuímos, não é talhada em pedra.

E em terceiro lugar, o Sysmon ainda é uma ferramenta externa, o que implica uma série de riscos. Por exemplo, tivemos casos em que o log de EIDs individuais foi encerrado sem declarar um motivo. Nesse caso, a gravação de outros eventos foi como de costume. Colegas mais eminentes afirmam que o problema estava relacionado a vazamentos de memória na versão 10.41. Mas a versão 10.42, na qual esse problema é encerrado total ou parcialmente (no changelog de Sysmon, tudo não é tão detalhado), não resolveu nossos problemas nessa direção. Somente o componente de desinstalação e instalação ajuda. Toda a segurança e tenha um bom dia!

Graças a Timurzinintpara obter ajuda na preparação da publicação.

UPD1 : É realmente difícil manter um registro de alterações normal ou adicionar novos recursos à descrição principal, como descobrimos (obrigado, tio Dimshudv), um caminhão com nishtyaks já virou na nossa rua há 9 meses ... Resumo: em Sysmon você pode fazer (A e B) ou (C e D), apenas shh ...

More articles:


All Articles