Incidentes no detectados, amenazas persistentes y problemas de respuesta: análisis de los proyectos de Kaspersky Compromise Assessment

En este artículo presentamos los hallazgos clave obtenidos a partir de los proyectos de Kaspersky Compromise Assessment realizados en 2025. Kaspersky Compromise Assessment es un servicio experto e independiente para detectar indicios de compromiso en las redes de las organizaciones. Como parte del servicio, analiza datos sobre amenazas (incluida información de diversas fuentes en la dark web), escanea endpoints con herramientas especializadas y realiza un análisis integral de registros de eventos de seguridad y tráfico de red. Cuando es necesario, también lleva a cabo la respuesta inicial a incidentes y el análisis forense.

El informe destaca incidentes que permanecieron sin detectar durante semanas, meses e incluso años.

Tendencias clave identificadas en los proyectos finalizados de Kaspersky Compromise Assessment

• La búsqueda de indicios de compromiso (compromise assessment) permite reducir la cantidad de incidentes de alta criticidad que pasan inadvertidos. Detectamos la mayor proporción de incidentes de alta criticidad en organizaciones que solicitaron este servicio tras contener un incidente de seguridad conocido. La menor proporción de incidentes de alta criticidad se observó en organizaciones que realizaban auditorías de seguridad de forma periódica. De todos los incidentes analizados, el 20% se detectó de forma manual. Cerca del 60% de las amenazas no fueron detectadas por las organizaciones debido a la falta de alertas fiables de las herramientas de protección existentes.
• Casi un tercio de los incidentes registrados se detectó más de tres meses después de la intrusión inicial. Cuanto más tiempo mantenía presencia la amenaza en el entorno objetivo, mayor era la probabilidad de que el incidente tuviera un nivel de criticidad alto. En el 30.8% de los csasos se hallaron indicios de actividad de los atacantes con una duración superior a tres meses, y entre las infecciones de alta criticidad esta proporción llegó al 52%. El incidente más antiguo detectado por nosotros en 2025 había permanecido sin detectar durante cuatro años.
• Es frecuente que los archivos maliciosos persistan en las copias de seguridad y se restauren tras aplicar las medidas de respuesta al incidente. Detectamos el 40% de los web shells en copias de seguridad, donde permanecieron sin detectar hasta que se realizó una búsqueda de indicios de compromiso completa.
• Los atacantes prefieren herramientas de administración remota y programas legítimos ya instalados (LOLBins). Este tipo de herramientas se utilizó en todos los incidentes detectados a raíz de la búsqueda de indicios de compromiso.
• Disponer de herramientas de monitoreo y protección no basta por sí solo; la madurez de los procesos operativos es el factor decisivo. Las soluciones de monitoreo deben configurarse de forma correcta y adaptarse al panorama de amenazas, que cambia con frecuencia. Además, los analistas deben revisar las alertas con un nivel de confianza bajo. La falta de monitoreo continuo y de búsqueda activa de amenazas aumentaba la probabilidad de incidentes de criticidad media y alta hasta el 84-86%. Al mismo tiempo, los incidentes de alta criticidad se presentaban con menor frecuencia en las organizaciones cuyos equipos contaban con habilidades de ingeniería inversa de malware.
• Los problemas de comunicación derivan en incidentes no detectados. Casi un tercio de las evaluaciones de compromiso reveló problemas de comunicación que afectaron la eficacia de la respuesta a incidentes.
• Los playbooks de respuesta a incidentes deben ser flexibles. Para que la respuesta sea eficaz, es necesario revisar los playbooks de forma periódica a medida que aparecen nuevos artefactos. Las organizaciones reducen la probabilidad de pasar por alto amenazas si actualizan con frecuencia el plan de respuesta a incidentes.

Sobre el funcionamiento del servicio Kaspersky Compromise Assessment

Nuestro servicio de búsqueda de indicios de compromiso es utilizado por empresas de distintos países. Alrededor del 71% de los incidentes detectados en 2025 correspondió a clientes de la región META (Medio Oriente, Turquía y África); el 29% restante correspondió a la región de Asia-Pacífico y la Comunidad de Estados Independientes (CEI).

Distribución geográfica de los incidentes detectados en 2025 en el marco de los proyectos de búsqueda de indicios de compromiso (descargar)

 

Nos contactaron organizaciones de diversos sectores económicos. El sector gubernamental concentró el 29% de los incidentes, seguido del sector educativo (19%) y el sector financiero (17%).

Distribución de los incidentes detectados en 2025 en el marco de los proyectos de búsqueda de indicios de compromiso, por sector económico (descargar)

Categorías de indicadores de ataque

El servicio Kaspersky Compromise Assessment se basa en un catálogo de indicadores de ataque (IoA) que se actualiza de forma constante. Dado que la lista completa de IoA es demasiado detallada para un informe general, la agrupamos en un conjunto limitado de familias según sus lógicas de detección. Las estadísticas indican que tres familias predominan entre los incidentes:

• credenciales extraídas de volcados (dumps): 12.4% de todos los incidentes;
• utilidades LOLBin específicas: 11.2%;
• familias específicas de malware: 11.2%.

Estas tres familias son indicadores de ataque fiables y de alta precisión para detectar el compromiso de la infraestructura, desde amenazas de archivos “inactivas” hasta ataques multietapa con persistencia en el sistema.

Distribución de las familias de lógicas de detección (descargar)

Motivos de las solicitudes al servicio Kaspersky Compromise Assessment

El análisis de los proyectos de búsqueda de indicios de compromiso de 2025 reveló una correlación clara entre los motivos declarados para solicitar nuestros servicios y el perfil de riesgos identificado. Con mayor frecuencia, las organizaciones contratan el servicio en el marco de una auditoría planificada (56%), seguida de la preparación de informes para reguladores (19%), la auditoría posterior a un incidente de seguridad (17%) y la adquisición de una nueva empresa (9%).

Estadísticas sobre los motivos de las solicitudes al servicio de búsqueda de indicios de compromiso (descargar)

Al comparar los motivos de la solicitud con el nivel de criticidad de los incidentes detectados, se observa que la mayor proporción de incidentes de alta criticidad (40.7%) corresponde a las organizaciones que solicitaron el servicio después de un incidente. A continuación, detallamos este análisis.

Distribución de incidentes por nivel de criticidad según el motivo de la solicitud
		Criticidad del incidente (%)
		Alta	Media	Baja
Motivo de la solicitud	Adquisición de una nueva empresa	28.6	42.8	28.6
	Auditoría planificada	27.7	36.7	35.6
	Preparación de informes para reguladores	30	46.7	23.3
	Auditoría posterior a un incidente de seguridad	40.7	25.9	33.4

Las empresas que se enfrentan a incidentes suelen contactarnos después de haber aplicado las medidas de respuesta iniciales. La mayor proporción de incidentes de alta criticidad detectados indica que las medidas de respuesta, que suelen enfocarse en contener las consecuencias de un incidente conocido, no ofrecen una visión completa del estado de la infraestructura. Como resultado, las amenazas pueden permanecer sin detectar después de dichas medidas hasta que se realiza una búsqueda de indicios de compromiso a gran escala.

En los casos de fusiones y adquisiciones, se nos solicita evaluar la red de la organización adquirida en busca de amenazas ocultas antes de unificar ambos entornos. En estos casos, el perfil de riesgo es mixto: el 28.6% de los hallazgos corresponde a incidentes de baja criticidad, el 42.8% a incidentes de criticidad media y el 28.6% a incidentes de alta criticidad. Esto indica un carácter mixto de los riesgos en la infraestructura de las empresas adquiridas, que suelen revisarse tanto en busca de vulnerabilidades conocidas como de actividad maliciosa oculta. Otras categorías de solicitudes preventivas, como las auditorías planificadas y la preparación periódica de informes para reguladores, muestran una distribución similar, lo que indica que la búsqueda regular de indicios de compromiso ayuda a detectar problemas graves en etapas tempranas del ciclo de vida del ataque, reduciendo la probabilidad de que evolucionen hacia incidentes de alta criticidad.

La mayor proporción de incidentes de baja criticidad (36%) y la menor proporción de incidentes de alta criticidad (28%) se observaron en organizaciones que realizaban auditorías de forma periódica. Con un grado razonable de certeza, concluimos que la búsqueda proactiva y regular de indicios de compromiso reduce con mayor eficacia la probabilidad de incidentes críticos, en comparación con una búsqueda reactiva realizada después de que ocurren los incidentes. Las estadísticas de 2025 respaldan nuestra hipótesis. Esto significa que integrar en los procesos de gestión una búsqueda regular de indicios de compromiso, realizada por expertos independientes, puede reducir la probabilidad de incidentes inesperados de alta criticidad y disminuir el nivel general de riesgo.

Para ilustrar las diferencias entre los enfoques reactivos y proactivos, veamos el siguiente ejemplo de nuestra práctica, en el que una amenaza persistente permaneció “inactiva” en la red del cliente y solo se detectó durante una búsqueda integral de indicios de compromiso realizada después de aplicar las medidas de respuesta iniciales.

Caso práctico: una amenaza “inactiva” detectada solo mediante la búsqueda de indicios de compromiso

Una empresa mediana sufrió un incidente de alta criticidad. El equipo interno de respuesta logró contener y remediar la amenaza en la medida en que se conocía a partir de la alerta inicial. Tras contener el incidente, la organización decidió confirmar que no existieran focos adicionales de compromiso en la red. Para ello, contrató a los especialistas de Kaspersky Compromise Assessment, quienes realizaron un análisis forense a gran escala de la infraestructura que superó el alcance del incidente inicial.

Nuestros expertos recopilaron metadatos forenses, registros de eventos de seguridad y datos de configuración de Active Directory de toda la infraestructura. Tras consolidar la telemetría obtenida, realizaron una búsqueda de amenazas en estos datos mediante diversas consultas centradas en indicios de persistencia, propagación en la red y actividad anómala de procesos. Como resultado, se identificaron y documentaron varias amenazas graves, entre ellas los siguientes mecanismos de persistencia en el sistema:

1. Tarea cron que descarga un web shell
   En un servidor web Linux de importancia crítica se detectó una tarea cron que descargaba de forma automática una copia de un web shell en PHP desde un repositorio público de GitHub y la colocaba en un directorio accesible desde internet. Incluso si el personal de seguridad eliminaba el archivo, la tarea cron volvía a descargarlo de la red, lo que proporcionaba a los atacantes un mecanismo de persistencia estable en el servidor web y la posibilidad de ejecución remota de código.
   
2. Reverse shell activo
   En el servidor donde se alojaba la aplicación web, se detectó en la lista de procesos un reverse shell activo implementado mediante bash.
   
   Se ejecutaba con el usuario apache, la misma cuenta con la que se ejecutaba la aplicación web. Es probable que el atacante haya aprovechado alguna vulnerabilidad de la aplicación web para obtener ejecución remota de código y establecer un canal de control confiable que evadía el firewall, ya que la conexión se iniciaba desde dentro de la red.
3. Stealer ClipBanker con persistencia mediante el registro de Windows
   En la estación de trabajo de un usuario se detectó una variante del stealer ClipBanker que se mantenía en el sistema mediante la clave de registro HKU\S-1-5-21-[OCULTO]-500\Software\Microsoft\Windows\CurrentVersion\Run\9Er6IIp.
   
   Antes de establecer la persistencia, la carpeta con el malware se agregó a las exclusiones de Windows Defender, y al archivo se le aplicaron los atributos “oculto” y “de sistema” para que no llamara la atención de los usuarios comunes.
   
4. Consumidor de eventos WMI malicioso con alias engañoso
   También se detectó un consumidor de eventos WMI malicioso que descargaba y ejecutaba un script de PowerShell. Este consumidor crea el alias kaspersky para el comando Invoke-Expression, con el fin de disfrazar su actividad como legítima y reducir la probabilidad de detección en un análisis superficial. El script descargado (que ahora se encuentra inaccesible), según confirmaron los especialistas de Kaspersky Threat Intelligence, era una carga útil encargada de propagar aún más la infección.
   

Las medidas de respuesta se centraron en contener de forma rápida y eficaz el incidente concreto que había activado la alerta. Sin embargo, la búsqueda de indicios de compromiso a mayor escala reveló múltiples backdoors en el entorno, cada uno con su propia técnica de persistencia: tareas cron, ejecución programada mediante el registro y suscripciones WMI. Los hosts infectados no estaban cubiertos por la respuesta inicial, por lo que las amenazas asociadas a ellos permanecieron sin detectar hasta que se realizó un análisis a gran escala.

La prioridad de los especialistas en respuesta a incidentes es eliminar lo antes posible la amenaza evidente para continuar operando el negocio tras el incidente. La búsqueda de indicios de compromiso, por su parte, es una verificación integral que permite identificar incluso los indicios de infección ocultos y menos evidentes, dondequiera que se encuentren. Cuando la respuesta oportuna se complementa con una búsqueda regular de indicios de compromiso en toda la red, la organización logra tanto la contención reactiva de incidentes como la eliminación proactiva de indicios ocultos de actividad maliciosa. El análisis realizado permitió detectar plataformas de ataque adicionales, aumentar la visibilidad de la infraestructura y reducir la probabilidad de que se repita el incidente.

Incidentes antiguos no detectados

Muchos incidentes permanecen sin detectar durante períodos prolongados, como lo demuestran las estadísticas del tiempo medio de detección (MTTD) de los incidentes en los proyectos de búsqueda de indicios de compromiso. Por ejemplo, en 2025 detectamos un incidente cuya antigüedad era de alrededor de cuatro años.

En el 30.8% de los casos, los indicios de compromiso abarcaban un período superior a tres meses. Un tiempo de detección tan prolongado puede tener consecuencias graves para la organización. Además, los incidentes pueden tener distinta naturaleza: desde amenazas de archivos “inactivas” hasta compromisos persistentes, lo que subraya la necesidad de contar con mecanismos sólidos de detección y respuesta.

Distribución de incidentes por criticidad en función del MTTD (descargar)

Para analizar la relación entre el retraso en la detección y la criticidad de los incidentes, agrupamos los resultados según el MTTD.

• En el caso de los incidentes detectados durante el primer mes, el nivel de criticidad se distribuye de forma relativamente uniforme entre las categorías baja, media y alta.
• A medida que aumenta el MTTD, se observa un desplazamiento hacia una criticidad más alta. Cabe destacar que la gran mayoría de los incidentes detectados entre 30 y 60 días después del compromiso corresponde a la categoría de criticidad media (78.57%), mientras que los incidentes con un tiempo de detección de entre 60 y 90 días son en su mayoría, de alta criticidad (71.43%).
• Entre los incidentes detectados después de más de 90 días, los casos de alta criticidad también representan una proporción significativa (52%).

En general, el 52% de todos los incidentes de alta criticidad se detecta solo después de 90 días de presencia sin detectar. El riesgo es evidente: cuanto más se demora la detección, mayor es la probabilidad de un compromiso más grave. Las organizaciones que implementan detección continua, prácticas de búsqueda activa de amenazas y una búsqueda regular de indicios de compromiso pueden reducir el MTTD, limitar la escalada de los ataques y disminuir el nivel general de riesgo.

El siguiente ejemplo de nuestra práctica destaca la importancia de la detección y la respuesta oportunas para evitar que un incidente escale a la categoría de alta criticidad.

Caso práctico: cuatro años de minería de criptomonedas oculta en controladores de dominio

En mayo de 2025, los expertos en búsqueda de indicios de compromiso detectaron que tres controladores de dominio en la red del cliente estaban infectados con archivos maliciosos que habían permanecido sin detectar durante casi cuatro años. Los archivos maliciosos estaban ocultos en la carpeta C:\Windows\Fonts\Mysql, en la que los usuarios comunes solo ven archivos de fuentes. Allí se encontraron archivos con los nombres nei.bat, dl1host.exe, bat.bat y cmd.bat, así como un svchost.exe falsificado, creados en junio y julio de 2021.

Según los datos de Kaspersky Threat Intelligence, estos archivos están vinculados a una campaña de minería oculta de criptomonedas llamada NSABuffMiner. El malware correspondiente se propaga a través del protocolo SMB mediante la explotación de la vulnerabilidad EternalBlue (MS17-010). El parche para esta vulnerabilidad se publicó cuatro años antes del compromiso inicial (en marzo de 2017), es decir, hubo tiempo más que suficiente para actualizar los sistemas. Este caso subraya la importancia de contar con procesos de gestión de parches bien establecidos y de monitorear los flujos de datos de amenazas.

A solicitud del cliente, los archivos maliciosos se recopilaron junto con una imagen del sistema para su posterior análisis forense, que reveló lo siguiente:

• Los archivos bat.bat y cmd.bat generan direcciones IP aleatorias y las escanean con un escáner de puertos ligero, renombrado como taskhost.exe, para identificar hosts activos y vulnerables con el puerto SMB 445 y el puerto NetBIOS 139 abiertos.
• Las direcciones IP vulnerables detectadas se transmiten a los scripts auxiliares poad.bat, poab.bat, load.bat y loab.bat, que ejecutan los componentes maliciosos mance.exe, Eter.exe y puls.exe. Estos componentes inyectan las bibliotecas DLL maliciosas Eternalblue2.dll y Doublepulsar2.dll en los procesos lsass.exe y explorer.exe para implementar el mecanismo de propagación posterior.
• A continuación, para lograr persistencia en el sistema, se crean tareas programadas que ejecutan los scripts de propagación e infección, además de servicios que inician el criptominero. Estas tareas y servicios se denominan MicrosoftMysql, MicrosoftFonts y MicrosoftMSSql. En el programador también se encontraron tareas con los nombres At1 y At2, creadas con el mismo propósito.
• Tras el compromiso exitoso y la instalación de los mecanismos de persistencia, se ejecuta un procedimiento de limpieza: se eliminan del disco los archivos temporales y los archivos de los componentes maliciosos.

Debido a la falta de procedimientos adecuados de monitoreo y búsqueda de amenazas, la organización no sabía que, durante cuatro años, los atacantes habían estado minando criptomonedas en sus controladores de dominio.

Preservación involuntaria de componentes maliciosos

Durante la búsqueda de indicios de compromiso, con frecuencia nos encontramos con situaciones en las que los web shells permanecen en los sistemas o se restauran en la infraestructura objetivo. Según los datos de las solicitudes al servicio Compromise Assessment en 2025, el 64% de los incidentes con web shells se clasificó como de alta criticidad, el 7% como de baja criticidad (en este caso existe la posibilidad de compromiso, pero los archivos hallados también podrían ser legítimos) y el 29% como de criticidad media (en este caso, los archivos deben eliminarse).

Distribución de incidentes con web shells por nivel de criticidad (descargar)

Una de las formas en que los web shells persisten en el sistema es la infección de las copias de respaldo. Según las estadísticas de los incidentes detectados en nuestros proyectos, el 60% de los web shells se encontró en sistemas activos y el 40% en copias de respaldo. Las copias de seguridad pueden provocar que los sistemas vuelvan a comprometerse mucho tiempo después de la infección inicial.

Ubicación de los web shells (descargar)

Otro problema frecuente son las deficiencias en el inventario de activos, observadas en el 25% de los casos. Se trata de sistemas no registrados, entre ellos servidores Linux en la nube no integrados a Active Directory, que son invisibles para los mecanismos de escaneo estándar.

Problemas con el inventario de activos (descargar)

Los atacantes pueden implantar web shells en servidores en la nube que no figuran en los inventarios, pero de los cuales se hacen copias de respaldo con regularidad. Como resultado, el web shell puede permanecer en dicho servidor durante mucho tiempo, y aunque en algún momento se elimine, el servidor de copias de respaldo restaurará más tarde los archivos infectados, con lo cual el web shell volverá a estar accesible desde el exterior. Esto demuestra que, sin un inventario de activos completo y actualizado, las capacidades de detección y respuesta se ven muy limitadas.

En uno de los casos, el web shell estaba oculto en un servidor de archivos interno (no un servidor web) dentro de un archivo RAR, en la siguiente ruta: D:\backup\[OCULTO].rar/wwwroot/<…>/[OCULTO].aspx.

Durante la investigación, los administradores del servidor informaron que la carpeta se había copiado desde un servidor web que estaba apagado en el momento de la búsqueda de indicios de compromiso. Debido a un inventario de activos incompleto, el equipo interno de seguridad no detectó el compromiso del servidor web, y tras la ejecución de los procedimientos de copia de respaldo, el web shell terminó en el servidor de archivos interno. El análisis forense del servidor web apagado mostró que los atacantes habían logrado implantar un backdoor en la mayoría de los servidores Windows de la infraestructura, configurando en ellos cuentas de administrador local con la misma contraseña.

Durante el ataque, los atacantes ejecutaron mediante PsExec, en todos los servidores enumerados en un archivo TXT, un script CMD que cambiaba la contraseña de la cuenta de administrador local por el valor indicado en el script:

Legítimas, pero sospechosas: herramientas de administración remota y utilidades LoLBin

En 2025, en todos los proyectos de búsqueda de indicios de compromiso detectamos el uso de herramientas de administración remota no estándar. Asimismo, en cada proyecto estaban presentes archivos ejecutables legítimos que pueden emplearse con fines maliciosos (living-off-the-land binaries, LoLBins). La presencia de ambos elementos complica la tarea de detección para los centros de monitoreo y respuesta (SOC), que deben distinguir entre la administración legítima y la actividad maliciosa.

Entre las herramientas de administración remota se identificaron diversas plataformas propietarias, como TeamViewer y AnyDesk, así como soluciones de distribución gratuita, entre ellas PsExec, servidores VNC y frameworks de código abierto. En muchos entornos, este tipo de archivos ejecutables se emplea a diario para la resolución de problemas, el despliegue de software y la asistencia remota. Sin embargo, esas mismas acciones (crear nuevas cuentas administrativas locales, copiar archivos a recursos remotos, ejecutar escaneos de puertos de red) también son realizadas por los atacantes tras el compromiso. Nuestros analistas se encuentran a menudo con situaciones en las que las acciones legítimas de los administradores de sistemas son indistinguibles de los intentos de movimiento lateral en la infraestructura, por lo que el simple hecho de usar una herramienta de acceso remoto no basta para vincular esa actividad con un incidente. En estos casos, el comportamiento debe evaluarse frente al perfil base de uso de la herramienta en la organización en cuestión. Elaborar ese perfil requiere una comprensión contextual profunda de quién está autorizado a usar la herramienta, desde qué endpoints y bajo qué condiciones. Elaborar el perfil base de uso de cada herramienta es un proceso laborioso que requiere un enfoque personalizado.

Las utilidades LoLBin integradas en el sistema operativo o instaladas con frecuencia por los usuarios, como certutil, bitsadmin, regsvr32 y wmic, también aparecieron de forma habitual en incidentes de todos los proyectos. Aunque se trata de componentes de sistema confiables, según nuestros datos de inteligencia de amenazas, con frecuencia son utilizados por los atacantes para la propagación posterior, la exfiltración de datos y la persistencia en el sistema. La distribución por criticidad de los incidentes en los que se emplearon programas no deseados (riskware) o utilidades LoLBin se muestra en el siguiente gráfico. La proporción relativamente alta de incidentes de criticidad media (40%) y alta (31%) pone de relieve que el uso de utilidades legítimas suele ser un vector clave que permite a los atacantes ampliar el ataque más allá del punto de apoyo inicial.

Distribución por criticidad de los incidentes en los que se utilizó software no deseado o legítimo en 2025 (descargar)

Para detectar el posible uso de utilidades LoLBin y herramientas de administración remota por parte de los atacantes, recomendamos aplicar un enfoque multinivel, mucho más eficaz que las listas estáticas de aplicaciones bloqueadas:

1. Elabore una política que enumere las herramientas de administración remota autorizadas. Conviene aplicarla junto con el requisito de enviar los registros de funcionamiento de dichos programas a un sistema centralizado de gestión de eventos de seguridad (SIEM o un agregador de logs dedicado). El monitoreo continuo de estos datos permite al SOC detectar desviaciones respecto de los perfiles estándar de uso autorizado.
2. Realice inventarios periódicos del software para identificar herramientas de administración remota no autorizadas. En la medida de lo posible, recopile datos de las siguientes claves de registro en todos los hosts:
   • HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall
   • HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
   • HKEY_USERS\*\Software\Microsoft\Windows\CurrentVersion\Uninstall
   • HKEY_USERS\*\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
3. Enriquezca los hashes (MD5/SHA-256) de cada archivo ejecutable con una categoría funcional, como “Acceso remoto”, “Imagen de referencia” o “Software de protección”. Correlacionar la categoría con la ruta de ejecución permite detectar los casos en que un ejecutable se inicia desde una ubicación atípica, por ejemplo, un programa de la categoría “Acceso remoto” ejecutado desde %TEMP% o la carpeta de descargas del usuario.
4. Implemente reglas de detección basadas en patrones conocidos de abuso de utilidades LoLBin, como certutil -decode, bitsadmin -transfer, regsvr32 -i <dll> y wmic process call create. Estas reglas deben compararse siempre con un perfil base que describa la actividad normal de la utilidad en la organización y que se construya a partir de un período de uso legítimo verificado. Cuando surgen nuevos casos de uso legítimo, el perfil base debe actualizarse. Las alertas deben generarse solo cuando el comportamiento observado se desvía de la norma establecida, lo que reduce el ruido en las alertas sin perder sensibilidad ante amenazas reales.

Falta de monitoreo continuo y de búsqueda proactiva de amenazas

El análisis de proyectos recientes de búsqueda de indicios de compromiso reveló un punto ciego sistemático en las organizaciones que estructuran su protección bajo el principio de “comprar y olvidar”. Cuando no existe un monitoreo continuo por parte de especialistas ni un programa dedicado de búsqueda de amenazas, el nivel de criticidad de los incidentes detectados se desplaza con claridad hacia valores más altos:

Distribución de incidentes por nivel de criticidad en ausencia de monitoreo continuo o búsqueda activa de amenazas
Características del sistema de seguridad	Baja criticidad	Criticidad media/alta
Sin monitoreo continuo	14%	86%
Sin búsqueda activa de amenazas	16%	84%

A menudo, el problema no radica en la falta de herramientas, sino en su uso ineficiente. Muchas organizaciones implementan soluciones de seguridad modernas, pero las operan bajo un esquema de “configurar y olvidar” o estructuran sus procesos en torno a la respuesta a alertas. Estas organizaciones suelen presentar los siguientes problemas:

• Fatiga por alertas: una alta tasa de falsos positivos reduce la atención de los analistas, lo que los obliga a clasificar los eventos por indicios superficiales en lugar de realizar una investigación profunda y contextual.
• Distribución fragmentada de tareas entre analistas: cuando no existe un equipo dedicado a la búsqueda de amenazas, un mismo analista puede recibir decenas de alertas no relacionadas entre sí, lo que limita el tiempo disponible para plantear y verificar las hipótesis necesarias para detectar puntos de acceso ocultos de los atacantes.

En la práctica, esto hace que los atacantes permanezcan más tiempo en el sistema y puedan moverse de forma lateral y exfiltrar datos antes de que la organización detecte la vulneración. Se trata de un riesgo medible que conlleva consecuencias negativas directas para el negocio. El siguiente ejemplo muestra que implementar una solución de protección no garantiza por sí sola la detección de amenazas, y subraya la importancia del monitoreo continuo, la validación periódica de alertas y una búsqueda de amenazas estructurada para reducir el tiempo de permanencia de los atacantes en la red y minimizar el impacto en el negocio.

Caso práctico: un entorno “protegido desde el diseño” sin monitoreo continuo

La empresa había adquirido soluciones de seguridad y, tras implementarlas, asumió que su entorno estaba ahora “protegido desde el diseño” (secure by design). Sin embargo, los controles de seguridad solo son eficaces si están configurados de forma correcta, se adaptan de forma continua durante su operación y cuentan con monitoreo activo. Las soluciones estaban desplegadas, pero nadie supervisaba su configuración, ningún analista revisaba las alertas generadas y no existía un procedimiento programado de revisión de los logs recopilados.

Cuando la organización decidió recurrir al servicio Compromise Assessment, los expertos de Kaspersky recopilaron y analizaron los registros de eventos de seguridad. El objetivo era simple: determinar qué había estado ocurriendo en la red durante los últimos meses.

En los registros se hallaron indicios claros de actividad maliciosa. En particular, se detectaron rastros del uso de Impacket para desplegar Cobalt Strike y de la aplicación de Mimikatz en varios servidores críticos, incluidos los controladores de dominio. Todas estas acciones habían ocurrido tres meses antes de su detección, y la empresa las desconocía por la falta de un monitoreo eficaz las 24 horas.

Impacket es un conjunto de scripts en Python para trabajar con protocolos de red y realizar interacciones de bajo nivel con paquetes de red, que los atacantes pueden utilizar para propagarse por ella. A continuación se muestra un ejemplo de los artefactos de Impacket detectados en la red:

Mediante Impacket, los atacantes ejecutaron un comando de PowerShell que descargó un archivo ejecutable desde un servidor de comando y control remoto. Se determinó que este servidor estaba vinculado a la infraestructura de Cobalt Strike. Cobalt Strike es utilizado por los atacantes en la etapa posterior al compromiso y ofrece capacidades de ejecución remota de comandos y movimiento dentro de la red comprometida. La ejecución de esta herramienta se organizó mediante una tarea programada disfrazada de una actualización legítima de Google Chrome.

El análisis de la cronología de eventos también confirmó la presencia, en el sistema comprometido, de un binario de Mimikatz y un volcado de memoria vinculados al mismo incidente, lo que confirma el robo de credenciales.

La organización no sospechaba del compromiso: la actividad maliciosa permaneció sin detectar durante tres meses porque nadie era responsable de monitorear los controles de seguridad implementados. Al conocer los resultados de la revisión, la organización inició medidas de respuesta a incidentes a gran escala para eliminar los puntos de presencia de los atacantes, rotar las credenciales y reforzar la seguridad de la infraestructura.

Los controles de seguridad no son autosuficientes: instalar un firewall o una solución EDR no garantiza protección automática. Sin una configuración correcta, la formación y el mantenimiento de un perfil base de actividad y, sobre todo, sin monitoreo continuo de logs y búsqueda activa de amenazas, estos controles pueden resultar inútiles. Contar con monitoreo continuo, ya sea con personal propio o mediante terceros, que incluya la correlación de eventos, la detección de uso anómalo de plataformas de pruebas de penetración y utilidades de hacking, así como la investigación de otra actividad sospechosa, puede ser el factor decisivo que determine si un incidente se convierte en un compromiso prolongado o se detecta en cuestión de minutos.

Estadísticas de respuesta a incidentes

Como muestra el análisis de proyectos anteriores de búsqueda de indicios de compromiso, con frecuencia existe una brecha entre los playbooks de respuesta a incidentes basados en las mejores prácticas del sector y su aplicación real en entornos no preparados, en especial cuando hay sistemas obsoletos. El siguiente gráfico muestra la frecuencia con la que se aplicó cada acción durante la etapa inicial de la respuesta a incidentes, a partir de los resultados de la búsqueda de indicios de compromiso.

Medidas de respuesta aplicadas al detectar incidentes durante la búsqueda de indicios de compromiso (descargar)

En esta distribución se destacan tres acciones, las más frecuentes:

• El análisis forense se realizó en la mayoría de los incidentes: en alrededor del 59% de los casos fue necesario recopilar y analizar al menos un conjunto de datos forenses.
• La eliminación remota de malware (por ejemplo, archivos o claves de registro) se aplicó en el 39% de los casos.
• El plan de respuesta se revisó durante la investigación en el 39% de los proyectos, lo que refleja el carácter iterativo del proceso.

Por qué la respuesta suele comenzar con la recopilación de datos forenses

La recopilación y el análisis de conjuntos de datos forenses fue la etapa de respuesta más frecuente, necesaria en el 59% de los casos. Esto se explica por dos factores característicos de los proyectos de búsqueda de indicios de compromiso: 1) la disponibilidad limitada de eventos históricos en las organizaciones analizadas y 2) el hecho de que una parte considerable de los incidentes había ocurrido más de 90 días antes del inicio de la búsqueda de indicios de compromiso. En muchos casos, los registros de eventos estándar habían sido sobrescritos o se habían perdido, lo que obligaba a los investigadores a reconstruir la cronología de los eventos a partir de artefactos residuales, como entradas de la MFT, hives del registro y marcas de tiempo del sistema de archivos.

Según nuestras observaciones, la recopilación remota de conjuntos de datos forenses es un requisito indispensable y no una simple comodidad opcional. El siguiente gráfico presenta un resumen de la capacidad de las organizaciones para recopilar de forma remota conjuntos de datos forenses, según el nivel de criticidad de los incidentes. Los datos muestran que, en una proporción considerable de los casos de alta criticidad, las organizaciones carecían de esta capacidad.

Capacidad de recopilar datos forenses de forma remota en las organizaciones, desglosada por criticidad del incidente (descargar)

Contención de la amenaza: dificultades para eliminar archivos y claves de registro

La adopción de medidas para neutralizar la amenaza, por ejemplo, la eliminación de archivos o claves de registro (necesaria en el 39% de los casos), es otra etapa importante de la respuesta a incidentes; sin embargo, su implementación práctica en las organizaciones a menudo dejaba mucho que desear. Aunque muchos clientes afirmaban contar con la posibilidad de eliminación remota mediante soluciones EDR, en la práctica estas operaciones solían delegarse a los equipos de TI o a proveedores MSP a través de sistemas de tickets, lo que podía generar demoras y reducir la calidad del resultado. La eliminación de malware requiere una precisión quirúrgica, en especial en escenarios multietapa, sin archivos o con persistencia profunda. Para que la erradicación sea completa y oportuna, la capacidad técnica debe combinarse con conocimiento experto, una planificación clara y una ejecución meticulosa. Esto es muy relevante, ya que los artefactos pueden estar ocultos en copias de sombra y de respaldo, directorios ocultos o cadenas de descargadores.

Problemas de comunicación como sobrecarga operativa adicional

Un hallazgo interesante estuvo relacionado con la comunicación. En el 32% de los proyectos, los problemas de comunicación internos de la organización afectaron de forma significativa el proceso de respuesta. Ejemplos típicos:

• Confirmación ambigua de las acciones: los administradores de sistemas no podían determinar con rapidez si un archivo sospechoso era legítimo.
• Demoras en la validación por parte de los propietarios de los sistemas: el procesamiento de incidentes se ralentizaba a la espera de respuesta de los propietarios de los sistemas.
• Canales de comunicación comprometidos: ante la sospecha de compromiso del dominio, es razonable asumir que las cuentas de correo electrónico o los portales de soporte también podrían estar bajo el control de los atacantes.
• Rotación de personal: pérdida de conocimiento sobre las configuraciones base anteriores.

Todo esto pone de relieve la necesidad de realizar simulacros de mesa (tabletop exercises) de forma periódica, que permitan poner a prueba no solo el aspecto técnico de los playbooks de respuesta, sino también la interacción entre los participantes del proceso, así como verificar el cumplimiento de los acuerdos de nivel operativo (OLA) que rigen la interacción entre equipos y de los procedimientos operativos estándar (SOP) empleados para la documentación adecuada.

Actualización iterativa del plan de respuesta

En el 39% de los casos fue necesario ajustar los planes de respuesta a partir de nuevos datos analíticos. Esta observación confirma la premisa de que la respuesta a incidentes es, por naturaleza, un proceso iterativo. Los planes elaborados en las etapas iniciales no pueden tener en cuenta todos los factores que influyen en las medidas de respuesta. A continuación se presentan las causas más frecuentes de revisión del plan de respuesta:

• la identificación de servidores de comando y control que antes eran desconocidos, o de nuevos patrones de comportamiento a partir de la ingeniería inversa;
• nuevos hallazgos forenses, entre ellos tareas programadas ocultas, artefactos en copias de sombra y bibliotecas DLL “inactivas”;
• la detección de rutas adicionales de movimiento lateral a partir del análisis del tráfico de red;
• el factor humano: falta de disponibilidad de los propietarios de los sistemas, cambios en los procesos de gestión o espera de una decisión por parte de la dirección.

Como demuestra la experiencia, cuando los equipos tratan el plan de respuesta como un documento vivo (lo actualizan de forma regular con nuevos artefactos, revisan las prioridades de las acciones y lo actualizan antes de cada etapa de contención de la amenaza), se reduce el riesgo de omitir medidas de erradicación críticas. Por el contrario, seguir de forma estricta el plan inicial, elaborado con un volumen limitado de datos forenses, aumenta la probabilidad de pasar por alto determinados puntos de persistencia de los atacantes.

Distinción entre artefactos de ataques reales y rastros de pruebas de penetración

Por último, otro problema persistente, observado en el 12% de los casos, es la dificultad para distinguir entre la actividad de los atacantes y los artefactos de pruebas de penetración (pentest) legítimas. Durante la búsqueda de indicios de compromiso, con frecuencia se detectan rastros de herramientas de pruebas legítimas, y no siempre es posible determinar con certeza si un artefacto concreto está relacionado con una intrusión real o con un pentest autorizado. Los principales factores que dificultan esta distinción son los siguientes:

• Informes de pentest que no han sido documentados en detalle y una limpieza incompleta de sus artefactos en los sistemas.
• El uso de las mismas herramientas (por ejemplo, SharpHound) tanto por parte de los especialistas en pentest como de los atacantes reales.
• La realización simultánea de actividades de búsqueda de indicios de compromiso y de un pentest activo, lo que dispersa la atención de los analistas y aumenta la cantidad de falsos positivos. Aunque es fundamental cotejar los resultados de la búsqueda de indicios de compromiso con los informes de pentest, debe tenerse en cuenta que se trata de un proceso de investigación que se lleva a cabo bajo la supervisión de analistas. Los artefactos generados durante la simulación de ataques en un pentest pueden inducir a error a los analistas, lo que provoca una interpretación incorrecta de los datos y reduce la eficacia de la búsqueda de indicios de compromiso.

Competencias de respuesta y su impacto en la criticidad de los incidentes

Nuestros datos indican una correlación entre la presencia de competencias internas de análisis forense digital e ingeniería inversa de malware y la distribución de los niveles de criticidad de los incidentes. En los proyectos de búsqueda de indicios de compromiso de 2025, la proporción de incidentes de baja, media y alta criticidad difirió mucho entre las organizaciones que contaban con dichas competencias y las que no. Los datos que se presentan a continuación ilustran esta correlación y pueden ayudar a evaluar el valor comercial de desarrollar habilidades de respuesta dentro de la organización.

Gravedad de los incidentes que requieren análisis forense, según la disponibilidad de esta capacidad en la organización (descargar)

En las organizaciones con capacidad propia para analizar artefactos forenses digitales, detectamos la mitad de incidentes de alta criticidad y una proporción mayor de incidentes de baja y media criticidad.

Gravedad de los incidentes que requieren análisis de malware, según la disponibilidad de esta capacidad en la organización (descargar)

En nuestra muestra, cuando la organización contaba con un especialista dedicado a la ingeniería inversa, no se registraron casos de alta criticidad; la mayoría de los incidentes correspondió a la categoría media, y también se observó una mayor cantidad de incidentes de baja criticidad.

Al analizar estas estadísticas, con un grado razonable de certeza, suponemos que es muy improbable que la diferencia observada entre los incidentes se deba al tamaño de la muestra y, más bien, refleje un efecto operativo real: las competencias internas en análisis forense digital y análisis de malware influyen no solo en la eficacia del SOC, sino también en la ciberresiliencia general de la organización.

Caso práctico: el malware LionTail operando en memoria en servidores Windows críticos

En uno de los proyectos de búsqueda de indicios de compromiso se detectó una amenaza persistente presente en la memoria RAM de varios servidores críticos. Estaba vinculada al framework LionTail, un conjunto sofisticado de loaders personalizados e implantes residentes basados en shellcode. LionTail aprovecha características no documentadas del controlador HTTP.sys de Windows para entregar de forma encubierta su carga útil a través del tráfico HTTP entrante, camuflando la actividad maliciosa como flujos de red legítimos.

Varios de los ejemplares detectados se vincularon al grupo Scarred Manticore, que crea un implante único para cada host comprometido y exfiltra datos, camuflando las comunicaciones con los servidores de comando y control como tráfico de red habitual.

Detectamos la amenaza mediante una firma estática en memoria RAM, identificada dentro del proceso scrcons.exe. Aunque scrcons.exe es un archivo ejecutable legítimo del host WMI, ubicado en el directorio C:\Windows\System32\wbem, los atacantes suelen inyectarle su carga útil, lo que permite ejecutar código en memoria sin llamar la atención.

El plan de respuesta incluyó una serie de medidas, entre las cuales las más críticas se enumeran a continuación:

• recopilación de volcados de memoria RAM para un análisis en profundidad;
• obtención de imágenes forenses completas de los discos de los sistemas afectados;
• análisis detallado de los artefactos recopilados y la posterior actualización del plan de respuesta a incidentes.

A la organización le resultó difícil implementar estas medidas debido a sus capacidades limitadas en análisis forense digital e ingeniería inversa. Para responder a incidentes relacionados con amenazas sin archivos que se ejecutan en memoria, estas competencias son indispensables. Sin ellas, las organizaciones corren el riesgo de perder evidencia importante, evaluar de forma incorrecta el alcance del compromiso o no lograr eliminar por completo implantes sofisticados que dejan mínimos rastros en el disco.

Aunque nuestros especialistas lograron completar la investigación y contener la amenaza, este caso reveló un nivel insuficiente de preparación de la organización. Demostró que depender de ayuda externa en incidentes de alta criticidad constituye un riesgo operativo concreto, y confirmó la importancia de contar de forma interna con especialistas experimentados en análisis forense digital e ingeniería inversa para lograr una erradicación oportuna, precisa e integral de los incidentes.

Búsqueda de causas raíz de los incidentes

Al finalizar un proyecto de búsqueda de indicios de compromiso, pasamos de la etapa de respuesta a la etapa de consultoría. La reunión final se centra en prevenir la repetición de incidentes: en ella se analizan las causas raíz por las que el ataque pasó inadvertido. Las recomendaciones que ofrecemos están orientadas a su aplicación práctica y toman en cuenta las particularidades del entorno del cliente. Para los fines de este informe, las agrupamos por categorías.

Categoría de causa raíz	Proporción de incidentes	Conclusiones típicas
Precisión de detección insuficiente	60.7%	• Las soluciones EPP/EDR o las fuentes de registro de eventos relacionadas no generaron alertas confiables. • En el 9.4% de los casos, el producto estaba mal configurado, desactualizado o no funcionaba de forma correcta.
Falta de monitoreo basado en alertas	35.9%	• Se generaron alertas que podían indicar compromiso, pero el incidente no fue registrado. • Las señales con un alto nivel de incertidumbre (por ejemplo, la detección heurística de web shells) requerían revisión por parte de un analista.
Deficiencias en la gestión de vulnerabilidades y configuraciones	28.2%	• Se detectaron errores evidentes de configuración (por ejemplo, la desactivación de registros de auditoría o cuentas de servicio con privilegios excesivos). • Las vulnerabilidades conocidas permanecieron sin parchear, o no se adoptaron medidas para mitigar los riesgos asociados.
Ausencia de procesos estructurados de búsqueda activa de amenazas	27.4%	• Las alertas con un nivel de confianza bajo no se revisaban tras el filtrado inicial. • Grandes volúmenes de telemetría permanecieron sin procesar debido a la falta de personal.
Programas de concientización en seguridad de la información poco eficaces	25.6%	• Las fugas de credenciales desde dispositivos personales de empleados o contratistas representaron el 27.2% de los incidentes relacionados con una concientización insuficiente en materia de seguridad. • Los intentos de ingeniería social tuvieron éxito debido a la falta de preparación de los usuarios frente a este tipo de ataques.
Ausencia de políticas o procesos documentados	23.9%	• No existían escenarios formalizados de respuesta a incidentes, procedimientos de gestión de cambios ni normativas para el manejo de datos.

Principales conclusiones sobre las causas raíz

La verificación del funcionamiento de los sistemas de detección fue la medida correctiva más frecuente. En más de la mitad de los casos en que no se generaron alertas, se recomendó realizar una revisión básica del funcionamiento de los sensores y de la vigencia de las reglas para cerrar esta brecha. Sin dicha revisión, no se podía determinar con rapidez si la ausencia de alertas estaba relacionada con el incidente o con la configuración del propio producto.

Los analistas deben seguir procesando de forma manual las alertas con un level de confianza bajo, porque el procesamiento automatizado no puede compensar el comportamiento de reglas propensas a falsos positivos (por ejemplo, la heurística genérica para la detección de web shells). Para reducir el tiempo de permanencia de los atacantes en la red, se recomienda incorporar una etapa de clasificación manual de las señales de amenaza entrantes.

La falta de procesos consolidados (gestión de vulnerabilidades, búsqueda activa de amenazas, políticas de seguridad) representa una proporción significativa de las causas raíz de los incidentes. Incluso en organizaciones maduras persisten brechas en los procesos rutinarios, que pueden subsanarse con procedimientos de trabajo bien definidos. La ausencia de políticas y procesos documentados fue la causa raíz del 23.9% de los incidentes.

Un ejemplo actual de políticas de seguridad poco meditadas es el desarrollo de software con IA generativa sin reglas claras de tratamiento de datos. Durante uno de los proyectos, encontramos una estación de trabajo basada en macOS en la que el asistente Claude Code (Anthropic), con interfaz de línea de comandos, se utilizaba como extensión de VS Code. La herramienta registraba de forma automática el estado del sistema de archivos para enriquecer los prompts del modelo de lenguaje. Las capturas obtenidas incluían listados completos de directorios y rutas absolutas a varios libros de Excel que contenían datos internos confidenciales:

Línea de comandos del proceso principal	Línea de comandos
/bin/zsh -c -l source /Users/[OCULTO]/.claude/shell-snapshots/snapshot-zsh-[OCULTO].sh && eval ‘ls -lh “/Users/[OCULTO]/Documents/[OCULTO]/”*.xlsx‘ \\< /dev/null && pwd -P >| /var/folders/[OCULTO]/claude-[OCULTO]	ls -lh /Users/[OCULTO]/Documents/[OCULTO].xlsx /Users/[OCULTO]/Documents/[OCULTO].xlsx /Users/[OCULTO]/Documents/[OCULTO].xlsx .. [OCULTO]

Recomendamos a la organización realizar una serie de sesiones de capacitación para el personal, orientadas a aumentar la concientización sobre los riesgos de divulgación de información interna confidencial al usar herramientas de IA generativa, así como elaborar una política que regule el uso de dichas herramientas al trabajar con datos sensibles.

Problemas de detección: causas y consecuencias

Las búsquedas de indicios de compromiso muestran, una y otra vez, que una cobertura de detección insuficiente influye de forma considerable en la proporción de incidentes de alta criticidad. En los casos en que la cobertura de detección se calificó como baja, el 52% de los incidentes se clasificó como de alta criticidad y solo el 15% como de baja criticidad. Esta distribución señala una correlación: la visibilidad limitada parece aumentar la proporción de incidentes que evolucionan hacia compromisos de alta criticidad.

Distribución de la criticidad de los incidentes causados por una detección insuficiente de las herramientas de protección vigentes (descargar)

Existe la creencia extendida de que la madurez de los procesos de detección puede mejorarse contratando a un proveedor de servicios de seguridad gestionados (MSSP). Sin embargo, nuestros datos muestran un panorama menos concluyente. Incluso con un MSSP, el 26.5% de los incidentes pasó desapercibido por falta de una detección suficiente, y en alrededor del 50% de los proyectos con MSSP se observaron brechas evidentes en la auditoría de Windows (por ejemplo, ausencia de recopilación de logs de eventos o políticas de auditoría deshabilitadas).

Como muestran las estadísticas, externalizar el servicio no garantiza por sí solo una detección eficaz; se requiere participación activa en la gestión y validación continua. La detección debe considerarse una función en evolución, que exige pruebas, evaluación y mejora constantes, ya se realice con recursos propios o se delegue a un proveedor externo.

Distribución de incidentes pasados por alto por falta de capacidad de detección, entre organizaciones que utilizan y no utilizan servicios de MSSP (descargar)

El análisis de las causas raíz de los incidentes pasados por alto revela varios patrones recurrentes. En muchos entornos existen las tecnologías necesarias, pero los procesos para operarlas están mal estructurados. Los principales problemas son los siguientes:

• Falta de verificación del funcionamiento de la plataforma de protección de endpoints (EPP): en los proyectos donde esta verificación se realizaba de forma deficiente o no se realizaba, casi el 50% de los incidentes escalaba a la categoría de alta criticidad. Se trata del caso clásico de una solución que se implementa y luego se abandona: los agentes están instalados, pero pueden estar mal configurados, sin actualizar o sin validar.
• Falta de datos actualizados sobre amenazas: sin acceso a un feed o plataforma de inteligencia de amenazas (threat intelligence), cerca de la mitad de los incidentes alcanzaba un nivel de criticidad alto. Sin indicadores de compromiso verificados ni enriquecimiento contextual, los analistas se ven obligados a depender de alertas estándar y pueden pasar por alto actividades maliciosas asociadas a amenazas conocidas.

Este problema tiene su raíz en la mentalidad de “instalar y olvidar”, que implica que las organizaciones asumen que las herramientas implementadas ofrecen protección de forma automática, aun cuando su configuración no se supervisa, su funcionamiento no se valida y no reciben datos actualizados sobre amenazas.

Distribución de incidentes por nivel de criticidad en ausencia de verificación del funcionamiento del EPP o de los flujos de inteligencia de amenazas
Elemento de seguridad ausente	Alta criticidad	Criticidad media	Baja criticidad
Verificación del funcionamiento del EPP	48.3%	36.7%	15%
Flujo de inteligencia de amenazas	50%	40%	10%

La incapacidad de detectar una amenaza rara vez se debe a la ausencia de un único componente de protección; por lo general, obedece a la combinación de una configuración débil, una recopilación insuficiente de telemetría y la falta de revisiones regulares que confirmen el funcionamiento real de las herramientas de protección, en especial en los modelos tercerizados. Un enfoque híbrido de monitoreo, que combina el control interno con el apoyo externo de un MDR o MSSP, ha demostrado ser el modelo más resiliente, siempre que se definan con claridad los roles, las expectativas y las métricas de rendimiento. La detección de amenazas debe entenderse como una función en desarrollo constante, y no como el resultado de una compra puntual de soluciones de protección.

Para ilustrar las consecuencias reales de un control insuficiente sobre las herramientas de seguridad, veamos un incidente grave que permaneció sin detectar durante varios meses solo por la falta de los mecanismos de detección necesarios en la organización.

Caso práctico: infección con el malware PurpleFox, que opera en memoria RAM y evade las herramientas tradicionales de protección de endpoints

Durante un proyecto de búsqueda de indicios de compromiso, realizamos un escaneo de la memoria RAM de los hosts analizados utilizando un conjunto de reglas que ha sido diseñado para la búsqueda activa de amenazas. Como resultado, se lograron identificar dos objetos ocultos:

• código del rootkit PurpleFox, inyectado en procesos legítimos de svchost.exe en varios servidores críticos;
• firmas del criptominero XMRig dentro de esos mismos procesos svchost.exe comprometidos.

PurpleFox deposita en el sistema bibliotecas DLL especialmente preparadas y las fuerza a cargarse a través del proceso svchost.exe; estas, a su vez, instalan un controlador en modo kernel que brinda al atacante persistencia encubierta en el sistema, con la capacidad de ejecutarse sin ser detectado y de descargar cargas útiles adicionales, incluido el ya mencionado minero XMRig.

La solución EPP implementada supervisaba la creación de archivos, los cambios en el registro y las conexiones de red, pero su módulo de análisis de memoria RAM estaba deshabilitado. El conjunto de firmas utilizado en el momento de la búsqueda de indicios de compromiso también estaba desactualizado. Como resultado, las bibliotecas DLL inyectadas y el shellcode del minero no generaron ninguna alerta. Durante la etapa de análisis de memoria, nuestro equipo detectó el problema en la configuración de los sistemas de detección y documentó en el informe final la ausencia de la función de verificación de memoria.

La organización había externalizado la seguridad a un proveedor MSSP, que recopilaba los logs y los enviaba al sistema SIEM. Dado que los logs originales no contenían señales de actividad en memoria RAM, la actividad de PurpleFox no fue detectada.

Gestión deficiente de vulnerabilidades: un catalizador de incidentes de alta criticidad

Más de la mitad de los incidentes detectados en los proyectos de búsqueda de indicios de compromiso de 2025, vinculados a una gestión deficiente de vulnerabilidades o a la falta de parches, tuvieron un nivel de criticidad alto. Con mayor frecuencia derivaban en el despliegue de web shells que permitían persistencia y ejecución remota de código, así como en la explotación de servicios de Active Directory mal configurados.

Distribución de incidentes por criticidad en casos de gestión deficiente de vulnerabilidades (descargar)

Las causas de la falta de parches pueden ser muy diversas, entre ellas un inventario de activos insuficiente (registrado en el 25% de los proyectos) y la ausencia de procesos formalizados de gestión de vulnerabilidades (41% de los proyectos). Es más, en el 86% de las organizaciones que declaraban contar con un programa de gestión de vulnerabilidades, la búsqueda de indicios de compromiso también reveló errores de configuración explotados por atacantes. Estas observaciones muestran que una gestión de parches eficaz, un inventario de activos completo y procesos de gestión de vulnerabilidades bien estructurados son fundamentales para prevenir incidentes de alta criticidad.

Caso práctico: un ejemplo típico de las consecuencias de permisos excesivos en la distribución de software mediante GPO

En diversos proyectos de búsqueda de indicios de compromiso, nos encontramos de forma recurrente con el siguiente error crítico de configuración: mediante un objeto de directiva de grupo (GPO) se definía la ruta a un archivo ejecutable en una carpeta de red compartida, que se ejecutaba en cada estación de trabajo a través de una tarea programada. Además, todos los usuarios tenían control total mediante una lista de control de acceso (ACL).

Dado que cualquier usuario autenticado puede escribir archivos en esta carpeta de red, al atacante le basta con comprometer una sola cuenta de bajo privilegio para reemplazar el archivo ejecutable legítimo por su carga útil. En la siguiente ejecución de la tarea, el archivo malicioso llegará de forma automática a todos los endpoints alcanzados por dicha directiva de grupo, lo que proporciona:

• privilegios elevados en el contexto de ejecución: la tarea programada suele ejecutarse con la cuenta SYSTEM o de administrador local;
• propagación automática: el ejecutable malicioso se propaga sin necesidad de explotar vulnerabilidades de red adicionales;
• escalada de privilegios potencial: el compromiso de una cuenta de bajo privilegio puede derivar en la ejecución de código con permisos de administrador de dominio.

Si la organización hubiera seguido procedimientos de gestión de vulnerabilidades que incluyeran una auditoría sistemática de los permisos de GPO y de las carpetas de red, la posibilidad de escritura en ese directorio se habría clasificado como un problema crítico y se habría corregido antes del inicio del ataque. Para solucionar este problema, por lo general basta con limitar los permisos de los usuarios autorizados solo a lectura y otorgar permisos de modificación a un conjunto muy limitado de cuentas privilegiadas. Incorporar este tipo de verificaciones a los controles de seguridad básicos reduce la superficie de ataque y disminuye mucho los riesgos cuando se realizan de forma adecuada auditorías y pruebas de penetración (VAPT).

Conclusión

En 2025, los especialistas del servicio Kaspersky Compromise Assessment ayudaron a las organizaciones a identificar una serie de amenazas antiguas, que no habían sido detectadas: los rastros de actividad en el 30.8% de los incidentes abarcaban un período superior a tres meses, y entre los incidentes de alta criticidad esa proporción llegó al 52%. De todos los incidentes detectados, el 20% se encontró de forma manual, y el 60% de las amenazas pasó inadvertido para las organizaciones por la falta de alertas confiables de las herramientas de protección existentes. La antigüedad del incidente no detectado más antiguo, identificado por el equipo de Kaspersky Compromise Assessment en 2025, fue de alrededor de cuatro años.

Las revisiones posteriores a un incidente concentraron la mayor proporción de incidentes de alta criticidad, mientras que las auditorías preventivas periódicas, las verificaciones de cumplimiento normativo y las auditorías previas a la unificación de dos redes, por lo general, permitían detectar problemas en etapas más tempranas. Esto indica que las investigaciones que solo son reactivas suelen no detectar los mecanismos ocultos de persistencia de los atacantes. Tras analizar la experiencia de los proyectos de 2025, recomendamos a las organizaciones realizar una verificación integral del funcionamiento de los módulos de detección para fortalecer la seguridad:

• realizar una verificación integral del funcionamiento de los módulos de detección dentro de los 30 días posteriores a la finalización del proyecto, priorizando la integridad de la telemetría y la vigencia de las reglas;
• crear un equipo de validación de alertas de primer nivel que revise con frecuencia todos los eventos con un nivel de confianza bajo según un cronograma establecido;
• implementar un monitoreo riguroso las 24 horas y reforzarlo con búsqueda activa de amenazas, orientada a los perfiles base de actividad, las alertas de baja precisión y las nuevas técnicas de los atacantes;
• revisar los procesos de gestión de vulnerabilidades y garantizar la aplicación regular de parches, así como el registro completo de logs de auditoría en todos los activos críticos;
• actualizar los programas de concientización en seguridad de la información, prestando especial atención a las filtraciones de credenciales desde dispositivos personales y a las prácticas seguras de uso de dispositivos propios para el trabajo (BYOD);
• realizar de forma periódica simulacros de mesa (tabletop exercises) para poner a prueba los playbooks de respuesta, mejorar la capacitación de los equipos y optimizar las comunicaciones;
• elaborar acuerdos de nivel operativo (OLA) que regulen la interacción entre equipos, así como procedimientos operativos estándar (SOP) para una documentación adecuada.

Trabajar de forma sistemática sobre las categorías de causas raíz mencionadas ayudará a las organizaciones a reducir la probabilidad de puntos ciegos futuros y a elevar el nivel general de seguridad.