Utilizando os IoCs do Microsoft Defender Threat Intelligence no Sentinel
A alguns anos que a Microsoft adquiriu a RiskIQ e lançou recentemente o Microsoft Defender for Threat Intel (MDTI).
O que é o MDTI?
Já tratei algumas vezes sobre IoCs, ou indicadores de comprometimento em inglês, e como eles podem ser integrados como o caso do VirusTotal (Marcelo Sincic | Enriquecendo o Sentinel com dados do Virus Total).
Nesse post vamos falar da solução do MDTI e como integrar a base dele ao Senitnel e utilizar para hunting e análise de incidentes e alertas em seu ambiente.
Primeiramente é importante saber que o serviço MDTI é pago por usuário em um modelo de licenciamento por contrato, mas a base de dados pode ser importada para o Sentinel por meio de um conector.
Conectando o Sentinel a base do MDTI
Para isso você precisará instalar a solução Microsoft Defender for Threat Intel no Sentinel a paritr do Content Hub e depois configurar o Data Connector como abaixo:
Uma vez configurado será feita a ingestão diária os dados do MDTI para a base Threat Intelligence do Sentinel:
Importante lembrar que os IoCs ingeridos do MDTI irão se somar aos IoCs customizados ou importados de outras bases que você tenha configurado.
Configurando as integrações de Log com TIs
Ao instalar a solução e fazer a configuração do conector de dados, o passo seguinte é configurar e instalar as regras de cruzamento de dados utilizando o Analytics do Sentinel.
São varias regras diferentes que você poderá utilizar que já estão prontas:
Estas regras são compostas de consultas KQL que analisar um alerta e incidente para cruzar co ma base de IoCs importadas, resultando em um enriquecimento de dados ao validar que um determinado IP ou URL maliciosa foi acessada ou tentou acessar seu ambiente.
Claro que isso pode ser feito manualmente, bastaria rodar uma query KQL manual ou customizada no Sentinel em hunting queries para cruzar IPs e URLs com os diferentes logs do Sentinel existentes. Um exemplo disso foi um recente cliente onde discutimos o cruzamento do log do Umbrella DNS com o MDTI para detectar sites maliciosos acessados pelos usuários.
Visualizando os incidentes com os dados do MDTI
Agora vem a parte prática. Tudo configurado você terá alertas e incidentes novos em seu ambiente:
Vamos abrir os detalhes do primeiro e ver o IP que indica um ataque potencial:
Uma vez que no proprio incidente já sei que o IP é considerado suspeito, podemos investigar os detalhes importados na base para visualizar os detalhes:
E por fim, vou utilizar a interface do MDTI para consultar os dados do IP, lembrando que neste caso preciso ter uma licença de MDTI para ver os detalhes:
Vamos agora fazer o mesmo processo com o segundo incidente de exemplo que tenho na minha lista e abrir os detalhes no MDTI:
Conclusão
O serviço Microsoft Defender for Threat Intel (MDTI) irá ajudá-lo a detectar diversas formas de ataques vindas de ofensores e grupos profissionais ou previamente identificados.
Alem disso, sua base é rica em detalhes do tipo de ataque, alvos e grupos que atuam com aquele IoC especifico que foi utilizado para tentar acesso ao seu ambiente.
Protegendo o log do WAF contra vazamentos e exfiltração de dados
Pode parecer uma proteção desnecessária, mas proteger o log do WAF é um item importante na preservação de dados pessoas (PII) ou mesmo corporativos de seus clientes e parceiros.
Cenário
Como seu site precisa receber dados de login (sejam clientes, parceiros ou fornecedores) nas chamadas POST ou JSON com nome de usuário e senha, você poderá ter um vazamento caso o log caia em mãos de um agente malicioso que pode ser um funcionário ou externo.
Um exemplo que tive a alguns anos atras foi em um sistema de consulta de crédito integrado a parceiros de cadastro como SERASA e Associações Comerciais. O log de erros do sistema guardava em formato plain text no banco de dados os chamados com erros para que os desenvolvedores e o SAC pudessem encontrar erros no retorno de consultas.
Porém, nesse log muitas vezes o problema era erro na senha e nome de usuário enviados e com isso bastaria usar a lógica para deduzir que o usuário escreveu uma letra ou digito a mais ou diferente para conseguir saber sua senha.
E pior ainda, no log completo do serviço de autenticação era possível ver no GET os dados enviados para o cliente. Ou seja, se um parceiro consultar o meu CPF ou de alguém que me interesse, eu poderia procurar no log o retorno que foi enviado a performance nos serviços de crédito desta pessoa sem que isso fosse logado em qualquer lugar já que acessei diretamente o log.
Agora no Azure podemos deixar isso no passado, uma vez que não precisamos mais guardar logs programáticos já que ele armazena tudo no Log Analytics. Mas ainda temos um log onde qualquer operador de segurança pode usar um KQL e ver os dados, até mesmo utilizar um usuário valido para consultar dados no sistema.
Solução
Na época que notamos este problema a solução teve que ser manual, remover programaticamente nas funções a gravação de log para usuário e senha, além de mascarar CPF e CNPJ. Mas obviamente este não era uma solução definitiva, já que o log do WAF e do IIS ainda guardariam os dados brutos.
Agora no Azure WAF é possível criar regras de mascaramento para o log, ou seja, poderei identificar os dados no JSON e no POST que preciso proteger e proibir que sejam usados em consultas KQL.
Configuração
Nas propriedades da política do WAF use o menu "Sensitive Data" para acessar o log scrubbing como a minha configuração abaixo:
Em meu exemplo utilizei os parâmetros e variáveis que são utilizadas pelos meus desenvolvedores para identificar usuário, senha, número de contrato e ID do cliente. Aqui poderia acrescentar CPF, CNPJ ou outros documentos que sejam argumentos recebidos e enviados.
Abaixo temos a lista de tipos de variáveis que podem ser mascaradas atualmente:
Com exceção do IP Address todos os outros tipos permitem a opção "Equal" e "Equal any" onde a primeira permite indicar uma informação nomeada e a segunda mascara qualquer que seja o conteudo no item selecionado. No caso do "Equal any" é importante lembrar que ele irá criptografar todas as variaveis daquele formato, o que pode ser ruim para debug futuro.
Referência
Utilizando o Log Analytics do Application Insights para detectar anomalias em Web Apps
Em um post passado abordei o uso do Log do Application Insigths para visualizar ataques e anomalias Marcelo Sincic | Utilizando o Azure Application Insigths na Analise de Vulnerabilidades
Porem, vi a necessidade de complementar para alguns que me pediram para integrar as consultas com logs do MCAS, Defender e outros.
Partindo do principio que em todas as ferramentas utilizaremos KQL (Kusto Query Language) o primeiro passo é escrever o comando para isso e trazer o log como a imagem abaixo:
Na consulta acima é possivel trazer os dados que estão no dashboard do artigo anterior, porem por estar escrito em KQL poderá customizar as colunas, formatos e filtra o que melhor lhe interessa.
Por exemplo, poderá alerar a consulta original para trazer os IPs por paises que mais consultaram as páginas de seu site para detectar origens que deseja filtrar e barrar no firewall:
AppRequests
| where TimeGenerated > ago(1d)
| where Success == False
| summarize count() by ClientIP, ClientCountryOrRegion
Outro exemplo é filtrar as requisições que tentaram baixar arquivos compactados diretamente de seu site, como o exemplo abaixo:
AppRequests
| where TimeGenerated > ago(1d)
| where Success == False
| where Url contains "zip" or Url contains "rar"
| project ClientCountryOrRegion, ClientStateOrProvince, ClientCity, ClientIP, Url
Um terceiro exemplo é eu conseguir identificar as tentativas de SQL Injection a partir dos comandos básicos utilizados para esse tipo de exploração de vulnerabilidade:
AppRequests
| where TimeGenerated > ago(1d)
| where Success == False
| where Url contains "select" or Url contains "union"
| project Url, ClientCountryOrRegion, ClientStateOrProvince, ClientCity, ClientIP
Conclusão
Com o uso dos logs armazenados de sua aplicação será possivel visualizar os principais ataques e como se defender melhorando sua aplicação e ter um monitoramento de atividades.