DAT.3 - Coleta de Logs de Aplicações Web

Nota do grupo DAT (Coleta de Dados e Telemetria) da seção 15 do Framework CTH.
Deriva do Capítulo 6 do PDF de referência e do controle DAT.3 do modelo CIS Controls v8.
Cobre a telemetria de servidores web, WAF, API gateway e autenticação de aplicação, camada onde grande parte dos ataques reais acontece.

1. Contexto e Posicionamento no Framework CTH

Aplicações web e APIs permanecem como o principal vetor de ataque contra a maioria das organizações, alvo recorrente de SQL Injection, XSS, execução remota de código, quebra de controle de acesso e ataques de força bruta. Apesar disso, seus logs estão entre as fontes mais subaproveitadas dos centros de operações: muitos ambientes colecionam access logs genéricos sem parse adequado, sem corpo de requisição e sem retenção suficiente para investigação. O resultado é que ataques que contornam controles de rede e endpoint passam despercebidos na camada onde de fato ocorrem.

Dentro do Framework CTH, DAT.3 complementa DAT.1 e DAT.2 com a visibilidade da aplicação, que é o único ponto capaz de responder perguntas como qual usuário lógico acessou qual registro e qual regra de negócio foi violada. Os logs aqui definidos alimentam DAT.4 para normalização e correlação, sustentam hipóteses de hunting específicas de aplicação e fornecem evidência forense para incidentes envolvendo vazamento de dados. A análise desta camada também devolve inteligência ao grupo CTI, na forma de padrões de reconhecimento e exploração observados.

A construção deste controle segue três camadas de coleta: logs de acesso e erro do servidor web, logs da própria aplicação incluindo autenticação e operações sensíveis, e logs de controles de frente como WAF e API gateway. A evolução vai do formato estendido no servidor web até a normalização unificada de todas as aplicações, de modo que consultas e correlações funcionem de forma idêntica em qualquer origem.

2. O Que Coletar em Access Logs

O access log é a base da telemetria de aplicação e precisa ir além do formato combinado padrão. Campos essenciais incluem IP de origem real, user agent, URI completa com query string, método HTTP, código de status, bytes transferidos e tempo de resposta. O tempo de resposta é frequentemente omitido e tem alto valor de hunting, pois requisições anormalmente lentas podem indicar SQL Injection por tempo ou força bruta de parâmetro.

O IP de origem merece atenção especial em arquiteturas com proxies reversos e CDNs, nas quais o IP do socket é o do intermediário. A coleta deve capturar o cabeçalho X-Forwarded-For ou X-Real-IP, validando a cadeia de proxies confiáveis para evitar spoofing, e registrar ambos os valores quando houver dúvida. Sem o IP real, todo o hunting baseado em distribuição de origem fica comprometido.

Um exemplo de formato de log para servidor web em frente de proxy reverso:

log_format hunting '$remote_addr-$http_x_forwarded_for [$time_iso8601] '
                   '"$request" $status $body_bytes_sent '
                   '"$http_user_agent" $request_time '
                   'rt=$upstream_response_time host=$host uri=$uri';
access_log /var/log/nginx/access.log hunting;

A tabela abaixo resume os campos críticos e o que cada um habilita:

3. Logs de WAF: Regras Acionadas, Payload e Classificação CRS

O WAF é a fonte que explica o porquê de uma requisição ser suspeita, registrando a regra acionada, a severidade, a transação completa e os trechos que casaram com a detecção. Em implementações baseadas em ModSecurity com OWASP CRS, cada bloqueio traz o ID da regra, a categoria de ataque estimada e o payload suspeito, dados que permitem diferenciar varredura automatizada de exploração dirigida. Esses logs devem ser coletados tanto em modo bloqueio quanto em modo detecção, porque o modo detecção revela o que está tentando passar caso o bloqueio falhe.

A análise dos logs de WAF em hunting cobre tentativas repetidas contra o mesmo endpoint, distribuição de regras acionadas por origem e requisições que passaram pelo WAF mas geraram erros no backend. Um padrão de alto valor é cruzar requisições bloqueadas do WAF com access logs: se um IP recebeu bloqueios de SQLi e depois produziu respostas 200 volumosas na mesma rota, há hipótese forte de exploração parcialmente bem sucedida. Essa correlação exige que ambas as fontes compartilhem um identificador de transação, como o ID de requisição propagado.

Um trecho típico de configuração de auditoria em ModSecurity ilustra o formato do registro:

<IfModule mod_security2.c>
  SecRuleEngine On
  SecAuditEngine RelevantOnly
  SecAuditLogParts ABIJDEFHZ
  SecAuditLogType Serial
  SecAuditLog /var/log/modsec_audit.log
</IfModule>

Payloads completos de WAF são dados sensíveis e frequentemente contêm senhas em tentativas de login, o que exige filtragem de campos, mascaramento de segredos e controle de acesso ao log. A retenção recomendada para logs de WAF é de no mínimo 180 dias, equilíbrio entre valor investigativo e volume.

4. Logs de API Gateway: Chave, Rota e Quota

APIs expõem superfície de ataque ampla e sua telemetria própria vem do gateway, que registra chave de API ou identidade do cliente, rota chamada, método, status, latência e consumo de quota. Esses logs permitem hunting de abuso de API, como clientes que exaurem quota repetidamente, uso de chaves revogadas ou antigas, chamadas a rotas descontinuadas e acesso a endpoints administrativos por identidades que nunca os usaram. A chave de API funciona como uma entidade de "usuário de máquina" e deve ser tratada com a mesma dedicação de uma conta humana nas análises.

Padrões relevantes incluem picos de chamadas a endpoints de listagem de dados, mudança súbita no perfil de rotas consumidas por uma chave e tentativas de chamada sem autenticação contra rotas protegidas. Um log estruturado de gateway exemplifica os campos de interesse:

{"event_time":"2025-04-17T12:41:02Z","api_key_id":"pk_8c31","route":"/v2/customers",
 "method":"GET","status":200,"latency_ms":812,"quota_remaining":41,
 "source_ip":"198.51.100.7","request_id":"b77d0e"}

O gateway também deve registrar falhas de assinatura e erros de autorização, que precedem frequentemente a exploração de quebra de controle de acesso. Quando a aplicação gera IDs de correlação, o log do gateway deve carregá-los para amarrar a transação completa entre gateway, aplicação e backend.

5. Autenticação de Aplicação: Logins, Resets e MFA

A autenticação na camada de aplicação produz eventos distintos dos logs de rede e deve ser coletada com estrutura própria: login com sucesso e falha contendo usuário, IP, user agent e método de autenticação, reset de senha solicitado e concluído, alteração de e-mail ou telefone, e todos os desafios de MFA com resultado. Esses eventos sustentam detecção de credential stuffing, takeover de conta e abuso de fluxo de recuperação, que raramente aparecem em outra telemetria com essa nitidez.

Um exemplo de log estruturado de evento de autenticação:

{"event_time":"2025-04-17T13:02:11Z","event_type":"login_failure",
 "user":"maria.souza","source_ip":"203.0.113.45","user_agent":"python-requests/2.31",
 "auth_method":"password","mfa_attempted":false,"reason":"invalid_password",
 "request_id":"a1f3c9"}

Eventos de MFA merecem cuidado especial, pois repetição de desafios aceitos em IPs distintos em janela curta indica token reutilizado ou phishing de segunda fator. Resets de senha disparados em massa contra muitos usuários sugerem preparação para takeover. Esses logs devem ter a maior retenção da aplicação, com no mínimo 365 dias, porque fraudes e takeovers são frequentemente investigados meses depois do fato.

6. Casos de Hunting em Aplicações Web

A telemetria de aplicação habilita hipóteses de hunting específicas que nenhum outro dado suporta. A tabela abaixo resume os casos clássicos e os sinais de busca:

Para credential stuffing, a distribuição de IPs é o sinal central: o atacante usa poucas tentativas por IP para driblar bloqueios, de modo que a agregação por conta visada, e não por IP de origem, revela a campanha. Uma consulta exemplificativa em pseudo-SPL:

sourcetype=app:auth event_type=login_failure
| stats dc(source_ip) as ips_distintos, count by user
| where ips_distintos > 20
| sort - ips_distintos

Para varredura de conteúdo, a busca agrega URIs com status 404 por origem e verifica a sequência semântica dos caminhos tentados:

sourcetype=web:access status=404
| stats count, values(url_path) by source_ip, http_user_agent
| where count > 100

Para exploração de CVE, o hunter cruza padrões de URI característicos da vulnerabilidade com erros de aplicação subsequentes e com logs de WAF em modo detecção. Cada caso deve ter consulta salva, revisada quando novas aplicações entram no escopo.

7. Normalização entre Aplicações Distintas

Ambientes reais reúnem aplicações em tecnologias diversas, cada uma com formato de log próprio, e sem normalização o hunting precisa de uma consulta diferente por aplicação. O objetivo do DAT.3 é mapear todos os logs web para um modelo de campo unificado, alinhado ao padrão adotado em DAT.4, de forma que source.ip, http.request.method, url.path, http.response.status_code e user.name signifiquem a mesma coisa em qualquer fonte. Essa padronização é o que permite uma única consulta cobrir todo o parque de aplicações.

A normalização inclui padronizar timestamps para UTC, extrair campos estruturados de URIs e query strings, harmonizar nomenclatura de usuário e propagar IDs de correlação entre proxy, WAF, gateway e aplicação. Transformações devem ser documentadas para garantir rastreabilidade forense. Aplicações novas devem ser aprovadas para produção apenas com logging estruturado conforme o padrão, critério que deve constar da definição de pronto dos times de desenvolvimento.

A tabela abaixo exemplifica o mapeamento de campos equivalentes entre fontes típicas de aplicações web:

Esse mapa de equivalência deve ser mantido como documento vivo do DAT.3, pois é a referência usada pelos pipelines de parse e pelos hunters que escrevem consultas multi-fonte.

8. Implementação Prática e Salvaguardas por Nível

O controle DAT.3 se materializa nas salvaguardas abaixo, com complexidade crescente:

A implantação deve começar pelo inventário de aplicações e seus pontos de log, incluindo virtual hosts e server blocks que frequentemente ficam sem logging. Cada aplicação deve receber testes sintéticos de ataque controlado para validar que os eventos chegam ao SIEM com os campos esperados. A retenção por tipo de log deve seguir a orientação do controle DAT.5, com destaque para autenticação de aplicação em 365 dias:

9. Erros Comuns e Pontos de Atenção

O erro mais grave é registrar log sem o dado necessário para a hipótese, como não capturar corpo de requisição onde a exploração só é visível no payload, ou não capturar o IP real atrás de proxy, o que neutraliza toda análise de origem. Retenção curta é o segundo erro recorrente: access logs mantidos por 7 dias impedem a investigação de fraudes e takeovers descobertos semanas depois, contrariando o raciocínio de dwell time tratado em DAT.5. Aplicações que registram apenas erros, sem eventos de sucesso, também quebram hunting, porque a movimentação bem sucedida deixa pouco rastro de falha.

Outros pontos de atenção incluem logs sem parse, user agent tratado como confiança absoluta, e ausência de IDs de correlação entre as camadas de frente e backend. Senhas e tokens em logs são um risco que exige mascaramento na fonte. Por fim, virtual hosts esquecidos e aplicações legadas sem coleta representam pontos cegos silenciosos que o inventário periódico deve eliminar.

10. Integração com Outros Controles do Framework CTH

DAT.3 alimenta DAT.4 com fontes que exigem parsing rico e normalização, e depende de DAT.5 para retenção compatível com investigações de fraude e vazamento. As hipóteses de hunting do grupo TH sobre ataque a aplicações só são executáveis com esta telemetria, e o grupo DET consome os eventos de autenticação e os logs de WAF para regras de correlação. Com CTI, os padrões de exploração observados aqui retroalimentam o entendimento das ameaças direcionadas à organização, e com IR os logs de aplicação fornecem a linha do tempo de acesso a dados que sustenta notificações e relatórios de incidente.