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.

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)

Já comentei em posts passados sobre o MDTI (Microsoft Defender for Threat Intelligence) quando integrado com o Sentinel para detectar com KQL indicadores de ataque ou comprometimento (https://www.marcelosincic.com.br/post/Utilizando-os-IoCs-do-Microsoft-Defender-Threat-Intelligence.aspx).

Desta vez vamos introduzir uma nova ferramenta que é o EASM (Defender External Attack Surface Management) onde ao indicar um “seed” que podem ser nomes de domínios, IPs de hosts ou DNS ele faz a procura por indicadores de possível ataque.

Ele é abrangente por não apenas olhar os Threat Indicators na base do MDTI, mas incluir na analise os certificados vencidos, CVEs que estão expostos, técnicas OWASP, postura de segurança nas configurações e aderência ao GDPR.

O melhor de tudo: O EASM É GRATUITO NOS PRIMEIROS 30 DIAS!

Habilitando e Configuração Inicial

O processo é muito simples, segue um passo a passo:

1. Crie o recurso no Azure, onde informará subscrição, grupo de recursos e tags basicamente
2. Entre nas configurações em “Discovery” e crie a raiz de procura (ou seed) com o “Discovery Group”
3. Nas configurações da procura indique a periodicidade e o que quer procurar
   Aqui tem um ponto interessante, onde empresas e organizações conhecidas podem ser pré-carregadas na opção de “Import…” que são empresas já conhecidas por bases de internet comum
4. Lembre-se de colocar exclusões caso possua servidores honeypot para não gerar alertas desnecessários

Agora é só aguardar de 48 a 72 horas para que a descoberta gere os dados.

Analisando os dados gerados

No Overview já é possível detectar os diferentes itens que precisam ser observados na forma de listas em tabs. Nesta lista eu já detecto IPs suspeitos por ser utilizado em distribuição de malware na base do MDTI.

Olhando ali descobrimos um IP antigo que utilizei em um servidor que hoje é um indicador de ataque:

Aqui já pode ser visto um resumo e o indicativo de que um dos IPs é suspeito:

O próprio EASM já carrega as informações indicando qual tipo de ataque este IP está sujeito e está registrado no MDTI:

Abrindo as tabs de obervação do host podemos ver o que este host hospeda, certificados, reputação e todos os detalhes:

Também já tenho uma visão de todos os certificados usados no host para os diferentes domínios, o que me permite detectar certificados internos e externos que estejam vencidos ou próximos de vencer:

Neste exemplo descobri mais tarde investigando que um dos dominios hospedados no mesmo servidor estava com vulnerabilidades e sendo usado para distribuição de um site de videos.

Alterei o host e removi o registro DNS que apontava para este host, que na verdade era apenas um registro de verify antigo e não estava mais ativo.

Conclusão

Com o uso do EASM podemos monitorar nossos recursos que estão expostos na internet e assim proteger a nós mesmos e aos nossos clientes!