Análisis e Ingeniería Inversa de un troyano bancario de la familia Zeus

1. Introducción y objetivos

En este artículo vamos a mostrar cómo realizar un estudio de análisis mediante ingeniería inversa a un troyano bancario de la familia Zeus.

Como materiales de estudio se nos proporciona un único archivo binario llamado «fichero.bin». Lo podemos descargar desde el GitHub de JMSec:

• https://github.com/JAYMONSECURITY/JMSec-Blog-Resources

Para llevar a cabo una estudio de estas características necesitaremos unos conocimientos básicos de ingeniería inversa.

2. Montaje del laboratorio y descripción de los materiales

Para dar comienzo al ejercicio decir que el análisis del binario se realiza bajo S.O. Windows 10 y que a continuación se enumeran las herramientas y archivos que serán necesarios para la correcta resolución del ejercicio:

• “fichero.bin”: Con hash de integridad md5 «75D07360E1837D847AA4F0CC9DC6A28F».
• IDA Debugger: https://www.hex-rays.com/products/ida/debugger/
• Editor HTML (o cualquier editor de texto): http://editor-html.softonic.com/
• Servidor Apache: https://httpd.apache.org/download
• Offzip: http://aluigi.altervista.org/mytoolz.htm#offzip
• Lectura de la librería open source “zlib”: http://www.zlib.net/zlib_tech.html

Una breve descripción de cada herramienta:

• “fichero.bin”: Se trata del binario a analizar.
• IDA Debugger: La usaremos para hacer un análisis estático del binario.
• Editor HTML: Será necesario para poder estudiar ordenadamente y/o editar lo que necesitemos de los archivos resultantes del des-empaquetamiento del binario.
• Apache Server: Será necesario para subir los archivos descomprimidos al servidor web, y poder ver cómo son interpretados en el browser para poder hacer las consiguientes inspecciones de los elementos que compongan las distintas webs bancarias. Podríamos decir que es necesario para llevar a cabo un análisis dinámico.
• Offzip: Herramienta de gran utilidad para descomprimir los datos contenidos en cualquier tipo de archivo como archivos en bruto, paquetes zip (zlib / gzip / deflate), archivos “zip”, ejecutables y todo lo demás. Usando la opción de búsqueda útil “–S” es capaz de escanear el archivo para su posterior descompresión. Tras el des-empaquetamiento los archivos se pueden volcar con una extensión de manera automática que puede ser útil para su rápida identificación. Destacar que como herramienta es similar a «binwalk«.
  

• Zlib: Es una biblioteca de compresión de datos, de software libre/fuente abierta, multiplataforma. Provee una implementación del algoritmo DEFLATE usado en el programa de compresión “gzip”.

3. Análisis del empaquetamiento del binario

El binario “fichero.bin” presenta una serie de complicaciones que a priori son difíciles de interpretar desde el punto de vista de un análisis de malware común, ya que su análisis presenta un empaquetamiento que a primera vista nos es desconocido y difícil de interpretar.

a) Fase de reconocimiento

El binario proporcionado no es propiamente un archivo ejecutable, por lo que si lo intentamos operar con herramientas como “Immunity Debugger” o “OllyDebugger” nos arroja el siguiente error:

Si lo intentamos abrir con “Resource Hacker” también obtenemos un resultado erróneo:

Como podemos observar por los errores obtenidos no se trata de un archivo ejecutable. De la misma manera si intentamos abrirlo con “Dependency Walker” o con “w32dasm” obtenemos mismos resultados.

Sin embargo, al abrirlo con nuestro querido “IDA Debugger” obtenemos los primeros resultados positivos:

Como podemos observar el código está bien empacado y no se puede hacer ninguna interpretación clara de las instrucciones del binario. El resto de las pestañas (Exports, Imports, Names, Functions…) no aportan resultado alguno. Las cadenas de caracteres o “strings” reconocidas las podemos ver en el archivo de descarga:

• https://github.com/JAYMONSECURITY/JMSec-Blog-Resources/blob/main/Files%20descompressed%20fichero.bin.zip
  

Si hacemos una interpretación de las cadenas de caracteres encontradas a lo largo del binario, podemos llegar a la rápida conclusión de que se trata de una posible web (por sentencias como «</body>» o «</script>») bancaria (por palabras como “Situazione Portafoglio” o “Security Check”) destinada a su uso en Italia (por estar escrita en italiano). No obstante esta es una conclusión que todavía está muy lejos de una demostración fiable.

Llegados a este punto debemos estudiar el hexadecimal del binario para poder sacar conclusiones de cómo interpretarlo, y conocer cómo está comprimido para poder encontrar la herramienta adecuada y realizar posteriormente su desempaquetado.

Con la finalidad de averiguar el tipo de compresión que presenta el binario hacemos uso de las herramientas “scalpel”, “foremost”, “dumpbin” y “PEiD”, pero los resultados no son los esperados por lo que procedemos a recabar más información con la que poder divisar algún posible vector de ataque al desempaquetado del binario.

Sabemos que los compresores de archivos presentan unos métodos de compresión que trabajan sobre algoritmos conocidos, dejando una «marca» en la cabecera («header») del archivo resultante de la compresión. Esta «marca» se denomina «magic numbers». Así pues, podemos observar que cuando un archivo es comprimido con un software que emplea la librería «zlib», en su cabecera podemos encontrar que sus «magic numbers» comienzan con el hexadecimal 0x78 0x9C. Para verificarlo se recomienda hacer uso de la herramienta «offzip». Esto es justo lo que necesitábamos saber, ya que el archivo que tenemos que analizar contiene esos «magic numbers» en su cabecera, como podemos ver en la siguiente imagen:

b) Des-empaquetamiento con herramienta «offzip»

Vamos a comprobar con la herramienta “offzip” que realmente el binario está comprimido con zlib.

Los comandos que usaremos con “offzip” serán los siguientes:

• Para saber si efectivamente el binario está comprimido con zlib: «offzip -S fichero.bin 0 0»
• Para volcar los resultados de zlib en una carpeta llamada «output»: «offzip -a fichero.bin c:\output 0»
• Para volcar los resultados en un único archivo, muy útil cuando hay archivos fragmentados: «offzip -a -1 fichero.bin c:\output 0»
• Para analizar/recuperar el contenido de la tabla de índice del archivo: «offzip -S -x fichero.bin 0 0»
  

Comprobamos con los comandos anteriormente detallados la veracidad de la existencia de “zlib” y la obtención satisfactoria de los archivos comprimidos:

1. «offzip -S fichero.bin 0 0»: Comprobamos que está empaquetado con “zlib” y vemos cómo nos informa de que hay «42 valid compressed streams found», por lo que posteriormente podremos ver cómo extraeremos 42 archivos resultado del des-empaquetamiento del binario.

2. «offzip -a fichero.bin c:\output 0»: Desempaquetamos y volcamos resultados en carpeta “output”.

Aquí podemos ver los 42 archivos extraídos en la carpeta “output”:

3. «offzip -a -1 fichero.bin c:\output_unico 0»: Como podemos ver que hay una gran fragmentación de archivos (42) hacemos uso de este comando para unificar todos los resultados del des-empaquetamiento en un único archivo.

El resultado del archivo obtenido:

c) Breve explicación sobre los resultados y des-empaquetamiento manual

Llegados a este punto se hace necesaria una breve explicación de lo presentado para poder profundizar en los resultados obtenidos. Sabemos que la presencia del empaquetamiento de “zlib” viene marcada concretamente por “0x78 0x9c”:

• ZLIB_MARKERS = [‘\x78\x9c’]

Ya hemos visto los resultados que nos arroja “offzip”:

Así pues, podemos obtener nosotros mismos de manera manual los diferentes fragmentos empaquetados por “zlib” con el editor hexadecimal de IDA buscando la secuencia 0x78 0x9C, como bien se demuestra a continuación:

Como podemos ver si hacemos una comparativa entre los resultados obtenidos por “offzip” y los obtenidos por IDA, las direcciones presentadas son exactamente las mismas: (00fa, 01fd, 0234, 026f, 0f4b…). De esa manera podemos obtener los fragmentos de datos empaquetados por “zlib” de manera manual, para poder manipularlos a nuestra discreción e identificar las diferentes partes de las que consta el binario. No obstante, nos servimos de “offzip” para automatizar el proceso y desempaquetar el binario.

4. Análisis estático de los archivos obtenidos tras el desempaquetado

Habiendo aclarado la forma de proceder para el descubrimiento de la presencia de “zlib” para el posterior des-empaquetamiento del binario, continuamos con el análisis de los ficheros obtenidos.

a) Análisis estático basado en el archivo unificado «000000fa.htt»

Vamos a empezar por el archivo unificado «000000fa.htt». Lo operamos con IDA y con el Editor HTML para ver resultados:

Si analizamos detenidamente las “strings” encontradas con IDA podemos observar cómo el programador de este binario puso mucho esfuerzo en redirigirnos a una dirección IP específica (209.85.229.104), al querer visitar una lista de páginas webs de especial interés destinadas a la lucha de malware a nivel global y a la actualización de software, como son por ejemplo:

bitdefender.com, trendmicro.com, update.avg.com, pctools.com, secure.lavasoft.com, virustotal.com, avira.com.au, nortonantiviruscenter.com, www.zonealarm.com, anti-spyware.com.au, virusscan.jotti.org, virscan.org, kaspersky.co.uk, entre muchas otras.

Con un análisis escueto de la IP 209.85.229.104 comprobamos que se trata del famoso buscador “google”:

Si introducimos en un browser la dirección IP mencionada podemos comprobar que efectivamente se trata de la web de “google”:

Habiendo llegado a este punto ya podemos afirmar que el binario intenta evitar por todos los medios que nos conectemos a las principales webs de seguridad informática y también gubernamentales (*.gov) haciendo un redireccionamiento de DNS, redirigiéndonos concretamente a la web de “google”.

Ahora nos vamos a centrar en las siguientes “strings” del binario:

Leyendo de abajo hacia arriba podemos ver el interés del atacante en “facebook” o “microsoft”, sitios muy bien conocidos por cualquier desarrollador de malware por las posibilidades/ventajas que presentan a la hora de buscar un vector de infección (para distribuir el malware).

Si continuamos la lectura vemos cómo el atacante tiene interés en lanzar el comando “ipconfig /all” para conocer toda la configuración de las tarjetas de red de la víctima (direcciones IP, puerta de enlace, tipo de tarjeta de red…); y también vemos que tiene interés en el comando “net view” para poder saber los equipos (ordenadores, impresoras, otros recursos compartidos) que están bajo la misma LAN de la máquina víctima.

Por la utilización de estos comandos ya podemos sacar la conclusión de que el binario está destinado a su uso en máquinas con SO Windows.

Un atacante (o malware inteligente programado para ello), con todos estos datos recabados desde “el interior” de la maquina víctima, con los privilegios necesarios, puede ocasionar un destrozo importante en una organización empresarial, ya que conociendo los recursos compartidos bajo la misma LAN (Local Area Network) puede distribuir el malware al resto de máquinas infectando de esta manera a toda la red interna.

Con respecto a las direcciones webs que aparecen en la parte superior de las “strings” reconocidas podemos ver que todas emplean la tecnología “wordpress”, y en cuanto a actividad decir que a día de hoy únicamente continua activa:

• http://www.yalchin.com/

(El resto de los dominios no existen o están a la venta).

Pero lo realmente importante de este conjunto de direcciones webs radica en su estructura: «www.xxx.com/../../.. /instal/file.php|file=profi.bin».

Al estudiar la estructura «file.php|file=profi.bin» llegamos a la conclusión de que es una llamada remota a un archivo de configuración («profi.bin») similar al que presentan algunos troyanos, como por ejemplo el famoso “ZeuS”.

A continuación se exponen unas capturas del uso de este archivo de configuración obtenidas de «ZeuS Tracker»:

Otras estructuras similares como la descrita anteriormente están presentes en algunos “malwares” pero con otra función diferente, pues consisten en hacer una llamada al sistema (similar al comando “start” en Windows) con la que se efectúa de manera simultánea la ejecución/instalación del archivo binario a la misma vez que lanzan una visita a una web para “enmascarar” en segundo plano el proceso malicioso.

A continuación se demuestra la ejecución de una web y un ejecutable con la finalidad de ver cómo la web se ejecuta mostrándose en pantalla en primer plano, mientras que el binario se vuelca en el sistema en segundo plano (también dependerá de cómo se haya programado el binario, evidentemente).

Aquí podemos ver cómo a través del comando «start http://localhost/trojanweb.php|Bicharraco.exe» se realiza en primer lugar la apertura de la web indicada en el browser por defecto del sistema y simultáneamente la ejecución del binario en segundo plano volcándose directamente en la línea de comandos (cmd.exe).

Continuando con el análisis del binario, una vez desempaquetado nos encontramos con pequeñas partes en hexadecimal que debemos de procesar, como por ejemplo:

Una vez realizada esta conversión con todas las cadenas afectadas y habiendo limpiado el código “web” del archivo “unificado” de impurezas, el “source” a analizar queda como sigue:

Pero esto sólo nos da una visión global de lo que hace el binario, por lo que si realmente queremos profundizar y saber qué es lo que se trae entre manos el atacante, debemos analizar los códigos fragmentados obtenidos con “offzip” detenidamente parte por parte. Así pues, damos paso al análisis de los archivos más importantes obtenidos del des-empaquetamiento del binario.

b) Análisis estático por discriminación de archivos obtenidos tras el des-empaquetamiento

• En los archivos “00000f4b.txt”, “00015045.txt” y “00015677.txt” podemos ver cómo se usa el logo de “deutsche-bank” desde la dirección https://dbonline.deutsche-bank.it/db/img/LOGO_DB_B5C9E3.gif y se lanza un mensaje al usuario como sigue a continuación:

La conclusión que sacamos de este análisis es que se trata de una web con la interfaz de “Deutsche Bank” que envía este mensaje a la víctima para que posteriormente pulse al enlace que le dirija al “balance de su cuenta” o al de “hacer la restitución” para devolver el dinero por el que se le acusa. De esta manera la víctima será redirigida al link “goToTransfer” en el que se accede a otra web en la que deberá de introducir todos los datos para hacer una transferencia bancaria a través del sistema “Bonifici SEPA” (Single Euro Payments Area) con la cantidad económica estimada por el atacante, que se supone fue enviada a la cuenta de la víctima por error. El tipo “bonifici” quiere decir que se trata de una operación bancaria que consiente la transacción de fondos de una cuenta corriente a otra.

• En el archivo “0000a09d.txt” podemos ver cómo se lanza el siguiente mensaje al usuario:

Tras el mensaje los campos que se cargan son de peticiones de usuario y contraseña, entre otros:

Y que al terminar de rellenar todos los campos, como bien solicita la web con su mensaje “Vi preghiamo di compilare tutti i campi”, nos lleva al siguiente mensaje:

Sin embargo, si no se rellenan todos los campos correctamente nos lleva a un mensaje de error que nos vuelve a pedir que rellenemos los campos necesarios correctamente:

Para ello lanza un “alert()” que salta en pantalla pidiendo que se rellenen todos los campos:

En este archivo también nos llama la atención la variable definida “_0xf6fa”, pues su contenido está en su totalidad en hexadecimal, por lo que si queremos saber qué esconde detrás de esos valores vamos a tener que hacer la conversión a ASCII:

Convertido a ASCII nos queda de la siguiente manera:

Como podemos ver se tratan de cadenas de caracteres de especial interés usadas por el binario y que estarán presentes a lo largo de todo el análisis, ya que el mismo código en hexadecimal lo podremos encontrar en muchos de los archivos fragmentados. Conforme vayamos avanzando en el análisis iremos comentando cada una de las cadenas obtenidas.

Pero todavía no acaba aquí el análisis de este archivo, ya que podemos ver algo muy importante en mitad del código que debemos procesar para saber de qué se trata.

Si nos damos cuenta podemos ver que en mitad del código hay unas instrucciones en “javascript” que debemos analizar concienzudamente, pues además este fragmento de código está presente en la mayoría de los archivos fragmentados que vamos a analizar con posterioridad:

Vemos que se hace referencia a varias direcciones web. Si vamos a http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab y nos descargamos “swflash.cab”, vemos que al descomprimirlo contiene un ejecutable “autoextraíble” y un archivo de configuración de información (“.inf”) que contiene en su interior instrucciones:

Posteriormente en el código vemos que aparece la web para descargarse “flash player” desde http://www.macromedia.com/go/getflashplayer y si continuamos leyendo vemos que se hace una llamada a la dirección http://nfriedly.github.com/Javascript-Flash-Cookies/storage.swf

Para obtener un poco más de información sobre esta web vamos al enlace de abajo a la derecha (http://www.nfriedly.com/techblog/2010/07/swf-for-javascript-cross-domain-flash-cookies/) y vemos que se trata de un proyecto de “cross-domain flash cookies”, para qué decir más, sobran las palabras en cuanto a explicar cuáles son las intenciones del atacante ante este fenómeno:

Llegados a este punto podemos obtener más información sobre el ejecutable “FP_AX_CAB_INSTALLER64.exe” (obtenido de la descompresión del archivo “swflash.cab” ) mediante el uso de herramientas online como ANYRUN o virustotal (porque no es nuestro cometido analizarlo en este ejercicio) y nos hace un análisis detallado con los siguientes resultados:

Así pues, no nos pilla de sorpresa al ver en la parte de “Signatures” que el ejecutable sustrae información privada de los navegadores (tal como el historial o las cookies, como podemos ver en “Summary Mutexes”), y que también se configura para ser ejecutado en cada inicio de sesión de Windows.

Lo más seguro es que la información sustraída de los navegadores la almacene en “storage.swf” y posteriormente llame a la web de “Cross-domain Flash Cookies”, como ya hemos visto anteriormente. Como en este ejercicio no es nuestro cometido analizar este ejecutable nos quedaremos en este punto, ya que de continuar por este camino se haría muy extenso el análisis del binario original.

Continuamos con el análisis de los archivos “fragmentados”.

• En el archivo “0000d245.txt” encontramos una función que no tiene gran cosa que comentar, como su propio nombre indica (“conferma”) su función es hacer un “checkeo” de confirmación de que los campos han sido rellenados correctamente, y de no ser así se envía un mensaje de error:

• En el archivo “0000ea4c.dat” podemos observar cómo se define una función para cargar scripts (loadScript()) y otra para enviar los datos introducidos anteriormente por la víctima, al que parece ser el “centro de mando, de administración o panel de control” del binario situado en http://www.macgreccheckserving.net/securepanel/ con la función sendNumbers():

• En el archivo “00001a01.dat” encontramos una función encargada de la seguridad de la operación de transferencia al extranjero, solicitando al usuario que introduzca un código de una imagen (“captcha”) para verificar la autenticidad de la operación:

• En el archivo “00001c14.dat” podemos ver cómo se pide el PIN que debe introducir la víctima, además de darle sus datos de conexión:

Como cultura general decir que HB TOKEN es un pequeño dispositivo electrónico que sirve para el acceso seguro a la banca por Internet. Genera un código que sirve sólo para ser utilizado en el momento en el que nuestro sistema de acceso lo requiere. Además no necesita instalarse en el PC y tiene una duración predeterminada que está escrita en la parte posterior del dispositivo, como bien dice el mensaje analizado.

Continuando con el análisis podemos ver a lo largo del código cómo se espera la introducción de 10 cifras del PIN y de la contraseña del dispositivo, y su posterior sanitización:

En la siguiente imagen vemos cómo se “checkea” que los datos introducidos sean correctos y de no ser así se lanza un “alert” en pantalla avisando al usuario de que para poder acceder a sus datos es necesario que introduzca correctamente el PIN:

También podemos ver dicha comprobación en el archivo “0000374d.dat”:

• En el archivo “000026c8.dat” nos encontramos la función “dogetdata()” donde vemos que hace referencia a “pnlCruscotto” que guarda cierta relación con un “panel del tablero de instrumentos” (según una traducción estimada en italiano) donde se encontrarán ciertos datos de interés y posteriormente se ve cómo se hace usa el logo de “bancareale” desde su propia web: https://pr.bancareale.it/BRIO2/Images/logo_50.gif

• En el archivo “000061dd.opy” nos encontramos que hace referencia a la banca de “ingdirect” y envía un mensaje a la víctima pidiéndole que registre su tarjeta “TAN” verificando sus datos y su contraseña de la siguiente manera:

• En el archivo “00002875.dat” podemos ver cómo para poder proseguir con el proceso se le solicita a la víctima la introducción de un código de seguridad de 10 cifras con la finalidad de garantizar una mayor seguridad. También podemos ver que al final del archivo se emplea la imagen de la banca “bancareale”:

• En el archivo “00003506.dat” nos encontramos con un formulario de “entrada” para que la víctima ingrese en la aplicación Web. Los campos a completar son el de usuario, contraseña y dispositivo.

Interpretado por un navegador nos devuelve el siguiente formulario:

• En el archivo “00004038.dat” vemos que se pide a la víctima que introduzca la contraseña de internet de 8 caracteres, hace una ligera comprobación y de no ser válida devuelve un mensaje de error diciendo que los caracteres de la contraseña no son válidos:

Posteriormente, podemos ver que se hace uso de la imagen de “cartalis” desde la dirección https://www.cartalis.it/Autenticazione/img/logo_cartalis.jpg para la introducción de los 8 caracteres de la contraseña solicitada:

• En el archivo “00004804.dat” nos encontramos con que se hace uso de la imagen de “unicredit” desde la dirección https://online-smallbusiness.unicredit.it/ ibx/web/menu/menutop/images/logo.gif y lanza el siguiente mensaje a la víctima:

En el análisis de este mensaje se deja entrever por el uso del vocabulario que quien lo haya escrito no es propiamente italiano, pues en la primera línea escribe: «La Poste Italiane ed il suo personale la vuole informare»; Cuando realmente al ser plural lo correcto sería escribir “La Poste Italiane ed il suo personale la vogliono informare”. Además, al final del texto se puede ver cómo escribe “Poste Italiana”, lo cual está mal escrito ya que “Poste” es plural por lo que lo correcto es escribir la “Poste Italiane”, además de que se trata de un nombre propio.

Si continuamos leyendo el código podemos ver un mensaje de error y el módulo que la víctima debe rellenar:

• En el archivo “00005587.dat” podemos ver que se hace uso del logo de la banca “bancagenerali” desde la dirección https:// www.bancagenerali.it/fec/03075/img /logohead.gif y se envía el siguiente mensaje a la víctima:

Estudiando el código podemos ver al final que la “SECURITY CARD” se compone de 24 números.

• En el archivo “00013813.dat” se hace uso de la imagen de la banca “atime” desde la dirección web http://www.atime.it/img/logo.gif Y como ya viene siendo habitual durante todo el análisis se lanza a la víctima el siguiente mensaje, ya traducido anteriormente:

Posteriormente se pueden ver los siguientes mensajes, también analizados con anterioridad:

Llegados a este punto ya podemos decir que hemos analizado los archivos fragmentados obtenidos por el des-empaquetamiento del binario original. Huelga decir que los archivos desempaquetados a los que no he hecho referencia en el análisis es, bien porque contenían exactamente la misma información que otros a los que sí he hecho referencia, o bien porque el código que contenían no aportaba ninguna información relevante.

5. Conclusiones sobre el estudio

Tras el análisis de los archivos fragmentados sacamos las siguientes conclusiones:

• En primer lugar, tras el primer archivo analizado (00000f4b.txt) podemos sacar la conclusión de que se trata de un malware bancario que trata de usar a la víctima de “mula”, pues supuestamente el usuario ha recibido una transferencia económica errónea a su cuenta y debe devolverla si no quiere tener represalias. Para ello debe pulsar el link de “devolver el dinero” y lo lleva a una transferencia tipo “bonifico SEPA”, que estará configurada para que el capital transferido vaya a la cuenta del atacante, que nada tendrá que ver con el número de cuenta del que fue transferido el dinero por error (seguramente una cuenta comprometida). De esta forma el atacante obtiene un dinero de una cuenta comprometida, y la policía tendrá más complicada la tarea del seguimiento de ese capital para poder arrestar al verdadero delincuente.

• También vemos cómo a lo largo del análisis aparecen muchas webs bancarias, utilizando sus logos e imágenes y tipos de forma, por lo que sacamos la conclusión de que se trata de un troyano bancario que cubre una gran cantidad de bancos importantes. De cada uno de ellos se pide rellenar un formulario de datos del usuario (víctima) porque, supuestamente, están fortaleciendo la seguridad online o deben garantizar que el usuario es realmente quien dice ser, o porque recientemente el sistema informático ha sufrido algunas pérdidas de datos, entre otras escusas. De esta manera se obtienen todos los datos del usuario víctima. Decir que todas las webs están en italiano, por lo que su uso se limita a víctimas de lengua italiana. Las webs bancarias afectadas son:

seg000:00059964 00000045 C dbonline.deutsche-bank.it/db/jsp/menuDbspa.jsp?randomseed=&lang=i*
seg000:000599B9 00000049 C dbonline.deutsche-bank.it/db/jsp/appInvoker.jsp?app=RETWNewMovementQue
seg000:00059A12 00000035 C dbonline.deutsche-bank.it/db/jsp/genericHandler.js
seg000:00059A57 00000047 C dbonline.deutsche-bank.it/db/jsp/appInvoker.jsp?app=RETWBonificoSepa
seg000:00059AAE 0000003D C dbonline.deutsche-bank.it/db/jsp/ecdlHandler.jsp?pageTo=mio seg000:00059AFB 00000031 C https://hbnet.cedacri.it/CreateDocument&Login
seg000:00059B3C 00000030 C https://bancopostaimpresaonline.poste.it/bpiol*
seg000:00059B7C 0000001A C https://.bancareale.it/
seg000:00059BA6 00000023 C https://pr.bancareale.it//WfHome
seg000:00059BD9 0000001A C https://hb.bancareale.it*
seg000:00059C03 00000023 C https://hb.bancareale.it/Bonifico*
seg000:00059C36 00000012 C http://gbw.it
seg000:00059C58 0000003B C http://linksimprese.sanpaoloimi.com/pmiweb/LoginServlet*
seg000:00059CA3 00000017 C http://webanking.it*
seg000:00059CCA 00000039 C http://webanking.it/htdocs/_websitelogin_nocert.html
seg000:00059D13 00000025 C https://core.cedacri.it//LogonStep
seg000:00059D48 00000012 C monetaonline.it
seg000:00059D6A 0000002D C cartalis.it/AuthenticationDelegatedServlet
seg000:00059DA7 0000000F C unicredit.it
seg000:00059DC6 0000001D C unicredit.it/nb/itwelcome*
seg000:00059DF3 0000004D C https://bancopostaonline.poste.it/bpol/cartepre/servizi/cartapostepaysaldo
seg000:00059E50 00000056 C https://bancopostaonline.poste.it/bpol/cartepre/servizi/cartapostepaylistamovimenti
seg000:00059EB6 0000001D C bancagenerali.itlogincid
seg000:00059EE3 0000002C C https://www.bancagenerali.it/fec/logincid
seg000:00059F1F 00000022 C https://www.bancagenerali.it/fec*
seg000:00059F51 00000025 C https://secure.ingdirect.it/Welcome*
seg000:00059F86 0000001F C https://.csebo.it/webcontoc/
seg000:00059FB5 00000025 C https://www.csebanking.it/fec/login*
seg000:00059FEA 0000001C C bancamarche.itattenzione*
seg000:0005A016 00000022 C https://.bancamarche.it/webbdm/
seg000:0005A048 00000032 C https://www.isideonline.it/relaxbanking/sso.Logi*
seg000:0005A08A 00000036 C fideuramonline.it/script/LogonServlet?function=logi
seg000:0005A0D0 0000003B C ://hb.mps.it/PaschiHome/LOGIN2.0/RTLOGIN/ASPX/RTLogin01.
seg000:0005A11B 00000020 C hb.mps.itRTLoginToken01.aspx*
seg000:0005A14B 0000003E C ://hb.antonveneta.it/BAVIB/LOGIN2.0/RTLOGIN/ASPX/RTLogin01.
seg000:0005A199 00000028 C hb.antonveneta.itRTLoginToken01.aspx*
seg000:0005A1D1 00000031 C http://www.credem.it/secure/Forms/LoginForm.aspx
seg000:0005A212 0000001D C http://www.atime.it/home.htm
seg000:0005A23F 00000045 C dbonline.deutsche-bank.it/db/jsp/menuDbspa.jsp?randomseed=&lang=i*
seg000:0005A294 00000049 C dbonline.deutsche-bank.it/db/jsp/appInvoker.jsp?app=RETWNewMovementQue
seg000:0005A2ED 00000035 C dbonline.deutsche-bank.it/db/jsp/genericHandler.js
seg000:0005A332 00000047 C dbonline.deutsche-bank.it/db/jsp/appInvoker.jsp?app=RETWBonificoSepa
seg000:0005A389 0000003D C *dbonline.deutsche-bank.it/db/jsp/ecdlHandler.jsp?pageTo=mio

• A lo largo del análisis hemos podido comprobar que hay un par de direcciones web donde se ubican un par de “paneles de control” (C&C), los cuales no podemos investigar porque ya no existen:
  • http://www.macgreccheckserving.net/securepanel/
  • http://www.sercurmstandifservices.net/securepanel/

• Para finalizar las conclusiones, decir que el binario cumple íntegramente con el “esquema de comportamiento” de un troyano bancario, pues cuando la víctima trata de ingresar en su sistema de banca online se modifica la página web, de tal manera que los datos personales que la víctima introduce para autorizar su ingreso, inicio de sesión, u otras operaciones no se envían al banco, sino que se envían a un panel de control o servidor de administración remoto. Así pues, podríamos esquematizar lo que sucede de la siguiente manera:

• BOLETO: Perteneciente a la familia Zeus. La configuración de este troyano va cifrada con una clave XOR de 32 bits “hardcodeada” en el propio binario del troyano. Además de cifrarse, la configuración va comprimida con el algoritmo de compresión ZLIB .
• CITADEL: Perteneciente a la familia Zeus. Las variantes de Citadel más recientemente descubiertas tienen una funcionalidad de redireccionamiento DNS incorporada que evita que los sistemas infectados puedan conectar con los principales sitios web de seguridad informática y agencias de las fuerzas del orden a nivel global.

Sabiendo lo aportado anteriormente ya podemos dar por concluido que el binario analizado se trata de una variante del troyano bancario Zeus, que comparte características de otras variantes de Zeus como son Boleto y Citadel.

Para finalizar este análisis me gustaría mostrar los logos e imágenes de los bancos que nos hemos encontrado a lo largo del código analizado, para poder interpretar toda la información anterior de manera más gráfica. Decir que muchas de las direcciones bancarias que aparecen en el análisis del binario ya han restringido el acceso a sus logos e imágenes, y por lo tanto no podemos tener acceso directo desde los enlaces contenidos en el binario:

https://dbonline.deutsche-bank.it/db/img/LOGO_DB_B5C9E3.gif

https://pr.bancareale.it/BRIO2/Images/logo_50.gif

https://www.cartalis.it/Autenticazione/img/logo_cartalis.jpg

https://online-smallbusiness.unicredit.it/ibx/web/menu/menutop/images/logo.gif

https://www.bancagenerali.it/fec/03075/img/logohead.gif

https://secureca.ingdirect.it/images/errore/errore_attenzionetipo1.png

http://www.atime.it/img/logo.gif

6. Cómo evitar ser víctima de un troyano bancario

A lo largo del análisis hemos visto cómo funciona un troyano bancario. No obstante, en este apartado vamos a dar unas directrices básicas de cómo evitar ser víctima de uno de ellos.

Se sugieren las siguientes medidas a adoptar:

1. Tener correctamente instalados, configurados y actualizados los sistemas antivirus, al ser posible inteligentes y de última generación.
2. Lista blanca para las direcciones IP aceptadas, y/o servicios de VPN para realizar las conexiones entrantes a la red interna de la empresa.
3. Establecer jornadas de concienciación en ciberseguridad para los empleados y cargos directivos de la empresa.

Destacar que aunque todas las medidas son de gran importancia y se complementan entre sí, desde nuestro punto de vista profesional la última medida es la más importante de todas, ya que por normal general, tanto los troyanos bancarios como otros malware («ransomware», etc.), emplean la ingeniería social (phishing principalmente) basada en el engaño del usuario víctima como principal vector de ataque.

7. Conclusiones

En este artículo hemos podido ver lo peligroso que puede llegar a ser un troyano bancario dada su naturaleza de manipular a la víctima mediante técnicas de ingeniería social con las que poder robar credenciales bancarias y obtener transferencias económicas.

Ha quedado clara la importancia de proteger debidamente los sistemas informáticos, de establecer buenas políticas de seguridad y sobre todo, de concienciar en ciberseguridad a los empleados y directivos de la empresa.

De estar interesado en realizar unas jornadas de concienciación en ciberseguridad para los empleados y directivos de su empresa, o de realizar pruebas controladas de campañas de phishing no dude en contactarnos.

De estar interesado en adquirir conocimientos introductorios a hacking ético puede optar por matricularse en nuestro curso básico de hacking ético, o si prefiere adquirir conocimientos más avanzados en ciberseguridad ofensiva puede adquirir nuestro curso avanzado.