Mostrando entradas con la etiqueta Zeus. Mostrar todas las entradas
Mostrando entradas con la etiqueta Zeus. Mostrar todas las entradas

jueves, 28 de agosto de 2014

Estudio del Algoritmo de Generación de Dominios de Murofet, una variante de Zeus

Cada vez es más frecuente que los troyanos empleen un gran número de dominios para tratar de ocultar sus acciones: desde puntos de descarga, puntos de envió de instrucciones, etc. Para el malware es importante dificultar a los investigadores la localización de los sitios desde donde operan, de forma que cuanto más diversificados estén, mejor. Para generar un gran número de dominios de forma controlada se emplean los algoritmos de generación de dominios o Domain Generation Algorithm (DGA).

Para el atacante es importante controlar los dominios que se generan cada día para poder registrarlos previamente. De ahí la importancia que tiene para los investigadores conocer y controlar de que forma funcionan estos algoritmos. El Domain Generation Algorithm (DGA) fue usado por las variantes de Zeus como Murofet. Otras familias han usado DGAs como Conficker, BankPatch, etc. En el caso del Murofet (descrito como variante de Zeus), el DGA se usa para contactar con un sistema infectado y enviar  un ejecutable destinado a robar datos bancarios.

En esta entrada, analizamos el algoritmo DGA usado por un troyano de la familia Murofet (SHA256 99370d5162c2d9e165892af3bde7c6de8c44ec5945ed0a1ddb6b827b876931d0).

Cuando el malware se lanza empieza a generar los dominios. Para ilustrar el funcionamiento, tomamos el ejemplo de 3 dominios generados "whvqwshpulytfvx.biz", "rtqispmsdmrqcn.info", y "rtqispmsdmrqcn.org". Cuando los dominios resuelven a una dirección IP, el malware hace una petición HTTP al dominio generado. Aquí, el malware recoge un ejecutable desde el último ordenador, lo comprueba y lo ejecuta. Estos dominios fueron generados el 27 de Agosto 2014, y aquí la fecha toma especial importancia.



El algoritmo DGA se compone de dos partes. La primera parte va a inicializar el algoritmo mientras que la segunda parte va a construir el dominio. La fecha sirve para inicializar el algoritmo. En otras palabras, el algoritmo genera dominios diferentes de un día para otro. Cada día, Murofet genera 800 dominios diferentes. La ventaja principal de usar este sistema es la de aumentar la dificultad de recoger las infraestructuras con un sistema automatizado, de esta forma el proceso de obtener el ejecutable puede tardar horas, días, o meses. La otra ventaja que vemos es que a priori no se puede ver que el ordenador de la victima esta infectado por un troyano bancario, ya que la parte responsable de robar los datos bancarios todavía no fue descargada.

El algoritmo DGA genera un nuevo dominio a cada iteracion llamando la funcion "get_domain". El dominio se genera en base a dos parámetros que son la semilla (seed) y el contador (counter).
def DGA ():
        seed = GetSystemTime()
        for counter in range(0x320):
              domain = get_domain(seed[0:7], counter)
La semilla ("seed") resulta de la llamada a la función API de Windows "GetSystemTime" para inicializarse. La API de Windows lo guarda en una estructura SYSTEMTIME mientras que nosotros para más comodidad, lo guardamos en una lista que  llamamos "seed". Los dos primeros índices corresponden al año (2014 =  0x07*0x100 + 0xDE), el tercero al mes, el quinto al día de la semana, el séptimo al día, y el resto a los segundos y milisegundos. En la API de Windows, enero corresponde a 1, febrero a 2, etc. El domingo corresponde a 0, lunes a 1, etc. El día depende del mes y varia entre 1 y 28, 30 o 31. Abajo es el ejemplo de un seed:
Seed = [0xDE, 0x07, wMonth, 0x00, wDayOfWeek, 0x00, wDay, 0x00, 0x0F, 0x00, 0x31,
0x00, 0x33, 0x00, 0xD1, 0x03]
En la función "get_domain", la primera parte define una lista "data_to_hash" que esta inicializada con la semilla y el contador y luego se hace un XOR con los  bytes 0xB1, 0xA4, 0xD7, etc. Finalmente, se realiza el "hash" de esta lista con el algoritmo MD5 y el "hash" resultante se usa para generar el dominio.
def get_domain(seed, counter):
    //Primera parte
    data_to_hash = [0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0]

    data_to_hash[0] = (seed[0] + 0x30) & 0xff
    data_to_hash[1] = seed[2] & 0xff
    data_to_hash[2] = seed[6] & 0xff
    data_to_hash[3] = 0x00
    data_to_hash[4] = counter & 0xfe
    data_to_hash[5] = (counter >> 8) & 0xff

    data_to_hash[0] = (data_to_hash[0] ^ 0xB1) & 0xff
    data_to_hash[1] = (data_to_hash[1] ^ 0xA4) & 0xff
    data_to_hash[2] = (data_to_hash[2] ^ 0xD7) & 0xff
    data_to_hash[3] = (data_to_hash[3] ^ 0xD6) & 0xff
    data_to_hash[4] = (data_to_hash[4] ^ 0xB1) & 0xff
    data_to_hash[5] = (data_to_hash[5] ^ 0xA4) & 0xff
    data_to_hash[6] = (data_to_hash[6] ^ 0xD7) & 0xff
    data_to_hash[7] = (data_to_hash[7] ^ 0xD6) & 0xff

    hash_md5 = hashlib.md5(array.array('B', data_to_hash).tostring()).hexdigest()
    bytes_array = array.array('B', hash_md5.decode("hex"))
En la segunda parte, el algoritmo itera todos los bytes del "hash" con los cuales construye el nombre del dominio. Pone el límite de 0x7a que corresponde a la ultima letra del alfabeto (z)  y añade un offset 0x 61 (letra a) para solo generar letras. La extensión del dominio esta basada sobre el valor del contador. El DGA distingue 5 casos: la extensión “.org”, “.com”, “.net”, “.info”, o “.biz”. Concatenando el nombre y la extensión, conseguimos el dominio.

//Segunda parte
   #Generate the name
    for byte in bytes_array:
        al = (byte & 0xF) + (byte>>4) + 0x61
        if al <= 0x7A:
            name = "%s%c" % (name, chr(al))

    #Generate the extension
    if (counter % 5 != 0):
        if (counter & 0x3 != 0):
            if (counter % 3 == 0):
                extension = ".org"
            else:
                if (counter & 0x1 == 0x1):
                    extension = ".com"
                else:
                    extension = ".net"
        else:
            extension = ".info"
    else:
        extension = ".biz"

    domain = "%s%s" % (name, extension)
    return domain
Ejecutando el script Python, sobre el año 2014 entero, hemos notado que un dominio (epmmxkoszqyown.org) aloja un servidor nginx/1.6.0 activo, pero no pudimos recoger ningún ejecutable. Es la maquina de una victima, es decir sin instrumentación del algoritmo, la victima podría haberse infectado el día 14 de Agosto 2014.

Más información:

Domain Name Generator for Murofet,

ZeuS Gets More Sophisticated Using P2P Techniques,

W32/Murofet-A,



Laurent Delosières



jueves, 21 de febrero de 2013

Fines y medios: Ahora la NBC

Durante unas horas, la página oficial de la popular cadena norteamericana NBC estuvo infectando con troyanos bancarios a los sistemas Windows no actualizados que la visitaran. Este incidente se suma a una larga lista de páginas populares de medios de comunicación comprometidas.

Hace unas semanas, se conocía que uno de los subdominios de Los Angeles Times había sido infectado al menos durante mes y medio. Al menos, la NBC ha sido comprometida solo durante unas horas. También otras de las páginas de sus programas. Se detectó que varios sitios web incluían IFRAMES de tamaño minúsculo que cargaban código que llevaba al visitante al kit de explotación Red Kit. Aquí, el programa intenta explotar (sorpresa) vulnerabilidades en Java (una muy reciente, CVE-2013-0422, arreglada en la versión 11) y Adobe Reader. De tener éxito, el usuario es infectado por una variante de Citadel (una familia de Zeus). El troyano se encargará de modificar la web del banco y robarle las credenciales (en la muestra se han encontrado como objetivo los más populares de Estados Unidos) para realizar transferencias sin su consentimiento.


Dancho Danchev ha observado los "whois" de algunos de los dominios. En ellos, el email de registro aparece un viejo conocido (lockwr@rocketmail.com), encargado de otras recientes campañas a gran escala, en las que se inducía a los usuarios a "desbloquear" su cuenta de Facebook visitando un enlace y otra que involucraba la imagen de Verizon. Esto podría demostrar que esta banda está actuando en paralelo a través de varios frentes y, sobre todo, a gran escala en Estados Unidos.

Los binarios descargados eran muy poco detectados por los antivirus en el momento en el que estaban siendo servidos. En el mejor de los casos, siete motores lo detectaban a través de Virustotal. Google se encargó rápidamente de bloquear la página y marcarla como peligrosa y Facebook bloqueó el acceso desde su portal.

Fines y medios

Una vez más, nos presentamos antes un ataque en el que la NBC es un mero intermediario, y no el fin. Quizás la NBC sea un sitio complejo de comprometer, pero lejos están los tiempos en los que el ataque en sí, demostrar que era posible, representaba el fin en sí mismo. Ahora, el valor de atacar la NBC no es la hazaña de conseguirlo, sino su potencial en visitas. Más visitas, más gente infectada. Más gente infectada, más beneficios. Y ese es el verdadero fin. Igual que ocurrió hace poco con Bit9, en el caso en el que los atacantes consiguieron robar un certificado privado de la compañía, con el único objetivo de atacar a terceros que se encontraban protegidos por su software. Los medios para conseguir el fin pueden llegar a ser complejos, pero hoy ya se traducen en simples efectos colaterales.

¿Qué hubiera pasado?

Aunque en este caso el malware estaba destinado a bancos norteamericanos, existen bandas muy activas que lo programan para atacar a víctimas que visitan numerosas cajas y bancos españoles. Por pequeña que parezca, hemos observado que los atacantes tienen en cuenta prácticamente todas las entidades bancarias españolas en su código. ¿Qué hubiera pasado si se lanza una campaña de este tipo en España?

Realicemos un ejercicio hipotético, sin más valor que el de concienciar sobre las cifras. La NBC.com, según Alexa ocupa el puesto 2.211 en visitas globalmente en la Red. Un medio de televisión español popular, por ejemplo RTVE.es, ocupa el puesto 1.915. Según la propia RTVE esto significa que ha sumado casi 14 millones de usuarios únicos en enero de 2013. Imaginemos que alguien lo compromete, y comienza a lanzar malware desde ese portal solo durante un día. Esto hace 500.000 potenciales víctimas. De ellas, descartemos los usuarios de tabletas y televisores (31,2% según RTVE), Mac y Linux (añadamos sobre un 9% más). Pensemos que solo un 60% de los visitantes es una potencial víctima. Esto nos deja en 300.000 máquinas Windows. Aunque se eliminen de la ecuación los usuarios parcheados y a los que les bloquea el antivirus, seguiría siendo una suculenta cifra. Incluso de los ya infectados, no todos caerían en la trampa, visitaría el banco antes de que su antivirus lo detectase, etc. Imaginemos que apenas un 1% de esos 300.000 finalmente es estafado. Estamos hablando de 3.000 usuarios. Los atacantes se atreven a traspasar hasta 3.000 euros por estafado cuando existe dinero en la cuenta y para no levantar sospechas, pero la media en el robo de este tipo son 1.000 euros. Esto nos sitúa en un negocio de unos hipotéticos 3 millones de euros en beneficios por conseguir una buena difusión... ¿Merece la pena?

Estamos seguros de que en la banda, los encargados de encontrar espacios en los que esparcir el malware, se habrán llevado una buena comisión por este "éxito" en la NBC.

Más información:

RTVE.ES logra el mejor enero de su historia con casi 14 millones de usuarios únicos

Dissecting NBC's Exploits and Malware Serving Web Site Compromise

Exploit Sat on LA Times Website for 6 Weeks




Sergio de los Santos
Twitter: @ssantosv

domingo, 12 de agosto de 2012

XDocCrypt/Dorifel. ¿Hacia la unión del troyano bancario y ransomware? (y II)


Se ha descubierto Dorifel, un malware con dos características concretas que lo hacen interesante. Infecta ejecutables y documentos de Microsoft Word y Excel. Con estos últimos, se comporta como un "virus de los de antes", replicándose en por todos los ficheros de este tipo. Vuelve a poner de moda una técnica para pasar desapercibido de la que ya hablamos el año pasado... y puede significar un cambio de modelo en el malware.

Hablamos en la entrega anterior de qué hacía y cómo aparecía Dorifel: cifraba documentos en unidades compartidas y además, parecía descargarse entre los sistemas previamente infectados por una variante de Citadel. Veamos ahora otras cuestiones.

Cuál es su propósito

Se han visto otras conexiones con Zeus/Citadel, por ejemplo, comunicarse con servidores donde se alojan todo tipo de exploits, malware y componentes usados habitualmente por esta familia.

Ha afectado principalmente a las empresas de Holanda. No se sabe bien por qué, pero la historia encaja: si los atacantes han decidido la descarga en máquinas que ya controlan, por alguna razón han elegido un país concreto. Aunque nos consta que en España se han dado varios casos de infección.

El propósito de Dorifel es un pequeño misterio. Normalmente, el malware que cifra documentos pide un rescate por ellos, pero no es el caso. Podríamos pensar que por el hecho de estar programado en Delphi y no en otros lenguajes más comunes para este tipo de malware, como C o C++, se trata de un "entretenimiento" cuyo fin es el de "molestar". Pero, teniendo conexiones con creadores de troyanos tan sofisticados y que manejan un volumen de negocio como Zeus/Citadel... podríamos descartar esta hipótesis: debe haber lucro. Desde luego, tampoco pretende demostrar habilidades técnicas porque no es especialmente sofisticado.

Quizás se trate de un ensayo, o un paso más en una estrategia que puede llegar a consolidarse en el futuro.

Unir troyanos bancarios y ransomware

En mayo aparecieron varias noticias al respecto que pasaron un poco desapercibidas. F-Secure avisó de que había encontrado una variante de Zeus que bloqueaba el sistema, enseñando una página en un Internet Explorer que ocupaba toda la pantalla, mostrando un mensaje probablemente de extorsión. Exactamente igual que muchas variantes del virus de la policía.

También Trusteer avisó en mayo de que una variante de Citadel directamente descargaba una DLL con el famoso (y exitoso) malware de la policía. No olvidemos que otras variantes de este mismo malware, no solo bloqueaban el sistema sino que cifraban los documentos que encontraba en el disco duro.

Dado el éxito del ransomware últimamente (Briank Krebs acaba de escribir un artículo donde habla de beneficios de entre 30.000 y 40.000 euros diarios de algunas organizaciones con Reveton o virus de la policía) no resulta descabellado unir los dos conceptos: malware que intenta robar claves y credenciales bancarias pero que, en un momento dado, bloquea el sistema o cifra los documentos y pide un rescate.

Y ese "momento" dado puede ser cuando el atacante compruebe que, por ejemplo, la víctima infectada no accede durante días a su banca online, se impaciente o simplemente su banco implemente medidas de seguridad que impidan completar la estafa. Está demostrado que los bancos que analizan y persiguen el malware que les ataca, pueden impedir que se activen, añadiendo cambios en las páginas de banca online o incluyendo otras medidas de seguridad como tokens y otros factores de autenticación, etc.

Así es que, puesto que está comprobado que buena parte de este malware permanece días y semanas en el sistema antes de ser detectado, no es descabellado pensar en un "umbral de paciencia" del atacante donde pase a tomar medidas más drásticas: si no puede robar la cuenta bancaria de la víctima, la extorsionará bloqueando el sistema o cifrando sus documentos importantes. Quién sabe. Todo por el beneficio rápido e inmediato.

Más información:

Inside a ‘Reveton’ Ransomware Operation

ZeuS Ransomware Feature: win_unlock

Fake G-Men Attack Hijacks Computers for Ransom

Joint attack by banking Trojan and ransomware

Práctico: Cómo ocultar las extensiones de ficheros gracias a la codificación Unicode.

XDocCrypt/Dorifel – Document encrypting and network spreading virus

Dorifel crypto malware paralyzes Dutch companies and public sector

Dorifel Malware Encrypts Files, Steals Financial Data, May Be Related to Zeus or Citadel

Dorifel Malware Encrypts Files, Steals Financial Data, May Be Related to Zeus or Citadel

Complete details of the Dorifel servers, including its 'master' server in Austria


Sergio de los Santos
Twitter: @ssantosv


jueves, 22 de marzo de 2012

Zeus mejora su ingeniería social: la transferencia "ficticia"

La familia Zeus solía modificar las pantallas de los infectados para pedir la tarjeta de coordenadas completa. Así podían validar transferencias y robar a sus víctimas. A medida que los bancos van implantando los SMS como método de validación, Zeus mejoró incluyendo el envío del troyano al móvil e interceptando los SMS (man-in-the-mobile). Pero esto sólo es válido para BlackBerry y Android, además de que muchos usuarios se mostraban recelosos. ¿Cómo han solucionado este problema? Con un genial movimiento de ingeniería social.


Zeus y SpyEye ya han hecho frente en el pasado al "problema" que les supone la autenticación por móvil en la banca electrónica. Envían a sus víctimas un troyano al móvil, para interceptar así el código de validación en los SMS. De eso ya hemos hablado no hace mucho aquí:

Sin embargo, últimamente han desarrollado una técnica no tan sofisticada técnicamente, sino basada en lo que siempre parece el punto más débil: el usuario y su credulidad. Así, estas versiones funcionan de la siguiente manera. Cuando el usuario se presenta en su página de banca electrónica (y sólo cuando se presenta, no antes) el troyano se activa. Lo primero que hace es interpretar la página del banco concreto, buscando las cuentas que almacenen una mayor cantidad. Esta información la envía a un servidor externo con la siguiente petición HTTP:


Donde "country" es el banco atacado, "amount" la cantidad que guarda la cuenta de la víctima y "login" el login de usuario en la banca oline.

Después, muestra esta pantalla (incrustada en la original):

 
En ella se insta al usuario a realizar un "test" para probar el sistema de SMS de la banca. Bajo la premisa de una transferencia ficticia, se invita al usuario a que pruebe los beneficios del método de validación por móvil. El lenguaje, comparándolo con otro tipo de estafas, está relativamente cuidado.

Si el usuario decide continuar (no tiene otra opción, puesto que si cierra la pantalla no podrá acceder a su banca online), aparecerá este otro mensaje


En ella se hace una transferencia a un beneficiario (el mulero) del que incluso se muestran las últimas cifras de la cuenta. La transferencia es invariablemente por valor de 3.000 euros, e invita al usuario a validarla con el mensaje que ha recibido en su móvil. Lo que está ocurriendo es que el troyano está realizando realmente la transferencia, pero a través de una "interfaz" creada por él, usando los recursos del banco. O sea, al teléfono llegará realmente un mensaje legítimo generado por la entidad y si lo introduce y valida, el efecto será exactamente el mismo que si el usuario hubiese realizado la transferencia de forma habitual desde su portal.

Esta ingeniosa e interesante manera de engañar al usuario está teniendo cierto éxito, y supone un paso muy interesante en la evolución de esta familia y su uso de la ingeniería social.

El resto de comportamiento "técnico" del troyano Zeus, es el "habitual": se inyecta en Explorer.exe, descarga un archivo de configuración cifrado desde alguna ubicación, envía los datos robados a un panel del atacante donde quedan ordenados y clasificados, etc.


Sergio de los Santos
Twitter: @ssantosv

viernes, 16 de marzo de 2012

SpyEye y sus curiosas técnicas de ocultación


A finales de 2010, ya publicamos algunas noticias acerca de la familia SpyEye (con vídeo incluido) en las que se hablaba de su interesante panel de control. Dos años después, el troyano sigue gozando de una estupenda salud, y su variante que infecta también a los teléfonos móviles, está consiguiendo un éxito importante. Hablemos ahora de sus técnicas de ocultación y algunas curiosidades.

SpyEye es un troyano bancario del tipo DIY ("hágalo usted mismo") muy popular. Su nivel de sofisticación es punta de lanza del malware actual. Sus últimas versiones incorporan la infección del móvil con sistema operativo Android o Blackberry cuando se usa el SMS como segundo canal de autenticación de algunos bancos. Así, el troyano tiene el control sobre los dos dispositivos involucrados en la transacción.

SpyEye tiene muchas "virtudes". Entre ellas, es un rookit que impide que se vean sus ficheros si se explora el sistema desde el explorador. Se suele copiar en:

C:\$recycle$

Que queda invisible al explorador. Se puede consultar sin embargo, desde la línea de comando.


Hasta aquí "normal", esto ya lo hacía Zeus desde 2006 y rootkits en años anteriores. Algo que lo diferencia de algunas versiones de Zeus, es que SpyEye es invisible también en línea de comando, gracias a que modifica el comportamiento de dos funciones de Windows a bajo nivel: NtQueryDirectoryFile y NtVdmControl.

En la captura, en el directorio $recycled$ falta un ejecutable. ¿Dónde está? Lo que vemos es el archivo de configuración. El archivo está ahí, incluso oculto para el cmd. Si intentamos copiar cualquier fichero en la misma ruta... nos dice que ese nombre ya está siendo usado.

 
Ocultación en el registro

Durante el análisis de este tipo de malware, una técnica habitual es comprobar con la herramienta Autoruns qué se arranca en Windows. Autoruns recopila de forma muy eficaz todos los puntos que pueden servir para lanzar código que se inicia con el sistema operativo. ¿Dónde se ubican estas versiones de SpyEye para lanzarse en el inicio? Mientras que Zeus trabaja en la shell del Winlogon (más "rebuscado"), esta versión de SpyEye, sorprendentemente, utiliza una zona muy común para arrancar programas en el inicio:

HKLM\Software\Microsoft\Windows\CurrentVersion\run

... pero que se oculta, tanto a los ojos la herramienta "normal" de registro (regedit), como para Autoruns. De nuevo el rootkit de este malware va un poco más allá (los rootkits como tal, insistimos, ya contiene estas técnicas desde hace tiempo). En este caso, parchea en memoria la API NtEnumerateValueKey, que usa ntdll.dll. Esto es muy eficaz, puesto que la API se encuentra a muy bajo nivel. Es decir, cualquier programador usará APIs comunes como RegEnumValue o RegOpenKey, pero estas, internamente, llamarán a NtEnumerateValueKey. Con esto consigue engañar a la inmensa mayoría de programas que quieran leer el registro... aunque no a todos

Autorunsc, el más sincero

Como curiosidad, parece que una de las versiones de SpyEye comete algún tipo de error a la hora de "parchear" en memoria la función. Así, permite que, la primera vez que se lanza Autorunsc (la versión de línea de comandos de Autorun), se pueda leer bien el registro, mientras que en sucesivas consultas... se oculta.


 
Esta imagen lo resume un poco todo. La entrada "oficial" en el registro es solo la correspondiente a ctfmon.exe. Sin embargo, existe otra que solo se puede "ver" en el resultado de Autorunsc después de la infección, volcado en un texto. Se observa la entrada:

YZ5CZHZY5D1EWA9X
     C:\$Recycle$\B8DEA5BBC55.exe /q
     c:\$recycle$\b8dea5bbc55.exe
     7678946538a76066a7d0829584eaa0e3 (MD5)
     9c36092b853526aa340239ac70f5dfb1ced1e921 (SHA-1)
     e20b15ec8f0a5cffce47923dc79934e8c6dd9295c7256881f3d399632e7eaa90
(SHA-256)

Invisible al resto de programas. Si se lanza de nuevo autorunsc y se consulta el registro... desaparecerá. El funcionamiento interno de Autorun y Autorunsc es el mismo, llaman a las mismas API de sistema para leer los valores del registro, así que solo cabe achacar el comportamiento a algún error del troyano, que subsana en sucesivas consultas.

Más curioso todavía

¿Qué hacer entonces para eludir el parcheo en memoria que hace el troyano? Como hemos dicho, lanzando autorunsc.exe la primera vez, será incapaz de ocultarse. Pero existe otro método. SpyEye no afecta a los procesos que se llamen skype.exe. Lo tiene "incrustado" en su código. No es una "puerta trasera" sino que muy probablemente, lo hará para que no le llegue tanto tráfico desde esa aplicación, que quizás no le interese. Así, si renombramos autorunsc.exe a skype.exe, el valor oculto volverá a aparecer. Se observa en la figura el incremento de tamaño del fichero de texto resultante con uno y otro nombre. El aumento de tamaño corresponde a la entrada oculta.


Igualmente, renombrando autoruns.exe a skype.exe, se ve gráficamente la entrada.


Más información:

Bypassing the SpyEye "rootkit", or how to perform a quick disinfection

Analysis of TR/Spy.SpyEye

Vídeo: Así funciona SpyEye (I)

Así funciona SpyEye (y II)


 
Sergio de los Santos
Twitter: @ssantosv