Cyclops Blink vuelve con nuevas capacidades

agosto de 2026, los investigadores de la Counter Threat Unit™ (CTU) analizaron un ejecutable malicioso de Linux de 64 bits llamado «timezone_check» que los investigadores descubrieron en varios dispositivos Cisco Firewall Management Center (FMC) comprometidos. Este sofisticado implante modular proporciona acceso remoto persistente a un sistema Linux comprometido. El análisis de la CTU™ indica que se trata de una variante del malware Cyclops Blink analizado anteriormente por el Centro Nacional de Ciberseguridad del Reino Unido (NCSC) en 2022 y que probablemente esté relacionada con el grupo de amenazas IRON VIKING, con sede en Rusia (también conocido como Sandworm y Seashell Blizzard). Cisco publicó detalles sobre esta campaña el 9 de septiembre, lo que llevó a los investigadores de la CTU a hacer público su análisis.

A diferencia de las muestras centradas en WatchGuard documentadas en 2022, la variante de 2026 se ejecuta en Linux x86-64 y utiliza la persistencia genérica de System V (SysV) en lugar de una modificación del firmware específica del fabricante. Este cambio amplía la gama de dispositivos de perímetro de red potencialmente compatibles. Las capacidades ampliadas del implante incluyen la detección activa de redes y servicios, la vigilancia programable de paquetes, la transferencia de archivos y la ejecución de cargas útiles, lo que permite que un dispositivo comprometido sirva como plataforma para el reconocimiento interno, la recopilación de inteligencia y operaciones posteriores.

Resumen del malware

Cyclops Blink es una red de bots modular y un marco de malware organizado en torno a un controlador principal y cinco módulos de trabajo de procesos secundarios. El controlador principal crea canales dedicados de comunicación entre procesos (IPC) para cada módulo, enruta los comandos entrantes según el identificador del módulo, recopila la salida de los módulos, aplica protección criptográfica y envía los registros resultantes a la infraestructura de comando y control (C2). El uso de procesos separados ayuda a aislar los fallos de los módulos y permite que varias tareas se ejecuten al mismo tiempo. La figura 1 muestra la relación entre el controlador y sus módulos de trabajo.

Figura 1: arquitectura de Cyclops Blink

El controlador se hace pasar por un proceso llamado [kworker/0:1] para camuflarse entre la lista de procesos de Linux y reducir la probabilidad de que lo descubran por casualidad (mira la Figura 2). Los hilos kworker auténticos realizan tareas del núcleo en segundo plano y son habituales en los sistemas Linux.

Figura 2: pseudocódigo del controlador de Cyclops Blink

El controlador mantiene una estructura de estado de tamaño fijo que distribuye a todos los módulos de trabajo registrados. La estructura contiene la lista de direcciones IPv4 C2 activas, un valor relacionado con la sesión, el intervalo de balizas recurrentes, el tiempo restante hasta la próxima baliza, información de la cola de salida, el ID del proceso del controlador y el ID del módulo y el ID del proceso de cada trabajador instalado. El controlador reconstruye y difunde esta estructura durante la inicialización, antes de las comunicaciones C2 y tras procesar los comandos del controlador reconocidos. Este mecanismo mantiene sincronizados los procesos de los trabajadores, que se ejecutan de forma independiente, con los cambios en la configuración compartida y el estado del controlador. La Tabla 1 enumera los códigos de control implementados.

Tabla 1: códigos de control de Cyclops Blink

Durante la inicialización, el controlador añade reglas ACCEPT a la cadena OUTPUT de iptables de Linux para los puertos de destino TCP 43856 y 49172, que son los dos puertos que usa para sus comunicaciones C2. El controlador primero intenta modificar la tabla de filtrado directamente a través de la interfaz libiptc vinculada e incluye una ruta alternativa que invoca la utilidad iptables del sistema. El controlador elimina las reglas correspondientes al apagar o reiniciar el controlador. Estos cambios tienen como objetivo garantizar que la política del firewall local permita las conexiones C2 salientes del implante.

Descripciones de los módulos

El implante que los investigadores de la CTU analizaron contiene cinco módulos de trabajo que se encargan del reconocimiento del host, la transferencia de archivos y la ejecución de la carga útil, el descubrimiento activo de la red, la captura selectiva de paquetes y la persistencia.

Módulo 0x08: reconocimiento del host

El módulo 0x08 analiza el sistema Linux comprometido y su entorno de red inmediato, lo que proporciona al operador información detallada sobre la configuración del dispositivo, sus privilegios, su función operativa y su conectividad. El módulo recopila la siguiente información:

• información sobre el sistema operativo, el núcleo, el nombre de host y el tiempo de actividad
• detalles del procesador, la memoria, el sistema de archivos y el almacenamiento
• usuarios locales, grupos, procesos y líneas de comando
• interfaces de red, direcciones, datos ARP y configuración del resolutor

Si la instancia del implante tiene privilegios suficientes en el host comprometido, el módulo también puede acceder a /etc/shadow, lo que podría exponer los hash de contraseñas para su análisis offline (véase la figura 3).

Figura 3: pseudocódigo de alto nivel del módulo 0x08

El módulo de reconocimiento se ejecuta por defecto cada 10 minutos, aunque también se puede ejecutar bajo demanda. El módulo envía la información recopilada al controlador, que la transmite a su servidor C2. En un dispositivo perimetral de red, como un Cisco FMC, este reconocimiento proporciona un contexto valioso, ya que el host puede tener acceso a redes de gestión privilegiadas y a múltiples rangos de direcciones internas. El inventario resultante podría ayudar a un operador a comprender el entorno circundante, identificar servicios administrativos y sistemas adyacentes, evaluar las credenciales disponibles y planificar el posterior descubrimiento de la red o el movimiento lateral.

Módulo 0x0F: transferencia de archivos y ejecución de cargas útiles

El módulo 0x0F proporciona el mecanismo principal del implante para transferir archivos e implementar capacidades adicionales. El módulo puede subir archivos locales a la infraestructura C2, descargar contenido a través de HTTP o HTTPS, guardar las cargas útiles recuperadas en una ruta especificada por el operador y ejecutar los archivos descargados como procesos hijos. Cuando el comando del servidor C2 no proporciona un destino absoluto válido, el módulo crea una ruta dentro de /var/tmp utilizando el nombre base de la URL. Si no hay ningún nombre base válido, recurre a /var/tmp/a.tmp.

El módulo también puede escribir código descargado directamente en la memoria ejecutable, lo que permite que una carga útil se ejecute sin necesidad de almacenarla como un archivo convencional. Los ejecutables ELF de Linux recuperados pueden registrarse como módulos adicionales de Cyclops Blink, ampliando así la funcionalidad del implante mientras permanece activo. El módulo 0x0F gestiona las solicitudes de transferencia individuales del servidor C2 en procesos hijos independientes, lo que permite al implante llevar a cabo operaciones de transferencia de archivos y ejecución de cargas útiles sin bloquear el controlador ni otros módulos de trabajo.

El módulo 0x0F ofrece al operador una gran flexibilidad tras el compromiso del sistema. Puede recopilar y exfiltrar datos accesibles, recuperar herramientas complementarias, ejecutar malware adicional, actualizar el conjunto de módulos del implante y establecer mecanismos de acceso adicionales. En un dispositivo de gestión de red, esta flexibilidad podría permitir que el dispositivo comprometido sirva tanto como punto de recopilación de información como plataforma de preparación para operaciones contra sistemas a los que se pueda acceder desde su posición de confianza en la red.

Este módulo utiliza un resolutor DNS-over-HTTPS integrado cuando un destino de transferencia HTTP o HTTPS contiene un nombre de host en lugar de una dirección IPv4 numérica. El resolutor establece una conexión TLS directamente con el DNS público de Google en 8.8.8.8:443, envía una consulta DNS binaria mediante una solicitud HTTP POST a /dns-query que contiene un User-Agent codificado de forma fija, y extrae una dirección IPv4 de la respuesta DNS devuelta (véase la figura 4). El módulo utiliza entonces la dirección resuelta en sus rutinas de conexión HTTP o HTTPS. Este enfoque permite al implante resolver los destinos de transferencia proporcionados por el operador independientemente del servicio DNS configurado en el sistema comprometido y evita que queden rastros forenses en los registros locales de DNS.

Figura 4: búsqueda DNS de Cyclops Blink que contiene un User-Agent distintivo

La cadena User-Agent imita deliberadamente a un navegador de escritorio actual, aunque es internamente inconsistente porque combina el rv:129.0 y el token Gecko de Firefox con un token de producto de Chrome. Estos elementos no suelen verse juntos, salvo quizá en scripts y herramientas de scraping automatizadas que emplean generadores de User-Agent de código abierto. La misma cadena de User-Agent también aparece en las peticiones HTTP GET de Cyclops Blink (véase la Figura 5). Esta petición HTTP GET también es anómala porque incluye puntos y comas en lugar de comas en el campo «Accept-Language» y porque el campo «Accept» carece del tipo y subtipo de medio esperados (un comodín genérico sería «Accept: */*»).

Figura 5: solicitud HTTP GET malformada de Cyclops Blink

El módulo 0x0F también puede seguir este procedimiento para sustituir la instancia en ejecución de Cyclops Blink:

1. Identifica el ejecutable actual a través de /proc/self/exe.
2. Cambia el nombre de la imagen actual a una ruta de copia de seguridad.
3. Descarga la imagen de sustitución a la ruta original.
4. Restaura la imagen anterior si falla la descarga.
5. Elimina la copia de seguridad tras completarse con éxito.
6. Ejecuta la nueva imagen.

Módulo 0x11: escáner de redes y servicios

El módulo 0x11 ofrece capacidades internas de detección de redes y servicios. Enumera las redes IPv4 conectadas localmente y sondea bien un rango de puertos definido por el operador, bien una lista integrada de puertos asociados a infraestructuras y servicios de gestión que suelen ser objetivo de ataques. Las tareas de escaneo se ejecutan en procesos hijos independientes, lo que permite que se realicen múltiples operaciones sin bloquear el canal de comandos del módulo.

Un modo de escaneo construye y transmite tramas completas de Ethernet, IPv4 y TCP a través de un socket de paquetes sin procesar. Utiliza puertos de origen aleatorios y valores relacionados con la secuencia, identifica los puertos abiertos a partir de respuestas SYN-ACK coincidentes y completa un protocolo de enlace TCP mínimo. En el caso de los servicios abiertos, el módulo puede recopilar datos de respuesta. En el puerto TCP 80, envía la solicitud GET / HTTP/1.1\r\n\r\n, mientras que el puerto 443 se pasa a una rutina independiente de sondeo TLS. La funcionalidad de escaneo sin procesar solo realiza un manejo ligero de paquetes y no implementa un procesamiento completo del flujo TCP. El módulo envía los resultados positivos, que incluyen direcciones de destino, puertos de destino y datos opcionales de respuesta de servicio, al controlador para su transmisión protegida a través del canal C2 del implante.

Esta capacidad es especialmente importante cuando el operador despliega el implante en un dispositivo perimetral de la red. Desde esa posición, el módulo puede descubrir sistemas internos y servicios de gestión a los que no se puede acceder directamente desde Internet. Los resultados podrían ofrecer al operador una visión detallada de la red circundante, lo que puede facilitar la selección de objetivos, la identificación de la infraestructura administrativa y el posterior movimiento lateral. A diferencia del reconocimiento de hosts que realiza el módulo 0x08, el módulo 0x11 interactúa activamente con los sistemas vecinos y, por lo tanto, puede generar actividad detectable de escaneo, conexión y sondeo de servicios. El implante tiene una lista de puertos integrada que parece diseñada para detectar una amplia gama de sistemas internos estratégicamente valiosos (véase la Tabla 2).

Tabla 2: puertos escaneados por Cyclops Blink

Módulo 0x12: captura de paquetes y vigilancia de contenidos

El módulo 0x12 permite al operador supervisar el tráfico visible para el dispositivo comprometido y retener de forma selectiva los paquetes que contengan un contenido específico. Captura tramas Ethernet sin procesar y busca de forma eficiente en las cargas útiles de las aplicaciones IPv4 los términos especificados por el operador. A continuación, utiliza los patrones de búsqueda proporcionados por el operador para identificar el material relevante para la recopilación de información, en lugar de recopilar todo el tráfico disponible, lo que reduce el volumen de tráfico innecesario enviado al servidor C2.

El módulo implementa una vigilancia programable del tráfico de red y admite los tres comandos que aparecen en la Tabla 3.

Tabla 3: códigos de comando del módulo Cyclops Blink 0x12

El módulo 0x12 usa el siguiente código para abrir un socket de paquetes de Linux, lo que le permite recibir tramas Ethernet sin procesar visibles para el host comprometido, siempre que sus permisos y ubicación en la red lo permitan:

socket(
AF_PACKET,
SOCK_RAW,
htons(ETH_P_ALL)
);

El operador puede configurar la duración de la captura, el modo de procesamiento, los filtros de direcciones y puertos, y el comportamiento de la búsqueda de contenido. El implante compila los patrones proporcionados en un autómata de coincidencia al estilo Aho-Corasick, lo que permite una búsqueda simultánea y eficiente de múltiples valores. El implante analiza los paquetes IPv4 capturados para localizar cargas útiles de aplicaciones TCP o UDP. El comparador compilado busca el contenido, y el sistema conserva los paquetes que cumplen los criterios.

Una de las funciones de devolución de llamada contiene una heurística distintiva que suprime una coincidencia inicial cuando los bytes siguientes son «-AGE» o «-Age», lo que probablemente sea un intento de evitar que los términos de búsqueda relacionados con el usuario coincidan repetidamente en las cadenas HTTP User-Agent. El módulo conserva los paquetes que cumplen los requisitos como registros con marca de tiempo al estilo pcap, lo que permite al operador recopilar de forma selectiva el tráfico que contenga credenciales, tokens, comandos u otro material de interés. Este módulo podría permitir recopilar los siguientes elementos:

• credenciales en texto plano
• cookies de sesión
• tokens de autenticación
• solicitudes de aplicaciones
• tráfico de protocolos propios
• comandos administrativos
• otro contenido sensible de la red que coincida con términos definidos por el operador

El módulo no reensambla flujos TCP, por lo que un término de búsqueda dividido en varios segmentos TCP podría eludir una coincidencia de paquete individual.

Módulo 0x50: persistencia y autorrelocalización

El módulo 0x50 establece la persistencia reubicando el implante en un directorio del sistema y registrando el ejecutable reubicado como un servicio de inicio SysV. Cuando el módulo se inicia, resuelve la ruta del ejecutable en ejecución a través de /proc/self/exe y compara el resultado con su ubicación de instalación prevista (/lib/tz/timezone_check en las muestras analizadas). Si el implante ya se está ejecutando desde esta ubicación, el módulo se salta los pasos de copia de archivos y registro del servicio. Este enfoque evita la autorrelocalización repetida y la duplicación de los artefactos de persistencia.

Cuando se ejecuta desde otra ubicación, el módulo crea /lib/tz (estableciendo sus permisos en 0755) y copia el ejecutable en ejecución a /lib/tz/timezone_check. Tras confirmar que la operación de copia se ha realizado con éxito, desvincula el ejecutable original del sistema de archivos. El proceso en ejecución no se ve afectado, ya que Linux permite eliminar un archivo en ejecución mientras su imagen permanece mapeada en memoria. Este comportamiento reduce las pruebas en la ubicación de implementación original y deja solo la copia persistente, cuyo nombre resulta más verosímil.

A continuación, el módulo crea un script de inicialización ejecutable en /etc/init.d/timezone_check utilizando una plantilla de shell integrada (véase la figura 6).

Figura 6: plantilla para el script de inicio de Cyclops Blink

Para habilitar la ejecución automática, el módulo crea enlaces simbólicos para los niveles de ejecución SysV del 2 al 5, donde cada enlace apunta a ../init.d/timezone_check:

• /etc/rc2.d/S89timezone_check
• /etc/rc3.d/S89timezone_check
• /etc/rc4.d/S89timezone_check
• /etc/rc5.d/S89timezone_check

El prefijo S89 identifica el script como un servicio de inicio de SysV e indica su orden de ejecución dentro de la secuencia de arranque. En los sistemas que respetan estos directorios de niveles de ejecución de SysV, la configuración indica al sistema de inicialización que ejecute el script automáticamente según el estado del nivel de ejecución especificado, al tiempo que garantiza que timezone_check se inicie una vez que ya se hayan ejecutado los servicios a los que se les han asignado números de secuencia más bajos.

Tras instalar el servicio, el módulo avisa al controlador, hace una breve pausa y crea un proceso hijo que lanza el implante reubicado. Tanto el instalador como su proceso hijo se cierran si la ejecución falla. Si todo sale bien, el nuevo proceso empieza a ejecutarse desde la ruta persistente. La instancia reubicada reconoce que ya está instalada y no repite los cambios en el sistema de archivos.

Las rutas de instalación y el nombre del servicio se hacen pasar por componentes legítimos de Linux relacionados con la zona horaria. El código de persistencia no contiene ningún mecanismo de escalada de privilegios, por lo que una instalación exitosa indica que el implante se ejecutó con permisos suficientes para escribir en /lib y /etc. En un sistema Linux empresarial o un dispositivo de red, el acceso de escritura a estos directorios suele requerir privilegios de root o un contexto de ejecución con privilegios equivalentes.

Mando y control

Cyclops Blink se comunica con su infraestructura C2 a través de conexiones TCP salientes protegidas por TLS. Las muestras que los investigadores de la CTU analizaron contienen la dirección C2 codificada de forma fija 89[.]34[.]96[.]56 e intentan establecer conexiones a través del puerto TCP 43856 o 49172. El controlador aplica tiempos de espera de diez segundos para el envío y la recepción de sockets e intenta diferentes combinaciones de direcciones y puertos hasta que establece con éxito un protocolo de enlace TLS. El análisis de la CTU sugiere que la verificación convencional de certificados TLS está desactivada, lo que permite al implante establecer una sesión cifrada sin validar el servidor C2 a través del sistema de confianza de certificados públicos. Tras establecer una conexión TLS, el implante intercambia un protocolo de aplicación de red personalizado en lugar de utilizar HTTP.

El implante contiene la cadena de versión «OpenSSL 3.5.4 30 de septiembre de 2025» y un código de implementación coherente con la arquitectura del proveedor OpenSSL 3, lo que indica que probablemente el desarrollador enlazó el implante estáticamente con OpenSSL 3.5.4. La fecha de lanzamiento ofrece una útil referencia temporal para la compilación, aunque las cadenas de versión incrustadas pueden modificarse y no establecen por sí solas la fecha de compilación de la muestra.

En los incidentes que los investigadores de la CTU observaron, el implante envía una señal a su servidor C2 una vez por hora. Sin embargo, el controlador permite modificar en tiempo de ejecución su configuración de comunicaciones. Como se menciona en la sección de descripción general del malware, las tareas C2 pueden sustituir la lista de direcciones IPv4 activas (por hasta 32 direcciones alternativas), activar una señal inmediata, programar la siguiente conexión tras un retraso definido por el operador o cambiar el intervalo de señalización recurrente. El controlador almacena en memoria las direcciones C2 actualizadas y la información de temporización, y las distribuye a todos los módulos de trabajo registrados a través de un registro de estado de tamaño fijo.

Material criptográfico

Además de TLS, el controlador aplica una protección criptográfica independiente a nivel de aplicación a la salida de cada módulo antes de incluirla en el agregado C2 saliente. Este enfoque proporciona una capa adicional de confidencialidad dentro de la sesión TLS y cifra los datos recopilados —incluidos los detalles del host, los archivos recogidos, los resultados de los escaneos de red y los paquetes capturados— antes de su transmisión por la red. El binario de Cyclops Blink contiene tres objetos criptográficos integrados:

• una clave pública RSA-3072 independiente
• una clave privada RSA-2048
• un certificado X.509 autofirmado a juego

El implante asocia la clave pública independiente RSA-3072 a la protección en la capa de aplicación que ofrece a los datos C2 salientes. El controlador puede proporcionar a los módulos de trabajo el par independiente formado por la clave privada RSA-2048 y el certificado a través de tareas, lo que indica que el material está disponible para operaciones criptográficas o TLS a nivel de módulo, en lugar de ser un artefacto de compilación sin usar. Aún no se ha determinado el uso operativo exacto de este certificado y esta clave privada por parte de cada módulo.

Las muestras que los investigadores de la CTU analizaron contienen diferentes pares de claves RSA-2048 y certificados autofirmados, lo que indica que estos elementos no son fijos en todas las compilaciones de Cyclops Blink. Esta variación puede reflejar una generación específica por compilación, por despliegue u otra controlada por el operador, aunque los datos disponibles no aclaran con qué frecuencia se sustituye este material.

Los períodos de validez de los certificados tampoco deben interpretarse como fechas fiables de desarrollo o despliegue del malware. Como los certificados son autofirmados, sus creadores controlan los campos de validez y pueden asignar una fecha «notBefore» anterior a la creación real del certificado. Por lo tanto, los metadatos del certificado incrustados son más útiles para correlacionar muestras relacionadas e identificar variaciones criptográficas, más que para establecer cronologías de campañas o proporcionar indicadores de red duraderos.

Comparación con el informe del NCSC de 2022

Las muestras de Cyclops Blink desplegadas en 2026 conservan muchas de las características documentadas en 2022, como la arquitectura de controlador principal, los módulos de trabajo bifurcados, la comunicación entre procesos (IPC) basada en tuberías, la conmutación por error aleatoria del C2, los protocolos personalizados, el material criptográfico integrado y los distintivos módulos 0x08 y 0x0F. Sin embargo, el marco de 2026 se centra en x86-64 en lugar de en PowerPC, utiliza persistencia SysV genérica en lugar de la modificación del firmware específica de WatchGuard, incluye un conjunto de módulos reestructurado y añade escaneo activo de la red y vigilancia programable de paquetes. La tabla 4 resume estas diferencias.

Tabla 4: comparación de las versiones de Cyclops Blink

Dispositivos de red potencialmente en riesgo

Los investigadores descubrieron la versión de 2022 de Cyclops Blink en dispositivos WatchGuard comprometidos. La variante de 2026 probablemente amenace a los dispositivos de red basados en Linux x86-64 que ofrecen funciones centralizadas de gestión, seguridad, enrutamiento, acceso remoto o inspección de tráfico. Aunque los investigadores la descubrieron en FMC de Cisco, el implante no está estrechamente vinculado a la plataforma de un único proveedor. Su implementación genérica en Linux, la persistencia SysV, el modelo de ejecución modular, las conexiones de red mediante sockets sin procesar y el uso de interfaces estándar de Linux sugieren que podría funcionar en otros dispositivos compatibles una vez que un atacante haya obtenido privilegios suficientes y haya transferido el ejecutable.

Los controladores SD-WAN, los concentradores VPN, los orquestadores de red y las plataformas de gestión similares también deberían considerarse objetivos plausibles si utilizan un entorno Linux x86-64 compatible. Estos sistemas comparten varias características relevantes con el FMC: administración centralizada, acceso privilegiado a dispositivos distribuidos, visibilidad de múltiples segmentos de red y exposición a través de servicios de gestión web, API o SSH.

Atribución

Los investigadores de la CTU estiman con alta confianza que la actividad de Cyclops Blink de 2026 tiene un nexo con Rusia y, con confianza moderada, que está asociada al grupo de amenazas IRON VIKING. La evaluación se basa principalmente en la considerable continuidad a nivel de implementación entre el implante analizado y Cyclops Blink, que las agencias gubernamentales del Reino Unido y EE. UU. ya habían atribuido al grupo de amenazas Sandworm, vinculado al GRU ruso. Los investigadores de la CTU identifican a ese grupo como IRON VIKING. El menor grado de confianza en la atribución al grupo de amenazas se debe a la falta de pruebas concluyentes que vinculen directamente a IRON VIKING con los despliegues de 2026 observados.

Recomendaciones

La persistencia genérica de SysV en las muestras de Cyclops Blink de 2026 elimina la dependencia del firmware específico de WatchGuard, mientras que el escaneo activo de la red y la captura selectiva de paquetes amplían considerablemente las capacidades de recopilación de inteligencia del implante. El descubrimiento en dispositivos Cisco FMC pone de relieve el riesgo que supone una infraestructura de gestión de red comprometida. Los dispositivos en esta posición pueden proporcionar acceso a redes de gestión con privilegios, visibilidad a través de múltiples segmentos de red y una plataforma de confianza desde la que llevar a cabo reconocimientos o desplegar cargas útiles adicionales. La arquitectura de Linux, los mecanismos de persistencia, la estructura del sistema de archivos, las bibliotecas disponibles y los controles de seguridad varían según los productos y las versiones de software. Por lo tanto, las organizaciones deberían ampliar la búsqueda de amenazas más allá de la plataforma de Cisco identificada y examinar los dispositivos de red compatibles basados en Linux en busca de los indicadores documentados relacionados con el sistema de archivos, los procesos, la red y la criptografía.

Contramedidas e indicadores

La siguiente contramedida de Sophos se relaciona con esta amenaza:

• Linux/Agnt-JG

Puedes usar los indicadores de amenaza de la Tabla 5 para detectar actividad relacionada con esta amenaza. Ten en cuenta que pueden reasignar las direcciones IP. La dirección IP puede contener contenido malicioso, así que ten en cuenta los riesgos antes de abrirla en un navegador.

Tabla 5: indicadores de esta amenaza