FALCON MCP: INVESTIGANDO O CROWDSTRIKE COM IA E LINGUAGEM NATURAL

Quando uma detecção de alta severidade aparece

O cenário é familiar para qualquer analista de SOC: uma detecção de alta severidade surge no painel do CrowdStrike Falcon. “Machine Learning Identified High Confidence Malicious File” — detecção on-sensor ML, severidade alta. O endpoint afetado: um laptop de jogos da família, Windows 11, rodando o sensor Falcon. O card do console informa quase nada além do básico: processo Opera GX, arquivo .tmp aleatório na pasta Downloads, score acima do threshold de alta confiança do ML. Prevalência local: única, primeiro aparecimento do hash no ambiente. Disposição: apenas detect, nada bloqueado.

A pergunta imediata não é “existe um alerta?” — o alerta está lá. A pergunta é: “o que o Opera GX acabou de baixar?” Em vez de navegar por telas, montar consultas manualmente e alternar entre ferramentas, o investigador abriu o Claude Desktop e perguntou: “como investigar este alerta?”

CrowdStrike encontra Claude através do MCP

O Model Context Protocol (MCP) é um protocolo aberto que padroniza como modelos de linguagem se conectam a ferramentas externas. No caso do falcon-mcp — servidor MCP de código aberto (MIT) mantido pela comunidade e ativamente suportado pela CrowdStrike, atualmente em public preview — a arquitetura funciona assim:

Claude Desktop
    ↓ (MCP)
falcon-mcp server
    ↓ (Falcon API)
CrowdStrike Falcon
    ↓
Telemetria / Detecções / NGSIEM / Intel / RTR
    ↓
Contexto estruturado
    ↓
Claude Desktop
    ↓
Análise em linguagem natural

O falcon-mcp expõe cinco módulos principais: detections, hosts, intel, ngsiem e rtr. Cada módulo mapeia para scopes específicos da API Falcon. A configuração requer três peças: um API client no console Falcon (Support and resources → API clients and keys), um arquivo .env com credenciais, e o bloco mcpServers no claude_desktop_config.json.

{
  "mcpServers": {
    "falcon-mcp": {
      "command": "uvx",
      "args": [
        "--env-file",
        "C:\\path\\to\\falcon-mcp\\.env",
        "falcon-mcp",
        "--modules",
        "detections,hosts,intel,ngsiem,rtr"
      ]
    }
  }
}

O arquivo .env contém FALCON_CLIENT_ID, FALCON_CLIENT_SECRET e FALCON_BASE_URL (ex: https://api.us-2.crowdstrike.com). O uvx puxa e executa o pacote publicado — nada para instalar além do próprio uv. Reiniciar o Claude Desktop faz o servidor aparecer em Settings → Local MCP servers com badge “Running” e log viewer.

A dança dos scopes

A maior fonte de atrito na configuração é a granularidade dos scopes da Falcon API. As mensagens de erro revelam os scopes necessários um por vez. Lições aprendidas batendo em cada parede:

• NGSIEM search requer NGSIEM: Write — contraintuitivo mas correto: buscas NGSIEM são submetidas como jobs assíncronos, e criação de job é write. Mesmo consulta read-only precisa do scope write.
• Scopes de Intel são três linhas separadas: Actors, Indicators e Reports (Falcon Intelligence) são concedidos individualmente. Actor lookups funcionaram enquanto indicator lookups falharam, porque apenas uma linha estava marcada.
• Mudanças de scope precisam de token refresh — o servidor cacheia o token OAuth. Após adicionar scopes no console, reinicie o servidor MCP (ou todo o Claude Desktop) para pegá-los. Nenhuma rotação de secret necessária quando apenas adiciona scopes.
• Módulos são tudo-ou-nada — habilitar um módulo para obter suas ferramentas de busca também expõe toda ferramenta mutante que ele carrega. O módulo detections inclui update; o módulo rtr inclui execução de comando. O raio de explosão é controlado no API client: conceda scopes read-only e as ferramentas mutantes falham na API não importa o que o modelo chame. Essa camada — módulo no servidor, scope no client — é o modelo de permissão real.
• Claude Desktop faz snapshot das ferramentas disponíveis ao iniciar uma conversa. Adicione um módulo no meio da conversa e o chat em execução não o verá. Novo chat, novo snapshot.

Para capacidade de triagem ponta-a-ponta, este é o mapa módulo-para-scope que importou:

Módulo	Scopes	Finalidade
detections	Alerts: Read, Write	Encontrar, triar, fechar alertas
hosts	Hosts: Read, Write	Contexto de host, tags de agrupamento
ngsiem	NGSIEM: Read, Write	Caça no event lake
intel	Actors, Indicators, Reports: Read	Enriquecimento e atribuição
rtr	Real time response: Read (Write opcional), RTR audit: Read	Interrogação live de host

Recomendação para time pequeno: tudo Read, mais Write apenas em Alerts e NGSIEM. Escale RTR e writes de quarentena no dia que realmente precisar. Scopes levam trinta segundos para adicionar; acesso write permanente à frota não pode ser des-exposto após uma chamada de ferramenta ruim.

First Blood: a primeira investigação real

Enquanto ainda testava a configuração, o Falcon disparou a detecção real. A investigação via chat contou tudo. Aqui está a sequência, cada passo um único prompt.

Começando pela detecção

Prompt: “puxe a detecção completa”. O registro completo mostrou que o Opera GX escreveu um arquivo .tmp com nome aleatório na pasta Downloads do usuário e, segundos depois, esse tmp foi carregado como módulo e pontuado acima do threshold de alta confiança do ML on-sensor. Prevalência local: única, primeira vez que o hash foi visto no ambiente. Disposição: detect only, nada bloqueado. O navegador estava bem; a questão era o que ele havia baixado.

Investigando por linguagem natural

A investigação seguiu o padrão PERGUNTA → FERRAMENTA/CONSULTA → RESULTADO → INTERPRETAÇÃO → PRÓXIMO PIVÔ:

• “verifique o hash contra intel” → módulo intel → nenhuma associação known-bad (uma vez que o scope Indicators existia)
• “qual o blast radius via NGSIEM?” → módulo ngsiem → uma query CQL para o SHA256 em toda a frota: quatro eventos, um host, nenhum outro lugar. A telemetria revelou algo que o card do alerta não mostrava: um evento QuarantinedFileState existia para o tmp, então o sensor quarentenou o arquivo parcial afinal
• “encontre a origem” → DNS do host nos minutos antes do download mostrou github.com e release-assets.githubusercontent.com. Então a query decisiva: eventos MotwWritten. Mark-of-the-Web telemetry carrega a URL completa de download e referrer, e lá estava: Lumafly.exe, baixado de um asset de release de produção do GitHub, referrer sendo o site oficial GitHub Pages do desenvolvedor. Lumafly é o gerenciador de mods open source Hollow Knight do TheMulhima. Tráfego Steam na mesma janela DNS completou o quadro: alguém estava modding um jogo.

Buscando contexto no NGSIEM

O módulo NGSIEM permitiu consultar o event lake via CQL (CrowdStrike Query Language). A query do SHA256 em toda a frota retornou apenas quatro eventos em um único host — o blast radius estava contido. Criticamente, a telemetria NGSIEM revelou o evento QuarantinedFileState que o card de alerta original não mostrava: o sensor de fato quarentenou o arquivo parcial após o download.

Threat Intelligence entra na investigação

Com o scope Indicators habilitado, a consulta de threat intelligence contra o hash retornou: nenhuma evidência conhecida de malícia. Importante diferenciar: “nenhuma evidência conhecida de malícia” não é o mesmo que “arquivo comprovadamente seguro”. Ausência de detecção não deve ser apresentada automaticamente como prova absoluta de legitimidade. A verificação independente era necessária.

Mark-of-the-Web: de onde veio esse arquivo?

O Mark-of-the-Web (MOTW) é um recurso do Windows que marca arquivos baixados da internet com metadados de zona (Zone.Identifier), preservando a URL de origem e o referrer. No contexto da investigação, os eventos MotwWritten do Falcon telemetry carregam exatamente essa informação: a URL completa de download e o referrer.

O evento MotwWritten revelou: Lumafly.exe, baixado de um asset de release de produção no GitHub (release-assets.githubusercontent.com), com referrer sendo a página GitHub Pages oficial do desenvolvedor. Isso transformou a investigação: o arquivo não era um payload obscuro — era uma ferramenta legítima de modding baixada da fonte oficial.

Qual é o alcance do incidente?

Estabelecer o scope (abrangência) antes de concluir é fundamental. As perguntas: esse arquivo apareceu só nesse endpoint? Existem outras máquinas envolvidas? Outras detecções relacionadas? A query NGSIEM do SHA256 em toda a frota respondeu: quatro eventos, um host, nenhum outro lugar. Nada mais no ambiente jamais viu esse hash.

Entrando no endpoint com RTR

O arquivo Lumafly.exe completado na pasta Downloads era o que importava. Um comando RTR contra o host:

filehash "C:\\Users\\<user>\\Downloads\\Lumafly.exe"

O console RTR fala sua própria linguagem de comandos, não PowerShell, e filehash é purpose-built para exatamente isso. Scripts de resposta personalizados em PowerShell também podem ser escritos e executados como um todo. O SHA256 retornado foi um match exato, byte-por-byte, com o release oficial do GitHub.

Confirmando o hash

A verificação independente separa “provavelmente ok” de “confirmado”. De um sandbox, o investigador puxou o binário do release oficial mais recente do GitHub repo capturado na telemetria e o hasheou. Não bateu com o hash detectado — sobrancelha erguida por um minuto — até a timeline explicar: a detecção disparou no arquivo tmp mid-download. Um arquivo parcial nunca hasheia como o release finalizado.

Reconstruindo a origem do arquivo

A cadeia de evidências convergiu: detecção ML on-sensor → arquivo tmp partial no Downloads → DNS mostra github.com e release-assets.githubusercontent.com → MotwWritten confirma Lumafly.exe do release oficial GitHub → Threat Intel sem known-bad → NGSIEM confirma blast radius único → RTR filehash do Lumafly.exe completo matcha release oficial. Junior baixou ferramenta legítima da fonte legítima; sensor quarentenou arquivo parcial morto; nada mais no ambiente viu o hash.

Falso positivo

A investigação original chega à classificação de falso positivo. Lumafly é um bundle .NET single-file autocontido, ~137 MB de binário packed de alta entropia — precisamente o perfil que dispara heurísticas de ML on-sensor. O prompt final: fechar a detecção, taguear false_positive, e anexar toda a cadeia de evidências (URL de origem, ambos hashes, verificação RTR, blast radius) como comentário. Esse closure foi pela mesma conexão MCP, e agora está no registro no console para o dia que o ML disparar na próxima atualização do Lumafly.

IA não é evidência

Este ponto é fundamental. A IA pode: consultar, organizar, resumir, correlacionar, contextualizar, ajudar a formular hipóteses. Mas a decisão deve estar fundamentada em evidências provenientes das ferramentas de segurança. LLM ≠ fonte primária de evidência. A equação correta:

CrowdStrike/telemetria/evidências
+
contexto
+
raciocínio
=
conclusão

Diferencie: “Claude disse que era falso positivo” vs “o conjunto de evidências analisadas levou à classificação de falso positivo”. A IA aparece como ferramenta de investigação/orquestração, não como autoridade absoluta. Isso deve ser tratado profissionalmente, sem diminuir o valor da integração.

O que muda quando o EDR ganha uma interface conversacional

O gap entre “chatbot com plugin de segurança” e “analista júnior com recall perfeito da sua telemetria” é basicamente configuração de scope e saber qual pergunta fazer em seguida. A segunda parte continua sendo seu trabalho. Cenários follow-on valiosos para rodar no próprio tenant:

• Triage matinal: agregar detecções overnight por severidade e host, enriquecer as interessantes, rascunhar disposições para false positives óbvios, deixar pro humano as chamadas de julgamento
• Actor TTP overlay: puxar relatório MITRE ATT&CK de actor relevante à região, fazer o modelo traduzir técnicas em queries NGSIEM hunting contra sua telemetria — intel para hunt em uma conversa
• IOC sweep de relatório CTI: colar indicadores de qualquer relatório de vendor e varrer o event lake para todo hash, domínio e IP de uma vez
• Validação purple team: rodar teste Atomic Red Team em host de lab, pedir pro modelo achar: quais eventos dispararam, qual detection triggerou, como era a process tree. Excelente pra calibrar confiança no sensor e no agente
• Live RTR triage runbook: para host suspeito: ps, netstat, arquivos recentes, filehash nas estranhezas, tudo read-only, tudo em uma thread com a detecção que começou tudo
• Detection engineering: uma vez que query de hunt prove out, promova: rascunhe correlation rule ou custom IOA do CQL que funcionou. Módulos correlationrules e custom-ioa existem exatamente pra esse arco de hunt para detection

Segurança e limites do MCP

Um modelo conectado a uma plataforma EDR possui capacidades extremamente sensíveis. Boas práticas arquiteturais defensivas:

• Princípio do menor privilégio: conceda apenas scopes read-only exceto onde write é estritamente necessário
• Separação entre leitura e escrita: módulos expõem ambas; controle real está no API client scope
• Autorização e autenticação: credenciais no .env, token OAuth cacheado, refresh explícito em mudança de scope
• Logs e auditoria: cada chamada de ferramenta via MCP deixa rastro na API Falcon
• Confirmação humana: ações destrutivas (quarentena, containment) devem exigir aprovação explícita
• Gerenciamento de credenciais: rotação periódica, armazenamento seguro, não commitar .env

Não se afirma que a implementação original é vulnerável — a fonte não demonstra isso. Trata-se de boas práticas para qualquer deployment de MCP em produção.

Lições da investigação

• MCP transforma linguagem natural em interface operacional real para EDR — não demo, produção
• Configuração de scopes é o verdadeiro modelo de permissão; módulos são apenas agrupamento de ferramentas
• Mark-of-the-Web telemetry é ouro para atribuição de origem de arquivo
• Verificação independente (hash do release oficial) separa suposição de evidência
• RTR read-only via linguagem natural acelera triagem sem risco de side effects
• False positive documentado com cadeia de evidências completa protege contra recorrência
• IA orquestra, evidência decide — manter essa fronteira clara é responsabilidade do analista

Conclusão

Falcon MCP: First Blood demonstra que Model Context Protocol não é apenas mais uma integração — é uma mudança de paradigma em como analistas interagem com plataformas de segurança. A investigação de 40 minutos, conduzida inteiramente por linguagem natural através do Claude Desktop conectado ao CrowdStrike Falcon, cobriu todo o ciclo: detecção → contexto → threat intel → atribuição de origem (MOTW) → verificação de abrangência (NGSIEM) → coleta de evidência forense (RTR) → verificação independente → disposição documentada. Cada passo auditável, cada evidência rastreável, nenhuma ação destrutiva sem confirmação. O analista permaneceu no controle; a IA removeu o atrito de navegar consoles, montar queries e alternar ferramentas. Isso não substitui o analista — multiplica sua capacidade. O próximo alerta de alta severidade não vai esperar você abrir cinco abas. A pergunta “o que aconteceu nesse endpoint?” já está pronta para ser feita.