OWASP: A09 2025 - Security Logging and Alerting Failures
¿Qué es Security Logging and Alerting Failures?
Security Logging and Alerting Failures agrupa deficiencias que impiden detectar, investigar, escalar o responder adecuadamente a actividad maliciosa.
El interés principal está en determinar si acciones claramente sospechosas generan evidencias útiles para los equipos defensivos y si esas evidencias terminan produciendo alertas accionables.
Una aplicación puede registrar numerosos eventos y continuar siendo vulnerable si los logs carecen de contexto, permanecen únicamente en el sistema local, pueden manipularse, no se monitorizan o nunca generan una alerta.
En este artículo analizamos las siguientes áreas:
Eventos de seguridad no registrados
Logs insuficientes o sin contexto
Monitorización y alertas
Detección de actividad ofensiva
Almacenamiento y centralización
Integridad y manipulación de logs
Log Injection
Exposición de información en logs
Respuesta y escalado
Eventos de seguridad no registrados
OWASP destaca especialmente los eventos auditables que deberían dejar una evidencia suficiente para poder identificar actividad sospechosa.
Entre ellos se encuentran:
- Inicios de sesión.
- Intentos de autenticación fallidos.
- Fallos de control de acceso.
- Errores de validación del lado servidor.
- Operaciones administrativas.
- Cambios de credenciales.
- Cambios de MFA.
- Creación y modificación de usuarios.
- Operaciones de alto valor.
- Modificaciones de configuración.
- Acceso a información especialmente sensible.
Desde Red Team no es necesario validar cada evento funcional de la aplicación.
Prioriza acciones que serían relevantes durante una intrusión real.
Por ejemplo:
- Múltiples fallos de autenticación
- Acceso repetido a recursos prohibidos
- Enumeración de identificadores
- Ejecución de operaciones administrativas
- Modificación de credenciales
- Acceso desde ubicaciones o sesiones inusuales
Validación
Si dispones de visibilidad sobre los sistemas defensivos durante el ejercicio, realiza una acción controlada y comprueba si existe un evento correspondiente.
Por ejemplo:
POST /login HTTP/1.1
username=test-user
password=incorrect
Después verifica si el registro permite identificar como mínimo:
- Qué ocurrió
- Cuándo ocurrió
- Qué cuenta estaba implicada
- Desde dónde se originó
- Sobre qué componente ocurrió
- Cuál fue el resultado
La ausencia de un evento relevante o la imposibilidad de atribuirlo correctamente puede dificultar considerablemente la investigación posterior.
Red Team OPSEC
No generes grandes volúmenes de eventos únicamente para comprobar si existe logging.
Un conjunto pequeño de acciones diferenciadas suele ser suficiente para validar qué información registra el sistema.
Logs insuficientes o sin contexto
Registrar un evento no garantiza que sea útil.
Un log como el siguiente aporta poca información si no permite determinar qué ocurrió realmente:
Login failed
Un evento de seguridad debería proporcionar contexto suficiente para reconstruir la actividad.
El objetivo es que un analista pueda correlacionar la actividad sin depender de información que ya no estará disponible cuando se investigue el incidente.
Validación
Realiza dos acciones similares desde contextos diferentes y comprueba si los eventos pueden distinguirse.
Si ambos aparecen únicamente como Authentication error sin ningún dato adicional, la información puede ser insuficiente para atribuir correctamente la actividad.
Warnings y errores poco claros
OWASP también contempla warnings y errores que:
- No se registran.
- Producen mensajes ambiguos.
- No proporcionan suficiente información.
- Generan demasiado ruido para resultar útiles.
Desde Red Team presta especial atención a errores que podrían indicar actividad ofensiva:
- Payloads rechazados
- Fallos de parsing
- Accesos a endpoints inexistentes
- Errores de autorización
- Uso incorrecto de tokens
- Excepciones repetidas
Una gran cantidad de errores genéricos puede ocultar precisamente las señales que deberían destacar.
Monitorización y alertas
Los logs tienen poco valor operativo si nadie los analiza.
OWASP A09 incluye explícitamente escenarios donde los logs de aplicaciones y APIs no se monitorizan para detectar actividad sospechosa.
Desde Red Team, el objetivo es determinar si determinadas acciones producen únicamente un registro pasivo o si generan también una señal que pueda llegar al equipo defensivo.
La existencia de una alerta depende del contexto y riesgo de cada aplicación.
Umbrales de alerta
Un sistema puede registrar correctamente cada intento y continuar siendo ineficaz si los umbrales están mal definidos.
Por ejemplo: Alerta después de 3.000 intentos de login fallidos puede ser técnicamente una alerta pero resultar inútil frente a ataques reales de menor volumen.
Durante una evaluación conjunta con Blue Team puede comprobarse si una actividad controlada supera un umbral razonable y qué información recibe el analista.
Detección de actividad ofensiva
OWASP utiliza específicamente como referencia que pruebas de penetración y análisis dinámicos deberían producir señales detectables.
Esto no significa que cada petición generada por un pentester deba activar una alerta. El objetivo es determinar si comportamientos suficientemente claros permanecen completamente invisibles.
Durante un Red Team pueden resultar especialmente interesantes:
Directory fuzzing
Intentos repetidos de acceso a /admin
SQL Injection
Path Traversal
Credential attacks
Modificación de tokens
Enumeración de recursos
Command Injection
Carga de archivos anómalos
Validación controlada
Utiliza una secuencia reducida y reconocible.
Por ejemplo:
GET /admin
GET /administrator
GET /phpmyadmin
GET /.git/config
GET /.env
Si la infraestructura defensiva dispone de controles destinados a detectar reconocimiento web, esta actividad debería proporcionar al menos una señal observable.
Otro ejemplo puede consistir en enviar unas pocas entradas claramente asociadas a una técnica:
../../../../etc/passwd
' OR 1=1 --
<script>alert(1)</script>
El objetivo no es explotar las vulnerabilidades, sino determinar si patrones ofensivos evidentes generan telemetría o alertas.
Red Team OPSEC
Cuando el objetivo sea evaluar detección, coordina previamente qué nivel de actividad está autorizado.
No incrementes artificialmente el volumen de peticiones para forzar una alerta si unas pocas acciones son suficientes para caracterizar la cobertura.
Almacenamiento y centralización
OWASP considera una debilidad que los logs permanezcan únicamente en el sistema local.
El almacenamiento local puede dificultar:
- Correlación entre servicios.
- Investigación después de una intrusión.
- Detección centralizada.
- Conservación de evidencias.
- Análisis cuando el host ha sido comprometido.
Desde Red Team esto resulta especialmente relevante después de obtener acceso a un servidor.
Si todos los registros se encuentran únicamente en:
/var/log/application.log
y una cuenta comprometida puede modificarlos o eliminarlos, el atacante puede reducir considerablemente la visibilidad defensiva.
Validación
Determina conceptualmente si los eventos relevantes son enviados fuera del host hacia:
SIEM
Servidor de logs
Plataforma cloud
Collector
Servicio de monitorización
No es necesario borrar ningún registro.
Si puedes demostrar que la única copia se encuentra localmente y que el contexto comprometido dispone de permisos para modificarla, el riesgo ya puede documentarse.
Retención
Los logs deben conservarse durante un tiempo suficiente para permitir investigaciones diferidas.
Un incidente puede detectarse días o semanas después de producirse.
Desde Red Team normalmente no será posible validar toda la política de retención mediante observación directa, pero pueden revisarse configuraciones, documentación o comportamiento del sistema cuando estén disponibles.
Integridad y manipulación de logs
Los registros utilizados como evidencia deben disponer de controles suficientes para impedir modificaciones no autorizadas.
OWASP recomienda especialmente proteger los audit trails de operaciones de alto valor.
El riesgo aparece cuando un atacante con acceso limitado puede:
Eliminar registros
Modificar eventos
Truncar archivos
Sobrescribir timestamps
Alterar resultados de auditoría
Validación
Después de obtener acceso autorizado a un sistema, revisa los permisos sobre las fuentes de log.
Por ejemplo:
ls -l /var/log/
o sobre archivos concretos:
stat /var/log/application.log
El objetivo es determinar si la misma identidad comprometida que ejecuta la aplicación puede también eliminar o modificar las evidencias que describen su actividad.
No es necesario alterar registros reales.
Red Team OPSEC
No elimines ni modifiques logs reales para demostrar falta de integridad.
Los permisos, arquitectura de almacenamiento o un archivo de prueba suelen aportar evidencia suficiente.
Log Injection
Cuando una aplicación incluye datos controlados por el usuario directamente dentro de los registros, un atacante puede intentar modificar la estructura aparente del log.
Por ejemplo:
Login failed for user: sam
Si el nombre de usuario acepta caracteres de nueva línea, una entrada podría intentar producir:
sam
Login successful for user: admin
El resultado podría almacenarse como:
Login failed for user: sam
Login successful for user: admin
Esto puede confundir análisis manuales o herramientas que dependan de un formato concreto.
Validación
Utiliza una cadena claramente identificable y no engañosa:
log-test-123
y después caracteres estructurales cuando sea necesario:
log-test-123\nsecond-line
Comprueba si el sistema:
- Codifica correctamente el valor.
- Conserva el formato del evento.
- Permite crear líneas adicionales.
- Rompe el parser utilizado por la plataforma de logs.
No introduzcas eventos falsos que puedan confundirse con actividad real durante una operación.
Inyección en formatos estructurados
Los logs pueden utilizar:
JSON
CSV
CEF
Syslog
En estos casos el problema puede aparecer si la aplicación construye manualmente la estructura mediante concatenación.
Por ejemplo:
{"user":"<INPUT>","event":"login"}
El sistema debería serializar correctamente los datos en lugar de permitir que una entrada modifique campos adicionales.
Red Team OPSEC
Utiliza marcadores inequívocos como
REDTEAM-LOG-TESTpara evitar que una prueba se interprete como un evento legítimo.
Exposición de información en logs
Los logs pueden convertirse también en una fuente de información sensible.
No deberían registrar innecesariamente:
Contraseñas
Tokens de sesión
Authorization headers
API keys
Refresh tokens
Códigos MFA
Secretos
Datos completos de tarjetas
Información personal innecesaria
Validación
Realiza una operación con una cuenta de prueba y revisa, cuando dispongas de acceso autorizado, qué información termina almacenada.
Por ejemplo:
Authorization: Bearer eyJ...
El log debería evitar conservar la credencial completa.
Un registro puede indicar que se utilizó un token sin almacenar el propio secreto.
URLs y parámetros
Presta atención a secretos transmitidos mediante URLs:
/reset-password?token=...
Los parámetros de la URL pueden terminar automáticamente en:
- Access logs.
- Reverse proxies.
- WAF.
- Sistemas de observabilidad.
- Analítica.
- Historiales.
El problema puede existir incluso aunque la aplicación principal no registre explícitamente el token.
Errores y excepciones
Stack traces y errores también pueden terminar en plataformas centralizadas.
Comprueba si contienen:
Variables de entorno
Connection strings
Credenciales
Tokens
Consultas sensibles
Contenido completo de peticiones
La exposición de secretos en logs puede ampliar significativamente el impacto de un acceso posterior a la infraestructura de monitorización.
Respuesta y escalado
OWASP A09 no se limita a registrar y detectar.
También contempla la ausencia o ineficacia de procesos de escalado y respuesta.
Un sistema puede generar una alerta correctamente y continuar siendo ineficaz si:
Nadie la recibe
No existe responsable
La alerta no contiene contexto suficiente
El volumen de falsos positivos impide revisarla
No existe un procedimiento de escalado
La respuesta llega demasiado tarde
Desde un Red Team esto puede evaluarse mediante ejercicios coordinados con el equipo defensivo.
Tiempo de detección
Cuando el ejercicio lo contemple, registra el momento aproximado en que se ejecuta una actividad claramente sospechosa y compáralo con:
Momento de generación del evento
Momento de creación de la alerta
Momento de investigación
Momento de escalado
No existe un tiempo universalmente correcto.
La expectativa depende de la criticidad del sistema y del tipo de evento.
Alertas sin contexto
Una alerta como Suspicious activity detected puede resultar prácticamente inútil.
Una alerta accionable debería permitir al analista comenzar la investigación identificando, cuando corresponda:
Sistema afectado
Usuario
Origen
Acción
Timestamp
Recurso
Severidad
Eventos relacionados
Qué puede validar un Red Team
A diferencia de otras categorías del OWASP Top 10, muchas deficiencias de A09 no pueden observarse completamente desde el exterior.
Un Red Team puede ayudar a medirlas desde dos perspectivas.
Black Box
Sin acceso a sistemas defensivos, normalmente puedes identificar indirectamente:
Ausencia aparente de bloqueo
Falta de respuesta ante actividad prolongada
Exposición de logs
Log injection visible
Errores que filtran información
Sin embargo, no debes afirmar que una actividad no fue registrada únicamente porque no observaste una respuesta defensiva.
El evento puede existir sin producir una acción visible para el atacante.
Purple Team o acceso a telemetría
Cuando existe colaboración con Blue Team pueden comprobarse directamente:
Qué eventos se registraron
Qué campos contenían
Qué alertas se generaron
Qué fuentes llegaron al SIEM
Qué actividad no fue detectada
Cómo se correlacionaron los eventos
Cuánto tardó la respuesta
Este enfoque permite validar A09 con mucha más precisión.