Las empresas han reforzado sus redes con numerosas herramientas de seguridad, pero muchas aún no detectan a tiempo lo que sucede en su interior. EDR, SIEM, firewalls, EPP, proveedores gestionados y alertas automáticas no aseguran una visibilidad completa si no se verifica que la telemetría está llegando correctamente, que las reglas siguen siendo efectivas y que las señales débiles se investigan antes de que el atacante gane terreno.
El último informe de Kaspersky Compromise Assessment, basado en evaluaciones realizadas en 2025, cuantifica este problema. El 30,8 % de los incidentes detectados tenían actividad histórica superior a tres meses, y el 52 % de los compromisos severos solo fueron identificados después de más de 90 días sin detectar. El caso más antiguo localizado había permanecido oculto en la red de una organización durante cuatro años.
La conclusión para los equipos de tecnología y seguridad es clara: la brecha no siempre radica en la falta de herramientas, sino en su forma de operación. Según el informe, el 20 % de los incidentes se descubrieron manualmente y el 60 % pasó desapercibido porque las herramientas existentes no generaron alertas de alta confianza. Kaspersky describe así una debilidad común en muchas organizaciones: controles instalados, pero mal configurados, poco monitoreados o sin una rutina de revisión continua.
La seguridad adquirida no equivale a seguridad operada
Durante años, muchas organizaciones han medido su postura defensiva en función del inventario de soluciones instaladas. Contar con EDR en los endpoints, un SIEM centralizado, logs reenviados, antivirus de última generación o un MSSP contratado parecía suficiente para reducir riesgos. Sin embargo, el informe cuestiona esa comodidad.
Kaspersky detecta que la ausencia de monitorización continua elevó al 86 % la proporción de incidentes de severidad media o alta. Cuando no existía threat hunting estructurado, esa cifra fue del 84 %. La diferencia entre ver y no ver no solo depende de la herramienta, sino de que exista un equipo, ya sea interno o externo, que valide alertas, revise señales de baja confianza, contraste patrones y busque actividad anómala de manera proactiva.
Un ejemplo citado en el informe ilustra bien el problema: una empresa que había invertido en controles de seguridad asumió que su entorno estaba protegido. Sin embargo, la revisión histórica de logs reveló actividad relacionada con Impacket, despliegue de Cobalt Strike y presencia de Mimikatz en servidores críticos, incluidos controladores de dominio. La actividad llevaba tres meses sin detectarse por falta de monitorización 24/7 efectiva.
| Problema detectado | Impacto operativo |
|---|---|
| Alertas sin validación humana | Señales débiles que nunca son investigadas |
| EDR/EPP mal configurado | Sensores presentes, pero sin detección útil |
| Ausencia de threat hunting | Persistencia y movimiento lateral durante semanas |
| Backups no inspeccionados | Reintroducción de web shells tras restauraciones |
| Inventario incompleto | Servidores fuera de escaneo y monitorización |
| Playbooks rígidos | Respuesta limitada solo al primer síntoma del ataque |
| Comunicación deficiente | Retrasos en confirmaciones, escalados y decisiones |
El informe también destaca el papel de los servicios gestionados. Contar con un MSSP puede fortalecer la postura defensiva, pero no elimina la necesidad de una gestión interna. En proyectos con proveedores gestionados, Kaspersky observó incidentes no detectados por la baja cobertura de detección y carencias básicas en auditorías de Windows, como eventos no registrados o políticas de auditoría desactivadas. Externalizar ayuda si existen expectativas, métricas y responsabilidades claras; no si se usa como sustituto de la gestión interna de la seguridad.
Backups, inventario y persistencia: las áreas menos revisadas
Uno de los hallazgos más prácticos se relaciona con las copias de seguridad. El 40 % de las web shells detectadas por Kaspersky estaban almacenadas en backups. Esto significa que una organización puede limpiar un servidor, cerrar una incidencia y, al restaurar una copia, volver a introducir la puerta trasera.
La copia de seguridad suele considerarse una garantía de recuperación, pero en una intrusión también puede actuar como una cápsula de conservación del malware. Si los backups no se escanean, comparan con líneas base o se validan antes de restaurar, pueden mantener vivo un acceso que el equipo de respuesta creía haber eliminado.
El problema se agrava con inventarios incompletos. Kaspersky identificó brechas en el inventario en el 25 % de los casos, incluyendo servidores Linux en la nube que no estaban vinculados a Active Directory y que quedaban fuera de los escaneos rutinarios. Un atacante puede instalar una web shell en esos activos y permanecer mucho tiempo sin ser detectado, especialmente si los servidores se respaldan automáticamente pero no se incluyen en las herramientas habituales de detección.
En otro ejemplo, una web shell fue detectada en un archivo comprimido .rar almacenado en un servidor interno no conectado durante la evaluación, que no había sido incluido en el inventario. La investigación reveló posteriormente una puerta trasera instalada en varios servidores Windows mediante cambios en las contraseñas de administrador local.
LoLBins y herramientas remotas: el ruido que oculta al atacante
El informe resalta un patrón conocido por los equipos SOC: los atacantes usan cada vez más herramientas legítimas. En todos los compromisos detectados, aparecieron utilidades de administración remota no estándar y LoLBins, es decir, binarios o herramientas del sistema que pueden ser utilizadas tanto para tareas legítimas como para actividades maliciosas, como movimiento lateral, persistencia o exfiltración.
No existe una regla simple en este contexto. PsExec, AnyDesk, TeamViewer, VNC, certutil, bitsadmin, regsvr32 o wmic pueden ser herramientas perfectamente legítimas. Pero también pueden ser usadas en intrusiones. La diferencia radica en el contexto: quién ejecuta la herramienta, desde qué endpoint, en qué horario, con qué parámetros, contra qué destino y si ese uso forma parte de la actividad habitual de la organización.
Kaspersky recomienda establecer políticas explícitas sobre herramientas de administración remota, enviar logs a una plataforma central, auditar el software utilizado, enriquecer los hashes ejecutados con categorías funcionales y definir reglas para detectar patrones comunes en el abuso de LoLBins. La clave no es bloquear todo por defecto, sino crear una línea base realista y detectar desviaciones.
Este trabajo, aunque no tan visible como adquirir otra consola, suele marcar la diferencia. Cuando los analistas desconocen qué uso normal tiene su entorno, cada alerta genera dudas. Pero si existe una línea base, la investigación se enfoca en lo que sale del patrón habitual.
Responder a un incidente no implica seguir una receta fija
Kaspersky también señala una brecha en la respuesta a incidentes: el 39 % de los casos analizados requirieron modificar el plan de respuesta durante la investigación, y el 59 % precisó recoger y analizar paquetes forenses. Esto se debe a que los incidentes reales evolucionan a medida que aparecen nuevas evidencias.
Una organización puede contener el primer servidor comprometido, pero aún así dejar persistencia en otros sistemas. El informe cita un ejemplo: tras una respuesta inicial efectiva, se detectaron varias puertas traseras fuera del alcance original, como un cron que recreaba una web shell, una reverse shell activa, persistencia mediante registro de Windows y un consumidor malicioso de WMI.
La respuesta a incidentes debe ser un proceso dinámico. Cada nuevo artefacto puede cambiar prioridades, alcance y pasos para erradicar la amenaza. Seguir un playbook rigido puede detener solo la hemorragia visible, dejando abiertas otras vías de entrada.
La comunicación también es fundamental. El 32 % de los proyectos analizados presentaron problemas internos que afectaron la respuesta, como confirmaciones poco claras, validaciones lentas por parte de responsables, canales comprometidos o pérdida de conocimiento por rotación del personal. En un incidente crítico, la técnica es importante, pero la coordinación hace la diferencia en el resultado final.
La inteligencia artificial generativa ya es parte del riesgo corporativo
El informe presenta un ejemplo que refleja las nuevas formas de trabajo: en una evaluación, Kaspersky identificó una estación macOS que utilizaba Claude Code como extensión de VS Code. Esta herramienta capturaba snapshots del sistema de archivos para enriquecer prompts, incluyendo listados de directorios y rutas completas a archivos Excel con datos confidenciales internos.
No se trata de una crítica general a los asistentes de desarrollo con IA, sino de una advertencia sobre su adopción sin políticas claras. Las herramientas de IA ya están en uso en desarrollo, administración de sistemas y tareas productivas. Si una organización no define qué datos pueden exponerse, qué proveedores están autorizados, qué carpetas se excluyen y qué controles aplicar, la IA puede convertirse en otra zona de sombra.
Para los equipos de seguridad, esto implica ampliar la vigilancia. La superficie de riesgo ya no está solo en endpoints, correos, identidad, entornos cloud y aplicaciones web. También en extensiones, asistentes de código, agentes locales, prompts, snapshots, conectores y automatizaciones que pueden acceder a datos internos sin pasar por los controles tradicionales.
Qué deberían hacer los equipos de tecnología y seguridad
El informe sugiere una recomendación fundamental: tratar la detección como una función activa, no como una compra. Esto comienza con una revisión de la salud de los motores de detección: sensores activos, reglas actualizadas, telemetría completa, logs críticos habilitados, cobertura de endpoints y alertas relevantes. La ausencia de señales no implica automáticamente que no exista ataque, hasta validar que el sistema puede detectar correctamente.
Luego, se requiere revisar alertas de baja confianza, establecer un ritmo de threat hunting, definir líneas base para herramientas remotas y LoLBins, auditar el inventario de activos, verificar backups antes de restaurar y actualizar los playbooks en función de nuevas evidencias.
También es recomendable fortalecer las capacidades internas en análisis forense digital y análisis de malware. Kaspersky observa que las organizaciones capaces de analizar artefactos forenses internamente tuvieron menos incidentes severos y que contar con recursos de ingeniería inversa estuvo asociado con menor gravedad en los casos estudiados.
La conclusión no es que todas las empresas deban gestionar todo internamente, sino que incluso en la delegación alguien debe ejercer gobernanza. La seguridad no consiste en simplemente instalar una herramienta y esperar que detecte. Es necesario verificar a diario que escucha, comprende y permite actuar a tiempo.
Preguntas frecuentes
¿Qué es un compromise assessment?
Es una evaluación independiente destinada a verificar si una red ha sido comprometida o lo fue en el pasado. Combina inteligencia de amenazas, escaneo de endpoints, revisión de logs, análisis de tráfico y, en caso necesario, forense digital.
¿Por qué las herramientas de seguridad a veces no detectan algunos ataques?
Porque pueden estar mal configuradas, desactualizadas, sin suficiente telemetría o sin análisis humano que revise señales de baja confianza. La operación suele ser la causa principal del problema, no solo la tecnología.
¿Por qué son peligrosos los backups infectados?
Porque pueden restaurar web shells, scripts maliciosos o mecanismos de persistencia, reabriendo la puerta al atacante incluso después de una limpieza inicial.
¿Qué son los LoLBins?
Son binarios o herramientas legítimas del sistema que los atacantes reutilizan para ejecutar acciones maliciosas sin desplegar malware sospechoso.
¿Qué debe revisar una empresa inicialmente?
La salud de los sensores y reglas de detección, la integridad de logs, el inventario de activos, alertas de baja confianza, backups y la revisión y actualización de los playbooks de respuesta según nuevas evidencias.
Fuente: Open Security