2:DETECCIÓN

Dominio de la visibilidad y los indicadores de compromiso (IoC)

La detección de incidentes de seguridad es la capacidad de una organización para identificar actividades anómalas o maliciosas que puedan indicar una intrusión, un abuso de privilegios, una vulnerabilidad explotada o una filtración de datos. Esta etapa es crítica para activar el ciclo de respuesta a tiempo y limitar el daño.

Un error común en los entornos empresariales es confundir disponibilidad de logs con capacidad de detección real. La detección es una capacidad activa, analítica y contextualizada, no solo una colección pasiva de eventos.


🔍 Tipos de Indicadores de Compromiso (IoCs)

Los indicadores pueden ser: Tipo de indicador Ejemplo técnico -- Nivel de detección

  • Táctico (Low-level) Hashes, IPs, dominios maliciosos -- Detección reactiva
  • Operacional (Contextual) Actividad anómala en procesos, cambios de privilegios -- Detección analítica
  • Estratégico (Alto nivel) Patrón de comportamiento de un grupo APT -- Detección predictiva / Threat Intel


📡 Canales y fuentes de detección

La detección efectiva requiere correlación de múltiples capas de información, automatización e intervención humana. Aquí los principales canales:

1. Logs de infraestructura

  • Sistemas operativos: autenticación, creación de procesos, conexiones de red.

  • Firewalls y routers: flujos de red, puertos inusuales, conexiones persistentes.

  • Aplicaciones y bases de datos: accesos no autorizados, consultas anómalas.

🛡️ Blue Team Tip: Centraliza y categoriza los logs en tu SIEM. Aplica etiquetas de prioridad y falsos positivos comunes para mejorar la precisión.


2. Alertas automáticas (detección basada en firmas o reglas)

  • IDS/IPS (Snort, Suricata): analiza tráfico con reglas conocidas.

  • Antivirus/EDR (CrowdStrike, SentinelOne): detección en endpoints.

  • SOAR/SIEM (Splunk, Wazuh, Elastic, QRadar): correlación de eventos.

⚠️ Limitación: Las firmas no detectan ataques desconocidos o "fileless".


3. Análisis de comportamiento (UEBA / ML)

  • Detecta anomalías en el comportamiento normal de:

    • Usuarios (inicio de sesión en horas inusuales, geolocalización anómala).

    • Sistemas (procesos que se elevan sin justificación).

    • Redes (exfiltración lenta, conexiones laterales).

🎯 Detecta ataques de día cero y APTs silenciosos.


4. Threat Hunting (búsqueda proactiva de amenazas)

  • Actividad manual avanzada del Blue Team.

  • Usa hipótesis y técnicas del Red Team (TTPs).

  • Busca lo que los sistemas automáticos no detectan.

  • Requiere alto conocimiento de MITRE ATT&CK y análisis forense.

🧠 Purple Team Power: El Red Team proporciona las TTPs, el Blue Team las rastrea y afina las reglas de detección.


5. Notificación interna o humana

  • Reportes de empleados, usuarios o proveedores sobre:

    • Correos de phishing sospechosos.

    • Errores del sistema fuera de lo común.

    • Conductas sospechosas de compañeros.

🚨 Clave: Canal anónimo para denuncias internas = detección de amenazas internas y empleados descontentos.


6. Alertas externas

  • Proveedores, agencias gubernamentales, grupos CERT/CSIRT.

  • Alertas de CVEs, zero-days, campañas activas.

  • Fuentes: CISA, INCIBE, Microsoft Threat Intelligence, Cisco Talos, etc.


👥 Rol del personal de primera respuesta (First Responder)

Al detectar un evento sospechoso, el primer nivel de atención es el analista de detección (Tier 1) o el miembro del CIRT con guardia activa. Este profesional debe:

  • Clasificar el evento (incidente real vs falso positivo).

  • Priorizarlo según el impacto y la criticidad.

  • Escalarlo si excede su capacidad o autoridad.

  • Preservar evidencia (sin contaminarla).

  • Activar la cadena de respuesta (contención, análisis, etc.).

🛡️ Es crítico que todo el personal de IT reciba formación para identificar eventos anómalos y saber a quién notificar de forma segura e inmediata.


📈 Metrificación de la detección

Una detección eficaz se mide con indicadores como:

Métrica Descripción
Time to Detect (TTD) Tiempo desde el ataque hasta su detección.
True Positive Rate (TPR) Porcentaje de alertas que eran incidentes reales.
False Positive Rate (FPR) Porcentaje de alertas irrelevantes o erróneas.
Detección por canal Fuente que generó la detección (automático vs humano).
🧠 Purple Insight: Estas métricas se revisan post-incident en la fase de lecciones aprendidas. Ayudan a mejorar reglas y sensores.


Claves Estratégicas y Curiosidades sobre la Detección

🕵️‍♂️ 1. El 93% de los ataques avanzados se detectan demasiado tarde

Aunque muchas empresas creen que tienen una buena cobertura, lo cierto es que:

  • El TTD (Time To Detect) en ataques persistentes supera los 200 días en muchas organizaciones.

  • Muchos incidentes se detectan por terceras partes, no por los propios equipos de seguridad.

  • Malwareless attacks (sin archivos) pasan desapercibidos en AV tradicionales.

🔍 Claves de mejora: Implementar monitoreo continuo del comportamiento del sistema, no solo de archivos.


🎭 2. Los atacantes saben cómo "camuflarse"

Durante la fase de post-explotación, los atacantes:

  • Usan procesos legítimos del sistema para moverse lateralmente (Living Off the Land – LOL).

  • Ocultan sus actividades usando nombres falsos de procesos (e.g. svch0st.exe, rund132.exe).

  • Limpian logs críticos para eliminar huellas (event ID 1102 en Windows → borrado de registros).

⚔️ Red Team tip: Usa herramientas como Invoke-Phant0m o LogCleaner.

🛡️ Blue Team tip: Monitoriza eventos de borrado de logs, uso de wevtutil, Clear-EventLog y ejecutables anómalos.


🧬 3. La mayoría de SIEMs no detectan movimientos laterales sin reglas específicas

La técnica de movimiento lateral silencioso mediante WMI, PSExec o Remote Services puede:

  • Generar poco o ningún ruido en el SIEM si no se tiene detección basada en comportamiento y no en firmas.

  • Ser confundida con acciones legítimas de administración.

🔍 Recomendación Purple: Correlacionar creación de procesos + conexiones remotas + cambios en privilegios en sesiones sin login interactivo.


📡 4. Muchas detecciones se quedan en eventos… pero no en acción

Un error común:

  • Se genera una alerta en el SIEM.

  • Nadie la revisa o la analiza por fatiga de alertas o falta de personal.

  • El atacante avanza sin obstáculos.

🧨 Resultado: La detección no sirve si no se integra con la respuesta (SOAR, playbooks, runbooks, escalado ágil).


💣 5. Los atacantes pueden deshabilitar o engañar herramientas defensivas

Un atacante con privilegios puede:

  • Desactivar logs: deshabilitar el registro de eventos de Windows o modificar syslog.

  • Cortar la conexión del agente SIEM: impedir que los logs lleguen al colector.

  • Inyectar ruido: generar miles de eventos falsos para ocultar los reales.

🔐 Recomendación: Supervisar la integridad de los agentes y establecer alertas si dejan de enviar datos.


🔎 6. No todos los logs valen lo mismo

Algunos logs aportan oro puro para detectar amenazas, mientras que otros solo generan ruido.

Fuente crítica ¿Qué puede revelar?

  • Security.evtx (Windows) Inicios de sesión, escaladas de privilegio
  • Sysmon Creación de procesos, cambios de red, DLLs cargadas
  • Linux auditd / journald Accesos root, su/sudo, cambios de archivos
  • Firewall logs Tráfico anómalo o lateral
  • DNS logs Dominio sospechoso, C2 Beaconing

🧠 Curiosidad Purple: DNS logs permiten detectar tráfico sigiloso de exfiltración tipo dnscat2 o iodine.


🧩 7. El atacante intenta moverse entre los puntos ciegos

Los puntos débiles más comunes en detección:

  • Red lateral interna no segmentada → sin visibilidad entre hosts.

  • Tráfico cifrado sin inspección → imposible ver payloads.

  • Máquinas sin agentes SIEM/EDR → tierra de nadie.

  • Logs locales no centralizados → si apagas la máquina, se pierden.

🛠️ Solución: Segmentación interna + inspección TLS + centralización de logs en tiempo real.


🔄 8. Los ataques "fileless" son casi invisibles

Los ataques sin archivos usan:

  • PowerShell o scripts directamente en memoria.

  • No dejan archivos en disco, por lo que los antivirus los ignoran.

  • Requieren detección basada en comportamiento, cadena de procesos y anomalías.

⚠️ Ejemplo: Empire, Cobalt Strike, PoshC2 → ejecutan shellcode directamente desde memoria.


🔐 9. SIEM sin contexto = ruído sin inteligencia

Un SIEM mal configurado:

  • Genera alertas genéricas.

  • Tiene reglas poco afinadas.

  • No contextualiza: no sabe si el host afectado es crítico, o si el usuario tiene permisos especiales.

💡 Solución Purple: Añadir contexto de activos (CMDB), etiquetas de criticidad, y usar playbooks para priorizar alertas.


🧨 10. Muchos SIEM ignoran procesos lanzados desde Temp o AppData

Los atacantes lo saben y abusan de rutas como:

  • C:\Users\[user]\AppData\Local\Temp

  • C:\Users\[user]\AppData\Roaming

📦 Estas carpetas se usan para cargar payloads en ejecución sin persistencia duradera.

🧬 Blue Tip: Añade reglas en EDR y SIEM que alerten por ejecución de binarios desde directorios no estándar.


🐚 11. La mayoría de los shells remotos no generan alertas directas

  • reverse shell, bind shell, meterpreter, nishang, nc.exe → no siempre se detectan si el proceso se camufla como legítimo (p. ej. svchost.exe).

  • Muchos shells se lanzan en puertos no estándar (puerto 443 o 53), evitando detección.

🎯 Recomendación Purple: crea alertas basadas en:

  • Procesos con conexiones salientes inusuales.

  • Actividades de red desde procesos que no deberían tener conexión.


🎥 12. Exfiltración lenta de datos pasa desapercibida sin DLP

Ataques sofisticados dividen grandes volúmenes de datos en fragmentos pequeños para evitar alertas por tamaño.

📊 Ejemplo real:

  • Enviar 10 GB en paquetes de 50 KB cada minuto → no salta ninguna alerta sin un sistema DLP.

🧠 Defensa: SIEM + reglas DLP para detectar patrones de exfiltración por volumen o frecuencia.


💥 13. La ejecución en memoria es indetectable sin registros de Sysmon o EDR

Los ataques en memoria no aparecen en los logs estándar del sistema operativo.

📌 Solo herramientas como Sysmon, Elastic EDR, Crowdstrike o Defender for Endpoint pueden registrar:

  • Cargas de DLLs.

  • Scripts cargados en memoria.

  • Procesos hijos sospechosos.

🧬 Curiosidad: Muchos ransomware modernos (LockBit, BlackCat) son fileless en sus primeras fases.


🔄 14. El comportamiento anómalo es la joya oculta de la detección moderna

La clave ya no es buscar el "qué" (hash, IP, firma), sino el "cómo".

📉 ¿Por qué tu CEO inicia sesión a las 3:47 AM desde Vietnam usando PowerShell?
Esa pregunta, no un hash, es la que salva a las empresas.

💡 Solución Purple: Implementar UBA/UEBA (User Behavior Analytics) y ML para detectar desvíos de comportamiento.


🧠 15. Las herramientas ofensivas avanzadas ya incorporan evasión nativa

Herramientas como:

  • Cobalt Strike

  • Sliver

  • Mythic

  • Havoc

  • Brute Ratel

➡️ Emulan tráfico legítimo, rotan user-agents, encriptan payloads y usan TLS mutuo para evadir IDS/EDR.

🛡️ Defensa avanzada: inspección profunda de comportamiento + honeypots internos + alertas por patrones inusuales, no solo IOC.


🕳️ 16. Los honeypots internos son oro puro para detección temprana

  • Si nadie debe tocar una carpeta o puerto… y alguien lo hace → señal directa de que algo raro está pasando.

🎣 Honeypots simples: archivos .docx con macros en carpetas compartidas, puertos sin servicio abiertos pero monitorizados (e.g., 8020).

🧱 Curiosidad: Honeypots bien colocados te alertan antes de que el atacante haga daño real.


📘 17. El MITRE D3FEND es el compañero de ATT&CK para mejorar detección

Si ATT&CK describe cómo ataca el Red Team, D3FEND describe cómo se defiende el Blue Team.

🧰 D3FEND categoriza tácticas defensivas como:

  • Process Analysis

  • Network Isolation

  • File Monitoring

  • Credential Hardening

🎯 Purple Team Ideal: Planear defensas alineadas con las TTPs más probables según ATT&CK → y reforzarlas con capacidades de D3FEND.



✅ Buenas prácticas para mejorar la detección (Purple Team)

  • Usar MITRE ATT&CK como referencia de cobertura: crea reglas de detección por TTPs, no solo por IOC.

  • Afina tus reglas en el SIEM con base en tu entorno real, priorizando los activos críticos.

  • Implementa alertas específicas para ataques sin archivos: monitoriza uso de PowerShell, WMI, rundll32 y scripting en memoria.

  • Asegura que todos los dispositivos críticos tengan EDR/SIEM y que reporten logs en tiempo real.

  • Inspecciona tráfico cifrado en la red interna, especialmente conexiones hacia IPs externas desde hosts inusuales.

  • Crea reglas de correlación que combinen múltiples eventos (inicio de sesión + creación de proceso + modificación de permisos).

  • Forma continuamente a tu equipo: la detección es una disciplina viva y evolutiva.

  • Monitorea integridad de tus agentes SIEM/EDR: si dejan de reportar → ¡alerta crítica!

  • Haz cazas de amenazas proactivas semanales: no todo se detecta con reglas automáticas.

  • Aplica reglas YARA o Sigma en tiempo real: para buscar patrones complejos de amenazas.

  • Establece honeypots por segmentos de red: incluso dispositivos falsos como impresoras o PLCs.

  • Simula ataques regularmente con Purple Teaming: mide qué detectas y qué no.

Purple Mystara - Cristina Martínez Girol
Todos los derechos reservados 2025
Creado con Webnode Cookies
¡Crea tu página web gratis! Esta página web fue creada con Webnode. Crea tu propia web gratis hoy mismo! Comenzar