Mientras que las nuevas formas de ciberdelincuencia van en aumento, las actividades tradicionales parecen estar cambiando hacia técnicas más avanzadas que implican la explotación de herramientas y protocolos estándar del sistema operativo que no siempre son monitoreados.

El último ejemplo de este tipo de ataque es DNSMessenger, un nuevo troyano de acceso remoto (RAT) que utiliza consultas DNS para ejecutar comandos maliciosos de PowerShell en computadoras comprometidas, técnica que hace que el RAT sea difícil de detectar en cualquier sistema tradicional.

El troyano llamó la atención del grupo de investigación Talos de Cisco. Un investigador de seguridad destacó un tweet que codificaba texto en un Script de PowerShell que tenía la cadena "SourceFireSux". SourceFire es uno de los productos de seguridad corporativos de Cisco.

El ataque de DNSMessenger es completamente sin archivos

Un análisis más profundo del malware llevó finalmente a los investigadores de Talos a descubrir un ataque sofisticado que comprendía un documento malicioso de Word y una puerta trasera de PowerShell que se comunicaba con los servidores de Comando y Control a través de solicitudes DNS.

Distribuido a través de una campaña de phishing de correo electrónico, el ataque DNSMessenger es completamente Fileless, ya que no implica escribir archivos en el sistema de destino. En su lugar, utiliza las capacidades de mensajería DNS para obtener comandos maliciosos de PowerShell almacenados de forma remota como registros TXT en los DNS. Esta característica lo hace invisible a cualquier defensa estándar contra el malware.

Según el post publicado por los investigadores de Talos Edmund Brumaghin y Colin Grady, "El documento malicioso de Word ha sido diseñado para parecer como si estuviera asociado con un servicio de correo electrónico seguro, garantizado por McAfee".

Cómo funciona el ataque DNSMessenger

Cuando se abre, el documento inicia una macro de Visual Basic para Aplicaciones (VBA) y ejecuta una secuencia de comandos PowerShell, en un intento de ejecutar la puerta trasera en el sistema de destino. Hasta este punto, todo se realiza en memoria, sin escribir ningún archivo malicioso en el disco del sistema.

A continuación, la secuencia de comandos de VBA descomprime un segundo y sofisticado script  de PowerShell, que implica comprobar varios parámetros del entorno, como los privilegios del usuario conectado y la versión de PowerShell instalada en el sistema. Esta información se utiliza para asegurar la persistencia en el host infectado, cambiando el registro de Windows e instalando un tercer script PowerShell que contiene una simple puerta trasera.

Si la víctima tiene acceso administrativo, esta puerta trasera se agrega a la base de datos de Windows Management Instrumentation (WMI), permitiendo que el malware permanezca persistente en el sistema, incluso después de un reinicio. Este script adicional establece un sofisticado canal de comunicaciones de dos vías a través DNS, usualmente usado para buscar direcciones IP asociadas con nombres de dominio, pero tiene soporte para diferentes tipos de registros.

La puerta trasera de malware de DNSMessenger utiliza los registros DNS TXT que, por definición, permiten a un servidor DNS adjuntar texto sin formato en una respuesta.

La puerta trasera periódicamente envía consultas DNS a una de una serie de dominios codificados en su código fuente. Como parte de esas solicitudes, recupera el registro DNS TXT del dominio, que contiene otros comandos de PowerShell, que se ejecutan en el sistema pero nunca generan archivos locales. Esta "cuarta etapa" de Powershell es la herramienta de control remoto real utilizada por los delincuentes.

Todos los comandos maliciosos y las salidas de los mismos son manipulados dentro de los registros TXT de los dominios controlados por los delicuentes. En este momento, todos los dominios registrados por DNSMessenger han sido dados de baja, por lo que hasta ahora, no se sabe qué tipos de comandos transmitieron a y desde los sistemas infectados. Sin embargo, los investigadores dicen que este RAT particular se utilizó en un pequeño número de ataques dirigidos.

Esta muestra de malware ilustra la importancia de que además de inspeccionar y filtrar protocolos de red como HTTP / HTTPS, SMTP / POP3, etc, se debe inspeccionar el tráfico DNS dentro de las redes corporativas y debe considerarse un canal que un atacante puede usar para implementar un protocolo completamente funcional y bidireccional para una infraestructura C&C.

Fuente: The Hacker News