Las herramientas de seguridad pueden lograr detener una versión conocida de un ataque, pero dejar pasar el mismo comportamiento cuando se ejecuta de una manera menos evidente. Esta es la principal conclusión de un análisis basado en Blue Report 2026, publicado por Picus Labs, que midió el rendimiento de los mecanismos de prevención y detección en entornos reales de clientes mediante más de 338 millones de simulaciones de ataques ejecutadas entre enero y junio de 2026.
La eficacia general de prevención aumentó al 69%, frente al 62% del año anterior, y volvió al nivel de 2024. Sin embargo, esta cifra representa un promedio del ecosistema de protección y no necesariamente muestra lo que un atacante puede hacer después de entrar en el entorno o al cambiar la herramienta y el método utilizados para alcanzar el mismo objetivo.
Un indicador conocido no equivale a protección frente al comportamiento
El análisis distingue entre dos tipos de pruebas. Las pruebas basadas en indicadores conocidos, o IOC-based testing, verifican la capacidad de los cortafuegos, los agentes web y las puertas de enlace de correo seguro para reconocer muestras maliciosas conocidas y bloquear sus intentos de descarga. Esta medición resulta adecuada para la capa de protección perimetral, pero no responde a una pregunta diferente: ¿puede el sistema impedir la acción que ejecuta el atacante, independientemente de la herramienta o la ruta?
Aquí entran en juego las pruebas de comportamiento basadas en tácticas, técnicas y procedimientos (TTP). En lugar de preguntar si la herramienta Mimikatz es conocida por el sistema, este enfoque prueba si cualquier programa del dispositivo puede obtener materiales de credenciales del usuario. Esta pregunta es importante para las herramientas de protección de endpoints y los sistemas de detección de intrusiones, porque el atacante normalmente ya ha comenzado la ejecución dentro del entorno cuando estos controles llegan a la fase de intervención.
La tasa de bloqueo de descargas de malware conocido según indicadores IOC descendió al 50% en los datos de 2026, frente al 60% en 2025 y al 71% en 2024. Esto indica que incluso la capa que depende más de las firmas no ofrece una cobertura constante, y que un buen resultado en una prueba de firma conocida no revela lo que ocurre cuando cambia el comportamiento o la forma de ejecutarlo.
El ejemplo de Mimikatz revela la brecha
Los entornos de los clientes utilizaron la herramienta Mimikatz para alcanzar el mismo objetivo, extraer credenciales, mediante tres rutas. La extracción de datos de la memoria del proceso LSASS fue bloqueada en el 94% de los intentos, la ruta tradicional que los productos supervisan ampliamente. Sin embargo, la proporción cayó al 17% al extraer credenciales RDP de otras ubicaciones de la memoria utilizando la misma herramienta, y al 3% al leer LSA Secrets del registro local del sistema.
Los tres casos pertenecen a la misma técnica principal, OS Credential Dumping (T1003), y terminan con el mismo resultado: que el atacante posea materiales de credenciales sensibles. La diferencia estaba en el grado de visibilidad de la ruta para los controles de seguridad. La lectura de la memoria de lsass.exe deja eventos que pueden correlacionarse con mayor facilidad, mientras que la lectura de una celda del registro con privilegios de SYSTEM puede parecer más cercana a una actividad administrativa normal.
Además, el éxito de la prevención contra una versión conocida de Mimikatz no garantiza que el resultado se mantenga. Se pueden cambiar las cadenas de texto en las que se basa la firma, recompilar la herramienta, cargar el código en la memoria sin dejarlo en el disco o utilizar herramientas firmadas por Microsoft, como ProcDump o comsvcs.dll, y analizar después los datos. En estos casos cambia la huella que buscan las firmas, mientras que el comportamiento y el objetivo final permanecen iguales.
La protección dentro del entorno es más débil que la protección en los límites
La tasa general de prevención alcanzó el 69% cuando se midió en el perímetro, pero las pruebas de penetración autónomas que miden lo que un atacante puede hacer después de entrar como usuario autenticado mostraron que solo se bloqueó el 37% de las acciones posteriores a la intrusión. En otras palabras, la protección pasó de detener cerca de dos tercios de los ataques en el perímetro a detener poco más de un tercio de las acciones dentro del entorno.
Las acciones más ruidosas fueron más fáciles de detectar: la detección del movimiento lateral alcanzó aproximadamente el 90%, la evasión de UAC superó el 85%, mientras que el bloqueo de la reutilización de credenciales y del abuso de Active Directory llegó a aproximadamente el 63%. En cambio, las tasas descendieron en las actividades menos evidentes: la protección de los materiales de credenciales leídos pasivamente de la memoria y el registro no superó el 22%, y fue inferior al 1% en el caso de la extracción de secretos del registro local. Asimismo, las actividades de descubrimiento y recopilación no superaron el 10%, y las operaciones de enumeración del dominio mediante SharpHound y la recopilación de archivos locales se ejecutaron, en su mayoría, sin obstáculos.
¿Qué cambia en la práctica?
La conclusión práctica del análisis es que los programas de validación de seguridad deben interpretar cada prueba según lo que mide, en lugar de tratar un único resultado como una prueba integral de cobertura. Las pruebas de muestras conocidas siguen siendo adecuadas para cortafuegos, agentes web, cortafuegos de aplicaciones web y puertas de enlace de correo seguro. En cambio, la capa de endpoints y detección, incluidos EDR, IDS y el contenido de SIEM, necesita probar todas las rutas que conducen al mismo objetivo: la memoria de LSASS, el registro, ubicaciones de memoria alternativas, herramientas nativas y versiones recompiladas.
El artículo advierte que probar únicamente la acción más conocida puede llevar a cerrar un punto que en realidad sigue expuesto. El análisis propone utilizar múltiples simulaciones del mismo comportamiento para verificar los controles existentes, en lugar de limitarse a demostrar que una firma reconoció una sola herramienta. Menciona Picus Swarm como una capa de coordinación para ejecutar y probar estas variaciones en todo el entorno, dentro del marco de los productos y servicios de la empresa.
La recomendación no consiste necesariamente en añadir nuevas herramientas, sino en identificar los controles existentes que realmente pueden interrumpir la cadena de ataque y después tomar una decisión documentada sobre cada exposición: corregirla, mitigarla, supervisarla o aceptarla con evidencias. Según el artículo, los resultados del informe siguen formando parte de un estudio más amplio que incluye las diferencias de rendimiento entre sectores y regiones, las vulnerabilidades más explotadas, una tasa de registro del 58% y una tasa de alertas del 14%.