Na edição Enterprise das Avaliações do ATT&CK® deste ano, o MITRE configurou três cenários de ataque: um cenário da República Popular Democrática da Coreia (DPRK) para testar atividades de ciberespionagem contra um sistema macOS; um cenário Cl0p para testar um ataque de ransomware contra um sistema Windows; e um cenário LockBit para testar um ataque de ransomware contra um ambiente corporativo que continha um servidor Linux e estações de trabalho e servidores Windows.
O ESET Inspect demonstrou boa visibilidade em cada cenário, detectando todas as etapas e, ao mesmo tempo, mantendo baixo o número total de detecções (ou volume). As detecções geradas pelos ataques foram automaticamente correlacionadas em incidentes pelo Incident Creator do ESET Inspect, oferecendo aos nossos analistas de segurança uma visão focada dos ataques e, assim, uma compreensão clara de como eles ocorreram passo a passo.
Para entender melhor como a ESET se saiu, vamos revisar algumas das mudanças metodológicas introduzidas pelo MITRE e, em seguida, analisar como o Incident Creator simplificou a visualização e o fluxo de trabalho dos analistas de segurança no painel do ESET Inspect.
Metodologia
Esta avaliação trouxe diversas mudanças bem pensadas para a metodologia dos cenários de Detecção, que acreditamos refletir melhor o trabalho dos analistas de segurança ao lidar com ciberataques do mundo real.
Primeiro, a telemetria deixou de ser uma categoria de detecção, o que significa que não basta mais apenas mostrar que um evento ocorreu. A categoria mais baixa de detecção agora é General, exigindo que a detecção indique que um evento ocorreu e que ele é, de alguma forma, suspeito ou malicioso. É importante destacar que um evento ocorrido em uma sandbox não se qualifica como um evento ocorrido no ambiente sob avaliação. Como indicado na própria definição, uma detecção do tipo General deve responder ao quê, onde, quando e quem em relação ao ambiente testado, e essas respostas não podem ser obtidas a partir de uma execução externa em sandbox.
Segundo, algumas subetapas benignas foram incorporadas como um teste de falsos positivos, e não como detecções. Essa é uma mudança bem-vinda, pois desencoraja a abordagem de “detectar tudo”, que poderia gerar muito ruído, trabalho desnecessário para os analistas e ainda aumentar os custos de armazenamento de dados. Outro benefício dessa mudança é permitir o cálculo de uma pontuação de precisão, indicando quantas das detecções realizadas correspondem de fato a subetapas maliciosas ou suspeitas.
Terceiro, algumas subetapas são incluídas, mas não avaliadas. O motivo para isso é simular melhor um ciberataque real, evitando saltos ilógicos na progressão do ataque.
Por fim, foi introduzida uma métrica de volume que registra o número de detecções exibidas no painel. Essa é mais uma forma de desencorajar a abordagem de “detectar tudo”, evitando que os fornecedores permitam que seus painéis sejam preenchidos, às vezes, com milhões de detecções. Também consideramos esse ajuste bastante positivo.
A métrica de volume também registra a severidade das detecções, usando cinco níveis: critical, high, medium, low e info. Como o ESET Inspect possui três níveis de severidade de incidentes (high, medium e low) e três níveis de severidade de detecção (threat, warning e info), alinhamos com a equipe do MITRE Engenuity o mapeamento apresentado na Tabela 1.
Tabela 1. Mapeamento entre os níveis de severidade da Avaliação ATT&CK e do ESET Inspect
Vale explicar por que escolhemos uma pontuação de severidade 22 para separar os níveis low e info. Como indicado em nossa documentação:
Regras com severidade 22 ou inferior são regras de telemetria. Elas geralmente são usadas apenas como informação adicional para investigar um incidente e muitas vezes podem ser acionadas por comportamentos legítimos. Se algumas dessas regras gerarem tráfego excessivo no seu ambiente, você pode considerar desativá-las.
A partir deste ponto, vamos nos referir aos níveis de severidade apenas conforme utilizados pelo ESET Inspect.
Uma consequência importante desse mapeamento é que detecções não correlacionadas a um incidente ficam fora do escopo da avaliação. Isso reflete, em grande parte, o uso pretendido do ESET Inspect no mundo real: incidentes preenchidos por detecções correlacionadas são o foco principal dos analistas de segurança. Informações adicionais e detecções não correlacionadas a incidentes, que podem ter valor em alguns casos, são secundárias.
Como os painéis inevitavelmente possuem diferentes seções que exibem detecções e outras informações em formatos detalhados, resumidos ou gráficos, foi permitido que os fornecedores indicassem, para fins da avaliação, a visualização padrão que os operadores de segurança deveriam usar para tratar ataques. Apenas as informações apresentadas nessa visualização são consideradas para efeito de detecção, falso positivo e medição de volume. No ESET Inspect, a visualização padrão para analistas de segurança é Incidents.
Incidentes
A visualização Incidents é o principal local que os operadores de segurança devem usar para gerenciar seu fluxo de trabalho. Os incidentes são automaticamente preenchidos nessa visualização de duas formas:
- ESET Incident Creator, que usa um mecanismo baseado em IA para correlacionar detecções em um único incidente.
- ESET Inspect, que atualmente possui mais de 100 regras que criam um incidente quando acionadas, agregando detecções em um único incidente por computadores afetados, por período de tempo, ou por ambos.
Recomenda-se que os operadores sigam o seguinte fluxo de trabalho:
- Investigar cada incidente.
- Investigar detecções de severidade threat que não estejam correlacionadas a nenhum incidente, se houver tempo.
Assim como na avaliação do ano passado, cada cenário de ataque foi executado duas vezes. Os fornecedores puderam fazer alterações de configuração na segunda execução para tentar aumentar a visibilidade, reduzir falsos positivos e diminuir o volume. A Figura 1 mostra a visualização Incidents após a execução com alterações de configuração.
Figura 1. A visualização Incidents no ESET Inspect após a execução com alterações de configuração
O Incident Creator não gerou nenhum incidente de falso positivo durante a avaliação. Pelo contrário, apenas um ou dois incidentes foram criados por cenário na execução com alterações de configuração, e praticamente todas as detecções relevantes disponíveis no ESET Inspect foram correlacionadas a um incidente.
Destaques dos cenários
Nas seções a seguir, vamos apresentar os principais destaques dos resultados da ESET em cada cenário.
DPRK
O ESET Inspect tratou automaticamente o cenário DPRK como um incidente de severidade média, criado pelo Incident Creator. Entre os destaques dos resultados da ESET nesse cenário estão a detecção dos dois backdoors sendo depositados em locais suspeitos, os processos dos backdoors se passando por Docker e Zoom, o roubo de dados dos arquivos do keychain e a ausência de falsos positivos.
A Figura 2 mostra parte do incidente com as detecções correlacionadas a esse ataque, destacando uma detecção do backdoor FULLHOUSE.DOORED instalando persistência para um backdoor de segundo estágio, o STRATOFEAR, como um launch daemon.
Figura 2. Detecções correlacionadas do incidente gerado pelo Incident Creator para o cenário DPRK
Cl0p
Na execução com alterações de configuração, o ESET Inspect tratou automaticamente o cenário Cl0p como dois incidentes de alta severidade, um criado pelo Incident Creator e outro por uma regra que monitora detecções de filecoders no endpoint.
Entre os destaques dos resultados da ESET nesse cenário estão a detecção do carregamento do instalador e das DLLs loader do SDBbot, a modificação de uma chave de registro para estabelecer persistência do RAT SDBbot, a exclusão de shadow copies, a desativação da recuperação do Windows após falha de inicialização e a execução do ransomware Cl0p.
A Figura 3 mostra parte do incidente com as detecções correlacionadas a esse ataque, destacando uma detecção de gravações ou renomeações de arquivos canário para detecção precoce da execução de ransomware. A regra acionada não apenas encerra o processo malicioso, como também cria um incidente na visualização Incidents.
Figura 3. Detecções correlacionadas do incidente gerado pelo Incident Creator para o cenário Cl0p
LockBit
Na execução com alteração de configuração, o ESET Inspect tratou automaticamente o cenário LockBit como dois incidentes de alta severidade, um criado pelo Incident Creator e outro por uma regra que monitora detecções de spyware nos endpoints.
Os destaques dos resultados da ESET nesse cenário incluem a detecção do login do atacante via VNC, a modificação de um valor do Registro para habilitar login automático, o uso de SSH para se conectar a um servidor Linux na rede interna, a propagação do ransomware LockBit para outras máquinas da rede via PsExec, a execução do LockBit e a limpeza dos logs de eventos do Windows para ocultar a atividade de intrusão.
A Figura 4 mostra uma parte do incidente com as detecções correlacionadas a esse ataque, destacando uma detecção de um processo suspeito gravando ou renomeando arquivos com extensões específicas, chamadas de “duplas extensões”, um comportamento típico de filecoders.
Figura 4. Detecções correlacionadas do incidente gerado pelo Incident Creator para o cenário LockBit
Considerações finais
Acreditamos que o resumo acima representa com precisão nossa abordagem no design do ESET Inspect. Ele indica que os analistas de segurança podem ter alto grau de confiança de que estão lidando de forma eficiente com ameaças reais sempre que o ESET Inspect apresenta um incidente com detecções correlacionadas.
Mais uma vez, gostaríamos de destacar que a equipe do MITRE conduziu profissionalmente mais uma rodada de avaliações, introduzindo diversas mudanças que incentivam os fornecedores a se prepararem melhor para a diversidade de táticas e técnicas observadas no mundo real, em vez de simplesmente buscar ser o “vencedor” de uma competição que, na prática, não existe.
Da nossa parte, embora certamente estejamos buscando aprimorar o ESET Inspect em alguns pontos para detectar mais subetapas com verdadeiro positivo, isso precisa ser equilibrado com o risco de que um aumento excessivo de cobertura reduza a precisão e eleve o volume de alertas, o que acabaria enfraquecendo nossa abordagem, entregando cada vez menos valor a um custo cada vez maior.
Em resumo, esperamos que a perspectiva da ESET sobre a avaliação deste ano tenha despertado seu interesse em explorar nossos resultados com mais profundidade na página oficial das ATT&CK Evaluations, disponibilizada pelo MITRE.