Autores
Seguimos con el análisis del programa malicioso Shamoon. Este artículo contiene información sobre los detalles de las muestras que hemos analizado.
Incrustación de muestras
El principal (archivo) ejecutable, un descargador, incluye 3 recursos, cada uno con un programa codificado. La codificación es muy sencilla: xor por dword. Ya mencionamos esto en nuestra primera entrada del blog
El recurso PKCS12:112 mantiene un (archivo) ejecutable codificado con la llave xor 0xFB5D7F25. Se guarda en el disco bajo un nombre tomado de una lista hardcoded en la carpeta %WINDIR%System32 durante la ejecución del descargador. A la vez, este módulo mantiene el recurso READONE :101 (llave xor: 0xF052AF15), un controlador decodificado y guardado en el disco como %WINDIR%System32DriversDRDISK.SYS.
El recurso PKCS7:113 mantiene un (archivo) ejecutable codificado con la llave xor 0x00BAD417 y que se guarda en el disco como %WINDIR%System32NETINIT.EXE durante la ejecución del descargador.
El recurso X509:116 mantiene una versión AMD64 del principal (archivo) ejecutable de Shamoon, un descargador codificado con la llave xor 0xBB1AC25C. A su vez, contiene el mismo juego de recursos que su contraparte de Win32. PKCS12:112 – este archivo es la versión AMD64 del primer (archivo) ejecutable descargado, con una versión AMD64 del controlador, y PKCS7:113 – la versión AMD64 de NETINIT.EXE. Entonces, los recursos 112 y 113 tienen las mismas llaves xor en las versiones x86 y AMD64 del descargador, pero las llaves de los controladores son distintas: La versión AMD64 está codificada con la llave xor 0x10CAFFA0 mientras que x86 está cifrada con 0xF052AF15. La siguiente imagen vale mil palabras y resume los archivos en el disco:
Luego, el principal (archivo) ejecutable de Shamoon está cifrado para trabajar en 3 modos:
- la muestra se ejecuta como un programa típico en un sistema operativo de 32-bit (argument-dependent)
- la muestra se ejecuta en un sistema operativo de 64-bit
- la muestra se ejecuta como un servicio en un sistema operativo de 32-bit
Entorno de 64-bit
Primero, el programa verifica si se ha ejecutado en un sistema operativo de 64-bit. Si es así, descarga la versión AMD64 del principal (archivo) ejecutable decodificando el recurso X509:116 y guardando los datos descifrados en el disco como %WINDIR%System32trksrv.exe. Después crea e inicia el servicio “TrkSvr” usando la siguiente línea de comandos:
%WINDIR%System32cmd.exe /c “ping -n 30 127.0.0.1 >nul && sc config TrkSvr binpath= system32trksrv.exe && ping -n 10 127.0.0.1 >nul && sc start TrkSvr ”
Esta rama finaliza y el programa concluye.
Veamos lo que el programa hace cuando se ejecuta como un programa típico en un sistema operativo de 32-bit.
Entorno de 32-bit: ejecución habitual, argumentos presentes
Resulta que el programa espera argumentos que se tratan como una lista de direcciones IP. Se trata de direcciones IP de ordenadores que el programa malicioso intentará infectar. Si el primer argumento plantea un solo símbolo de texto entonces el programa procede a infectar los ordenadores de una red local, enumerando el último valor de la dirección IP del ordenador infectado entre 1 y 254.Para esta dirección IP particular, el programa procede a abrir el archivo usando las siguientes rutas:
En otras palabras, el programa intenta acceder al directorio del sistema de los ordenadores existentes en la (sub) red local (u ordenadores con direcciones IP específicas en los argumentos). Si el programa malicioso logra abrir el archivo csrss.exe, se autorreplica en el ordenador remoto en la carpeta accesible System32 bajo un nombre aleatorio tomado de una lista hardcoded:
caclsrv.exe
certutl.exe
clean.exe
ctrl.exe
dfrag.exe
dnslookup.exe
dvdquery.exe
event.exe
findfile.exe
gpget.exe
ipsecure.exe
iissrv.exe
msinit.exe
ntfrsutil.exe
ntdsutl.exe
power.exe
rdsadmin.exe
regsys.exe
sigver.exe
routeman.exe
rrasrv.exe
sacses.exe
sfmsc.exe
smbinit.exe
wcscript.exe
ntnw.exe
netx.exe
fsutl.exe
extract.exe
Después el (archivo) descargador procede a ejecutar esta copia creando una tarea programada en el ordenador remoto. En caso de fracasar en su intento de infectar el ordenador remoto al crear la tarea programada, el programa malicioso cambia también el nombre a su copia (creada cuando se inicia la tarea programada) por “trksvr.exe” e intenta crear e iniciar el servicio “TrkSvr” (nombre visible: “Distributed Link Tracking Server“) relacionado con este (archivo) ejecutable en el ordenador remoto.
Ambiente de 32-bit ejecución habitual, sin argumentos
Cuando el programa se ejecuta sin argumentos, instala localmente el servicio “TrkSvr” (nombre visible: “Distributed Link Tracking Server“) (se autoreplica en %WINDIR%System32trksvr.exe y crea un servicio correspondiente) y lo inicia. En este punto, el autor recurre a un interesante truco para asegurar el funcionamiento de su programa malicioso a través de los reinicios: cambia la configuración del servicio “LanmanWorkstation” (nombre visible: “Workstation”). Hace que este servicio dependa del “TrkSvr”. Esto significa que cuando “Workstation” se inicia, también se ejecuta el “TrkSvr”. Pero, por lo general el “Workstation” se inicia automáticamente cuando el sistema operativo se carga.
Hay una forma más antigua de obligar al sistema operativo a ejecutar un servicio al inicio: basta con establecer la opción apropiada de un servicio particular. Además, el programa malicioso crea “TrkSvr” con esa opción ajustada para iniciarse automáticamente. Es difícil entender por qué prefirió el autor este método con dependencias.
Ambiente de 32-bit: se ejecuta como un servicio
Y por fin llegamos a la última condición: el (archivo) descargador se ejecuta como un servicio. Al principio, el (archivo) descargador guarda el recurso PKCS7:113 como %WINDIR%System32netinit.exe y lo inicia con un argumento “1” en una de estas dos formas:
- crea una tarea programada para iniciar “netinit.exe 1”
- ejecuta “netinit.exe 1” directamente llamando a la función CreateProcess
El servicio vigilante “TrkSrv” verifica continuamente si el proceso netinit.exe se está ejecutando y lo reinicia si deja de hacerlo (es decir, si no figura en la lista del proceso).
El servicio malicioso elimina en un bucle todos los (archivos) ejecutables de la lista hardcoded (ver arriba) en la carpeta local %WINDIR%WindowsSystem32. Como parte de este bucle, el programa verifica otra condición antes de pasar a la etapa final de su ejecución.
El (archivo) descargador comprueba si se ha cumplido una fecha determinada. La fecha se lee del archivo “%WINDIR%infnetft429.pnf” o, si eso falla, recurre a un valor hardcoded. La fecha hardcoded es 15 agosto de 2012 08:08 UTC. Al parecer, la función para verificar la fecha no funciona bien. Si la intención es dividir la línea de tiempo en “antes” y “después” de un determinado punto de verificación, entonces el autor ha fracasado. La condición contiene una lógica corrompida para hacer esto.
Por ejemplo, si el año es 2013, pero el mes actual es menor al mes objetivo, (digamos febrero), entonces la condición daría un resultado como si la fecha actual fuera antes del punto de verificación en agosto de 2012. En realidad, esta lógica es sencillamente fallida e incorrecta. Este error confirma de forma indirecta nuestra conclusión de que el programa malicioso Shamoon no es el programa malicioso Wiper que atacó los sistemas iraníes. Se asume que Wiper es un arma cibernética y, de confirmarse, tuvo que haber sido desarrollado por un equipo de profesionales. Pero es muy raro que programadores expertos fallen en una rutina de comparación de fechas.
Sin embargo, la condición funciona (aunque no en todos los casos previstos) y el (archivo) descargador procede a concluir su rutina. La función más importante que se realiza en este procedimiento es guardar el recurso PKCS12:112 como un archivo ejecutable usando un nombre tomado de la lista harcoded en la carpeta %WINDIR%System32 e iniciarlo (este componente lleva a cabo las medidas destructivas del programa malicioso Shamoon). Además, vemos que el programa usa este extraño texto hardcoded:
“kijjjjnsnjbnncbknbkjadc
kjsdjbhjsdbhfcbsjkhdf jhg jkhg hjk hjk
slkdfjkhsbdfjbsdf
klsjdfjhsdkufskjdfh”.
Asimismo, en esta etapa, el programa verifica si el archivo “c:windowstempout17626867.txt” existe en el sistema objetivo y carga la imagen “myimage12767” desde sus recursos. El (archivo) descargador no guarda el archivo “out17626867.txt” y hasta el momento no hemos encontrado ninguna referencia a este archivo en otros componentes del programa malicioso. El (archivo) descargador no contiene la imagen “myimage12767” en sus recursos. Entonces, no sabemos por qué verifica la presencia de este archivo, tampoco con qué se relaciona el archivo .txt, ni cuál es el propósito del recurso ausente “myimage12767”. Hemos descubierto que esta parte del código, que funciona con el texto raro, el archivo “out17626867.txt” y la imagen “myimage12767” es innecesaria y no ofrece ninguna funcionalidad adicional.
Eso es todo sobre el (archivo) ejecutable de Shamoon. Pronto daremos más información sobre otros componentes de este programa malicioso.
Autores
De los mismos autores
En la misma categoría
Shamoon el Limpiador al detalle