Las empresas han llenado sus redes de herramientas de seguridad, pero muchas siguen sin detectar a tiempo lo que ocurre dentro. EDR, SIEM, firewalls, EPP, proveedores gestionados y alertas automáticas no garantizan visibilidad si nadie comprueba que la telemetría llega, que las reglas siguen siendo útiles 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, pone cifras a ese problema. El 30,8 % de los incidentes descubiertos tenía actividad histórica de más de tres meses y el 52 % de los compromisos de alta severidad solo fue identificado después de más de 90 días sin detectar. El caso más antiguo localizado llevaba cuatro años oculto en la red de una organización.

La lectura para equipos de tecnología y seguridad es clara: la brecha no siempre está en la ausencia de herramientas, sino en la forma de operarlas. Según el informe, el 20 % de los incidentes descubiertos se encontró manualmente y el 60 % había pasado desapercibido porque las herramientas existentes no generaron alertas de alta confianza. Kaspersky describe así una debilidad habitual en muchas organizaciones: controles instalados, pero mal ajustados, poco vigilados o sin una rutina de revisión continua.

La seguridad comprada no equivale a seguridad operada

Durante años, muchas organizaciones han medido su postura defensiva por el inventario de soluciones desplegadas. Tener EDR en los endpoints, SIEM centralizado, logs reenviados, antivirus de nueva generación o un MSSP contratado parecía suficiente para reducir el riesgo. 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 había threat hunting estructurado, esa proporción fue del 84 %. La diferencia entre ver y no ver no depende solo de la herramienta, sino de que exista un equipo, interno o externo, que valide alertas, revise señales de baja confianza, contraste patrones y busque actividad anómala de forma proactiva.

Un caso citado en el informe ilustra bien el problema. Una empresa había invertido en controles de seguridad y asumia que su entorno estaba protegido. La revisión histórica de logs encontró 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 porque no existía una monitorización 24/7 efectiva.

Problema detectado	Impacto operativo
Alertas sin validación humana	Señales débiles que nunca llegan a investigarse
EDR/EPP mal configurado	Sensores presentes, pero sin detección útil
Sin 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 al primer síntoma del ataque
Comunicación deficiente	Retrasos en confirmaciones, escalados y decisiones

El informe también matiza el papel de los servicios gestionados. Contar con un MSSP puede mejorar la capacidad defensiva, pero no elimina la necesidad de gobierno interno. En proyectos con proveedor gestionado, Kaspersky observó incidentes no identificados por baja cobertura de detección y carencias básicas en auditoría de Windows, como eventos no recogidos o políticas de auditoría desactivadas. La externalización ayuda si hay expectativas, métricas y responsabilidades claras; no si se usa como sustituto de la propiedad interna de la seguridad.

Backups, inventario y persistencia: las zonas que menos se miran

Uno de los hallazgos más prácticos afecta a las copias de seguridad. El 40 % de las web shells descubiertas por Kaspersky estaba almacenado en backups. Esto significa que una organización puede limpiar un servidor, cerrar una incidencia y volver a introducir la puerta trasera al restaurar una copia aparentemente válida.

La copia de seguridad suele tratarse como una garantía de recuperación, pero en una intrusión también puede actuar como cápsula de conservación del malware. Si los backups no se escanean, no se comparan con líneas base y no se validan antes de restaurar, pueden mantener vivo un acceso que el equipo de respuesta creía haber eliminado.

El problema empeora con inventarios incompletos. Kaspersky observó brechas de inventario en el 25 % de los trabajos, con servidores Linux en cloud que no estaban unidos a Active Directory y quedaban fuera de escaneos rutinarios. Un atacante puede instalar una web shell en un activo de ese tipo y permanecer mucho tiempo sin ser visto, especialmente si el servidor se respalda de forma automática pero no se incluye en las herramientas habituales de seguridad.

En otro caso, una web shell apareció dentro de un archivo comprimido .rar almacenado en un servidor interno de ficheros. Procedía de un servidor que estaba desconectado durante la evaluación y que no había sido incluido correctamente en el inventario. La investigación posterior reveló una puerta trasera extendida en varios servidores Windows mediante cambios en la contraseña del administrador local.

LoLBins y herramientas remotas: el ruido que tapa al atacante

El informe insiste en 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, binarios o herramientas del propio sistema que pueden usarse tanto para tareas administrativas como para movimiento lateral, persistencia o exfiltración.

Aquí no sirve una regla simple. PsExec, AnyDesk, TeamViewer, VNC, certutil, bitsadmin, regsvr32 o wmic pueden ser perfectamente legítimos. También pueden ser parte de una intrusión. La diferencia está en el contexto: quién ejecuta la herramienta, desde qué endpoint, en qué horario, con qué argumentos, contra qué destino y si ese uso forma parte de la actividad normal de la organización.

Kaspersky recomienda políticas explícitas sobre herramientas de administración remota, reenvío de logs a una plataforma central, auditorías de software, enriquecimiento de hashes ejecutados con categorías funcionales y reglas para patrones habituales de abuso de LoLBins. La clave no está en bloquear por defecto todo lo que parezca sospechoso, sino en crear una línea base realista y detectar desviaciones.

Ese trabajo es menos vistoso que comprar otra consola, pero suele marcar la diferencia. Cuando los analistas no conocen el uso normal del entorno, cada alerta se convierte en una discusión. Cuando sí existe una línea base, la investigación puede centrarse en lo que se sale del patrón.

Responder a un incidente no es seguir una receta cerrada

Kaspersky también describe una brecha en la respuesta a incidentes. El 39 % de los compromisos evaluados exigió actualizar el plan de respuesta a mitad de la investigación, y el 59 % requirió recogida y análisis de paquetes forenses. La razón es sencilla: los incidentes reales cambian a medida que aparecen nuevas evidencias.

Una organización puede contener el primer servidor afectado y aun así dejar persistencia en otros sistemas. El informe cita un caso en el que, tras una respuesta inicial eficaz, la evaluación posterior encontró varias puertas traseras fuera del alcance original: un cron que recreaba una web shell, una reverse shell activa, persistencia mediante registro de Windows y un consumidor WMI malicioso.

La respuesta a incidentes debe funcionar como un proceso vivo. Cada nuevo artefacto puede cambiar prioridades, alcance y secuencia de erradicación. Si el playbook se ejecuta como una lista fija, puede parar el sangrado visible y dejar intactas otras vías de entrada.

También pesa la comunicación. El 32 % de los proyectos analizados mostró problemas internos que afectaron a la respuesta: confirmaciones poco claras, validaciones lentas por parte de propietarios de sistemas, canales potencialmente comprometidos o pérdida de conocimiento por rotación de personal. En un incidente serio, la técnica importa, pero la coordinación decide buena parte del resultado.

La IA generativa ya es parte del riesgo corporativo

El informe incorpora un ejemplo que conecta directamente con las nuevas formas de trabajo. En una evaluación, Kaspersky identificó una estación macOS que ejecutaba Claude Code como extensión de VS Code. La herramienta capturaba snapshots del sistema de archivos para enriquecer prompts, incluyendo listados de directorios y rutas absolutas a libros Excel con datos confidenciales internos.

No es una acusación general contra los asistentes de desarrollo con IA. Es una advertencia sobre adopción sin política. Las herramientas de IA ya están en el puesto de trabajo, en desarrollo, en administración de sistemas y en tareas de productividad. Si una empresa no define qué datos pueden exponerse, qué proveedores están autorizados, qué carpetas se excluyen y qué controles se aplican, la IA acaba funcionando como otra zona de sombra.

Para equipos de seguridad, esto implica ampliar la mirada. La superficie de riesgo ya no está solo en endpoints, correo, identidad, cloud y aplicaciones web. También está en extensiones, asistentes de código, agentes locales, prompts, snapshots, conectores y automatizaciones que pueden tocar datos internos sin pasar por los controles tradicionales.

Qué deberían hacer los equipos de tecnología y seguridad

El informe deja una recomendación de fondo: tratar la detección como una función viva, no como una compra. Eso empieza por una revisión de 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ñal no debe interpretarse como ausencia de ataque hasta haber validado que el sistema realmente puede ver.

Después llega la parte operativa: revisar alertas de baja confianza, crear una cadencia de threat hunting, establecer líneas base para herramientas remotas y LoLBins, auditar inventario de activos, comprobar backups antes de restaurar y actualizar playbooks según nuevas evidencias.

También conviene reforzar capacidades internas de forense digital y análisis de malware. Kaspersky observa que las organizaciones capaces de analizar artefactos forenses por sí mismas tuvieron menos incidentes de alta severidad, y que la presencia de recursos de ingeniería inversa se correlacionó con una menor gravedad en la muestra analizada.

La conclusión no es que todas las empresas deban hacerlo todo dentro. Es que incluso cuando se delega, alguien debe gobernar. Seguridad no es instalar una herramienta y esperar a que grite. Es comprobar cada día que escucha, entiende y permite actuar a tiempo.

Preguntas frecuentes

¿Qué es un compromise assessment?
Es una evaluación independiente para comprobar si una red está comprometida o lo ha estado. Combina inteligencia de amenazas, escaneo de endpoints, revisión de logs, análisis de tráfico y, si hace falta, forense digital.

¿Por qué las herramientas de seguridad no detectan algunos ataques?
Porque pueden estar mal configuradas, desactualizadas, sin telemetría suficiente o sin analistas que revisen señales de baja confianza. El problema suele estar en la operación, no solo en la tecnología.

¿Por qué son peligrosos los backups infectados?
Porque pueden restaurar web shells, scripts maliciosos o mecanismos de persistencia después de una limpieza inicial, reabriendo la puerta al atacante.

¿Qué son los LoLBins?
Son binarios legítimos del sistema o herramientas comunes que los atacantes reutilizan para ejecutar acciones maliciosas sin desplegar malware evidente.

¿Qué debería revisar una empresa primero?
La salud de sensores y reglas, la integridad de logs, el inventario de activos, la revisión de alertas de baja confianza, la inspección de backups y la actualización real de sus playbooks de respuesta.

Fuente: Open Security