Detectando e prevenindo ataques com observabilidade em seu CDN

Prevenir ataques ao seu site, seja ele corporativo ou pessoal, é hoje uma necessidade. A melhor forma de fazer isso é usando ferramentas WAF (Web Application Firewall) que permitem não apenas fazer o cache para aceleração de conteudo como um proxy reverso, mas tambem para fazer as proteções de conteudo.

No exemplo abaixo estou usando o CDN da Microsoft que é o Azure Front Door.

Utilizando o Workbook Azure WAF Workbook With Metrics

O workbook está disponivel no Github oficial da Microsoft em Azure-Network-Security/Azure WAF/Workbook - WAF Monitor Workbook at master · Azure/Azure-Network-Security

Uma vez baixado, basta informar os dados de seu CDN ou WAF.

Detectando as Anomalias de Ataque

Já a algum tempo que faço os bloqueios por paises e URLs mal formadas ou com indicios de ataque. Como rotina olho a cada manhã para ver as estatística e se preciso incluir novos tipos de acesso indevido.

Hoje me deparei com um aumento expressivo de request em meu dashboard principal indicando algo errado, como mostra a umagem abaixo:

Pode-se perceber que um alto numero de request ocorreu sem aumentar o numero de conexões ativas, ou seja uma unica conexão gerando milhares de requests é realmente algo suspeito. Na madrugada isso pode ocorrer realmente, afinal os buscadores costumam fazer suas varreduras durante os horarios fora de pico. Mas não na hora do almoço...

Ao abrir o workbook de analise do WAF vi que o resultado era o esperado, o numero de páginas legitimas nas ultimas 24 horas correspondia ao normal porem o numero excessivo de blocks se confirmou!

Na sequencia analisei as regras que geraram estes 30 mil bloqueios e pude notar que foram realmente tentativas de ataque utilizando SQL e JSON injection, brute-force de administração e quebra de páginas com script embedded:

Como observação, pude ver que os paises conhecidos como atacantes na minha segunda regra que mais gerou blocks tambem tem um alto indice de paridade indicando que por algum motivo fui alvo de um ataque zumbi e vou explicar mais abaixo sobre isso.

Continuando a observação pude ver que os ataques se concentraram basicamente em 3 IPs, destacando o 122.128.109.253 como o mais ativo. Detalhe que o IP 146.70.184.154 está se utilizando de um ataque anterior que irei abordar na conclusão.

Por fim, verifiquei no Microsoft Defender Threat Intelligence que o IP 122.128.109.253 é um IP registrado em Hong Kong pertencente a uma empresa real em um endereço legitimo em um condominio da JLL:

Essa informação bate com o resumo do tráfego no meu CDN Front Door:

Conclusão

Ao pesquisar os dados notamos que é provavel o uso deste IP como zumbi, já que se trata de uma empresa de internet. Isso pode ocorrer de várias formas como um injeção de código em um blog ou um site mal protegido. Por exemplo esta empresa pode hospedar sites de terceiros e um deles ao ser hackeado está servindo de fonte de ataques.

Isso não é raro de acontecer, por exemplo eu até inicio de 2023 utilizava uma versão de Wordpress que era vulnerável e sofri a injeção uma unica página no site chamada "video.aspx" que servia para gerar lucros por simular clicks em um video monetizado. Hoje eu tenho uma versão mais recente e não vulnerável alem de ter colocado a página "videos.aspx" na lista de bloqueios. Mas se eu já removi e fiz a atualização do engine do blog, porque preciso fazer o bloqueio da página?

O motivo é simples, os "zumbis" ainda usam o meu site como tentativa de monetizar click em videos externos... Pode-se ver que o IP 146.70.184.154 mostrado em um dos prints acima está tambem sob controle de algum tipo de atacante, pois ele está tentando disparar uma série de videos a partir do meu blog.

E o caso do IP 122.128.109.253?

Olhando depois os logs vi que todas as tentativas de acesso vindos deste IP foram bloqueadas com sucesso, comprovante que a minha regra funcionou bem!

Portanto, lembre-se que a observação e analise das suas regras precisa ser constante, uma rotina para sua equipe.

Repositório de Consultas KQL

Algumas consultas KQL que usamos para o Log Analytics e Resource Graph são simples mas nos fornecem todos os dados que precisamos para uma decisão ou servir de base para hunting.

Alem de algumas consultas "curiosas" que já precisei montar, tambem tenho as que uso em treinamento do Microsoft Defender for Cloud como exemplo de diferentes tipos de consultas.

Decidi juntar todas elas em um repositório no GitHub para ficar fácil a consulta e deixar disponivel para a comunidade.

msincic/scripts-KQL: Public KQL Scripts (github.com)

Nome do Script Tipo Proposito
Agents_Last_Comm Log Analytics List type of agent (MMA or AMA) and last communication of all computers monitored
Array-Text-Extract Log Analytics Examples of extract data in arrays or text columns
Attack-Examples Log Analytics Example of detect attacks in logs (SQL Injection)
Emails-Threat-Intel Log Analytics Detect malicious IPs and domains in email, URL or sender
Events_Chart_ByDay Log Analytics Example of chat to detect anomolous events registered
Graph_examples Log Analytics Examples of graph (bar, time, pie)
List_CWPP Resource Graph List workload protections in all subscriptions to map a coverage protection in your environment
List-Deployments-and-Details Log Analytics List all deploymentos to audit object creations and details about dependant objects in the same deploy
M365_Operations Log Analytics List operations in M365 and IP/DLP actions
More-Changed-Computers Log Analytics List top 10 computers and users with changed configs
PIM_Included Log Analytics List activities of include users in PIM
PoliciesAssigned-State Resource Graph List policies applied and compliance states. You can filter for compliance or non-compliance to addresses actions
Policies-List Resource Graph List policies and details to export and use for determine assigments in your enviromnent
Purview-IP-Events Log Analytics List all activities in Purview (IP, DLP, IRM, etc)
Secure-Controls Resource Graphs List Score, recommendations and assessments in details
Tables-Ingest-Day-by-Day Log Analytics List ingest data in all tables by day with indicator of billied or non-billed
ThreatIntel-Examples Log Analytics Samples to use Microsoft Defender Threat Intel table to detect malicious IP in sign-ins and consult tables
Usage_Tables Log Analytics Graph to identify and understand tables growing
VM_Process_Comm Log Analytics List of process communicated in all computers with IP and Port, source, destination, bytes send and received
VMs+Scale Set User Identity Resource Graph List VMs and Scale Sets using User Identity to mapped permissions

Sentinel SOC Optimization - Novo Recurso para Avaliação do Sentinel por Cenários

Este novo recurso atualmente (06/05/2024) em preview irá ajudar as empresas que utilizam Sentinel.

Por que é um recurso necessário?

Os utilizadores de Sentinel já conhecem bem o Content Hub e como ele ajuda disponibilizando os diferentes pacotes contendo regras analíticas, conectores e hunting para diferentes necessidades, produtos ou cenários. Alem disso, algumas tabelas e dados podem estar com baixa ou alta ingestão, o que compromete eficácia e custos.

Porem muitas vezes para se atingir a proteção a determinado tipo de ataque é necessário ter diversos pacotes do Content Hub para produtos diferentes ou isolados. Por exemplo para BEC é necessário algumas regras de Fortigate, outras de Cisco, outras de ENTRA e assim por diante, já que podemos ter diversos produtos em um ambiente e qualquer um deles pode ser a porta de entrada.

Resumindo, é dificil saber quais pacotes tem as regras que me protegeriam de um cenário de ataque especifico envolvendo múltiplos produtos e também otimização de custos.

Como o SOC Optimization ajuda e funciona?

Com avaliações periódicas das suas regras instaladas e habilitadas, ele identifica cenários em que sua organização está protegida ou vulnerável. Seguem um print do meu ambiente hoje, onde podem ser vistos os diferentes tipos de ataque:

No exemplo acima, escolhi o BEC para roubo de credencial como o foco de analise realizada pela plataforma e descubro que das 29 recomendações eu tenho apenas 16 aplicadas. Alem disso o grafico me permite ver por tipo de ataque qual é o foco das táticas e técnicas baseado no MITRE.

Ao clicar no link View all MITRE ATTACK technique improvement passo a ter um detalhe das tecnicas que estou cobrindo e quais não estou protegido:

Por fim, ao clicar no botão Go to Content Hub sou direcionado a uma nova tela onde tenho acesso a quais são os objetos que me ajudariam a cobrir o gap identificado e permitindo a instalação imediata:

No exemplo acima vejam que diversas regras estão relacionadas a analise de log de produtos de terceiros que eu não possuo. Como lidar neste caso?

Lembre-se que na tela iniciar de cada avaliação você tem a opção de indicar o estágio que se encontra a sua ação após a análise. Como em meu ambiente não tenho Cisco nem Proofpoint instalaria os objetos que cobrem o meu ambiente e definiria o estágio como Complete.

Conclusão

Simples de utilizar e prático, este recurso irá ajudar muito aos operadores de SOC ter cenários cobertos sem a necessidade de seguir manualmente verificações.
Também irá ajudar na visualização de tabelas com ingestão inadequada.