Fundamentos de KQL que Todo Analista de SOC Deveria Conhecer

Kusto Query Language (KQL) é a base da caça de ameaças e triagem de alertas no Microsoft Sentinel e Microsoft Defender. Se você trabalha em um SOC, fluência em KQL diferencia analistas que conseguem responder rapidamente "o que aconteceu aqui?" daqueles presos clicando em dashboards. Isso não é uma referência completa da linguagem — é o subconjunto prático que é usado constantemente durante o turno.

Por Que KQL Importa no SOC

KQL é apenas leitura e otimizada para consultar conjuntos de logs massivos rapidamente. Sentinel, Defender for Endpoint, Azure Monitor e Log Analytics todas falam KQL. Uma vez que você a domina, consegue pivotar entre produtos com o mesmo modelo mental: escolha uma tabela, filtre-a, formule a saída. Toda investigação — triagem de phishing, caças de movimento lateral, ajustes de falsos positivos — começa com uma consulta.

O Pipe É Tudo

Consultas KQL são construídas como um pipeline. Você começa com uma tabela e passa dados através de uma série de operadores, cada um filtrando, transformando ou sumarizando o resultado anterior:

SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(24h)
| summarize FailedLogons = count() by Account, Computer
| sort by FailedLogons desc

Leia de cima para baixo como uma frase: comece com logs SecurityEvent, mantenha apenas logons falhados (4625), restrinja ao último dia, conte falhas por conta/computador, depois ordene. Essa legibilidade linear é a maior vantagem de KQL sobre SQL para caças ad hoc.

Operadores Principais para Memorizar

• where — seu filtro principal. Use cedo e frequentemente para reduzir volume de dados antes de operações caras.
• project — selecione e renomeie colunas específicas, descartando ruído que você não precisa na saída.
• extend — adicione colunas computadas sem descartar as existentes, útil para fazer parsing de strings ou sinalizar condições.
• summarize — agregue dados com count(), sum(), dcount() ou make_set(), quase sempre emparelhado com by.
• join — correlacione entre tabelas, p.ex., vinculando logs de sign-in com inventário de dispositivos para detectar logons em dispositivos não gerenciados.
• render — visualize resultados como timechart ou barchart diretamente no editor de consultas, útil para detectar picos.

Filtragem de Tempo Feita Corretamente

Sempre filtre em TimeGenerated (ou a coluna de timestamp equivalente da tabela) o mais cedo possível no pipeline. Motores KQL otimizam pesadamente em torno de filtros de intervalo de tempo, e colocar | where TimeGenerated > ago(7d) perto do topo em vez de perto do fundo pode ser a diferença entre uma consulta que retorna em segundos versus uma que atinge timeout em um tenant ocupado.```kql SigninLogs | where TimeGenerated > ago(1h) | where ResultType != "0" | where UserPrincipalName has "@yourdomain.com"

## Correspondência de Strings: has vs contains vs ==

Um erro comum é usar `contains` para tudo. `has` corresponde a termos completos e usa um índice de termos, tornando-o dramaticamente mais rápido em tabelas grandes. Use `contains` apenas quando precisar de correspondências de substring dentro de uma palavra (como um fragmento de domínio parcial), e use `==` para correspondências exatas em campos estruturados como EventID ou IPAddress. Este único hábito acelera notavelmente caças em tabelas de alto volume como `DeviceNetworkEvents` ou `CommonSecurityLog`.```kql
DeviceProcessEvents
| where ProcessCommandLine has "powershell"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand")

Construindo Lógica de Detecção Reutilizável

Uma vez que uma consulta se prova útil, encapsule-a como uma função com let, ou salve-a como uma Sentinel Analytics Rule com execução agendada. Parametrize limites (como contagens de logon falhado) para que a mesma lógica escale entre tenants ou seja ajustada sem ser reescrita do zero. É assim que consultas de caça únicas evoluem para detecções permanentes que alertam o SOC automaticamente.

Armadilhas Comuns

• Esquecer filtros TimeGenerated, causando varreduras de tabela completa lentas e caras.
• Usar summarize antes de where, o que força o motor a agregar dados não filtrados.
• Nomes de coluna incompatíveis ao fazer join em tabelas — sempre verifique o schema com getschema primeiro.
• Usar contains em excesso, o que ignora benefícios de indexação e desacelera caças em larga escala.

KQL recompensa analistas que pensam em pipelines em vez de subconsultas aninhadas. Comece toda investigação com uma janela de tempo estreita e uma tabela específica, depois amplie apenas conforme necessário.

Se isso lhe deu uma base sólida, explore os segmentos Blue Team e Digital Forensics no Korra Studio para mais walkthroughs de consultas SOC práticas e exercícios de construção de detecções.