Do Log à Caça às Ameaças

A busca proativa de ameaças (também chamada de Threat Hunting) é um processo fundamental de qualquer estratégia de cibersegurança considerada madura. Em suma, implica a busca ativa do invasor dentro de nossa infraestrutura antes que ele possa causar algum dano.

Dentro dos ambientes de TI, tarefas e programas são executados, às vezes geram mudanças no ambiente, ou apenas utilizam recursos de rede (por exemplo), todos esses eventos são capturados pelos diferentes aplicativos e refletidos como rastros na forma de uma linha de texto em um arquivo de log, um evento do sistema operacional, um pacote de rede capturado ou, como analisamos anteriormente, na forma de um DataFlow (Post anterior). Fazendo uma abstração, podemos dizer que esses rastros são a unidade mínima dentro da caça às ameaças.

Uma estratégia eficiente de detecção de ameaças tentará responder a perguntas sobre essas fontes de dados de detecção. Decidir QUE captura de dados de detecção, QUANDO capturá-los,ONDEcapturá-los, por QUANTO tempo retê-los são algumas das peças que nos ajudarão a construir a melhor implementação desse processo de caça às ameaças.

Nesta postagem, exploraremos como passamos de um punhado de logs e diferentes tipos de dados para engenharia de detecção e análise de design para detectar comportamento malicioso.

Sobre a detecção

Entendemos que a detecção dos diferentes eventos em seus diversos formatos é a ferramenta que nos permite encontrar uma ameaça. É por isso que enfatizaremos a obtenção das melhores detecções.

Alertar para a conexão de um dispositivo desconhecido na rede com base na observação de uma lista de endereços IP (previamente registrados como válidos) parece ser um método de detecção eficaz (e é), mas implica a possibilidade de gerar muitos falsos positivos (alertas que não interessam), falaremos aqui sobre Precisão de detecção.

Por outro lado, se pensarmos na detecção baseada em assinaturas, podemos ter certeza de que praticamente todos os alertas que recebermos serão considerados de interesse e representarão claramente uma ameaça. Embora desta forma existam muitas outras situações de risco que não estão incluídas nas assinaturas e que não serão detectadas. Geramos muitos falsos negativos aqui, então nos referimos à exaustividade da detecção (ou “recall” em inglês)

Podemos definir esses aspectos em um diagrama tomando como referência a detecção de e-mail de spam, sendo o vermelho os e-mails de spam e o verde os e-mails legítimos:

Melhorar o escopo de nossas detecções nos permitirá “Não deixar comportamento malicioso de fora” e a precisão nos permitirá “Não alertar erroneamente sobre eventos válidos”.

Além disso, encontramos na detecção algumas categorias típicas que devemos destacar antes de passar para uma delas

Detecção baseada em assinatura: Nesta detecção, geralmente fazemos uso de IoCs (Indicators of Compromise), como endereços IP maliciosos, hashes de arquivos ou cadeias de caracteres contidas em binários. Conjuntos de itens que foram especificamente encontrados em incidentes anteriores.

Essa detecção tem uma precisão excelente, mas muitas vezes estamos a um bit de ficar com uma assinatura desatualizada.

Detecção baseada em anomalia: Este tipo de detecção baseia-se em “definir uma normalidade” no ambiente como lista de aplicações, listas de equipamentos, tipo de tráfego de rede, eventos esperados, e monitorizar as diferenças que existem face a este “estado normal”. Qualquer coisa encontrada como “Fora do normal” será considerada maliciosa.

Este tipo de detecção pode encontrar comportamentos maliciosos anteriormente desconhecidos, por outro lado não é fácil manter estes padrões “normais”, comportamentos válidos num ambiente tendem a mudar (como tudo o mais).

Detecção baseada em comportamento: Neste tipo de detecção iremos basear a detecção no comportamento que geralmente é considerado malicioso no ambiente particular onde a detecção é feita. Podemos pensar por exemplo

Não importa se um cibercriminoso usa tecnologia e habilidades de ponta, ou se usa malware escrito em go, python ou assembler, seu ataque dependerá 100% de nossas fraquezas. Isso nos dá uma vantagem.
Não podemos, portanto, avançar neste caminho de detecção sem passar pela Pirâmide da Dor de David Bianco, onde delineamos da base à ponta como aumenta para o adversário a dificuldade de substituir um elemento dentro de um ataque:


Da detecção ao entendimento

Geralmente, em relação à caça às ameaças, vem à mente "Procurar uma agulha no palheiro", mas ao contrário desta última, a caça às ameaças pode ser melhorada, com uma metodologia que dê uma resposta mais eficaz, a experiência encurta o seu tempo.

Tomemos como referência o seguinte caso:

O Windows Event Viewer é executado através do Microsoft Management Console (MMC), isso implica rodar em um contexto altamente privilegiado. Além disso, o "visualizador de eventos do Windows" é um software que tenta executar em primeira instância com base em uma configuração de chave do registro localizada em HKCU\Software\Classes\mscfile\shell\open\command quando essa chave não é detectada, é executado de acordo com a configuração de HKCR\mscfile\shell\open\command.

O leitor atento se perguntará:

O que acontece se dentro dessa chave, que está disponível para o usuário (CURRENT_USER), for inserido um valor como C:\Users\Documents\TrustMeImNotAMalware.exe?
Vamos fazer o teste, tentamos acessar a chave e modificar seu valor. Em nosso teste, o resultado desse teste simples parece não ter surtido efeito, notamos até um problema no editor de registro, tentamos rodar como usuário padrão, até mesmo como usuário administrador. O editor travou ao aplicar um novo valor a esta chave.

Passados alguns minutos e sem ter encontrado registros sobre esta situação, a equipe do SOC contactou-nos para indagar sobre comportamento suspeito do terminal onde estávamos a realizar o teste, um alerta referente a uma táctica de Privilege Escalation:


A questão então para começar a mapear o entendimento da caça às ameaças é:

POR QUE esse comportamento estava sendo monitorado?
A questão, embora pareça trivial, requer saber que não é possível de forma alguma coletar cada uma das alterações ou eventos que ocorrem em um grupo de dispositivos dentro de uma Organização. Quer se trate de uma questão técnica ou de recursos associados, algo estará sempre “fora do radar”.

Por outro lado, o “COMO” poderemos entender rapidamente fazendo uma pequena análise, a modificação naquela chave de registro gera algum tipo de rastro, seja na modificação do próprio valor ou em algum arquivo de registro, esse rastro é percebido (por uma solução EDR neste caso), e em contraste com uma técnica, que corresponde a um comportamento, esse comportamento é o que geralmente chamamos de "Tática", e colocado dentro de um contexto é a forma como responderemos ao PORQUÊ.

Nós, então, detectamos eventos, mas alertamos sobre comportamentos
Metodologia MITRE
Para moldar todo o processo de caça às ameaças, adotaremos uma metodologia. A equipe da MITRE Engenuity compartilha uma série de etapas para isso onde começaremos com o entendimento da "Atividade Maliciosa" para depois decantar em elementos específicos para a execução de detecções específicas.

Começando de top down nesta metodologia, para detectar atividades consideradas maliciosas dentro do ambiente devemos entender essa atividade. Entender esse modelo de ameaça nos ajuda a moldá-lo, por exemplo, usando o MITRE ATT&CK. Tomando o caso anterior como referência, podemos dizer:

“Um adversário pode aumentar seus privilégios de execução no ambiente afetado para causar maior impacto”
Para conseguir uma análise correta e entender o que detectar é que desenvolvemos hipóteses que podem ser confirmadas a partir da implementação de um comportamento. Continuando com o caso anterior:

“Se a chave de registro correspondente ao comando Windows Event Viewer no registro do usuário for modificada, um adversário está realizando uma elevação de privilégio”
Já abaixo do ângulo do nosso V metodológico estamos muito próximos dos dados, que dados devemos coletar para validar as hipóteses? É aqui que respondemos a uma pergunta anterior para o nosso exemplo:

Avaliamos os valores de uma determinada chave de registro, para detectar o comportamento do Privilege Escalation”
Com outro olhar e analisando nosso V, da esquerda para a direita podemos encontrar à esquerda as ações de compreensão, pesquisa e planejamento em torno da caça às ameaças, processo muitas vezes realizado "no papel", aqui encontramos descrições de comportamentos, detecção de hipóteses e dados requisitos.

Do lado direito, por outro lado, começamos a subir no próprio processo de "caça", identificamos os dados necessários, confirmamos as hipóteses e detectamos as ameaças (ou não). É só aqui que encontraremos todas as ferramentas, softwares, soluções, SIEMs, EDRs, IDS, etc.

Na prática, essa metodologia não é aplicada de forma linear, são realizadas múltiplas iterações em diferentes direções, sempre levando em conta os resultados de cada etapa. A metodologia realizada pela mão de um especialista pode ter múltiplos feedbacks a partir de novas descobertas a cada execução.


EExistem alguns modelos mais ou menos difundidos para caçar ameaças há anos, mas todos eles compartilham a necessidade de entender o que está acontecendo “do outro lado” para agir “deste lado”.

A caça a ameaças como uma implementação ativa de defesa cibernética nos permite não apenas detectar o adversário, mas também gerar métodos melhores para passar rapidamente da detecção à erradicação.

Em nossos próximos capítulos, exploraremos as diferentes formas de "hipóteses" para detecção e analisaremos alguns TTPs (Táticas, Técnicas e Procedimentos) sob a ótica dessa metodologia de caça às ameaças.