Quem Puxou as Chaves: Encontrando Coleta de Chaves em Logs de Aplicação
O desafio
Um endpoint de debug foi deixado exposto e serve material de chave privada. Nos seus logs da aplicação, a maior parte do tráfego são páginas normais, mas um IP fica acessando /debug/keys e /.well-known/private-keys recebendo 200 toda vez - está baixando os segredos silenciosamente. Filtre os caminhos suspeitos, encontre a única origem que puxa o material de chave, e envie o IP dela.
O que você vai aprender
- Filtrar um log de acesso por caminho para isolar endpoints sensíveis
- Reconhecer que um 200 em um caminho de segredos significa que os dados foram servidos
- Usar a coluna de user-agent para diferenciar um script de um navegador
- Identificar coleta sistemática de chaves a partir de uma única origem
- Atribuir a exfiltração de segredos a um único IP
Habilidades testadas
Pré-requisitos
- Compreensão de caminhos HTTP e códigos de status
- Consciência de que chaves privadas são material secreto
- Familiaridade com strings de user-agent
Como funciona
Segredos ficam expostos quando um endpoint de debug ou diagnóstico, pensado para uso interno, fica acessível em produção. Caminhos como /debug/keys e /.well-known/private-keys podem servir material bruto de chave privada, e qualquer um que os encontre pode simplesmente baixá-lo. Nos logs, o roubo não parece violento - é apenas uma série de requisições GET bem-sucedidas - então a habilidade é saber quais caminhos nunca deveriam ser servidos e perceber quem os está acessando.
Filtrando por path:/debug e path:/.well-known, uma única origem, 198.51.100.31, é responsável por tudo. Ela solicita /debug/keys nos formatos pem e jwk, /.well-known/private-keys e /debug/config, repetidamente, cada uma retornando 200. O código de status é a prova: um 200 significa que o servidor realmente retornou o material de chave, não um 403 ou 404. Dois outros sinais confirmam a intenção: nenhum usuário legítimo visita esses caminhos, e o ua da requisição é python-requests, um cliente scriptado, enquanto todo IP benigno usa um agente de navegador real para carregar páginas da aplicação.
Essa é uma falha recorrente no mundo real: uma rota de debug esquecida vaza chaves de assinatura ou chaves privadas TLS, e um atacante roda um script em loop para coletá-las. A evidência no log é a combinação de um caminho que nunca deveria ser público, um 200 repetido, uma única origem, e um user agent automatizado.
Erros comuns
- Tratar um 200 como inofensivo. Em um caminho de segredos, um
200é o pior cenário - significa que a chave foi servida. O sucesso aqui é o alarme. - Contar apenas as requisições. Vários IPs estão ativos; apenas um está ativo nos caminhos de debug e private-keys.
- Ignorar o user agent. O agente
python-requestsem contraste com os navegadores é um forte indício de que essa origem é um script, não uma pessoa. - Enviar o caminho em vez do IP. A pergunta é sobre quem está coletando as chaves - o endereço da origem única.
Como se proteger
Segredos expostos são, antes de tudo, um problema de configuração e código, mas a detecção no log de acesso captura a coleta ativa. Trate qualquer acesso a um caminho de segredos como um incidente.
- Nunca exponha endpoints de debug, diagnóstico ou que sirvam chaves em produção - remova-os ou proteja-os com autenticação forte e restrição à rede interna.
- Alerte para qualquer requisição a caminhos que sirvam segredos (
/debug,/.well-known/private-keys), especialmente as que retornam200. - Rotacione qualquer material de chave que ficou acessível e considere comprometido tudo que foi servido com
200. - Bloqueie ou limite a taxa de clientes automatizados que martelam caminhos sensíveis e revise user agents que não sejam de navegador.