Un estudio que abarcó más de 25 millones de alertas de seguridad en entornos corporativos reales reveló un problema estructural: casi el 1% de los incidentes confirmados se originó en notificaciones clasificadas inicialmente como de baja prioridad o meramente informativas. En los endpoints, esta cifra alcanzó el 2%. Con un volumen medio de 450 000 alertas por organización al año, esto significa alrededor de 54 amenazas reales anuales —aproximadamente una por semana— que en el modelo tradicional de SOC o MDR nunca se investigan. Los datos indican que el problema no está en la detección, sino en la economía del triage: los recursos de los analistas se agotan antes que el flujo de notificaciones.

Alcance del estudio

Según el informe, el conjunto de datos incluía telemetría de 10 millones de endpoints y cuentas de usuario, 82 000 investigaciones forenses con análisis de memoria en vivo, 180 millones de archivos analizados, así como datos de 7 millones de direcciones IP, 3 millones de dominios y URL, y más de 550 000 correos electrónicos de phishing. Es importante tener en cuenta que el informe primario (2026 AI SOC Report de Intezer) no fue proporcionado para verificación independiente, por lo que las cifras concretas deben tomarse con la cautela de su origen.

EDR: una falsa sensación de seguridad

El hallazgo más preocupante se refiere a la fiabilidad de las soluciones de clase EDR. De las 82 000 alertas sometidas a análisis forense de memoria, 2 600 hosts presentaban una infección activa. Al mismo tiempo, según se indica, el 51% de esas máquinas comprometidas de forma confirmada ya habían sido marcadas por el proveedor de EDR como «mitigated». En la práctica, más de la mitad de las infecciones reales permanecían invisibles porque la herramienta de protección había cerrado el ticket y declarado la amenaza como eliminada.

Entre las familias de malware detectadas en la memoria durante el escaneo figuraban:

• Mimikatz: herramienta para la extracción de credenciales
• Cobalt Strike: framework de post-explotación
• Meterpreter: componente de Metasploit para control remoto
• StrelaStealer: stealer de credenciales de clientes de correo

No se trata de muestras experimentales, sino de herramientas operativas empleadas en operaciones criminales y estatales.

Phishing: plataformas de confianza como arma

Menos del 6% de los correos de phishing maliciosos confirmados contenían adjuntos. La inmensa mayoría se basaba en enlaces e ingeniería social. Los atacantes, según el estudio, han trasladado su infraestructura a plataformas que se consideran confiables por defecto: Vercel, CodePen, OneDrive y el sistema de facturación de PayPal.

Una de las campañas documentadas utilizaba la función legítima de solicitud de pago de PayPal para enviar correos de phishing. Los números de devolución de llamada se incluían en las notas del pago y se empleaban homógrafos Unicode para eludir la detección basada en firmas. El correo superaba todas las comprobaciones estándar de autenticación, ya que efectivamente se enviaba desde los servidores de PayPal.

Una observación adicional: los sitios que utilizaban Cloudflare Turnstile CAPTCHA en el conjunto de datos analizado se correlacionaban de forma consistente con páginas de phishing, mientras que Google reCAPTCHA se asociaba con infraestructura legítima. Los atacantes emplean mecanismos de protección anti-bots para bloquear los escáneres de seguridad automatizados.

Cuatro técnicas de evasión de gateways de correo identificadas en los datos:

1. Carga útil en formato Base64 oculta dentro de archivos SVG
2. Enlaces incrustados en los metadatos de anotaciones de PDF, invisibles para escáneres superficiales
3. Páginas de phishing cargadas dinámicamente a través de carpetas compartidas legítimas de OneDrive
4. Archivos DOCX que contienen HTML archivado con códigos QR

Infraestructura en la nube: configuraciones erróneas silenciosas

Las alertas en la nube del estudio se concentraban en torno a tácticas de evasión de detección y establecimiento de persistencia en el entorno. Los movimientos laterales y la elevación de privilegios se registraron con mucha menor frecuencia. Según el informe, los atacantes actúan con paciencia: manipulación de tokens, abuso de funciones legítimas de los servicios cloud y ofuscación para evitar el disparo de detecciones de alta prioridad.

AWS S3 representó alrededor del 70% de todas las infracciones de políticas de seguridad en la nube en el conjunto de datos. Los principales problemas fueron la gestión de accesos, el logging del lado del servidor y las restricciones a la interacción entre cuentas. Estos hallazgos suelen clasificarse como de baja prioridad y rara vez generan alertas, pero son precisamente los que se explotan repetidamente tras obtener el acceso inicial.

Recomendaciones prácticas

• No confíe en el estado «mitigated» del EDR sin verificación. Implemente escaneos periódicos de memoria en vivo en los hosts críticos, especialmente en aquellos donde el EDR haya detectado y «mitigado» una amenaza.
• Revise la política de ignorar alertas de baja prioridad. Asigne recursos para la investigación selectiva de notificaciones informativas, en especial en los endpoints.
• Actualice las reglas de filtrado de phishing teniendo en cuenta el abuso de plataformas de confianza. Añada la comprobación de enlaces a Vercel, CodePen y OneDrive en el contexto del correo entrante.
• Realice una auditoría de la configuración de buckets S3 centrándose en la gestión de accesos, el logging y las políticas entre cuentas. Aumente la prioridad de estos hallazgos en los procesos de gestión de vulnerabilidades.
• Cierre el ciclo de retroalimentación: los resultados de las investigaciones de alertas de baja prioridad deben retroalimentar la configuración de las reglas de detección. Sin esto, el sistema no se auto‑mejora.

La conclusión clave que se extrae de estos datos no reside en las cifras concretas (que requieren verificación independiente), sino en una pauta sistémica: el modelo de triaje basado en niveles de criticidad crea puntos ciegos previsibles que los atacantes explotan de forma deliberada. El primer paso concreto consiste en realizar un análisis retrospectivo de las alertas que el EDR haya cerrado como «mitigated» en los últimos 90 días, utilizando una herramienta forense independiente para revisar la memoria al menos en una muestra del 5–10% de los hosts.