Las empresas han comprado más herramientas de ciberseguridad que nunca, pero eso no significa que estén viendo lo que ocurre dentro de sus redes. Un informe de Kaspersky Compromise Assessment, basado en proyectos realizados en 2025, apunta a una brecha incómoda entre tener tecnología desplegada y convertirla en una capacidad real de detección y respuesta.
El dato que mejor resume el problema es este: el 30,8 % de los incidentes descubiertos por el equipo de evaluación de compromisos de Kaspersky llevaban más de tres meses activos en la organización. En los casos de alta severidad, el retraso fue aún más preocupante: el 52 % solo se detectó después de más de 90 días. El incidente más antiguo identificado durante el año había pasado cuatro años sin ser descubierto.
El informe no describe una amenaza nueva, sino una debilidad conocida que muchas organizaciones siguen arrastrando: confiar en que el EDR, el SIEM, el antivirus, el firewall o el proveedor gestionado harán el trabajo por sí solos. La realidad que muestra Kaspersky es menos cómoda. En el 60 % de los incidentes descubiertos, las empresas no habían recibido alertas de alta confianza de sus herramientas. Y el 20 % de los casos se encontró manualmente.
El problema no es solo comprar seguridad, sino operarla
La ciberseguridad empresarial lleva años moviéndose hacia un modelo basado en herramientas avanzadas, automatización, telemetría y servicios gestionados. Ese modelo es necesario, pero tiene una trampa: muchas organizaciones instalan controles y los dejan funcionando en modo “set and forget”, como si la mera presencia de una solución garantizara detección.
Kaspersky señala que las herramientas de monitorización no son autosuficientes. Necesitan configuración continua, ajuste de reglas, validación de telemetría, revisión de falsos positivos, análisis humano de alertas de baja confianza y capacidades de threat hunting. Cuando no existe monitorización 24/7, el 86 % de los incidentes observados acabó en severidad media o alta. Cuando no hay threat hunting, la proporción fue del 84 %.
No es un mensaje nuevo, pero sí aparece respaldado por casos reales. En uno de ellos, una organización había invertido en controles de seguridad y asumía que el entorno estaba protegido. La revisión histórica de logs reveló actividad de Impacket, despliegue de Cobalt Strike y uso de Mimikatz en servidores críticos, incluidos controladores de dominio. La actividad llevaba tres meses sin detectarse porque nadie estaba revisando de forma efectiva la telemetría.
| Hallazgo del informe | Dato |
|---|---|
| Incidentes con más de tres meses de actividad histórica | 30,8 % |
| Compromisos de alta severidad detectados tras más de 90 días | 52 % |
| Incidente más antiguo localizado | 4 años |
| Incidentes descubiertos manualmente | 20 % |
| Incidentes sin alertas de alta confianza | 60 % |
| Web shells encontrados en backups | 40 % |
| Evaluaciones con problemas de comunicación interna | 32 % |
| Casos que exigieron actualizar el plan de respuesta durante la investigación | 39 % |
La lectura es clara: una alerta no investigada, una regla mal ajustada o un sensor que no envía datos pueden convertir una intrusión limitada en una presencia persistente. El informe también advierte de que incluso contar con un MSSP no garantiza madurez. En proyectos con proveedor gestionado, Kaspersky observó incidentes no identificados por baja cobertura de detección y, en aproximadamente la mitad de los casos respaldados por MSSP, carencias básicas de auditoría en Windows, como falta de recogida de eventos o políticas desactivadas.
Backups infectados: cuando la recuperación devuelve al atacante
Uno de los puntos más prácticos del informe afecta a las copias de seguridad. Kaspersky afirma que el 40 % de los web shells descubiertos estaba en backups, no solo en sistemas activos. Esto significa que una organización puede limpiar el servidor visible, cerrar el incidente y, semanas después, restaurar sin saberlo los mismos archivos maliciosos que daban acceso al atacante.
El problema se agrava cuando el inventario de activos no está completo. El informe menciona servidores Linux en cloud que no estaban unidos a Active Directory y escapaban a los escaneos rutinarios. Si un atacante instala una web shell en uno de esos sistemas y ese servidor se copia regularmente, la amenaza puede quedar preservada dentro del proceso de backup. En una restauración posterior, el acceso malicioso vuelve a aparecer.
Este punto debería preocupar a cualquier equipo de sistemas. Las copias de seguridad suelen verse como la última línea de defensa frente a ransomware, borrados accidentales o fallos graves. Pero si no se inspeccionan, también pueden convertirse en un archivo histórico de compromisos. La integridad de backup no debería limitarse a comprobar si la copia se puede restaurar; también debe incluir revisión de contenido, búsqueda de artefactos sospechosos y validación antes de volver a producción.
El informe cita un caso en el que una web shell apareció dentro de un archivo .rar almacenado en un servidor interno de ficheros. La investigación posterior mostró que el material procedía de otro servidor que estaba offline durante la evaluación y que había quedado fuera del inventario visible. Ese tipo de situación explica por qué la respuesta a incidentes no puede limitarse al sistema que disparó la alerta inicial.
LoLBins, herramientas remotas y actividad que parece normal
Los atacantes no siempre necesitan malware exótico. En todos los proyectos de compromiso que terminaron detectando incidentes, Kaspersky encontró herramientas de administración remota no estándar y uso de LoLBins, binarios legítimos del sistema o utilidades comunes que pueden abusarse para moverse lateralmente, persistir o extraer datos.
Aquí está una de las grandes dificultades para los SOC. PsExec, AnyDesk, TeamViewer, VNC, certutil, bitsadmin, regsvr32 o wmic pueden usarse de forma legítima por administradores. También pueden formar parte de una cadena de ataque. Ver que una herramienta se ha ejecutado no basta para declarar un incidente. Hay que saber quién la ejecutó, desde qué equipo, en qué horario, con qué argumentos y si ese comportamiento encaja con la línea base normal de la organización.
El informe recomienda formalizar qué herramientas de administración remota están autorizadas, centralizar sus logs, auditar periódicamente el inventario de software y enriquecer los hashes de binarios ejecutados con categorías funcionales. También propone reglas de detección para patrones conocidos de abuso de LoLBins, pero ajustadas contra la actividad normal de cada entorno para no inundar al equipo con ruido.
Este punto enlaza con un problema más amplio: la fatiga de alertas. Si todo parece sospechoso, nada acaba investigándose bien. Los equipos que solo trabajan por cola de alertas pueden pasar el día descartando señales superficiales y no dedicar tiempo a búsquedas hipótesis-dirigidas, que son las que suelen descubrir persistencia silenciosa.
La respuesta a incidentes debe cambiar durante la investigación
Otro dato relevante del informe es que el 39 % de los proyectos necesitó actualizar el plan de respuesta durante la investigación. No es un fallo del plan inicial; es una característica de los incidentes reales. A medida que aparecen nuevos artefactos, servidores de mando y control, tareas programadas, backdoors, movimientos laterales o evidencias forenses, la estrategia tiene que cambiar.
Kaspersky insiste en que los playbooks deben tratarse como documentos vivos. Una respuesta rígida, basada solo en la primera evidencia, puede contener el síntoma principal y dejar intactas otras vías de persistencia. En un caso citado en el informe, una empresa de tamaño medio contuvo un incidente de alta severidad, pero una evaluación posterior descubrió varias puertas traseras fuera del alcance inicial: un cron que recreaba una web shell, una reverse shell activa, un stealer ClipBanker persistente en registro y un consumidor WMI malicioso.
También aparece una carencia organizativa: el 32 % de las evaluaciones reveló problemas de comunicación interna que afectaron a la respuesta. Confirmaciones poco claras, propietarios de sistemas que tardan en validar acciones, canales potencialmente comprometidos y pérdida de conocimiento por rotación de personal pueden retrasar decisiones críticas.
Por eso los ejercicios de mesa no deberían comprobar solo si el playbook técnico existe. Deben probar si los equipos saben comunicarse, si hay acuerdos operativos claros, si se documentan las acciones, si existen responsables alternativos y si la organización puede actuar cuando el correo o el sistema de tickets no son de confianza.
La IA generativa entra también en el mapa de riesgos
El informe incluye un ejemplo especialmente actual: el uso de herramientas de desarrollo con IA sin políticas claras de tratamiento de datos. Durante un proyecto, 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 información interna confidencial.
El hallazgo no implica que las herramientas de IA para desarrollo sean inseguras por definición. Sí muestra que las empresas están adoptándolas más rápido de lo que crean reglas para usarlas. En entornos con datos sensibles, el uso de asistentes de código, copilotos y agentes locales debe tener políticas claras: qué carpetas pueden leerse, qué datos no deben exponerse, qué proveedores están autorizados, cómo se gestionan logs y qué formación reciben los empleados.
La ciberseguridad ya no puede tratar la IA generativa como una rareza. Forma parte del puesto de trabajo, del desarrollo, de la administración de sistemas y de la productividad diaria. Si no se gobierna, aparecerá como otro punto ciego.
Qué deberían revisar las empresas
El informe de Kaspersky deja varias tareas concretas. La primera es comprobar la salud de los motores de detección: sensores activos, reglas actualizadas, telemetría íntegra, logs críticos habilitados y alertas relevantes. La segunda es crear una capa humana para revisar alertas de baja confianza con una frecuencia definida. Muchas señales no generan incidentes automáticamente, pero sí merecen análisis.
La tercera es combinar monitorización continua con threat hunting. Esperar a que una herramienta levante una alerta perfecta es una mala estrategia cuando los atacantes abusan de herramientas legítimas, credenciales filtradas, tareas programadas o técnicas en memoria. La cuarta es revisar backups e inventario de activos con el mismo rigor que sistemas activos. Lo que no está inventariado no se monitoriza, y lo que no se monitoriza puede estar comprometido durante años.
La quinta es actualizar playbooks y ejercicios. Responder a incidentes no es ejecutar una receta cerrada, sino coordinar evidencias, personas, herramientas y decisiones bajo presión. Los planes deben cambiar conforme aparece información nueva.
La idea de fondo es sencilla: la seguridad no es un producto comprado, sino una función viva. Las empresas que solo compran herramientas acumulan paneles. Las que las operan, las ajustan y las cuestionan cada semana reducen tiempo de permanencia del atacante. Y en ciberseguridad, el tiempo es muchas veces la diferencia entre una alerta contenida y una crisis.
Preguntas frecuentes
¿Qué es una evaluación de compromiso?
Es una revisión independiente para determinar si una red está o ha estado comprometida. Combina análisis de inteligencia, escaneo de endpoints, revisión de logs, tráfico de red y, cuando es necesario, investigación forense.
¿Por qué una empresa puede tardar meses en detectar un incidente?
Por falta de monitorización continua, alertas mal configuradas, ausencia de threat hunting, telemetría incompleta, logs no revisados y exceso de confianza en herramientas instaladas pero no operadas.
¿Qué riesgo tienen los backups en una intrusión?
Pueden conservar web shells, scripts maliciosos o archivos de persistencia. Si se restauran sin inspección, la empresa puede reintroducir al atacante después de la respuesta inicial.
¿Qué son los LoLBins?
Son binarios legítimos del sistema o utilidades comunes que los atacantes reutilizan para ejecutar comandos, moverse lateralmente, persistir o extraer datos sin desplegar malware evidente.
¿Qué debería hacer una organización en los próximos 30 días?
Revisar la salud de sus motores de detección, validar telemetría, comprobar reglas críticas, revisar alertas de baja confianza, verificar backups, confirmar inventario de activos y probar su playbook de respuesta.
vía: kaspersky
