28. Evasión, detección, logs y coordinación con equipos defensivos
Un pentest moderno no solo busca comprobar si una vulnerabilidad existe. También permite medir si la organización puede observar, detectar, investigar y responder. En este tema veremos cómo coordinar pruebas con equipos defensivos, evaluar logs y fortalecer detecciones sin convertir la evasión en un fin en sí mismo.
Objetivo
Comprender cómo validar visibilidad, alertas, trazabilidad y respuesta durante pruebas autorizadas.
Enfoque
Usar coordinación, evidencia y criterios de seguridad para mejorar detección, no para ocultar actividad real.
Resultado
Transformar actividad de pentesting en mejoras concretas para SOC, SIEM, EDR, logging y respuesta a incidentes.
28.1 Introducción
Durante muchos años, los pentests se centraron en encontrar vulnerabilidades y demostrar impacto. Eso sigue siendo importante, pero no alcanza. Una organización también necesita saber si sus controles detectan actividad sospechosa, si los logs permiten reconstruir eventos y si los equipos defensivos pueden responder a tiempo.
Este tema aborda evasión y detección desde una perspectiva ética. No se trata de enseñar a ocultar ataques, sino de entender cómo las defensas pueden fallar, cómo validar controles de forma autorizada y cómo mejorar la capacidad de monitoreo frente a técnicas reales.
28.2 Qué significa evasión en un pentest autorizado
En un contexto profesional, evasión significa probar si un control detecta o bloquea una actividad acordada. La prueba debe estar documentada, acotada y coordinada. No se busca permanecer oculto indefinidamente ni debilitar defensas, sino comprobar supuestos: qué se registra, qué alerta, qué se bloquea y qué pasa inadvertido.
Si una actividad requiere simular comportamiento sensible, debe aprobarse antes. El equipo debe conocer límites, ventanas, indicadores de prueba y criterios de detención. El valor está en aprender dónde mejorar, no en sorprender al equipo defensor sin marco de control.
28.3 Purple teaming
Purple teaming combina perspectivas ofensivas y defensivas. El equipo ofensivo ejecuta acciones autorizadas y el equipo defensivo observa, detecta, ajusta reglas y mejora procedimientos. Puede ser colaborativo en tiempo real o ejecutarse con diferentes niveles de conocimiento previo.
A diferencia de un pentest cerrado, el objetivo principal no es solo obtener hallazgos, sino mejorar controles de detección y respuesta. Una sesión purple team puede producir nuevas reglas, mejores logs, playbooks más claros y menor tiempo de investigación.
28.4 Alcance y reglas de coordinación
Antes de probar detección, se deben definir sistemas, cuentas, técnicas permitidas, horarios, contactos, ventanas de observación, límites de impacto, datos de prueba, direcciones, etiquetas de campaña y criterios de suspensión. También debe quedar claro qué equipos estarán informados y cuáles serán evaluados.
La coordinación reduce falsos incidentes, evita interrupciones y permite medir correctamente. Si el SOC no sabe que debe observar una ventana específica, quizá la falta de alerta sea un problema de comunicación y no de tecnología.
28.5 Fuentes de logs
Los logs son la materia prima de la detección. Pueden venir de endpoints, servidores, aplicaciones, firewalls, proxies, DNS, correo, identidad, cloud, Kubernetes, bases de datos, VPN, EDR, WAF, sistemas de ticketing y herramientas de CI/CD. Cada fuente aporta una parte de la historia.
| Fuente | Qué aporta | Riesgo si falta |
|---|---|---|
| Identidad | Autenticaciones, MFA, cambios de roles y sesiones | No detectar abuso de cuentas |
| Endpoint | Procesos, archivos, conexiones y comportamiento local | No reconstruir actividad en estaciones o servidores |
| Red | Flujos, DNS, proxy, firewall y conexiones externas | No observar movimiento lateral o exfiltración |
| Aplicación | Acciones de usuario, errores, cambios y eventos de negocio | No entender impacto funcional |
| Cloud | Uso de APIs, IAM, almacenamiento, red y recursos | No detectar cambios críticos de configuración |
28.6 Calidad de logs
No basta con tener logs. Deben ser completos, consistentes, protegidos, sincronizados en tiempo, enriquecidos con contexto y retenidos por el periodo necesario. Un log sin usuario, origen, recurso o resultado puede ser insuficiente para investigar.
Durante el pentest se debe observar si los eventos críticos quedan registrados con suficiente detalle: quién actuó, desde dónde, sobre qué recurso, qué cambió, si tuvo éxito o falló, y qué identificador permite correlacionar la actividad con otras fuentes.
28.7 SIEM y correlación
Un SIEM centraliza eventos y permite correlacionar señales entre fuentes. Su valor depende de la calidad de datos, reglas, contexto, normalización, enriquecimiento y operación diaria. Un SIEM lleno de eventos sin reglas útiles puede dar una falsa sensación de cobertura.
La revisión debe validar si las acciones del pentest aparecen en el SIEM, si se correlacionan con identidad, activos críticos y severidad, y si generan alertas accionables. También se debe revisar si existe exceso de ruido que haga invisibles los eventos importantes.
28.8 EDR, XDR y monitoreo de endpoints
Las soluciones EDR y XDR observan comportamiento en endpoints y servidores: procesos, memoria, archivos, conexiones, credenciales, persistencia, scripts y acciones administrativas. Su efectividad depende de cobertura, configuración, políticas, exclusiones y respuesta operativa.
En una prueba autorizada se debe confirmar qué activos tienen agente, si el agente está activo, si las acciones simuladas generan telemetría, si hay alertas, si el equipo puede investigarlas y si las exclusiones crean puntos ciegos relevantes.
28.9 Detección por comportamiento
Las detecciones basadas solo en firmas pueden fallar frente a variaciones simples. Las detecciones por comportamiento observan patrones: accesos inusuales, secuencias de acciones, cambios masivos, uso anómalo de herramientas administrativas, conexiones raras o desviaciones de la línea base.
El pentest puede ayudar a validar si la organización detecta comportamientos de riesgo aunque los detalles técnicos cambien. Esto favorece reglas más robustas y menos dependientes de indicadores frágiles.
28.10 Cobertura de MITRE ATT&CK
MITRE ATT&CK permite mapear técnicas adversarias contra controles de detección. No debe usarse como una lista para ejecutar acciones sin criterio, sino como un lenguaje común entre equipos ofensivos, defensivos y de gestión.
Una matriz de cobertura ayuda a identificar qué técnicas se detectan, cuáles solo se registran, cuáles no tienen visibilidad y cuáles no aplican al entorno. El objetivo es priorizar mejoras según riesgo real, no llenar una tabla por formalidad.
28.11 Alertas accionables
Una alerta útil debe indicar qué ocurrió, dónde, con qué identidad, qué severidad tiene, qué evidencia la respalda y qué pasos debe seguir el analista. Alertas vagas o excesivas aumentan fatiga y reducen capacidad de respuesta.
Durante una prueba, es importante revisar si la alerta generada permite tomar decisiones. Si el equipo necesita buscar manualmente demasiada información básica, el problema puede estar en enriquecimiento, playbooks o diseño de la regla.
28.12 Falsos positivos y falsos negativos
Un falso positivo alerta por actividad legítima; un falso negativo no alerta ante actividad riesgosa. Ambos dañan la seguridad: el primero genera ruido, el segundo deja huecos. La mejora de detección consiste en ajustar reglas, contexto y umbrales sin perder señales críticas.
El pentest puede identificar falsos negativos al ejecutar acciones acordadas que deberían generar alertas. El purple teaming puede ajustar la regla y repetir la prueba para confirmar que la detección mejora.
28.13 Trazabilidad de extremo a extremo
Una investigación efectiva requiere reconstruir la cadena: evento inicial, identidad, activo, acción, recurso, movimiento, impacto y respuesta. Si cada sistema usa formatos, tiempos o identificadores incompatibles, la investigación se vuelve lenta.
La trazabilidad mejora con sincronización horaria, identificadores de solicitud, correlación entre aplicación e infraestructura, etiquetado de activos, inventario actualizado y retención suficiente.
28.14 Detección en cloud
En cloud, muchas acciones críticas ocurren mediante APIs de administración: cambios de IAM, creación de claves, modificación de reglas de red, acceso a almacenamiento, despliegue de funciones o desactivación de logs. Estas acciones deben registrarse y correlacionarse con identidad, recurso y región.
La revisión debe comprobar si los eventos cloud críticos llegan al SIEM, si se alertan cambios de alto impacto, si los logs están protegidos contra modificación y si existe visibilidad entre cuentas, proyectos o suscripciones.
28.15 Detección en aplicaciones
Las aplicaciones deben registrar eventos de negocio relevantes: cambios de permisos, exportaciones, operaciones sensibles, errores de autorización, cambios de configuración, accesos administrativos y patrones de abuso. Sin estos eventos, el SOC puede ver tráfico, pero no entender impacto.
Durante el pentest se puede validar si acciones como acceso no autorizado, abuso de funciones o cambios críticos generan eventos útiles. Esto conecta seguridad técnica con riesgo de negocio.
28.16 Coordinación durante la ejecución
La ejecución debe tener canales claros. El equipo ofensivo registra hora, sistema, acción y objetivo de cada prueba. El equipo defensivo observa alertas, crea tickets, documenta tiempos y comparte brechas. Si algo supera los límites, se detiene y se comunica.
Esta coordinación evita confusiones y permite medir con precisión. Cuando una acción no se detecta, se puede revisar si faltó log, regla, contexto, cobertura del agente, permiso de lectura o procedimiento de escalamiento.
28.17 Evidencia para detección
La evidencia no debe limitarse al hallazgo ofensivo. También debe incluir si hubo log, alerta, ticket, bloqueo, investigación, tiempo de respuesta y conclusión defensiva. Esa información permite priorizar mejoras de visibilidad y operación.
| Dato | Por qué importa | Ejemplo de uso |
|---|---|---|
| Hora exacta | Permite correlación entre fuentes | Comparar evento de endpoint con alerta SIEM |
| Identidad usada | Relaciona actividad con permisos y riesgo | Validar alertas de abuso de cuenta |
| Activo afectado | Ubica la señal en el inventario | Determinar criticidad del evento |
| Resultado defensivo | Mide si el control funcionó | Registrado, alertado, bloqueado o no observado |
28.18 Retesting de detecciones
Cuando se ajusta una regla o se agrega una fuente de logs, debe repetirse una prueba controlada para comprobar que la mejora funciona. El retesting no solo valida que aparece una alerta, sino que el equipo puede interpretarla y responder con el procedimiento adecuado.
Un buen ciclo de mejora es: prueba, observación, brecha, ajuste, repetición y documentación. Si no se repite la prueba, la organización puede creer que corrigió la visibilidad sin evidencia suficiente.
28.19 Reporte de brechas defensivas
Las brechas defensivas deben reportarse con claridad. No basta decir “no se detectó”. Se debe explicar qué actividad se ejecutó, qué fuente debería haber registrado, qué control se esperaba, qué ocurrió realmente y qué cambio reduciría el riesgo.
También conviene distinguir entre falta de logging, falta de correlación, alerta mal priorizada, ausencia de playbook, exceso de ruido, cobertura parcial o problema de comunicación. Cada causa necesita una solución diferente.
28.20 Remediación
La remediación debe fortalecer visibilidad, reglas, procesos y coordinación. Una nueva alerta sin dueño ni procedimiento puede convertirse en ruido. Un log nuevo sin retención ni protección puede no servir durante un incidente real.
- Habilitar logs críticos en identidad, endpoints, red, aplicaciones y cloud.
- Centralizar eventos relevantes en SIEM o plataforma equivalente.
- Enriquecer alertas con identidad, activo, criticidad y contexto de negocio.
- Reducir falsos positivos mediante ajustes basados en evidencia.
- Crear playbooks para alertas de alto impacto.
- Proteger logs contra modificación y definir retención suficiente.
- Repetir pruebas controladas después de cada mejora importante.
28.21 Flujo práctico de validación defensiva
Un flujo efectivo comienza con objetivos de detección, selección de escenarios, coordinación con defensores, ejecución controlada, revisión de telemetría, ajuste de reglas y retesting. El resultado debe integrarse al reporte general del pentest.
- Definir qué controles y técnicas se quieren validar.
- Confirmar alcance, ventanas, contactos y criterios de detención.
- Preparar cuentas, activos y datos de prueba identificables.
- Ejecutar acciones autorizadas registrando hora y contexto.
- Comparar eventos esperados contra logs, alertas y tickets.
- Identificar causa de brechas: fuente, regla, contexto o proceso.
- Ajustar detecciones y repetir pruebas críticas.
- Documentar mejoras, riesgos residuales y próximos pasos.
28.22 Errores frecuentes
Un error común es evaluar detección sin coordinar horarios ni acciones. Eso produce resultados ambiguos. Otro error es medir éxito solo por alertas generadas, ignorando si el analista entendió el evento, si hubo respuesta y si el procedimiento fue correcto.
También es frecuente depender demasiado de una sola herramienta. Una defensa madura combina logs, EDR, SIEM, controles cloud, telemetría de aplicaciones, inventario, playbooks y criterio humano.
28.23 Qué debes recordar
La detección es tan importante como la prevención. Un control que no bloquea puede seguir aportando valor si registra y alerta a tiempo. Pero una alerta que nadie interpreta o investiga no reduce el riesgo de forma real.
La coordinación entre pentesters y defensores permite convertir pruebas ofensivas en mejoras medibles: cobertura, calidad de logs, reglas más útiles, menor tiempo de respuesta y mejores playbooks.
28.24 Conclusión
Evasión, detección y logging deben tratarse con responsabilidad. En un pentest ético, la simulación de técnicas adversarias sirve para validar controles, no para ocultarse sin límites. El objetivo es que la organización vea más, entienda mejor y responda antes.
En el próximo tema veremos elaboración de reportes: severidad, impacto, evidencia y recomendaciones, donde todo el trabajo técnico se convierte en decisiones claras para corregir riesgos.