Construya sus defensas contra los ataques de envenenamiento de caché DNS

Puntos Clave

• El envenenamiento de la caché DNS falsifica los registros DNS almacenados en caché de un servidor DNS, de modo que las búsquedas de un dominio real devuelven una dirección IP controlada por el atacante, sin tocar el dispositivo de la víctima.
• Esta técnica se dio a conocer ampliamente después de que el investigador de seguridad Dan Kaminsky revelara una vulnerabilidad crítica en un resolvedor DNS en 2008 (CVE-2008-1447), lo que obligó a que se lanzara un parche coordinado a nivel de toda la industria entre los proveedores de DNS.
• Sigue siendo un riesgo activo. ISC reveló fallos de envenenamiento de caché en BIND 9 (CVE-2025-40778 y CVE-2025-40780) en octubre de 2025, y los investigadores informaron de una campaña de envenenamiento de DNS por parte del grupo de amenazas Evasive Panda a finales de 2025.
• Ningún control por sí solo lo detiene. La aleatorización del puerto de origen reduce el margen de error, DNSSEC autentica las respuestas criptográficamente y DoH/DoT cifra la ruta de consulta para que los atacantes que se encuentren en ella no puedan leerla ni manipularla.
• El despliegue de DNSSEC aún es desigual. APNIC Labs midió que la validación global de DNSSEC alcanzaría aproximadamente el 36 por ciento en 2025, lo que supone un avance con respecto a hace una década, pero aún deja a la mayoría de los resolvedores sin la capacidad de verificar criptográficamente lo que almacenan en caché.

Publicado: mayo de 2022. Actualizado: agosto de 2026. Revisado por el equipo de seguridad de Encryption Consulting.

¿Qué es el envenenamiento de la caché DNS y cómo funciona?

El envenenamiento de la caché DNS es un ataque que inyecta una respuesta falsificada en la caché de un servidor DNS, de modo que las futuras consultas a un dominio legítimo devuelvan una dirección IP controlada por el atacante en lugar de la real. El Sistema de Nombres de Dominio (DNS) traduce los nombres de dominio legibles por humanos a direcciones IP. Un servidor DNS recursivo, el tipo de servidor más afectado por este ataque, realiza dicha traducción en nombre del cliente y almacena temporalmente la respuesta en caché para no tener que repetir la consulta en cada solicitud.

La resolución DNS depende de dos roles de servidor. Los servidores de nombres autoritativos almacenan los registros oficiales de los dominios para los que están configurados. Los resolvedores recursivos realizan la búsqueda en nombre del cliente, consultando a los servidores autoritativos según sea necesario y almacenando en caché la respuesta. Este artículo se centra en los ataques contra los resolvedores recursivos, ya que una caché recursiva comprometida afecta a todos los clientes que la consultan.

En el ataque clásico, un atacante externo (que no puede ver directamente el tráfico DNS legítimo) engaña a un resolvedor para que envíe una consulta a un servidor de nombres autoritativo y, a continuación, intenta inyectar una respuesta falsificada antes de que llegue la real. Para ser aceptada, la respuesta falsificada debe coincidir con la IP de origen y destino de la consulta, el puerto de origen y destino (históricamente fijo en el puerto 53) y un identificador de transacción (TxID) de 16 bits. Con el puerto fijo, un atacante solo tenía que adivinar el TxID de 16 bits, un espacio lo suficientemente pequeño como para realizar un ataque de fuerza bruta con aproximadamente 65 536 respuestas falsificadas, y técnicas como el ataque de cumpleaños podrían reducirlo aún más.

Envenenamiento de caché frente a suplantación de DNS: ambos términos describen el mismo objetivo subyacente (lograr que un servidor DNS o un cliente acepte una respuesta DNS falsa), pero difieren en su alcance. La suplantación de DNS es la categoría más amplia, que abarca cualquier respuesta DNS falsificada, incluyendo la interceptación de un ataque de intermediario en una red local. El envenenamiento de caché DNS se refiere específicamente a lograr que esa respuesta falsificada persista en la caché de un servidor DNS, de modo que siga proporcionando respuestas erróneas a todos los clientes posteriores hasta que caduque la entrada de la caché.

¿Cuál es la historia del envenenamiento de la caché DNS? Eventos clave e incidentes recientes.

El envenenamiento de la caché DNS no es un incidente aislado, sino una técnica de ataque de larga data con un historial de revelaciones importantes y una explotación continua en el mundo real. Tres eventos definen su cronología.

1. 2008, la vulnerabilidad Kaminsky (CVE-2008-1447). El investigador de seguridad Dan Kaminsky descubrió una vulnerabilidad en la forma en que los resolvedores DNS gestionaban la aleatoriedad de TxID, lo que permitía realizar ataques de envenenamiento de caché a gran escala contra prácticamente todas las implementaciones de DNS en uso. La divulgación se realizó mediante una publicación coordinada de parches por parte de varios proveedores, en lugar de un aviso habitual de un solo proveedor, lo que aún se cita como uno de los primeros esfuerzos de divulgación coordinada a gran escala en la seguridad de la infraestructura de Internet. Como resultado directo, la aleatorización del puerto de origen se convirtió en una configuración predeterminada casi universal.
2. Octubre de 2025, fallos de envenenamiento de caché en BIND 9 (CVE-2025-40778 y CVE-2025-40780). El Consorcio de Sistemas de Internet (ISC) reveló vulnerabilidades en BIND 9, una de las implementaciones de resolución DNS más utilizadas, que permitían el envenenamiento de caché mediante registros de recursos no solicitados. Poco después se publicó un código de prueba de concepto, y los investigadores de seguridad estimaron que cientos de miles de servidores BIND conectados a internet ejecutaban versiones vulnerables en el momento de la divulgación. Esto demuestra que el envenenamiento de caché no es solo un problema de 2008; las fallas de implementación que lo permiten siguen apareciendo en el software DNS actual.
3. A finales de 2025, la campaña de envenenamiento DNS de Evasive Panda. Los investigadores de Securelist de Kaspersky informaron que el grupo de ciberdelincuentes Evasive Panda, vinculado a China, utilizó técnicas de envenenamiento de DNS junto con ataques de intermediario para redirigir a los usuarios objetivo hacia una infraestructura maliciosa que distribuía la puerta trasera MgBot. Este es un ejemplo documentado del uso operativo del envenenamiento de caché por parte de un actor vinculado a un Estado, y no solo una vulnerabilidad teórica del protocolo.
4. En curso, la respuesta DNSSEC y de transporte cifrado. DNSSEC (DNS Security Extensions), estandarizado en los RFC 4033 a 4035 de la IETF, firma criptográficamente los registros DNS para que un resolvedor validador pueda detectar una respuesta falsificada en lugar de confiar en la primera que llegue. DNS sobre HTTPS (DoH, RFC 8484) y DNS sobre TLS (DoT, RFC 7858) cifran la consulta en sí, cerrando así otra superficie de ataque: la interceptación y manipulación en ruta. Estas tres defensas (aleatorización del puerto de origen, DNSSEC y DoH/DoT) constituyen la base de las mejores prácticas actuales, y ninguna de ellas por sí sola es suficiente.

¿Qué tecnologías y sistemas se ven afectados por el envenenamiento de la caché DNS?

Técnicamente, cada capa de almacenamiento en caché DNS en una cadena de resolución moderna está expuesta a ataques de envenenamiento, no solo el resolvedor recursivo que la mayoría de la gente imagina.

• Resolutores de stubs del sistema operativo. El sistema operativo del cliente mantiene su propia caché DNS y reenvía las consultas a niveles superiores en lugar de resolverlas iterativamente. Una caché de reenvío comprometida afecta a un solo dispositivo, pero a menudo se pasa por alto en la monitorización DNS empresarial.
• Reenviadores DNS. Los reenviadores, que suelen estar integrados en los routers Wi-Fi de hogares y pequeñas oficinas, mantienen su propia caché y envían las consultas a un servidor de resolución recursivo superior. Una caché de router dañada afecta a todos los dispositivos de esa red.
• Resolutores recursivos, incluidos los resolutores de ISP y los resolutores públicos. Este es el objetivo clásico, ya que una entrada manipulada se sirve a cada cliente que la consulta hasta que expire el TTL del registro.
• Infraestructura DNS empresarial. Los servidores DNS internos que resuelven direcciones para redes corporativas, clientes VPN y cargas de trabajo en la nube son objetivos de alto valor, ya que un registro interno manipulado puede redirigir el tráfico de autenticación, las comprobaciones de actualización de software o las llamadas a la API.
• Software DNS autoritativo. El caso BIND 9 en 2025 demostró que las vulnerabilidades en el propio software de resolución, y no solo las debilidades del protocolo, pueden reabrir el envenenamiento de caché incluso después de que existan la aleatorización del puerto de origen y la compatibilidad con DNSSEC.

¿Cuál es el impacto de un ataque exitoso de envenenamiento de caché DNS?

Un ataque exitoso de envenenamiento de caché DNS otorga al atacante el control sobre adónde se dirige realmente el tráfico de la víctima, sin que esta realice ningún cambio en su propio dispositivo.

• Redirección de tráfico. Los usuarios que introducen un nombre de dominio legítimo son redirigidos silenciosamente a un servidor controlado por el atacante.
• Robo de credenciales. El tráfico redirigido a una página de inicio de sesión que imita a la original puede recopilar nombres de usuario, contraseñas y tokens de sesión.
• Posicionamiento de hombre en el medio. Un atacante que controla la resolución DNS para un objetivo puede interceptar y, en algunas configuraciones, modificar el tráfico entre el cliente y el destino previsto.
• Distribución de malware. Los registros manipulados pueden dirigir las comprobaciones de actualización de software o los enlaces de descarga hacia la infraestructura del atacante, como se documenta en la campaña Evasive Panda.
• Erosión de los pilares de confianza que dependen del DNS. La validación del dominio del certificado, las comprobaciones de registros CAA y la autenticación de correo electrónico (SPF, DKIM, DMARC) dependen de que las respuestas DNS sean fiables. Un resolvedor manipulado durante la validación del control de dominio puede, en determinadas circunstancias, comprometer la integridad de dicho paso de validación.

¿Cómo se detecta el envenenamiento de la caché DNS?

La detección combina la monitorización específica de DNS con la misma disciplina de detección de anomalías que se utiliza en otras partes de la red.

1. Supervise posibles cambios inesperados de TTL o IP. Un cambio repentino en la dirección IP resuelta de un dominio conocido, o un TTL inusualmente corto en un registro que normalmente cambia con poca frecuencia, es un indicador común de envenenamiento.
2. Habilitar el registro de validación DNSSEC. Un resolvedor validador registrará y rechazará las respuestas que no superen la validación de la firma, lo cual es una señal directa de un intento de falsificación.
3. Esté atento a un volumen de consultas anormales dirigidas a un único servidor de nombres. Un aumento repentino en las consultas o fallos en las consultas contra un servidor autoritativo puede indicar que un atacante está intentando "anclar" un resolvedor a un único servidor de nombres, que es más fácil de falsificar.
4. Verifique los resultados de la resolución desde múltiples puntos de vista. Comparar los resultados que devuelven los resolvedores internos, los resolvedores públicos y los servicios de monitorización de terceros para el mismo dominio puede revelar un evento de envenenamiento localizado que pasaría desapercibido desde un único punto de vista.
5. Realizar un seguimiento de las versiones del software de resolución y reenvío en función de los avisos de seguridad. Las vulnerabilidades de BIND 9 de 2025 eran explotables específicamente en versiones sin parchear, por lo que el seguimiento de versiones en comparación con los avisos del proveedor (ISC, en el caso de BIND) constituye un control de detección y prevención a la vez.

¿Cómo remediar y prevenir el envenenamiento de la caché DNS? Una lista de verificación numerada.

Ningún control por sí solo elimina por completo el envenenamiento de la caché DNS. La mejor práctica de defensa actual se basa en un enfoque por capas.

1. Confirme que la aleatorización del puerto de origen esté activa. El software de resolución moderno habilita esto por defecto, pero conviene confirmarlo en cualquier infraestructura DNS heredada o configurada a medida. Esto aumenta el margen de error al que se enfrenta un atacante externo de 16 bits a aproximadamente 32 bits.
2. Implemente DNSSEC en las zonas autoritativas que usted controla. Firmar tus propios dominios permite que cualquier resolvedor validador detecte una respuesta falsificada para tu dominio. Esto protege los dominios de tu organización incluso antes de que todos los resolvedores de internet los validen.
3. Habilita la validación DNSSEC en los servidores DNS que administras. Firmar por sí solo no sirve de nada si los servidores DNS que usa su organización no validan las firmas. Es necesario que ambos componentes de DNSSEC, tanto la firma como la validación, estén presentes.
4. Trasladar el tráfico DNS interno y de clientes a DoH o DoT. El cifrado de la ruta de consulta impide que los atacantes que se encuentren en dicha ruta lean o manipulen el tráfico DNS entre el cliente y el servidor DNS.
5. Actualizar el software del servidor DNS y del resolvedor según un calendario predefinido. Las vulnerabilidades de envenenamiento de caché de BIND 9 de 2025 son un recordatorio directo de que parchear el software de resolución es un control de envenenamiento de caché, no solo una medida de higiene general.
6. Restringe los servidores de nombres que utilizan tus dominios y monitoréalos. Un menor número de servidores de nombres autoritativos, pero bien supervisados, reducen la superficie de ataque que un atacante externo puede aprovechar con técnicas de "fijación" de fallos de consulta.
7. Agregue registros CAA a sus zonas DNS. Los registros CAA (Autorización de Autoridad de Certificación) limitan qué autoridades de certificación pueden emitir certificados para su dominio, lo que reduce el impacto si la confianza del DNS se ve brevemente comprometida durante la emisión del certificado.
8. Registrar y alertar continuamente sobre anomalías de DNS. Incorpore los registros de resolución, los fallos de validación DNSSEC y las alertas de cambio de TTL/IP al sistema de monitorización para detectar rápidamente un intento de envenenamiento en lugar de descubrirlo después de que haya tenido lugar.

¿Qué ha cambiado en la seguridad DNS desde la publicación de este artículo? Registro de actualizaciones

Este artículo se publicó por primera vez en mayo de 2022 y se actualizó sustancialmente en agosto de 2026. Desde su publicación original, los siguientes acontecimientos han modificado el panorama de la seguridad DNS:

• En octubre de 2025, ISC reveló y corrigió las vulnerabilidades de envenenamiento de caché CVE-2025-40778 y CVE-2025-40780 de BIND 9, lo que demuestra que los fallos de implementación, y no solo las debilidades a nivel de protocolo, siguen permitiendo el envenenamiento de caché en el software de resolución ampliamente utilizado.
• Investigadores de seguridad documentaron que el grupo Evasive Panda, vinculado a China, utilizó operativamente el envenenamiento de DNS, junto con técnicas de ataque de intermediario (adversario-in-the-middle), para distribuir la puerta trasera MgBot, transformando el envenenamiento de caché de un riesgo teórico para el protocolo a una técnica explotada activamente en campañas vinculadas a estados nación.
• Según las mediciones de APNIC Labs, la validación global de DNSSEC aumentó a aproximadamente el 36 por ciento para 2025, un progreso significativo con respecto a los bajos porcentajes de un solo dígito que citaba originalmente este artículo, pero que aún deja a la mayoría de los resolvedores incapaces de verificar criptográficamente lo que almacenan en caché.
• DNS sobre HTTPS y DNS sobre TLS pasaron de ser propuestas emergentes a configuraciones predeterminadas generalizadas en los principales navegadores y sistemas operativos, añadiendo una capa de defensa de transporte cifrado que la versión original de este artículo de 2022 no cubría.
• La decisión del CA/Browser Forum de reducir los períodos de validez de los certificados TLS (un límite de 200 días a partir de marzo de 2026, que se reducirá a 47 días en marzo de 2029) aumenta la frecuencia con la que se ejecuta la validación del control de dominio, lo que incrementa la importancia de la integridad del DNS durante ese período de validación.

¿Qué medida de protección contra el envenenamiento de la caché DNS debería implementar primero?

Cada medida de defensa aborda una parte diferente del problema. Utilice esta tabla para secuenciar el despliegue, en lugar de considerar que una sola fila es suficiente por sí sola.

Mecanismo de defensa	Contra qué protege	Complejidad de implementación
Aleatorización del puerto de origen	Adivinación de TxID fuera de ruta (el clásico ataque al estilo Kaminsky)	Bajo, valor predeterminado en el software de resolución moderno
DNSSEC (firma de tus zonas)	Respuestas falsificadas para tus propios dominios, validadas criptográficamente por resolvedores que verifican firmas.	De nivel medio a alto, requiere gestión de claves y firma de zona.
DNSSEC (validación en sus servidores DNS)	No se aceptan respuestas falsificadas para ningún dominio firmado que usted consulte.	Medio, principalmente un cambio de configuración del resolvedor
DNS sobre HTTPS (DoH)	Intercepción en ruta y manipulación de la propia consulta DNS.	Medio, necesita soporte para el cliente y el solucionador.
DNS sobre TLS (DoT)	Igual que DoH, transporte de consulta cifrada	Medio, necesita soporte para el cliente y el solucionador.
codificación 0x20	Agrega un grado limitado de aleatoriedad adicional mediante mayúsculas y minúsculas, mitigación parcial únicamente.	Soporte de servidor autoritativo bajo pero inconsistente
Monitorización de DNS y detección de anomalías	Detecta intentos de envenenamiento y cambios inesperados en los registros después de que ocurran.	Nivel medio a alto, requiere infraestructura de registro y alertas.

Limitaciones de las defensas contra el envenenamiento de la caché DNS

No tener control sobre esta lista por sí solo no es una solución completa, y las organizaciones deberían planificar una defensa en profundidad en lugar de una solución milagrosa.

• DNSSEC solo protege los dominios firmados y únicamente cuando el resolvedor que realiza la consulta realiza una validación. Dado que la validación global aún abarca aproximadamente un tercio de los resolvedores en 2025, la mayor parte del tráfico DNS a nivel mundial no se verifica criptográficamente.
• DoH y DoT protegen la consulta en tránsito, pero no autentican el contenido de la respuesta como lo hace DNSSEC. Un atacante que compromete el propio servidor de resolución, en lugar de la ruta de red, no se detiene solo con el cifrado.
• La aleatorización del puerto de origen aumenta el coste de un ataque, pero no lo hace imposible, y los errores de implementación en el software de resolución (como con las vulnerabilidades de BIND 9 de 2025) pueden reabrir rutas de envenenamiento independientemente de la aleatorización del puerto.
• Los resolvedores stub del lado del cliente y los enrutadores de consumo suelen ser el eslabón más débil, ya que los esfuerzos de las empresas para reforzar el DNS a menudo se detienen en el resolvedor recursivo y no se extienden a todos los reenviadores de la red.

¿Qué recomendaría Encryption Consulting?

Consideramos la integridad del DNS como un problema de confianza fundamental, no solo un problema de red. Las respuestas DNS influyen directamente en decisiones cruciales para la confianza criptográfica, como la validación del control de dominio para la emisión de certificados TLS y la aplicación de la CAA. Nuestra recomendación básica para los clientes es seguir la lista de verificación anterior: confirmar que la aleatorización del puerto de origen ya está implementada (casi siempre lo está en el software actual), y luego priorizar la firma DNSSEC en zonas externas, la validación en resolvedores internos y DoH o DoT para el tráfico de clientes, en ese orden. El ritmo de aplicación de parches para el software del servidor DNS debe seguirse con la misma rigurosidad que cualquier otro servicio con acceso a internet, dado que las recientes vulnerabilidades de BIND 9 demostraron que el software de resolución sigue siendo una superficie de ataque activa.

Dado que la resolución DNS es fundamental para la validación del control de dominios, las organizaciones que gestionan su propia infraestructura de autoridad de certificación o que dependen de CA públicas deben considerar el endurecimiento de DNS como parte de su cadena de confianza PKI, y no como un proceso independiente. Si su equipo está evaluando cómo se integran la validación basada en DNS, la aplicación de CAA y la emisión de certificados, nuestro equipo de PKI como servicio y nuestros servicios de asesoramiento en cifrado pueden ayudarle a determinar dónde las deficiencias en la integridad de DNS podrían debilitar la confianza en los certificados en su entorno. Encryption Consulting cuenta con las certificaciones ISO/IEC 27001:2022 y SOC 2, y recomendamos consultar con un asesor en lugar de tratar esto como una simple lista de verificación de configuración, ya que tanto el software de resolución como la actividad de amenazas DNS están en constante evolución.

Conclusión

El envenenamiento de la caché DNS ha sido una vulnerabilidad conocida y explotable desde mucho antes de que la revelación de Kaminsky en 2008 la hiciera imposible de ignorar, y no ha desaparecido. Las vulnerabilidades de BIND 9 de 2025 y la campaña Evasive Panda demuestran que se trata de un riesgo real y actual, no de un problema resuelto en un libro de texto antiguo. La aleatorización del puerto de origen es fundamental. DNSSEC y el transporte DNS cifrado (DoH/DoT) constituyen la capa de mejores prácticas actual, y ninguna de ellas es opcional si la integridad del DNS es crucial para la seguridad de su organización, incluida la validación del dominio de la que dependen sus certificados TLS. Implemente la defensa por capas descrita anteriormente, actualice el software de resolución de forma regular y supervise las anomalías que indiquen un intento en curso.

Preguntas frecuentes

¿Cuál es la diferencia entre el envenenamiento de caché DNS y la suplantación de DNS? La suplantación de DNS es la categoría general de falsificación de una respuesta DNS, incluidos los ataques de intermediario en redes locales. El envenenamiento de caché DNS es un tipo específico de suplantación en el que la respuesta falsificada se almacena en la caché de un servidor DNS, de modo que sigue afectando a todos los clientes que consultan dicho servidor hasta que caduca el registro almacenado, y no solo al cliente objetivo del ataque inicial.

¿Puede DNSSEC por sí solo detener los ataques de envenenamiento de caché DNS? No. DNSSEC solo protege los dominios firmados y solo es efectivo si el servidor DNS que realiza la consulta valida las firmas. Dado que la validación global de DNSSEC aún abarca aproximadamente un tercio de los servidores DNS en 2025, los dominios no firmados y los servidores DNS que no validan las firmas siguen expuestos, independientemente de que DNSSEC sea un estándar.

¿Cómo puedo saber si mi servidor DNS ha sido atacado? Preste atención a si un dominio conocido se resuelve repentinamente a una dirección IP desconocida, si el tiempo de vida (TTL) de un registro que normalmente cambia con poca frecuencia es inusualmente corto, si se producen fallos de validación DNSSEC en los registros del servidor o si los usuarios informan de advertencias de certificados en sitios que normalmente se cargan sin ellas. La forma más rápida de confirmar un ataque localizado es comparar los resultados de resolución en servidores DNS internos, públicos y de terceros.

¿Reemplazan DNSSEC a HTTPS (DoH) y DNS sobre TLS (DoT)? No, resuelven problemas diferentes. DoH y DoT cifran la consulta DNS durante la transmisión, lo que impide la interceptación y manipulación en ruta. DNSSEC firma criptográficamente la respuesta DNS, lo que impide que un servidor DNS acepte un registro falsificado, incluso si llega a través de un canal que, de otro modo, sería seguro. Las organizaciones necesitan ambos, no uno en lugar del otro.

¿Con qué frecuencia debemos auditar nuestra infraestructura DNS para detectar riesgos de envenenamiento de caché? Como mínimo, revise las versiones del software del servidor DNS y del resolvedor según los avisos del proveedor cada vez que se publique una actualización de seguridad, y realice una revisión completa de la configuración (aleatorización del puerto de origen, estado de firma y validación de DNSSEC, registros CAA, compatibilidad con transporte cifrado) al menos dos veces al año o después de cualquier cambio en la infraestructura DNS.

Referencias

• Base de conocimientos de ISC, “CVE-2008-1447: Problema de envenenamiento de caché DNS (el error de Kaminsky)”: https://kb.isc.org/docs/aa-00924
• Base de conocimientos de ISC, “CVE-2025-40778: Ataques de envenenamiento de caché con registros de recursos no solicitados”: https://kb.isc.org/docs/cve-2025-40778
• IETF RFC 4033 a RFC 4035, “Introducción y requisitos de seguridad DNS” y especificaciones DNSSEC relacionadas: https://datatracker.ietf.org/doc/html/rfc4033
• IETF RFC 8484, “Consultas DNS sobre HTTPS (DoH)”: https://datatracker.ietf.org/doc/html/rfc8484
• IETF RFC 7858, “Especificación para DNS sobre seguridad de la capa de transporte (TLS)”: https://datatracker.ietf.org/doc/html/rfc7858
• APNIC Labs, “Hacia una práctica recomendada en la industria para la automatización de DNSSEC” (mediciones de validación de DNSSEC de 2025): https://blog.apnic.net/2026/02/25/towards-an-industry-best-practice-for-dnssec-automation/
• Kaspersky Securelist, “El APT Panda evasivo envenena las solicitudes DNS para distribuir MgBot”: https://securelist.com/evasive-panda-apt/118576/