En busca de Mythic en el tráfico de red

Marcos posteriores al abuso

Los actores maliciosos suelen emplear marcos posteriores al abuso en los ciberataques para mantener el control sobre los hosts en riesgo y desplazarse lateralmente dentro de la red de la organización. Si bien antes se preferían marcos de código cerrado, como Cobalt Strike y Brute Ratel C4, los proyectos de código abierto como Mythic, Sliver y Havoc ganaron gran popularidad en los últimos años. Los actores maliciosos también adoptan rápidamente marcos relativamente nuevos, como Adaptix C2.

El análisis de los marcos más populares reveló que su desarrollo se centra en gran medida en evadir la detección por parte de soluciones antivirus y EDR, a menudo a expensas de la discreción frente a los sistemas que analizan el tráfico de red. Si bien ocultar la actividad de red de un agente es intrínsecamente difícil, los agentes deben comunicarse inevitablemente con sus servidores de comando y control. En consecuencia, la presencia de un agente en el sistema y sus acciones maliciosas pueden detectarse con la ayuda de diversos Sistemas de Detección de Intrusos (IDS, por sus siglas en inglés) basados en la red y, por supuesto, de soluciones de Detección y Respuesta en la Red (NDR, por sus siglas en inglés).

Este artículo examina métodos para detectar el marco Mythic dentro de una infraestructura mediante el análisis del tráfico de red. Este marco ganó popularidad entre diversos actores maliciosos, incluidos Mythic Likho (Arcane Wolf) y GOFFEE (Paper Werewolf), y sigue usándose en ataques APT y otros.

El marco Mythic

Mythic C2 es una plataforma de comando y control (C&C, o C2) multiusuario diseñada para gestionar agentes maliciosos durante ciberataques complejos. Mythic se basa sobre una arquitectura de contenedores Docker, y sus componentes centrales (el servidor, los agentes y los módulos de transporte) están escritos en Python. Esta arquitectura permite a los operadores agregar nuevos agentes, canales de comunicación y modificaciones personalizadas sobre la marcha.

Dado que Mythic es una herramienta versátil para el atacante, desde la perspectiva del defensor, su uso puede alinearse con múltiples etapas de la Cadena de Ataque Unificada (Unified Kill Chain), así como con una gran cantidad de tácticas, técnicas y procedimientos del marco MITRE ATT&CK®.

• El pivotaje es una táctica en la que el atacante usa un sistema en riesgo como punto de pivote para obtener acceso a otros sistemas dentro de la red. De esta manera, expande gradualmente su presencia dentro de la infraestructura de la organización, eludiendo firewalls, la segmentación de la red y otros controles de seguridad.
• La recopilación (TA0009) es una táctica enfocada en recopilar y agregar información de valor para el atacante: archivos, credenciales, capturas de pantalla y registros del sistema. En el contexto de las operaciones de red, la recopilación a menudo se realiza localmente en los hosts en riesgo, y luego los datos se empaquetan para su transferencia. Herramientas como Mythic automatizan el descubrimiento y la selección de los datos que busca el adversario.
• La exfiltración (TA0010) es el proceso de sacar la información recopilada de la red protegida a través de canales legítimos o encubiertos, como HTTP(s), DNS o SMB, entre otros. Los atacantes pueden usar agentes residentes o relés intermedios (hosts pivote) para ocultar el origen y la ruta de la exfiltración.
• El comando y control (TA0011) abarca los mecanismos para establecer y mantener un canal de comunicación entre el operador y los hosts en riesgo con el fin de transmitir comandos y recibir actualizaciones de estado. Esto incluye conexiones directas, retransmisión a través de hosts pivote y el uso de protocolos encubiertos. Los marcos como Mythic brindan capacidades avanzadas de C2, tales como la ejecución programada de comandos, la creación de túneles y la comunicación multicanal, lo que complica la detección y el bloqueo de su actividad.

Este artículo se enfoca exclusivamente en la táctica comando y control (TA0011), cuyas técnicas pueden detectarse de manera efectiva dentro del tráfico de red de los agentes de Mythic.

Detección de la actividad de agentes Mythic en el tráfico de red

Al momento de redactar este artículo, Mythic admite la transferencia de datos a través de HTTP/S, WebSocket, TCP, SMB, DNS y MQTT. La plataforma también cuenta con más de una docena de agentes diferentes, escritos en Go, Python y C#, diseñados para Windows, macOS y Linux.

Mythic emplea dos arquitecturas principales para su red de comandos:

• En este modelo, los agentes se comunican con agentes adyacentes formando una cadena de conexiones que, finalmente, conduce a un nodo que se comunica directamente con el servidor C2 de Mythic. Para este fin, los agentes usan TCP y SMB.
• En este modelo, los agentes se comunican directamente con el servidor C2 a través de HTTP/S, WebSocket, MQTT o DNS.

Comunicación P2P

Mythic brinda capacidades de pivotaje a través de tuberías SMB con nombre y sockets TCP. Para detectar la actividad de los agentes Mythic en modo P2P, examinaremos su tráfico de red y crearemos las reglas de detección (firmas) de Suricata correspondientes.

Comunicación P2P a través de SMB

Al administrar agentes a través del protocolo SMB, se usa de manera predeterminada una tubería con nombre para la comunicación, cuyo nombre coincide con el UUID del agente.

Aunque este parámetro se puede modificar, sirve como un indicador confiable y se puede describir fácilmente con una expresión regular. Ejemplo:
[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}

Para la comunicación SMB, los agentes codifican y cifran los datos según el patrón: base64(UUID+AES256(JSON)). Luego, estos datos se dividen en bloques y se transmiten por la red. La captura de pantalla a continuación muestra cómo se ve en Wireshark una sesión de red para establecer una conexión entre agentes.

Los comandos y sus respuestas se empaquetan dentro de la estructura de datos MythicMessage. Esta estructura tiene tres campos de encabezado, así como los propios comandos o las respuestas correspondientes:

• Tamaño total (4 bytes)
• Cantidad de bloques de datos (4 bytes)
• Número de bloque actual (4 bytes)
• Datos codificados en Base64

La captura de pantalla a continuación muestra un ejemplo de comunicación SMB entre agentes.

El agente (10.63.101.164) envía un comando a otro agente en el formato MythicMessage. Las primeras tres solicitudes de escritura transmiten el tamaño total del mensaje, la cantidad total de bloques y el número de bloque actual. La cuarta solicitud transmite los datos codificados en Base64. A esto le sigue una secuencia de solicitudes de lectura, que también se transmiten en el formato MythicMessage.

A continuación se muestran los datos transmitidos en el cuarto campo de la estructura MythicMessage.

El contenido está codificado en Base64. Al decodificarlo, se hace visible la estructura de la información transmitida: comienza con el UUID del host infectado, seguido de un bloque de datos cifrado con AES-256.

El hecho de que los datos comiencen con una cadena UUID puede aprovecharse para crear una regla de detección basada en firmas que busque el patrón de identificador en los paquetes de red.

Para buscar paquetes que tengan un UUID, se puede aplicar la siguiente firma. Usa tipos de solicitud específicos e indicadores de protocolo como filtros (Command: Ioctl (11), Function: FSCTL_PIPE_WAIT (0x00110018)), seguido de una verificación para ver si el nombre de la tubería coincide con el patrón UUID.

La actividad del agente también se puede detectar analizando los datos transmitidos en paquetes SMB WriteRequest con el indicador de protocolo Command: Write (9) y una estructura de paquete distintiva en la que los campos BlobOffset y BlobLen están establecidos en cero. Si el campo Data está codificado en Base64 y, tras la decodificación, comienza con una cadena con formato UUID, esto indica un canal de comando y control.

A continuación se muestra la interfaz de usuario de KATA NDR con una alerta sobre la detección de un agente Mythic que opera en modo P2P a través de SMB. En este caso, se activó la primera regla, la cual verifica el tipo de solicitud, los indicadores de protocolo y el patrón de UUID.

Cabe señalar que estas firmas tienen una limitación. Si se usa el protocolo SMBv3 con el cifrado habilitado, la actividad del agente Mythic no se puede detectar con métodos basados en firmas. Una posible alternativa es el análisis de comportamiento. Sin embargo, en este contexto, tiene baja precisión y una alta tasa de falsos positivos. El protocolo SMB es ampliamente usado por las organizaciones para diversos fines legítimos, lo que dificulta aislar patrones de comportamiento que indiquen de manera definitiva una actividad maliciosa.

Comunicación P2P a través de TCP

Mythic también admite comunicaciones P2P a través de TCP. El proceso de inicialización de la conexión aparece en el tráfico de red de la siguiente manera:

Al igual que con SMB, se usa la estructura MythicMessage para transmitir y recibir datos. Primero, la longitud de los datos (4 bytes) se envía como un DWORD en formato big-endian en un paquete separado. Los paquetes siguientes transmiten la cantidad de bloques de datos, el número de bloque actual y los datos en sí. Sin embargo, a diferencia de los paquetes SMB, el valor del campo de número de bloque actual es siempre 0x00000000, debido al soporte integrado de fragmentación de paquetes de TCP.

El esquema de codificación de datos también es análogo al que observamos con SMB y se presenta de la siguiente manera: base64(UUID+AES256(JSON)). A continuación se muestra un ejemplo de un paquete de red que tiene datos de Mythic.

Los datos decodificados se ven así:

Al igual que en la comunicación a través de SMB, se pueden crear reglas de detección basadas en firmas para el tráfico TCP con el fin de identificar la actividad del agente Mythic mediante la búsqueda de paquetes que contengan cadenas con formato UUID. A continuación se muestran dos reglas de detección de Suricata. La primera regla es una regla de utilidad. No genera alertas de seguridad, sino que marca la sesión TCP con un indicador interno, el cual luego es verificado por otra regla. La segunda regla verifica el indicador y aplica filtros para confirmar que el paquete actual se está analizando al inicio de una sesión de red. Luego decodifica los datos Base64 y busca en el contenido resultante una cadena con formato UUID.

A continuación se muestra la interfaz de NDR con un ejemplo de las dos reglas que detectan un agente Mythic operando en modo P2P sobre TCP.

Módulos de transporte Egress

Comunicación Egress encubierta

Para operaciones sigilosas, Mythic permite administrar los agentes mediante servicios populares. Esto hace que su actividad sea menos llamativa dentro del tráfico de red. Mythic incluye módulos de transporte basados en los siguientes servicios:

• Discord
• GitHub
• Slack

De estos, solo los dos primeros siguen siendo relevantes al momento de escribir este artículo. La comunicación a través de Slack (el módulo de transporte Slack C2 Profile) ya no cuenta con el apoyo de los desarrolladores y se considera obsoleta, por lo que no la analizaremos más a fondo.

El módulo de transporte Discord C2 Profile

El uso del servicio Discord como intermediario para la comunicación C2 dentro del marco de Mythic ganó popularidad recientemente. En este caso, el tráfico del agente es indistinguible de la actividad normal de Discord, ya que los comandos y los resultados de su ejecución se presentan como mensajes y archivos adjuntos. La comunicación con el servidor se realiza a través de HTTPS y está cifrada con TLS. Por lo tanto, detectar el tráfico de Mythic requiere descifrarlo.

Análisis del tráfico TLS descifrado

Supongamos que estamos usando una plataforma NDR junto con un sistema de descifrado de tráfico de red (inspección TLS) para detectar actividad sospechosa en la red. En este caso, partimos de la suposición de que podemos descifrar todo el tráfico TLS. Examinemos las posibles reglas de detección para ese caso.

La comunicación entre el agente y el servidor se realiza mediante llamadas a la API de Discord para enviar mensajes a un canal específico. La comunicación entre el agente y Mythic usa la estructura MythicMessageWrapper, que tiene los siguientes campos:

• message: los datos transmitidos
• sender_id: un GUID generado por el agente, incluido en cada mensaje
• to_server: un indicador de dirección: un mensaje destinado al servidor o al agente
• id: no se usa
• final: no se usa

Nos interesa especialmente el campo message, que contiene los datos transmitidos codificados en Base64. El mensaje MythicMessageWrapper se transmite en texto plano, lo que lo hace accesible para cualquier persona con permisos de lectura de los mensajes en el servidor de Discord.

A continuación se muestra un ejemplo de transmisión de datos a través de mensajes en un canal de Discord.

Para establecer una conexión, el agente se autentica en el servidor de Discord mediante la llamada a la API /api/v10/gateway/bot. Observamos los siguientes datos en el tráfico de red:

Tras una inicialización exitosa, el agente adquiere la capacidad de recibir y responder a comandos. Para crear un mensaje en el canal, el agente realiza una solicitud POST al endpoint de la API /channels/<channel.id>/messages. El tráfico de red de esta llamada se muestra en la captura de pantalla a continuación.

Tras decodificar el Base64, el contenido del campo message se ve así:

Al inicio del paquete se observa una estructura característica de un UUID.

Tras procesar el mensaje, el agente lo elimina del canal mediante una solicitud DELETE al endpoint de la API /channels/{channel.id}/messages/{message.id}.

A continuación se muestra una regla de Suricata que detecta la actividad de comunicación del agente basada en Discord. Verifica la actividad de la API para la creación de mensajes HTTP en busca de datos codificados en Base64 que contengan el UUID del agente.

A continuación se muestra la interfaz de usuario de NDR con un ejemplo de detección de la actividad del módulo de transporte de Discord C2 Profile para un agente Mythic dentro del tráfico HTTP descifrado.

Análisis del tráfico TLS cifrado

Si se permite el uso de Discord en la red y no se cuenta con la capacidad de descifrar el tráfico, resulta casi imposible detectar la actividad del agente. En este caso, el análisis del comportamiento de las solicitudes al servidor de Discord puede resultar útil. A continuación se muestra el tráfico de red con conexiones TLS frecuentes al servidor de Discord, lo que podría indicar que se están enviando comandos a un agente.

En este caso, podemos usar una regla de Suricata para detectar las sesiones TLS frecuentes con los servidores de Discord:

Otro método para detectar estas comunicaciones consiste en rastrear múltiples consultas DNS al dominio discord.com.

Se puede aplicar la siguiente regla para detectarlas:

A continuación se muestra la interfaz de usuario de NDR con un ejemplo de una regla personalizada en funcionamiento, que detecta la actividad del módulo de transporte Discord C2 Profile para un agente Mythic dentro del tráfico cifrado, basándose en consultas DNS características.

Las opciones de reglas propuestas tienen baja precisión y pueden generar una gran cantidad de falsos positivos. Por lo tanto, deben adaptarse a las características específicas de la infraestructura en la que se ejecutarán. Los parámetros Threshold y count, que controlan la frecuencia de activación y la ventana de tiempo, requieren ajustes.

Módulo de transporte del perfil C2 de GitHub

La popularidad de GitHub lo convirtió en una opción atractiva como mediador para la gestión de agentes Mythic. El concepto central es el mismo que en otros módulos de transporte de comunicación encubierta de Egress. La comunicación con GitHub usa HTTPS. Para un funcionamiento correcto, se requiere una cuenta en la plataforma de destino y la capacidad de comunicarse mediante llamadas a la API. El módulo de transporte usa la API de GitHub para enviar comentarios a incidencias predefinidas y para confirmar archivos en una rama dentro de un repositorio controlado por los atacantes. En este modelo, el agente interactúa solo con GitHub: crea y lee comentarios, carga archivos y administra ramas. No se comunica con ningún otro servidor. El algoritmo de comunicación a través de GitHub es el siguiente:

1. El agente publica un comentario (registro) en una incidencia designada en GitHub, destinada a que los agentes reporten sus resultados.
2. El servidor Mythic valida el comentario, lo elimina y publica una respuesta en una incidencia designada para uso del servidor.
3. El agente crea una rama con un nombre que coincide con su UUID y escribe un archivo get_tasking en ella (realiza una solicitud de push).
4. El servidor Mythic lee el archivo y escribe un archivo de respuesta en la misma rama.
5. El agente lee el archivo de respuesta, elimina la rama, hace una pausa y repite el ciclo.

Análisis del tráfico TLS descifrado

Consideremos un enfoque para detectar la actividad del agente cuando es posible descifrar el tráfico.

La comunicación del agente con el servidor usa llamadas a la API de GitHub. La carga útil está codificada en Base64 y se publica en texto plano; por lo tanto, cualquier persona que pueda ver el repositorio o analizar el contenido del tráfico puede descodificarla.

El análisis de la comunicación del agente reveló que el tráfico más útil para crear reglas de detección está asociado con la publicación de comentarios de registro, la creación de una rama y la publicación de un archivo.

Durante la fase de registro, el agente publica un comentario para registrar un nuevo agente y establecer la comunicación.

Los datos transmitidos están codificados en Base64 y contienen el UUID del agente y la parte del mensaje cifrada con AES-256.

Esto permite crear una firma que detecte subcadenas con formato UUID dentro de las solicitudes de creación de comentarios en GitHub.

Otra etapa adecuada para la detección es cuando el agente crea una rama separada con su UUID como nombre. Toda la comunicación relevante posterior con el servidor ocurrirá dentro de esta rama. A continuación se muestra un ejemplo de una solicitud de creación de rama:

Por lo tanto, podemos crear una regla de detección para identificar cadenas con formato UUID dentro de las solicitudes de creación de ramas.

Después de crear la rama, el agente escribe un archivo en ella (envía una solicitud push), que contiene datos codificados en Base64.

Por lo tanto, podemos crear una regla que se active ante solicitudes de publicación de archivos en una rama cuyo nombre coincida con el patrón UUID.

La captura de pantalla a continuación muestra cómo la solución NDR registra todas las comunicaciones sospechosas que usan la API de GitHub y, posteriormente, identifica la actividad del agente Mythic. El resultado es una alerta con el veredicto Trojan.Mythic.HTTP.C&C.

Análisis del tráfico TLS cifrado

La comunicación con GitHub se realiza a través de HTTPS; por lo tanto, al no contar con la capacidad de descifrar el tráfico, no se pueden aplicar los métodos basados en firmas para detectar la actividad del agente. Consideremos un enfoque de detección de la actividad del agente basado en el comportamiento.

Por ejemplo, es posible detectar conexiones a servidores de GitHub que sean atípicas en cuanto a frecuencia y propósito, y que se originen en segmentos de red donde no se espera esta actividad. La captura de pantalla a continuación muestra un ejemplo de las múltiples sesiones TLS de un agente. El tráfico refleja la ejecución de varios comandos, así como el tiempo de inactividad, que se manifiesta como un sondeo constante del servidor mientras se esperan nuevas tareas.

Se pueden detectar múltiples sesiones TLS con el servicio de GitHub procedentes de segmentos de red inusuales usando la regla que se presenta a continuación:

Además, se pueden registrar en el tráfico múltiples consultas DNS dirigidas al servicio.

Esta actividad se detecta con la ayuda de la siguiente regla:

La captura de pantalla a continuación muestra la interfaz de NDR con un ejemplo de la primera regla en acción, que detecta rastros de la actividad del perfil de GitHub de un agente de Mythic dentro del tráfico TLS cifrado.

Las opciones de reglas sugeridas pueden generar falsos positivos, por lo que, para mejorar su efectividad, deben adaptarse a las características específicas de la infraestructura en la que se ejecutarán. Se deben configurar los parámetros de la palabra clave threshold, específicamente los valores de count y seconds, que controlan la cantidad de eventos necesarios para generar una alerta y el intervalo de tiempo para que estos ocurran en el NDR.

Comunicación Egress directa

El modelo de comunicación Egress permite a los agentes interactuar directamente con el servidor C2 a través de los siguientes protocolos:

• HTTP(S)
• WebSocket
• MQTT
• DNS

Los dos primeros protocolos son los más comunes. El módulo de transporte basado en DNS aún se encuentra en desarrollo y el módulo basado en MQTT tiene poco uso entre los operadores. No los analizaremos en este artículo.

Comunicación a través de HTTP

HTTP es el protocolo más común para construir una red de control de agentes Mythic. El contenedor de transporte HTTP actúa como un proxy entre los agentes y el servidor Mythic. Permite transmitir datos tanto en texto plano como en forma cifrada. Fundamentalmente, los metadatos no están cifrados, lo que permite la creación de reglas de detección basadas en firmas.

A continuación se muestra un ejemplo de tráfico de red de Mythic sin cifrar a través de HTTP. Durante una solicitud GET, los datos codificados en Base64 se pasan en el valor del parámetro query.

 

Tras la decodificación, se hace visible el UUID del agente, generado según un patrón específico. A este identificador le sigue un objeto JSON que tiene los parámetros clave del host, recopilados por el agente.

Si se aplica el cifrado de datos, el tráfico de red para la comunicación del agente se muestra tal como se ve en la captura de pantalla a continuación.

Tras descifrar el tráfico y decodificarlo de Base64, los datos de comunicación revelan la estructura habitual: UUID+AES256(JSON).

Por lo tanto, para crear una firma de detección para este caso, también podemos basarnos en la presencia de un UUID dentro de los datos codificados en Base64 en las solicitudes POST.

La captura de pantalla a continuación muestra cómo la plataforma NDR detecta la comunicación del agente con el servidor a través de HTTP, generando una alerta con el nombre Trojan.Mythic.HTTP.C&C.

Comunicación a través de HTTPS

Los agentes Mythic pueden comunicarse con el servidor a través de HTTPS usando el módulo de transporte correspondiente. En este caso, los datos se cifran con TLS y no son susceptibles de análisis basado en firmas. Sin embargo, la actividad de los agentes Mythic puede detectarse si usan el certificado SSL predeterminado. A continuación se muestra un ejemplo de tráfico de red de un agente Mythic con dicho certificado.

Para este fin, se aplica la siguiente firma:

WebSocket

El protocolo WebSocket permite la comunicación full-duplex entre un cliente y un host remoto. Mythic puede usarlo para la administración de agentes.

El proceso de comunicación del agente con el servidor a través de WebSocket es el siguiente:

1. El agente envía una solicitud al contenedor de WebSocket para cambiar el protocolo de la conexión HTTP(S).
2. El agente y el contenedor de WebSocket cambian a WebSocket para enviar y recibir mensajes.
3. El agente envía un mensaje al contenedor de WebSocket solicitando tareas del contenedor de Mythic.
4. El contenedor WebSocket reenvía la solicitud al contenedor Mythic.
5. El contenedor Mythic devuelve las tareas al contenedor WebSocket.
6. El contenedor WebSocket reenvía estas tareas al agente.

Vale la pena mencionar que, en este modelo de comunicación, tanto el contenedor WebSocket como el contenedor Mythic residen en el servidor Mythic. A continuación se muestra una captura de pantalla de la conexión inicial del agente al servidor.

Un análisis de la sesión TCP muestra que los datos reales se transmiten en el campo data con codificación Base64.

La decodificación revela la estructura de datos conocida: UUID+AES256(JSON).

Por lo tanto, podemos usar un enfoque similar a los discutidos anteriormente para detectar la actividad del agente. La firma debe basarse en la cadena UUID al inicio del campo de datos. La regla primero verifica que los datos de la sesión coincidan con el formato data:base64, luego decodifica el campo data y busca una cadena que coincida con el patrón UUID.

A continuación se muestra la firma de Trojan.Mythic.WebSocket.C&C que se activa en la comunicación del agente Mythic a través de WebSocket.

Conclusiones

El marco posterior al abuso de Mythic sigue ganando popularidad y evolucionando rápidamente. Están surgiendo nuevos agentes, diseñados para la persistencia encubierta dentro de las infraestructuras de los objetivos. A pesar de esta evolución, las diversas implementaciones de la comunicación de red en Mythic comparten muchas características comunes que se mantienen en gran medida consistentes a lo largo del tiempo. Esta consistencia permite que las soluciones IDS/NDR detecten de manera efectiva la actividad de los agentes del marco mediante el análisis del tráfico de red.

Mythic admite una amplia gama de opciones de administración de agentes usando varios protocolos de red. Nuestro análisis de las comunicaciones de los agentes a través de estos protocolos reveló que la actividad de los agentes se puede detectar buscando patrones de datos específicos dentro del tráfico de red. El criterio principal de detección consiste en rastrear cadenas UUID en posiciones específicas dentro de los datos transmitidos codificados en Base64. Sin embargo, aunque el enfoque general para detectar la actividad de los agentes es similar en todos los protocolos, cada uno requiere filtros específicos para su protocolo. Por consiguiente, crear una firma única y universal para detectar agentes de Mythic en el tráfico de red es complejo; se deben diseñar reglas de detección individuales para cada protocolo. Este artículo brinda firmas incluidas en Kaspersky Anti-Targeted Attack (KATA).

El módulo NDR de KATA está diseñado para identificar amenazas actuales dentro de las infraestructuras de red. Permite la detección de todos los marcos posteriores al abuso más comunes basándose en sus patrones de tráfico característicos. Dado que los componentes de red de estos marcos cambian con poca frecuencia, el uso de una solución NDR garantiza una alta eficacia en la detección de agentes.

Veredictos de Kaspersky en las soluciones de Kaspersky (Kaspersky Anti-Targeted Attack con módulo NDR y Kaspersky NGFW)

Trojan.Mythic.SMB.C&C
Trojan.Mythic.TCP.C&C
Trojan.Mythic.HTTP.C&C
Trojan.Mythic.TLS.C&C
Trojan.Mythic.WebSocket.C&C