El “honeypot” de Winnti – un manjar para atraer a los intrusos

Al investigar al grupo Winnti, descubrimos una cantidad considerable de ejemplares de Winnti que atacaban a diferentes compañías de juegos. Usando este sofisticado programa malicioso , los cibercriminales obtuvieron acceso remoto a los equipos infectados de la empresa y continuaron con el ataque de forma manual.

Por supuesto, nos entusiasmó descubrir cómo las bibliotecas maliciosas se propagaban mediante la red local. Para hacerlo, rastreamos la actividad del atacante en un equipo infectado.

Primer intento: Equipo virtual #1

Al comenzar la investigación ejecutamos los programas maliciosos en un equipo virtual, lo que funcionó sin mayores problemas, hasta detectamos actividad de los cibercriminales. Pero no tardaron en darse cuenta de que no era un equipo que querían en su red y los servidores del atacante dejaron de responder a las solicitudes de los bots de los equipos virtuales.

Esto es lo que aprendimos en esta primera etapa de vigilancia:

En primer lugar, los atacantes veían lo que sucedía en el escritorio de la víctima. Después activaban la línea de comando a distancia y la usaban para buscar la carpeta raíz en el disco actual y así encontrar el archivo winmm.dll, y revisaban la versión del sistema operativo. Después entró en juego el complemento ListFileManager. Funciona con el sistema de archivos y los atacantes lo usaron para buscar las carpetas C:Windows y C:Work. Entonces trataron de reiniciar el equipo, pero cometieron un error en los parámetros del comando “shutdown” al escribir “shutdown /t /r 1” (el equipo debería reiniciarse en un segundo), pero poco después apagaron el equipo por completo usando el comando correcto: “shutdown /s /t 1”.

Secuencia de sucesos:

(Nota:
	– módulo de línea de comando remoto – CmdPlus.dll,
	– trabajo con sistema de archivos – ListFileManager.dll, TransPlus.dll)

Cuando se reinició el equipo virtual, los usuarios maliciosos se conectaron y descargaron un programa auxiliar llamado ff._exe_ en el folder Config.Msi.

(ff._exe_, MD5: 0xd2d6115a337cf4f40402d15cb9ece2ea, veredicto: Trojan.Win32.KillWin.sp)

Este programa busca este tipo de archivos en el disco duro:

• Documentos HTML (.htm, .html)
• Tablas de MS Excel (.xls, .xlsx)
• Presentaciones de PowerPoint (.ppt)
• Archivos de texto (.txt)
• Documentos de Microsoft Word (.doc, .docx)
• HTMLHelp (.chm) – archivos de ayuda de contexto
• Documentos de MS Works (.wps)
• Documentos de Adobe Reader (.pdf)

Además, ff._exe_ tiene una función destructiva: si el programa no reconoce el sistema de archivos del disco como FAT o NTFS, inicia un proceso para llenar el disco de ceros. Aunque el equipo virtual en cuestión tenía un sistema de archivos NTFS en todos los discos, ff._exe_ no pudo reconocer el sistema de archivos y comenzó con la limpieza del disco. Parece que los atacantes eran conscientes de esta falla en el programa y estaban tratando de evitar que el sistema operativo colisione obligando al programa a dejar de funcionar, pero lo hicieron demasiado tarde. Como resultado, el disco duro se había llenado con tantos ceros que el sistema operativo “murió”.

Sequencia de eventos:

Después de eso, habría sido sospechoso que el equipo virtual volviera a funcionar y se infectara de nuevo. Los intrusos se habrían sorprendido si un equipo infectado que acababan de “matar” volvía a funcionar 10 minutos después y un bot le informaba al C&C que estaba trabajando en el sistema con la misma configuración. Así que decidimos usar otro sistema operativo y, para estar seguros, otra variante del bot.

Segundo intento: Equipo virtual #2

Ejecutamos el nuevo bot en el nuevo equipo virtual y, después de un rato, los intrusos estaban activos en el equipo infectado. Descargaron tres archivos – wm.bat, ctime.exe y wm3280.dll – y ejecutaron wm.bat.

Archivo de lotes wm.bat:

• copia la última versión de la biblioteca maliciosa wm3280.dll a la carpeta c:windows bajo el nombre de winmm.dll;
• especifica el tiempo que atribuye al archivo que acaba de copiar (tiempo de creación, tiempo de modificación y último acceso) para que sean iguales a los de la biblioteca del sistema c:windowstwain.dll;
• especifica los atributos de la biblioteca maliciosa como “hidden”, “system”, “read only”;

Después, se descarga y ejecuta otro programa auxiliar: ec.exe.

(ec.exe, MD5: 0x14c112794ca492b7a82fa11f94b5b8b3, veredicto: Trojan-PSW.Win32.Certif.a)

Este programa busca certificados instalados en el sistema que contengan una llave privada. Si los encuentra, los guarda como archivos en el disco. Cuando el programa termina de trabajar, los intrusos usan el comando “dir” para revisar si ha aparecido algún certificado. Como el sistema operativo virtual infectado no tenía instalados certificados de este tipo, los atacantes perdieron el interés y eliminaron el programa ec.exe.

Después ingresaron de forma manual a los archivos del disco C:, encontraron una carpeta llamada “Sign” que yo había creado antes para guardar un certificado con el que se había firmado un programa. Esto volvió a despertar el interés de los cibercriminales en la carpeta y en un archivo con extensión “.cer” y copiaron el archivo.

Cuando se completó el robo del certificado, los atacantes usaron el comando “net view” para ver qué equipos existían en la red y desplegaron una lista de todas las conexiones establecidas con el comando “netstat-an”.

Esto es todo lo que les pareció interesante de mi equipo virtual. Después de analizar los datos que consiguieron, se dieron cuenta de que era un sistema falso y el servidor de C&C dejó de aceptar conexiones del bot que funcionaba en ese equipo virtual.

Secuencia de sucesos:

wm.bat:

Después de eso, no nos arriesgamos a usar más equipos virtuales – podríamos asustar a los cibercriminales. Entonces decidimos continuar con nuestras observaciones en un ambiente más realista.

Tercer intento: la trampa “Marta”

Había dispuesto la red local para que pareciera el departamento de alguna compañía de juegos. Parecía que el departamento participaba en la compilación de recursos de juegos. El equipo de Marta, la nueva empleada imaginaria, se infectó con Winnti una semana después de comenzar a trabajar. Todo tenía que parecer real, lo que significa que debíamos mantenernos comunicados con la empresa por correo durante esa semana. Por eso también creamos otros personajes con los que Marta se comunicara: un líder del equipo, el administrador del sistema, el director y los ingenieros. Pero pensar en los correos corporativos de Marta, la nueva empleada de la compañía falsa, es una tarea que consume mucho tiempo, y Marta no tenía muchos correos en su bandeja de entrada.

Como dijimos antes, los intrusos examinaban los equipos infectados de forma manual. Tuvimos que esperar un poco antes de notar en el tráfico de redes que alguien estaba activo en el equipo infectado. Nuestro principal propósito era descubrir los métodos que utilizarían los atacantes para infectar los ordenadores de los colegas de Marta. Pensábamos que los atacantes enviarían correos electrónicos infectados desde el equipo de Marta. Pero utilizaron otra estrategia.

Los intrusos examinaron el equipo infectado y su entorno dos veces. Esto fue al comienzo de la observación. Después, si volvían al equipo infectado, lo hacían sólo para recordar qué equipo era – no hacían nada importante.

Primer intento
La primera vez, los atacantes sólo trataban de familiarizarse con el lugar, observar lo que pasaba en el escritorio del equipo infectado:

Comenzaron a recolectar datos útiles del equipo con mucha cautela. Vieron algunas carpetas (que habíamos creado con anticipación para que parezca actividad del trabajo de nuestra nueva empleada ficticia):

D:WorkFasmatgui
C:UsersMarta FrDesktop
F:!Far
D:Exchange-MartaFor Magnus
D:WorkFasmatmenu
D:WorkFasmattex

Con la ayuda del comando “net use”, echaron un vistazo a los recursos de redes a los que el ordenador se había estado conectando y notaron que había sólo un disco de redes montado:

Trataron de ingresar al disco C: del equipo a distancia con el comando “dir” y se les negó el acceso:

Con el comando “net view”, pudieron ver otros equipos de la red:

Entonces trataron de acceder al sistema de archivos de uno de ellos, pero fallaron:

Usando “net user” de nuevo, se fijaron en los usuarios que estaban registrados en el equipo infectado:

Al parecer, en este momento, los intrusos decidieron tomar un descanso y pensar en qué hacer a continuación, ya que detuvieron su reconocimiento y volvieron varias horas después.

Secuencia de eventos:

Segundo intento

En su segunda visita al equipo infectado, los atacantes revisaron de inmediato, usando el comando “net use”, si habían aparecido nuevas conexiones a los recursos remotos de la red desde su última visita. No apareció nada.

Los intrusos estaban buscando su biblioteca maliciosa:

Examinaron el contenido de la carpeta de documentos del usuario actual:

El archivo “Default.rdp” capturó su atención:

Por alguna razón apagaron los siguientes atributos en su biblioteca maliciosa: “hidden”, “system”, “read onlу” (cuando los intrusos operaron en el equipo virtual hicieron lo opuesto y establecieron esos atributos en la biblioteca maliciosa usando el archivo wm.bat):

Cargaron el programa Network Password Recovery del desarrollador Nir Sofer en el equipo infectado. Este programa descubre las contraseñas guardadas en el sistema operativo vinculadas con:

• Cuentas que se usan para acceder a ordenadores remotos en una red local;
• Cuentas de Outlook 2003;
• Cuentas en los programas de mensajería instantánea MSN Messenger / Windows Messenger;
• Cuentas guardadas en los navegadores Internet Explorer 7.x y 8.x;
• Cuentas Remote Desktop 6;

El tráfico de redes reveló el programa netpass.exe, guardado en el sistema operativo de los atacantes mediante la ruta Z:dllpassnetpass.exe.

Los intrusos ejecutaron ese programa con el parámetro “/stext a.txt” que guarda las contraseñas encontradas en un archivo llamado a.txt.

Cuando el programa dejó de trabajar, apareció el archivo a.txt y los intrusos lo vieron:

Había carpetas compartidas para Marta en equipos remotos de la red local, supuestamente para compartir datos entre Marta y otros empleados. Marta ya se había conectado a los equipos de los usuarios Jonas-448 y KARL-SCH y, por supuesto, guardó las credenciales para acceder a las carpetas compartidas. Ahora los intrusos también tenían esos datos. Trataron de usar las credenciales de Marta para acceder al disco C: del equipo de Karl – no funcionó:

Revisaron si Karl estaba en la red – Karl estaba conectado:

Entonces trataron de jugar con los datos de ingreso del comando “net use” – no pasó nada:

Después de eso, los intrusos probablemente perdieron el interés, eliminaron todos los archivos que habían creado y no hicieron nada más de importancia.

A juzgar por los resultados de nuestra observación, asumimos que los miembros del grupo Winnti no se molestan con los trabajos complicados y se conforman con los blancos fáciles. También notamos esto cuando el grupo trataba de ingresar a una compañía de juegos por segunda vez. Sin duda querían volver a infectar a la compañía – era obvio que eran persistentes, pero utilizaban tácticas obviamente toscas, rara vez empleaban métodos sofisticados. Esto podría haber funcionado si la compañía en cuestión no hubiese estado preparada para estos ataques, pero estábamos esperando y sus numerosos ataques directos fracasaron. Al final se dieron por vencidos y, como en el caso anterior, lo más probable es que hayan postergado su próximo ataque alrededor de un mes, probablemente cambiando a otra víctima más susceptible. Considerando cuántas compañías ya han comprometido, está claro que no les faltan víctimas potenciales. Parece que no pierden mucho tiempo en objetivos particularmente difíciles y prefieren ganar dinero con las numerosas organizaciones que son más fáciles de penetrar.