As consultas KQL (Kusto Query Language) são a linguagem de consulta nativa do Microsoft Sentinel, a plataforma de inteligência de segurança da Microsoft que centraliza a análise de ameaças e investigação de incidentes. Se você trabalha ou pretende trabalhar com detecção de ameaças, resposta a incidentes ou análise de logs de segurança, entender o que são consultas KQL e para que servem é fundamental para aproveitar todo o potencial do Sentinel.

A KQL permite que analistas de segurança e administradores de TI consultem, filtrem e correlacionem grandes volumes de dados de eventos em tempo real. Com ela, é possível criar regras de detecção personalizadas, investigar comportamentos suspeitos, rastrear padrões de ataque e gerar relatórios de conformidade — tudo isso de forma precisa e eficiente. Dominar essa linguagem transforma você em um profissional mais capacitado para proteger infraestruturas corporativas contra ameaças cibernéticas.

Neste artigo, você vai descobrir os fundamentos das consultas KQL, seus principais componentes, casos de uso práticos e como começar a utilizá-las no Microsoft Sentinel para elevar sua expertise em cibersegurança.

O que é KQL (Kusto Query Language)?

Definição e origem do KQL

KQL é a sigla para Kusto Query Language, uma linguagem de consulta desenvolvida pela Microsoft para explorar grandes volumes de dados de telemetria, logs e eventos em tempo real. O nome "Kusto" vem do codinome interno do projeto que originou o Azure Data Explorer, serviço de análise de dados da Microsoft que usa KQL como linguagem nativa. Com o crescimento do ecossistema Azure, o KQL foi adotado em diversos produtos da empresa, incluindo o Microsoft Sentinel, o Azure Monitor, o Microsoft Defender for Endpoint e o Application Insights.

A linguagem foi projetada para ser expressiva, legível e altamente eficiente em cenários onde bilhões de registros precisam ser consultados em segundos. Diferente de linguagens de propósito geral, o KQL é orientado exclusivamente à leitura e análise de dados — ele não realiza operações de escrita, atualização ou exclusão de registros. Isso o torna ideal para ambientes de monitoramento e segurança, onde a integridade dos dados brutos deve ser preservada.

Como o KQL se diferencia de outras linguagens de consulta (SQL, SPL)

Profissionais que já conhecem SQL ou SPL (Search Processing Language, usada no Splunk) perceberão semelhanças conceituais com o KQL, mas também diferenças importantes na sintaxe e no modelo mental de construção de consultas.

  • KQL vs. SQL: enquanto o SQL usa cláusulas declarativas como SELECT ... FROM ... WHERE, o KQL adota um modelo de pipeline encadeado com o caractere pipe (|). Em vez de declarar o resultado esperado, você transforma os dados progressivamente, operador por operador. Isso torna o raciocínio mais linear e a depuração mais intuitiva.
  • KQL vs. SPL: o SPL do Splunk também usa pipelines, o que facilita a transição. Porém, o KQL tem sintaxe mais limpa e operadores mais expressivos para agregações e séries temporais. Além disso, o KQL é fortemente tipado, o que reduz erros em consultas complexas.
  • Performance: o KQL foi otimizado para o Azure Data Explorer, que utiliza indexação colunar e compressão agressiva. Isso permite consultas extremamente rápidas mesmo em tabelas com dezenas de terabytes de dados.

Para que servem as consultas KQL no Microsoft Sentinel?

Detecção de ameaças e criação de alertas de segurança

No Microsoft Sentinel, as consultas KQL são o núcleo de toda a lógica de detecção. Cada regra de análise é, essencialmente, uma consulta KQL que roda em intervalos definidos e gera alertas quando encontra padrões suspeitos nos dados ingeridos. Um analista de SOC pode escrever uma consulta que identifica múltiplas falhas de autenticação em um curto período, por exemplo, e transformá-la em uma regra que dispara um incidente automaticamente.

Threat hunting: investigação proativa de incidentes

O threat hunting é a prática de buscar ativamente por ameaças que ainda não geraram alertas. No Sentinel, a seção de Hunting permite salvar e executar consultas KQL de forma ad hoc, explorando hipóteses sobre comportamentos maliciosos. Um caçador de ameaças pode, por exemplo, buscar por processos incomuns iniciados por contas de serviço ou por conexões a domínios recém-registrados — tudo isso por meio de consultas KQL personalizadas.

Criação de regras de análise agendadas no Microsoft Sentinel

As regras de análise agendadas são o mecanismo mais usado para detecção contínua no Sentinel. Elas executam uma consulta KQL em intervalos configuráveis (a cada 5 minutos, 1 hora, 24 horas etc.) e comparam os resultados com uma janela de tempo definida. Quando os critérios são atendidos, o Sentinel cria automaticamente um incidente, que pode acionar playbooks de resposta automatizada. A qualidade da regra depende diretamente da precisão e eficiência da consulta KQL subjacente.

Monitoramento contínuo e correlação de eventos de segurança

O KQL permite correlacionar eventos de diferentes fontes de dados em uma única consulta. É possível, por exemplo, cruzar logs de autenticação do Azure Active Directory com eventos de processo do Windows e alertas do Microsoft Defender, identificando cadeias de ataque que seriam invisíveis se cada fonte fosse analisada isoladamente. Essa capacidade de correlação é um dos principais diferenciais do Microsoft Sentinel em relação a outras ferramentas de SIEM.

Transformação e ingestão de dados personalizados com KQL

Além da análise, o KQL também é usado nas regras de transformação de dados durante a ingestão. Por meio dos Data Collection Rules (DCRs), é possível aplicar consultas KQL para filtrar, enriquecer ou reformatar logs antes que eles sejam armazenados no workspace do Sentinel. Isso reduz custos de ingestão e melhora a qualidade dos dados disponíveis para análise. Saiba mais sobre esse processo em nosso guia sobre como fazer ingestão de logs no Microsoft Sentinel.

Estrutura básica de uma consulta KQL

Tabelas, operadores de pipe e filtros essenciais

Toda consulta KQL começa com o nome de uma tabela e, a partir daí, encadeia operadores separados pelo caractere | (pipe). A estrutura básica segue o padrão:

NomeDaTabela | operador1 | operador2 | operador3

Cada operador recebe o resultado do anterior e o transforma. Essa abordagem de pipeline torna o fluxo de dados explícito e facilita a leitura e manutenção da consulta. Os filtros são aplicados com o operador where, que reduz o volume de registros logo no início — prática essencial para performance.

Operadores mais usados: where, project, summarize, extend e union

  • where: filtra registros com base em condições booleanas. Exemplo: where EventID == 4625 retorna apenas eventos de falha de logon.
  • project: seleciona e renomeia colunas, equivalente ao SELECT do SQL. Reduz o volume de dados retornados e melhora a legibilidade.
  • summarize: agrega dados, permitindo contagens, médias, valores máximos e mínimos agrupados por uma ou mais colunas. Essencial para detectar padrões volumétricos.
  • extend: adiciona colunas calculadas à tabela sem remover as existentes. Útil para criar campos derivados, como extrair o domínio de um endereço de e-mail.
  • union: combina registros de duas ou mais tabelas em um único resultado, permitindo análises que cruzam múltiplas fontes de dados.

Como usar o operador union para consultar múltiplas tabelas simultaneamente

O operador union é especialmente valioso em cenários de threat hunting, onde a ameaça pode deixar rastros em diferentes tabelas. A sintaxe básica é union Tabela1, Tabela2 | where .... É possível usar wildcards para unir tabelas com nomes semelhantes, como union Security*, que inclui automaticamente todas as tabelas cujo nome começa com "Security". Ao usar o union, atenção ao esquema: colunas com o mesmo nome mas tipos diferentes podem gerar erros ou resultados inesperados.

Principais tabelas do Microsoft Sentinel consultadas via KQL

SecurityEvent, SigninLogs, AzureActivity e outras tabelas críticas

O Microsoft Sentinel organiza os dados ingeridos em tabelas dentro do workspace do Log Analytics. As mais consultadas em investigações de segurança incluem:

  • SecurityEvent: eventos de segurança do Windows coletados via agente MMA ou AMA. Inclui logons, criação de processos, alterações de políticas e muito mais.
  • SigninLogs: registros de autenticação do Azure Active Directory, incluindo logons interativos, condicionais e de aplicativos.
  • AzureActivity: operações realizadas na assinatura Azure, como criação e exclusão de recursos, alterações de permissões e implantações.
  • OfficeActivity: atividades no Microsoft 365, incluindo acesso a arquivos no SharePoint, envio de e-mails e alterações em configurações do Teams.
  • DeviceProcessEvents, DeviceNetworkEvents: eventos de processo e rede coletados pelo Microsoft Defender for Endpoint, essenciais para investigações em endpoints.
  • CommonSecurityLog: logs no formato CEF provenientes de firewalls, proxies e outros dispositivos de rede.

Como identificar a tabela certa para cada cenário de investigação

A escolha da tabela correta começa pela compreensão da fonte de dados relevante para o cenário. Se a investigação envolve autenticação em nuvem, SigninLogs é o ponto de partida. Para eventos em servidores Windows, SecurityEvent. Para atividades administrativas no Azure, AzureActivity. Uma boa prática é usar a função search do KQL para buscar um termo em todas as tabelas disponíveis, identificando onde o dado de interesse está armazenado antes de construir a consulta definitiva. Também é possível criar dashboards personalizados no Sentinel que consolidam dados de múltiplas tabelas para facilitar o monitoramento recorrente.

Exemplos práticos de consultas KQL no Microsoft Sentinel

Consulta para detectar logins suspeitos e tentativas de força bruta

A consulta abaixo identifica contas com mais de 10 falhas de autenticação em um intervalo de 1 hora, um padrão clássico de ataque de força bruta:

SecurityEvent | where TimeGenerated > ago(1h) | where EventID == 4625 | summarize FailedAttempts = count() by TargetAccount, IpAddress | where FailedAttempts > 10 | order by FailedAttempts desc

Essa consulta filtra eventos de falha de logon (EventID 4625), agrega por conta e IP de origem, e retorna apenas os casos com mais de 10 tentativas, ordenados pelo volume de falhas.

Consulta para identificar alterações privilegiadas em contas de usuário

Monitorar adições a grupos privilegiados como "Domain Admins" é crítico. O EventID 4728 registra adições a grupos de segurança globais no Windows:

SecurityEvent | where TimeGenerated > ago(24h) | where EventID == 4728 | project TimeGenerated, SubjectAccount, MemberName, TargetUserName | order by TimeGenerated desc

Essa consulta retorna todas as adições de membros a grupos de segurança nas últimas 24 horas, mostrando quem fez a alteração (SubjectAccount), quem foi adicionado (MemberName) e em qual grupo (TargetUserName).

Consulta para monitorar atividades anômalas no Azure Monitor

Para identificar operações de exclusão de recursos no Azure, que podem indicar sabotagem ou comprometimento de credenciais administrativas:

AzureActivity | where TimeGenerated > ago(7d) | where OperationNameValue has "delete" and ActivityStatusValue == "Success" | project TimeGenerated, Caller, ResourceGroup, OperationNameValue, SubscriptionId | order by TimeGenerated desc

Essa consulta filtra operações de exclusão bem-sucedidas nos últimos 7 dias, exibindo quem executou a ação, em qual grupo de recursos e em qual assinatura.

KQL integrado ao Microsoft Security Copilot

Como o Security Copilot gera e interpreta consultas KQL automaticamente

O Microsoft Security Copilot é uma camada de inteligência artificial integrada ao ecossistema de segurança da Microsoft que, entre outras capacidades, pode gerar consultas KQL a partir de linguagem natural. Um analista pode descrever o que deseja investigar — por exemplo, "mostre todos os logins bem-sucedidos de usuários fora do horário comercial nos últimos 3 dias" — e o Copilot traduz essa instrução em uma consulta KQL funcional, pronta para ser executada no Sentinel.

Além da geração, o Copilot também interpreta os resultados de consultas existentes, explicando o que cada operador faz e sugerindo otimizações. Isso reduz significativamente a curva de aprendizado para analistas menos experientes em KQL.

Benefícios da IA na aceleração de investigações com KQL

A integração de IA ao fluxo de trabalho com KQL traz benefícios concretos para equipes de segurança:

  • Redução do tempo de resposta: consultas que levariam horas para serem escritas manualmente podem ser geradas em segundos.
  • Democratização do conhecimento: analistas júnior conseguem realizar investigações avançadas sem dominar completamente a sintaxe KQL.
  • Sugestão de hipóteses: o Copilot pode sugerir consultas adicionais com base no contexto do incidente em investigação, ampliando o escopo da análise.
  • Explicação de consultas legadas: consultas antigas sem documentação podem ser explicadas pela IA, facilitando a manutenção e atualização do repositório do SOC.

Boas práticas para escrever consultas KQL eficientes

Otimização de performance: filtrar cedo, reduzir volume de dados

A regra de ouro do KQL é filtrar o mais cedo possível. Aplicar o operador where logo após o nome da tabela reduz drasticamente o volume de dados que os operadores subsequentes precisam processar. Sempre inclua um filtro de tempo (where TimeGenerated > ago(Xh)) como primeiro operador, pois o Azure Data Explorer usa a coluna TimeGenerated para particionamento físico dos dados. Consultas sem filtro de tempo varrem toda a tabela, o que aumenta o custo e o tempo de execução.

Uso de variáveis (let) e funções reutilizáveis

O operador let permite definir variáveis e subconsultas reutilizáveis dentro de uma consulta KQL. Isso melhora a legibilidade e evita repetição de lógica. Por exemplo:

let JanelaDeAnalise = ago(24h); let LimiteDefalhas = 5; SecurityEvent | where TimeGenerated > JanelaDeAnalise | where EventID == 4625 | summarize count() by TargetAccount | where count_ > LimiteDefalhas

Ao centralizar parâmetros em variáveis let, a consulta fica mais fácil de ajustar e compartilhar com a equipe.

Documentação e versionamento de consultas para equipes de SOC

Consultas KQL são ativos estratégicos de um SOC e devem ser tratadas como código. Boas práticas incluem:

  • Adicionar comentários descritivos com // explicando o objetivo e a lógica de cada bloco.
  • Armazenar consultas em repositórios Git, permitindo rastreamento de alterações e colaboração entre analistas.
  • Nomear consultas de forma padronizada, incluindo a categoria (detecção, hunting, monitoramento) e a ameaça alvo.
  • Revisar periodicamente as consultas para garantir que continuam relevantes frente à evolução das táticas dos atacantes.

Como começar a aprender KQL para o Microsoft Sentinel

Recursos oficiais da Microsoft e ambientes de prática gratuitos

A Microsoft disponibiliza uma série de recursos gratuitos para quem quer aprender KQL:

  • Microsoft Learn: o módulo "Write your first query with Kusto Query Language" oferece uma introdução estruturada com exercícios interativos diretamente no navegador.
  • Azure Data Explorer Demo: ambiente gratuito em dataexplorer.azure.com com conjuntos de dados públicos onde é possível praticar KQL sem precisar de uma assinatura Azure.
  • Log Analytics Demo Workspace: a Microsoft mantém um workspace de demonstração com dados reais de segurança, acessível via portal do Azure, ideal para praticar consultas no contexto do Sentinel.

Comunidades, laboratórios e repositórios de consultas prontas

A comunidade em torno do Microsoft Sentinel e do KQL é ativa e generosa em compartilhar conhecimento:

  • Repositório oficial do Microsoft Sentinel no GitHub: contém centenas de consultas de hunting, regras de detecção e workbooks prontos para uso e adaptação.
  • KQL Search (kqlsearch.com): mecanismo de busca especializado em consultas KQL compartilhadas pela comunidade, com filtros por produto e categoria.
  • Microsoft Tech Community: fóruns ativos com discussões sobre Sentinel, KQL e segurança em geral, onde é possível tirar dúvidas e acompanhar novidades.
  • Cursos especializados: plataformas de ensino focadas em cibersegurança oferecem trilhas que combinam teoria e prática de KQL dentro do contexto real do Sentinel, preparando analistas de segurança da informação para o mercado de trabalho.

Perguntas Frequentes sobre KQL e Microsoft Sentinel

KQL é exclusivo do Microsoft Sentinel ou funciona em outros produtos?

O KQL não é exclusivo do Microsoft Sentinel. A linguagem é usada em todo o ecossistema de dados e segurança da Microsoft. Ela está presente no Azure Data Explorer, no Azure Monitor (incluindo Log Analytics), no Microsoft Defender for Endpoint (via Advanced Hunting), no Microsoft Defender XDR, no Application Insights e no Microsoft Purview. Isso significa que aprender KQL é um investimento com alto retorno: a mesma habilidade se aplica a múltiplos produtos e cenários, desde monitoramento de aplicações até investigações forenses em endpoints. Para profissionais que atuam ou desejam atuar na área de segurança da informação, dominar KQL representa uma vantagem competitiva significativa e cada vez mais valorizada pelo mercado.