De los hallazgos del pentest a las detecciones del SOC

24.06.20264 min de lecturaEquipo Atalaia

La mayoría de los equipos usa un informe de pentest una sola vez. Los hallazgos se convierten en tickets, los tickets se corrigen y el informe se archiva. Pero un pentest también es lo más parecido que tienes a un ataque etiquetado contra tus propios sistemas: técnicas conocidas, objetivos conocidos, horas conocidas. Eso es exactamente lo que quieren los detection engineers.

Esta guía muestra cómo convertir hallazgos en detecciones que tu SOC pueda ejecutar, usando MITRE ATT&CK como lenguaje común y Sigma para reglas portables.

Por qué arreglar y detectar

Corregir el bug cierra una puerta. La detección te avisa cuando alguien prueba el picaporte de esa puerta, o el de la siguiente que aún no has encontrado. Responden a preguntas distintas:

• El arreglo responde: ¿puede este ataque concreto seguir funcionando?
• La detección responde: ¿hay alguien intentando ahora mismo esta clase de ataque?

Una detección construida a partir de un hallazgo también atrapa regresiones. Si una release posterior reabre el agujero, tu alerta puede ser el primer sitio donde te enteres.

El proceso, hallazgo a hallazgo

1. RecogerPide a los testers las IPs de origen, las marcas de tiempo y las peticiones en bruto. Acordadlo antes de que empiece el trabajo.
2. MapearAsigna a cada hallazgo una técnica de ATT&CK que describa lo que hizo el atacante, no cuál era el bug.
3. LocalizarEncuentra los logs que registraron la actividad: servidor web, WAF, auditoría cloud, proveedor de identidad.
4. EscribirExpresa el comportamiento observable como una regla Sigma.
5. PruebaReproduce la regla sobre la ventana del pentest. Debe saltar con el tráfico del tester y quedarse callada en los días normales.

Asociar hallazgos a ATT&CK

Mapea la acción del atacante. Un server-side request forgery es una clase de bug; el objetivo del atacante al explotarlo en la nube suele ser leer las credenciales de la instancia. Los hallazgos típicos de web y cloud se asocian así:

Registrar el ID de la técnica en cada detección te permite ver la cobertura en toda la matriz y detectar técnicas que pruebas pero nunca detectas.

Una regla Sigma a partir de un hallazgo de SSRF

Supón que los testers llegaron a la dirección de metadatos a través de un parámetro de descarga de imágenes. El servidor web registró la query string. Una regla Sigma para ese comportamiento:

title: Possible SSRF Targeting Cloud Metadata Service
id: 8f2b6c1e-4d7a-4b0e-9c3f-2a1d5e6f7a80
status: experimental
description: |
  Detects requests whose URL or query contains the link-local cloud
  metadata address or a common alias. Built from pentest finding PT-2026-11.
references:
  - internal://pentest/2026/PT-2026-11
tags:
  - attack.credential_access
  - attack.t1552.005
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection:
    cs-uri-query|contains:
      - '169.254.169.254'
      - 'metadata.google.internal'
      - '%31%36%39%2e%32%35%34'
      - '0xa9fea9fe'
  condition: selection
falsepositives:
  - Internal health checks that legitimately reference the address
level: high

Conviértela al lenguaje de consultas de tu plataforma con el Sigma CLI y ejecútala sobre la ventana del pentest:

pip install sigma-cli
sigma plugin list                  # find the backend for your log platform
sigma plugin install "$BACKEND"
sigma convert -t "$BACKEND" ssrf_metadata.yml

Elige el backend y, si los nombres de tus campos son distintos, un pipeline de procesamiento, para que encaje con tu plataforma de logs. Las variantes codificadas de la regla salen del mismo razonamiento que un buen retest: si los testers probaron una codificación, los atacantes probarán varias.

Combina la regla web con una segunda señal más fuerte donde puedas: logs de auditoría cloud que muestren las credenciales del rol de la instancia usadas desde una dirección fuera de tu red. Eso detecta el resultado, no solo el intento.

Prueba y ajusta

• Verdadero positivo: la regla salta con cada petición del tester en la ventana. Si se pierde alguna, mira qué cambió.
• Falso positivo: ejecútalo durante una semana normal. Añade exclusiones estrechas con un comentario que explique cada una.
• Responsable: cada regla tiene un responsable, un enlace al runbook y el ID del hallazgo de pentest del que viene.
• Control de versiones: guarda las reglas en un repositorio con revisión y CI, igual que el código de la aplicación. Valídalas con sigma check.

Qué hacer el lunes

1. Coge tu último informe de pentest y lista cada hallazgo con una técnica de ATT&CK.
2. Pregunta a los testers, o revisa tus notas, por las IP de origen y la ventana de pruebas.
3. Busca su actividad en tus logs. Anota cualquier hallazgo que no dejara rastro.
4. Escribe una regla Sigma para el hallazgo de mayor impacto y pruébala sobre la ventana.
5. En el próximo engagement, acuerda en el scope que los testers compartan marcas de tiempo y orígenes, para que las detecciones formen parte del entregable.

Hecho así, cada prueba deja la línea más difícil de romper y mejor preparada para notar cuándo alguien lo intenta.

Dónde encaja en la línea