viernes, junio 30, 2017

VBook Windows Server 2016. Los Video-Books de 0xWord

En el equipo de 0xWord se ha estado trabajando en un nuevo formato para llevar nuestros libros. Además de la línea de títulos de 0xWord, las novelas de ciencia-ficción y tecnología de 0xWord Pocket, e incluso el formato cómic de Hacker Épico, ahora se ha lanzado la línea de VBooks, o Vídeo-Books de 0xWord.

Figura 1: VBook Windows Server 2016. Los Video-Books de 0xWord

Se trata de la adaptación de los contenidos de nuestros libros a capítulos en vídeo hechos por los propios autores de los libros de 0xWord, pero con vídeos que permiten acceder a las explicaciones técnicas y las prácticas expuestas en el libro directamente en vídeo.
El primero de los que hemos lazando ha sido el VBook de Windows Server 2016, en el que Ángel A. Núñez recorre los contenidos del libro de Windows Server 206 para entregarlos en formato vídeo. Esta es la agenda del mismo.

Figura 3: Contenidos del VBook 0xWord: Windows Server 2016

Los VBooks se consumen online, y están disponibles durante seis meses para que se pueda consultar tantas veces como se considere necesario, con el objeto de hacer mucho más cómodo consumir el contenido del libro. Por supuesto, siempre puedes optar por el formato clásico del libro y acceder a los contenidos modo "old-school".

Saludos Malignos!

jueves, junio 29, 2017

Barcelona: Changing the Game with Big Data. Registro abierto

El próximo 13 de Julio llega a Barcelona el evento Changing the Game with Big Data, organizado por LUCA D3, la unidad de Telefónica que ayuda a las compañías a recorrer el camino hacia empresas Data-Driven. 
El registro está ya abierto, y tendrá lugar en el Auditorio en Torre Telefónica en Diagonal 00, sito en Plaça d'Ernest Lluch i Martin, 5, 08019 Barcelona. Este fue el lugar en el que presentamos por primera vez nuestra querida Aura, y es el lugar elegido para realizar el primer evento en Barcelona de LUCA D3, donde se podrán ver los productos y servicios que realiza Telefónica para clientes.

Figura 2: Ponentes de Changing the Game with Big Data en Barcelona

En este evento, además de poder ver casos concretos de usos de BigData para negocios como el transporte, el retail, el turismo, el mundo de la publicidad o las smartcities, se podrán ver casos concretos con clientes que los utilizan, contando en primera persona sus experiencias.

Figura 3: Agenda de Changing the Game with Big Data en Barcelona

Si quieres asistir, puedes hacerlo registrándote en la web, para reservar tu sitio. Nos vemos en Barcelona el próximo 13 de Julio.

Actualización: Contacta con hello@luca-d3.com para conseguir tu código de invitación

Equipo de LUCA D3

miércoles, junio 28, 2017

Petya con Eternalblue, el miedo a un nuevo WannaCry y el incentivo a no parchear inmediatamente de Microsoft

Ayer un nuevo ataque de ransomware ha comenzado a copar las portadas de todos los medios de comunicación, y también las redes sociales. No es nada nuevo, y son "solo" dos viejos amigos que se han juntado para volver a intentar hacer un WannaCry. Al igual que en la infección de WannaCry, el atacante ha unido un ransomware bastante conocido, como es Petya, y lo ha unido a la vulnerabilidad de Microsoft Windows EternalBlue, que fue utilizada en el caso de WannaCry. Es decir, un ransonmware más un exploit para crear un gusano y viralizar las infecciones.

Figura 1: Petya con Eternalblue, el miedo a un nuevo WannaCry
y el incentivo a no parchear inmediatamente de Microsoft

En este caso, el ransomware actúa de forma distinta a WannaCry, ya que Petya cifra el MBR (Master Boot Record) del disco duro al estilo de los Bootkits, lo que hace que aunque tengas los documentos protegidos en carpetas seguras, o bajo contenedores cifrados, tus documentos siguen desapareciendo. Lo que no le hace ninguna gracia a los dueños de los equipos. El resultado es el que puede verse en esta foto, de un supermercado de Ucrania que ha circulado por las redes sociales.


Figura 2: Equipos infectados por Petya en un supermercado de Ucrania

Este ataque utiliza otra vez una versión evolucionada de EternalBlue, el mismo fallo de seguridad de Microsoft Windows que utilizó WannaCry para la distribución, así que los equipos que se parchearon durante el ataque del mismo, deberían estar a salvo de posibles infecciones de este ataque. Y la pregunta que surge a muchos... ¿todavía quedan empresas u organizaciones que no se hayan parcheado? 

La pregunta tiene toda la lógica del mundo, especialmente después de WannaCry, pero.. vamos a pensar en un mundo nuevo, en el que después de WannaCry todo el mundo comienza a parchear al día siguiente de que salgan las vulnerabilidades. Es decir, que desaparecen los tiempos de QA en los parches. De hecho, Microsoft se "atrevía" a denominar a los equipos no parcheados aún como "Out-Of-Dated", algo que no era del todo cierto.  Podían ser equipos en proceso de validación del parche.
Esto querría decir que no se prueba el software en los sistemas antes de poner en producción el parche y eso no es una buena idea. Microsoft, cuando saca un parche, lo prueba con su software soportado, pero no con el software que no es suyo. Miento, es cierto que Microsoft, debido a la notoriedad e importancia de algunos software, tiene el compromiso de probar el software con algunos otros fabricantes, para garantizar que sistemas críticos no fallan, para lo que firmaron acuerdos de colaboración en los procesos de QA. Pero estas son excepciones, y no lo hacen con el software hecho a medida en las empresas.

¿Puede fallar de verdad tu programa si se aplica un parche de Microsoft?

Pues la realidad es que puede que hasta falle el software del propio Microsoft cuando se aplica un parche de Microsoft. Sí, así son los procesos de QA de complicados, ya que hay que probar todas y cada una de las características en todos los entornos. Y que no lo hagas. En estos mismos y recientes parches de Junio de Microsoft, Outlook se ha visto afectado por una buena cantidad de fallos que hace que malfuncione cuando se aplican las actualizaciones.

Con estos fallos en las actualizaciones de seguridad, es la propia Microsoft la que "incentiva" de manera involuntaria, a que se extiendan los tiempos en los procesos de QA, porque puede llegar a ser más costoso para una organización con cientos de miles de equipos el costo de repararlos todos - si se aplica masivamente un parche defectuoso - que detectar y responder contra un ataque que aproveche un fallo de seguridad durante la ventana de tiempo de los procesos de QA.

Figura 4: Problemas conocidos de las actualizaciones de seguridad de junio de 2017 en Outlook

Es decir, al final es una gestión del riesgo que debe balancear adecuadamente los procesos para garantizar integridad, privacidad y disponibilidad del negocio. Y por supuesto, cuanto más calidad tengan los parches, mejor que mejor, pues los tests de QA de las empresas no necesitarán ser tan exhaustivos y largos en todos los casos. No hay magia, solo trabajo.

Saludos Malignos!

martes, junio 27, 2017

Script PowerShell WinRM para descubrir Hidden Networks

Hace tiempo nuestro compañero Chema Alonso habló en un artículo de las Hidden Networks que se crean en las organizaciones gracias al - o por culpa del - uso de los dispositivos de almacenamiento USB. En el equipo de ideas locas de CDO de Telefónica estamos trabajando en diferentes experimentos y uno de ellos tiene que ver precisamente en cómo descubrirlas de forma rápida para tener un mapa actualizado de estas redes.

Figura 1: Script PowerShell WinRM para descubrir Hidden Networks

Antes de nada, vamos a repasar someramente lo que son las Hidden Networks y por qué son importantes ya que, seguramente, muchos administradores desconocerán estos riesgos. Cómo se menciona en el artículo de 2014 sobre las Hidden Networks, muchas organizaciones hablan de segmentos de redes aislados controlado e tráfico de uno a otro por un dispositivo de seguridad de red, pero, ¿realmente están aisladas? ¿o están unidas gracias a los dispositivos de almacenamiento USB?

Figura 2: Lista de dispositivos USB conectados a un equipo Mac OSX

Las redes de equipos aislados como, por ejemplo, una red de sistemas de control de fábricas puede estar aislados por seguridad. Esto sería algo lógico, pero si repasamos la historia de la informática nos encontramos con incidentes como Stuxnet, el cual se coló totalmente en una red aislada. Y recientemente hemos sabido del software de Brutal Kangaroo de la CIA que utilizaba los dispositivos de almacenamiento USB para infectar equipos totalmente desconectados.

Figura 3: Brutal Kangaroo para infectar discos -USB

En otras palabras, la historia nos ha demostrado que para tener una red aislada no es suficiente con tener una red de equipos no conectados con cable Ethernet o  ß, y que para contener lo que pasa en una red de una empresa, no es suficiente con segmentar las conexiones de red con Routers, Firewalls o Switches L3. Es decir, cualquier conexión que tengamos con el exterior, por ejemplo, a través de un puerto USB, puede conllevar una amenaza y la materialización de ésta provocando un incidente de seguridad.

PoC: Descubriendo a los USB que crean tus Hidden Networks

Hoy queremos mostrar un pequeño ejemplo en forma de prueba de concepto. Mi compañero Francisco José Ramírez ha creado un script en Powershell aprovechándose de la característica de gestión remota de Powershell WinRM. Esta característica permite a los administradores de IT poder lanzar instrucciones remotamente través de un dominio de Microsoft Windows. Existe una rama del registro que almacena los dispositivos que se conectan al equipo, como ya explicaba Chema Alonso en su artículo.

Figura 4: Claves del registro con IDs de discos USB conectados

Estos datos se pueden obtener en la siguiente ruta del registro SYSTEM\CurrentControlSet\Enum\USBSTOR, así que con un poco de programación podríamos ver todos los de los equipos de nuestra red. El código a modo de prueba de concepto en Powershell tiene el siguiente aspecto:
$Key = "SYSTEM\CurrentControlSet\Enum\USBSTOR"
$Reg = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey($Hive,$Computer)
$USBSTORKey = $Reg.OpenSubKey($Key) 
ForEach($SubKey1 in $USBSTORSubKeys1)
{

$Key2 = “SYSTEM\CurrentControlSet\Enum\USBSTOR\$SubKey1”
$RegSubKey2 = $Reg.OpenSubKey($Key2)
$SubkeyName2 = $RegSubKey2.GetSubKeyNames()
$Subkeys2 += “$Key2\$SubKeyName2”
$RegSubKey2.Close()
}#end foreach SubKey1 
ForEach($Subkey2 in $Subkeys2)
{

$USBKey = $Reg.OpenSubKey($Subkey2)
$USBDevice = $USBKey.GetValue('FriendlyName')
$USBContainerID = $USBKey.GetValue('ContainerID')
If($USBDevice)
{

$USBDevices += New-Object -TypeName PSObject -Property @{
USBDevice = $USBDevice
USBContainerID = $USBContainerID
USBComputerName= $ComputerName
ComputerIP = $ComputerIP
}
}
$USBKey.Close()
}
En breve lo subiremos al Github de ElevenPaths para que podáis utilizarlo a través de la característica WinRM. En la siguiente imagen os mostramos cómo ejecutando el script HiddenNetworks sobre un dominio que tiene varios equipos se puede hacer un listado de dispositivos USB que fueron insertados en dichos equipos, y estos podrían ser discos de almacenamiento, webcams o cualquier otro dispositivo que pueda realizar una función "polinizadora" de tu red.

Figura 5: Dispositivos USB detectados por cada equipo

Este hecho, puede ayudarnos a relacionar qué equipos han insertado el dispositivo USB, es decir, por cuáles equipos ha ido pasando el mismo dispositivo USB. Incluso, se puede trabajar en un timeline de un dispositivo USB y los equipos por los que ha ido pasando para conocer, en un momento de crisis, cuál ha sido el camino seguido de la infección, por lo que tener estos logs diarios en tu organización es de gran valor.

Figura 6: Grafo de conexiones USB en la red hecho con Gephi

Nosotros hemos utilizado una herramienta llamada Gephi para realizar un grafo que relaciona diferentes equipos, que harán de nodos, con dispositivos USB insertados en esos equipos, que serán sus aristas. Cuando dos equipos tienen una unión, significa que dicho USB ha estado conectado en ambos creando una Hidden Network temporal dentro de la organización. Incluso, una red segmentada o equipos que se encuentran en diferentes VLANes pueden quedar expuestos ante este tipo de redes ocultas.

Figura 7: PoC detectando Hidden Networks con PowerShell WinRM

Os dejamos un video dónde se puede ver a Hidden Networks actuando sobre un dominio de Microsoft Windows. ¿Has comprobado en tu red corporativa dónde se encuentran tus redes ocultas? ¿Has mapeado sobre un plano de red tus posibles redes ocultas? ¿Tienes estos logs bien guardados? Lógicamente, en este proceso nos quedarían aún los equipos macOS de Apple, pero esto lo vamos a atacar desde otra perspectiva que ya os contaremos más adelante.

Autores: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths y Fran Ramirez (@cyberhadesblog) escritor de libro "Microhistorias: anécdotas y curiosidades de la historia de la informática" e investigador en ElevenPaths

lunes, junio 26, 2017

Cómo unos "descuidos" de seguridad en Twitter pueden usarse para dominar el mundo

Donald Trump es un usuario muy activo en Twitter con 32,7 millones de followers pero no es ni de lejos el usuario que tiene más seguidores. En el número uno del ranking a día de hoy se encuentra Katy Perry, con más de 100 millones. Los tweets publicados por cualquiera de ellos tienen un impacto de millones de usuarios de dispositivos móviles y ordenadores. Pero ¿y si alguien se hiciera con el control de dicha cuenta y pudiera publicar, por ejemplo, un enlace de descarga que apunte a un malware?

Figura 1: Cómo unos "descuidos" de seguridad en Twitter pueden usarse para dominar el mundo

Las consecuencias serían realmente de proporciones "bíblicas" (como decían en nuestra querida película “Cazafantasmas”) ya que un alto porcentaje de esos seguidores ejecutarían el malware con toda tranquilidad, debido a su total confianza en la fuente. Esto que parece improbable, pudo haber estado más cerca de lo que parece, y no es la primera vez, que en el año 2014 también tuvo un CSRF peligroso que permitía robar cuentas.

En menos de un año han aparecido al menos dos fallos de seguridad relacionados con Twitter que permitían a un atacante realizar diversas acciones desde cualquier cuenta como publicar un tweet en su nombre, subir videos, borrar imágenes, ver ficheros privados, etcétera. Ambas tienen en común el mismo vector de ataque: Twitter Media Studio.

Figura 2: Twitter Media Studio

Media Studio fue lanzado en agosto de 2016 y sustituye a Video Studio. Está formado por una serie de herramientas las cuales ofrecen algunas nuevas características, como mejoras de rendimiento, nueva biblioteca de medios unificada, programación de tweets mejorada, nuevos controles de acceso, etcétera.

Los bugs de Twitter

El investigador Anand Prakash encontró la primera de ellas cuando comenzó a buscar agujeros de seguridad dentro de esta librería y se dio cuenta que todas las peticiones a la API de Studio estaban enviando un parámetro llamado “owner_id”. Este parámetro “owner_id” es un número, secuencial y público, que corresponde a un usuario real de Twitter. Desde esta página web puedes averiguar el id de cualquier usuario de Twitter:

Figura 3: Página web para obtener el id de cualquier cuenta de Twitter

Aunque parezca increíble, este parámetro carecía de un control de seguridad o autorización para confirmar si el usuario que estaba realizando la petición era realmente el propietario de la cuenta. Por lo tanto, simplemente cambiando este valor, era posible realizar acciones sobre cualquier cuenta de Twitter, como poner nuevos tweets, subir videos, fotos, etcétera. Todo esto sin necesidad de saber la contraseña de la cuenta de Twitter.

En este ejemplo vemos cómo se utilizó este fallo de seguridad en una petición a Studio utilizando el id de un usuario de Twitter donde “victim´s user id” puede ser cualquier id público de un usuario de Twitter:
POST /1/tweet.json HTTP/1.1
Host: studio.twitter.com
{"account_id":"attacker's account id","owner_id":"victim's user id","metadata":
{"monetize":false,"embeddable_playback":false,"title":"Test tweet by attacker",
"description":"attacker attacker","cta_type":null,"cta_link":null},"media_key":"",
"text":"attacker attacker"}
En este otro ejemplo vemos la forma de subir cualquier contenido multimedia a la cuenta atacada:
POST /1/library/add.json HTTP/1.1
Host: studio.twitter.com
{"account_id":"attacker's accountid","owner_id":"victim's id","metadata":{"monetize":false,"name":"abcd.png","embeddable_playback":true,"title":"Attacker","description":"","cta_type":null,"cta_link":null},"media_id":"","managed":false,"media_type":"TweetImage"}
Anand Prakash encontró el problema el mismo día de su lanzamiento, pero no fue hasta mayo de 2017 cuando decidió hacerlo público. Twitter asegura que lo solucionó en menos de 24 horas y que ninguna cuenta se vio comprometida. Además, argumentan que, durante el lanzamiento, sólo los desarrolladores autorizados por Twitter tuvieron acceso a estas nuevas herramientas de Studio.

Figura 4: Twitter Bug Bounty Program en HackerOne

Anand recibió 5.040 dólares según el programa de recompensas de Twitter (“bug bounty program”) por haber encontrado este fallo (aunque él reclamó más dinero, ya que pensaba que este fallo entraba en otra categoría más crítica). Pero ¿qué hubiera ocurrido si finalmente ese fallo no se hubiera encontrado y solucionado a tiempo? Charlando con mi compañero Santiago sobre esta situación, empezamos a pensar en posibles escenarios de un posible "apocalipsis" digital a través de Twitter.

Figura 5: Vínculos no seguros en Twitter

Twitter tiene publicado en su web que dispone de un control para analizar el origen y contenido de los enlaces que se publican en los tweets. En función del resultado del análisis del enlace y el nivel de seguridad de la cuenta, puede mostrarnos un aviso (“warning”) cuando la URL o incluso puede llegar a bloquear dicho sitio web si este se encuentra dentro de una lista de sitios potencialmente peligrosos.

PoC: Vínculos no seguros en Twitter

Vamos realizar una prueba para comprobar el nivel de control que Twitter realiza a las URL publicadas. Para ello hemos creado dos cuentas con los parámetros de seguridad que se activan por defecto al crearlas - sin ninguna verificación extra o protección con un segundo factor de autenticación -. Desde una de las cuentas vamos a publicar dos tweets que luego veremos en la otra cuenta que está siguiendo a la primera. La cuenta que publica las URL se llama Cibertest y la cuenta follower se llama Cibertest2.

En este primer video podemos ver la publicación de un tweet con una URL y un fichero ejecutable subido al servicio de intercambio WeTransfer:


Figura 6: Comportamiento de Twitter con tweet con malware en WeTransfer

Como hemos podido observar, parece que no se ha realizado ningún proceso de análisis sobre el fichero descargado ya que lo más probable es que la URL de WeTransfer esté autorizada. De todas formas, el fichero podría ser un malware y podemos bajarlo sin problemas y ejecutarlo (en este punto también es importante el factor de protección del ordenador del usuario que lo ha descargado).

El servicio de alojamiento lo más habitual (o al menos debería de ser así) es que pueda detectar que el fichero subido contenga algún tipo de malware. Por este motivo vamos a realizar de nuevo la prueba, pero esta vez hemos creado nuestro propio servidor de ficheros usando Owncloud - siguiendo este tutorial - y publicado en Internet y hemos subido allí de nuevo el fichero ejecutable. La URL generada no está registrada en las válidas de Twitter:

Figura7: Comportamiento de Twitter con tweet con malware en OwnCloud

De nuevo la URL se publica sin problemas, sin ningún tipo de aviso. Ocurre lo mismo que en el caso anterior, nos permite bajar el fichero, aunque esta vez Google Chrome nos avisa que el archivo es un ejecutable (no debería de ser difícil para un atacante buscar alternativas para ejecutar un programa y evitar este aviso).

Figura 8: Publicación de un tweet con una URL propia desde un servidor de ficheros propio

Ahora supongamos por un momento tenemos un fallo 0Day en Twitter que nos permitiera publicar en cualquier cuenta sin necesidad de saber la contraseña (como el que hemos mencionado al principio del artículo) y por otro lado hemos conseguido subir y camuflar un malware utilizando una URL propia de uno de nuestros servidores de ficheros. Si publicamos un tweet utilizando sólo las tres primeras cuentas en Twitter con más seguidores y además enlazamos el malware (con diferentes versiones para cada plataforma) tendríamos potencialmente casi 300 millones de usuarios potencialmente afectados:

Figura 9: Tres de las cuentas con más followers de Twitter

En definitiva, si este caso hipotético se pudiera llevar a cabo, podríamos estar ante el malware definitivo con uno de los factores de propagación e impacto más grande de la historia.

Autor: Fran Ramirez (@cyberhadesblog) escritor de libro "Microhistorias: anécdotas y curiosidades de la historia de la informática" e investigador en ElevenPaths.

domingo, junio 25, 2017

Google en Gmail ya no va a leerse más tus e-mails para ponerte los anuncios

Este es el anuncio que Google hizo esta semana, el pasado 23 de Junio de 2017, donde después de más de una década leyéndose el correo electrónico de los usuarios para ponernos anuncios "relevantes" en base a nuestras comunicaciones. Sí, Google te leía el correo electrónico de Gmail y te ponía anuncios en base al contenido de tus comunicaciones.

Figura 1: Google en Gmail ya no va a leerse más tus e-mails para ponerte los anuncios

Siempre me ha parecido que la compañía ha sabido gestionar muy bien la imagen pública, y conseguir que algo que no le permitiría a otras empresas, a Google se lo permitió. Leerse el contenido de tus comunicaciones personales. Mientras que con otras empresas, la privacidad era una bandera que esgrimir contra cualquier movimiento, en el caso de Google y Gmail, los usuarios lo aceptaron de facto. Si bien, a día de hoy, hay gente que aún no tenía ni idea de esto.

Figura 2: Gmail will not be used or scanned for any ads personalization

Explicar lo que hacía Gmail con el correo electrónico es fácil. Se lee todos tus correos electrónicos, y en función del contenido busca los anuncios que más tienen que ver con el mensaje. Esto llevaba a situaciones muy curiosas, como cuando yo hacía una demo de Phishing a un Banco, y era el propio banco el que pagaba por "sponsorizar" el phishing.

Figura 3: Correo de phishing "esponsorizado" por el banco suplantado

Al mismo tiempo, Google estaba empujando herramientas de cifrado extremo a extremo, como el uso de WebPG en Google Chrome para que nadie - excepto ellos - pudieran leer tus mensajes. Y si algún correo se entrega sin cifrar, entonces Google te alerta de que alguien - además de ellos - ha podido leer tus mensajes, poniendote un candadito rojo.
Al final, de lo que se trata es de datos. Datos para alimentar el Big Data y hacer mejores servicios de Programatic Advertising. Conseguir llevar el anuncio a la persona que necesita algo antes que los demás. El que antes conecte la necesidad con el producto es el que más puede cobrar por sus servicios de Programatic Advertising. Y Google tenía la ventaja de que se leía tu correo electrónico para localizar mejor tus necesidades.

Figura 5: El viral de Gmail hecho por Microsoft para explicar lo que hacia Gmail

Además, Google al principio era muy agresivo en la publicidad. La ponía en modo híperenlace de texto, pero recuerdo hacer hasta un conteo del número de píxeles que ocupaba la publicidad en Gmail y en Hotmail, para ver quién ponía más anuncios. Pero es que Google necesitaba lugares donde poner anuncios al principio. La demanda era tan grande, que necesitaban sacar muchos anuncios en los lugares donde podían ponerlos. Hoy en día, el número de lugares donde Google puede poner anuncios es tan grande que no necesita ser tan agresivo en Gmail, donde poco a poco se diluye y desaparece.

Al final, el movimiento de no leer más tu correo electrónico tiene muchas lecturas. La primera, claro está, porque al final era la única compañía de las grandes que aún lo hacía. En segundo lugar, la llegada del GDPR en Europa y la e-Privacy Directive que puede que le acabe aplicando, le dejan en una situación muy distanciada con respecto a lo que quiere Europa, y en breve el resto del mundo. Por último, no hay que olvidar que, a pesar de que no se produjo mucho ruido en contra de Google, también salió en la foto del programa PRISM de la NSA por el que - supuestamente - se le daba acceso a los datos de los clientes.

Ahora ya no lo va a hacer más, así que la defensa de que no pasaba nada porque se leyeran el correo electrónico, ahora debe pasar a defender el cifrado e2e y la protección de las comunicaciones de los clientes por encima de todo. Algo que está bien, pero que difiere un poco con el modelo que tenían hasta el anuncio del 23 de Junio

Saludos Malignos!

sábado, junio 24, 2017

Grandes decisiones... o no.

Me han salido canas. Muchas. Como manda el curso de la vida. Me han salido, y puedo ver la diferencia solo mirando las fotos que he publicado por aquí durante las cuatro mil doscientas noventa y seis entradas a las que he dado POST. Me han salido canas, al tiempo que he ido viviendo. Y muchos lo habéis visto. Me habéis acompañado en este viaje de mi vida.

Figura 1: Grandes decisiones... o no.

No está toda mi vida en la red, porque la eclosión de la Web 2.0, con la entrada masiva de las personas con los servicios sociales me pilló ya mayor. Mis padres no subieron nunca fotos digitales mías a una red social para compartir con sus amigos. Mis colegas del colegio nunca tuvieron un grupo de WhatsApp conmigo. No comencé a relacionarme con chicas por Internet, sino al viejo estilo del siglo XX. En las aulas y los bares.

Me hice adulto antes de la eclosión de esa web 2.0. Mis padres no tenían teléfonos móviles para llamarme – ni mucho menos enviarme mensajes – cuando yo estaba de fiesta con los amigos. Rompí con mi primera novia y no tuve que bloquearla en ninguna red social para evitar ver sus mensajes. Fui padre de una hacker preciosa antes si quiera de tener cuenta de Twitter.

Aún así, desde que hace unos doce años abrí este blog – mi entrada de cabeza en la web 2.0 – mi vida se puede seguir prácticamente en Internet. Artículos de mis charlas, comentarios de mis amigos, fotos de reuniones con compañeros, mis primeros trabajos con las técnicas de SQL Injection. Se puede ver lo que fui trabajando para terminar mi carrera universitaria, las charlas en conferencias por todo el mundo. Blind LDAP injection, Heavy Queries, Metadatos, IPv6 attacks, Connection String Parameter Pollution, Latch, Faast, FOCA, Sappo, DirtyTooth, Dust RSS, WordPress in Paranoid Mode, JavaScript Botnets, AURA y no sé cuantas cosas más.

También he ido cambiando en mi trabajo, de Informática 64 a 0xWord, pasando por Talentum, ElevenPaths, Alise Devices, LUCA d3, Telefónica. Viajes por todo el mundo. Países lejanos y cercanos. Cañas en Barcelona. Brisas en el mar de Almería. Cena en The View. Caída en las zarzas con la bici. Asado en Argentina. Conferencia en China. Vinos por Castilla. Charla en Estocolmo. Conferencias en Oslo. Paper defendido en Oporto. Presentación en Varsovia. Charla en San Diego. Viaje a Quito. Visita a las minas de sal en Colombia.

Una noche en la UVI en A Coruña. Un monasterio en Ourense. Concierto de Fito. Amsterdam y la Black Hack. Otra vez Amsterdam con el TechEd para ser MVP. Amsterdam de regreso a otra Black Hack. También por allí con la Hack in the Box. El Museo Van Gogh. Paris. Roma. Bucarest para estar con BitDefender. Charla en Munich. Una Campus Party en Berlín. Una reunión de amigos en Huelva. Snow Board en Baqueria y charla en la universidad de Lleida.

Miro atrás en mi parte de la vida que está volcada en la web y parece que he vivido más de una vida en este tiempo. He bebido la vida a tragos. He corrido para hacer dos cosas en la misma unidad de tiempo. Y he llegado hasta aquí.

Todo lo que he hecho, me ha traído hasta este punto. Como en las películas que comienzan por el final y luego te explican cómo el protagonista ha llegado hasta ese instante. Como si todas las decisiones tomadas, todas las cosas hechas, todas las casualidades sucedidas y habidas en el curso de los acontecimientos hubieran sido un masterplan para tenerme al final aquí, sentando en mi nuevo sofá, escuchando música, con el portátil sobre las piernas cansadas después de haber hecho mis 26 kilómetros mañaneros con la bici en mi ruta.

Todo era un plan para llegar aquí. Aquí comienza la película de verdad. Ya hemos visto el curso de los acontecimientos. Se pueden seguir en la red durante los últimos doce años. Se pueden ver mis aciertos y mis errores. Se puede ver que tengo fans, haters, premios, medallas, página en la Wikipedia, derrotas y victorias. Y ahí estoy. Tecleando letras sobre un documento blanco esperando al final de la película. A que continúe. No me malinterpretéis, yo quiero que esta película sea como la saga de Bond o Dr. Who. Acaba una peli, y comienza otra.

En estos momentos, cuando estás en el cine o en un sofá, llega el estado de excitación. Sentado con las gafas de tres dimensiones. Comiendo palomitas o chuches. Con alguien a tu lado que te da la mano puntualmente. Comentando la película – no muy alto que luego te regañan -. Es ahí cuando esperas que la película se acelere. Tu corazón palpita un poco más. Que algo pase y el prota salve al universo, o salte por la ventana, o muera como en Crank. Es el momento de las decisiones importantes. Matar o morir. Salvar a la chica. Sacrificarse. Cambiar el curso de la historia.

Pero en la realidad no suele ser así.

El número de decisiones que tienen un impacto grande en la vida de una persona son apenas una decena. El resto del tiempo nos dedicamos a tomar decisiones menores. De hecho, las grandes decisiones de tu vida tal vez las tomaste casi sin darte cuenta, y es con el paso del metraje de tu película, cuando haces flashback, el momento en que te das cuenta de lo importante que fue aquella decisión. El impacto que tiene hoy en día lo que hiciste aquel otro día en el pasado.

Yo hoy he decidido hacer una gran decisión. Me voy a patinar con mi nuevo monopatín y dejo el post técnico que tenía previsto publicar hoy para otro día. Me voy a patinar a la pista donde suelo hacerlo cuando quiero pensar quemando rueda. Es la decisión de este protagonista. ¿Será tan importante? ¿Pasará algo allí? ¿o será solo un rato del protagonista patinado escuchando Spottify sin que nada pase? Solo el curso del metraje nos lo desvelará. En la siguiente entrega sabremos.

Saludos Malignos!

viernes, junio 23, 2017

Brutal Kangaroo y la infección por USB de equipos aislados

Las técnicas de infección de equipos y distribución de malware usando discos USB no es algo nuevo. Se conocía desde antes, pero saltó a los titulares de todo el mundo con la ciberarma Stuxnet, - atribuido popularmente a la NSA - que, en pocas palabras, fue un malware especialmente creado para distribuirse por medio de discos USB hasta llegar a unos equipos muy concretos de una central de enriquecimiento de uranio en Iran.

Figura 1: Brutal Kangaroo y la infección por USB de equipos aislados

Desde entonces, los exploits y los payloads para, desde un disco USB infectar a un equipo y viceversa, desde un equipo infectar a un USB, han ido apareciendo a lo largo del tiempo. Desde payloads para copiar todos los datos que están en un disco USB conectado y llevarlos a la nube, hasta exploits que ejecutan código arbitrario en el servidor por medio de 0days que se han ido descubriendo.

Figura 2: USB Dumping para OS X

Este es un tema que a mí personalmente me gusta mucho, ya que los discos USB pintan en una organización una Hidden Network que puede ser utilizada para filtrar datos o para infectarte equipos mediante un sistema de polinización. Si tienes el mapa de la Hidden Network creada por discos USB en tu organización, probablemente podrás descubrir qué discos son los responsables de las últimas alertas de seguridad en tus sistemas antimalware o por donde te entró un software malicioso en tu organización.

Figura 3: Bug CVE-2017-8484 en ficheros .LNK

Como he dicho antes, desde Stuxnet todo el mundo puso mucha atención a estas técnicas de infección, y los 0days y payloads se han ido desarrollando a lo largo del tiempo. Sobre todo, porque en los equipos denominados Air-Gapped, es decir, totalmente desconectados de cualquier red, hay siempre dos trabajos a realizar. Primero conseguir llegar a él e infectar el equipo para ejecutar código malicioso y llegar a los datos o el sistema de control que protege ese servidor, y segundo, sacar la información o conectarse remotamente con un panel de control remoto.

Brutal Kangaroo de Vault7

Para el segundo trabajo, los estudios han ido apareciendo en los últimos tiempos, y se han utilizado desde sistemas de Radio Frecuencia, hasta la temperatura de máquinas cercanas, para conseguir esa comunicación entre un malware instalado en un servidor Air-Gapped (asilado) y el panel de control del atacante. Sin embargo, parece una canal muy rápido utilizar también el el propio canal USB, y eso es lo que parece que la CIA estaba utilizando.
La herramienta que ha sido publicada por Wikileaks dentro de las filtraciones de Vault7, lleva por nombre Brutal Kangaroo, y es, como se puede ver, un programa que permite implantar en un servidor aislado un software para infectar cualquier disco USB que se conecte al mismo. Brutal Kangaroo no está pensada para infectar al servidor aislado, sino para estar residente en él e infectar todos los discos USB que se conecten. Por supuesto, se podrían instalar las capacidades de este software malicioso también  por medio de un disco USB.

Una vez que el servidor aislado es infectado - al que denominan en la documentación "Emotional Simian", se utilizan varios 0days para Windows que hoy en día están cerrados por Microsoft en todas sus versiones soportadas (nota a esto, versiones soportadas), para infectar los discos USB. La lista de exploits no es muy larga, pero contaba con el 0day de los ficheros .LNK que Microsoft ha vuelto a revisitar hace dos días o con EzCheese que cuenta con soporte para diferentes versiones. En la imagen se puede ver cómo el creador de la instancia puede elegir su target correctamente.
Son más de 150 páginas de documentación, que para los investigadores van a abrir unas cuantas horas de análisis, para entender mejor cómo funcionan las herramientas de ciberespionaje que sacan partido de los 0days y payloads que se van descubriendo.

Saludos Malignos!

jueves, junio 22, 2017

Sesiones de Changing the Game with Big Data en Vídeo

Ha sido hace nada, y ya están disponibles los vídeos del evento que realizaron los compañeros de LUCA en Madrid. Bajo el título de "Changing the Game with Big Data" presentaron algunos de los proyectos en los que hemos estado trabajando durante los últimos tiempo, con experiencias concretas contadas directamente por los propios clientes.

Figura 1: Sesiones de Changing the Game with Big Data en Vídeo

Yo tuve el honor de dar la bienvenida a los asistentes que puedes ver aquí, pero lo realmente importante son las charlas donde se pudo ver todo lo en lo que desde el equipo de LUCA Data-Driven Decisions se ha estado trabajando. Estas son las sesiones.


Figura 2: La propuesta de LUCA para transformar tu sector 


Figura 3: LUCA Store: Conociendo mejor a tu cliente

En el Mobile World Congress presentamos LUCA Store, con varios casos concretos de clientes, que puedes ver en este vídeo de dos minutos donde se ve el poder de los insights generados.

Figura 4: LUCA Store


Figura 5: LUCA Transit: Innovación en la gestión de la movilidad en las smartciteis

Además del caso explicado en la charla de LUCA Transit de la movilidad de Zaragoza, ya en el Mobile World Congress de este año hablamos de cómo usar LUCA Transit con datos OpenData de las ciudades para medir la seguridad de las ciudades. Esta es la explicación de cómo se saca esa información.


Figura 6: LUCA Transit: Cómo medir la seguridad de las carreteras con Big Data


Figura 7: LUCA Tourism: Optimizando la oferta turística con Big Data 


Figura 8: Big Data & Business con Synergic Partners


Figura 9: Sesión de Preguntas y Respuestas

No hay nada mejor que ver a tus clientes hablando de las soluciones creadas, y en el mundo del Big Data, donde la aplicación de los insights que se extraen de los datos tiene tanto impacto, más todavía. Esperamos que estas experiencias os den ideas para aplicar el poder del Big Data en vuestro entorno.

Saludos Malignos!

miércoles, junio 21, 2017

Aprende a tener Redes más seguras con técnicas de Machine Learning con esta sesión en vídeo #redes

Esta semana ha tenido lugar el seminario dedicado a la consecución de "Redes más seguras con Machine Learning". Este seminario lo han realizado nuestros ingenieros de LUCA Data-Driven Decisions y analistas de ElevenPaths y mezcla las dos disciplinas conjuntamente: El análisis del tráfico de red y las técnicas de Machine Learning tan útiles para detectar anomalías en las situaciones que están sucediendo en la red.

Figura 1: Redes más seguras con Machine Learning

El vídeo de la sesión está ya disponible en Youtube, y lo puedes ver aquí mismo, aprovechando que ya llegan las jornadas de verano y las tardes de verano para aprender cosas nuevas. Nuestro analista de seguridad Rafa Sánchez y la Dra. Carmen Torrano dirigen esta sesión.

Figura 2: LUCA Talk 6: Redes más seguras con Machine Learning

Con estas técnicas, se detectan muchos de los ataques de redes IPv4&IPv6 que describimos en el libro de 0xWord dedicado a esta temática, y son de gran utilidad para tenerlas en los SOCs.

Saludos Malignos!

martes, junio 20, 2017

Cómo saltarse AppLocker en Windows 10 con las reglas por defecto

La semana pasada hablamos de un Bypass a AppLocker mediante el uso de la aplicación BgInfo. Hoy hablaremos de la configuración por defecto de AppLocker y los riesgos que esto proporcionan para la defensa del sistema. Las reglas por defecto de AppLocker permiten a todos los ficheros que se encuentran dentro de la ruta Windows y Program Files ser ejecutados, ya que, si no fuera así, el sistema no funcionaría de forma normal. Si no se establecen los permisos de forma adecuada en estas carpetas, un atacante podría explotar esto para conseguir bypassear AppLocker.

Figura 1: Cómo saltarse AppLocker en Windows 10 con las reglas por defecto

En Windows 2008 R2, se permite por defecto a los usuarios estándar del sistema tener acceso de lectura y escritura sobre estas carpetas: \Windows\Temp y \Windows\Tracing. La herramienta accesschk se puede utilizar para identificar si el grupo de usuarios o “Users” tiene permisos de lectura y escritura dentro de la carpeta Windows. En la imagen se puede visualizar este hecho en Windows 10.

Figura 2: Ejecución accesschk64 en Windows 10

Aunque en la imagen no se visualiza, la ruta \Windows\Tasks también está disponible y podemos almacenar binarios en dicha ruta. Ahora vamos a ver cómo funciona todo esto para hacer un bypass de AppLocker.

PoC: Jugando con las rutas y AppLocker

En primer lugar, vamos a ver las reglas que se crean por defecto en AppLocker al activarlo. Hay que recordar que tenemos que, en caso de no estarlo, tenemos que reiniciar el servicio de identidad llamado Application Identity. En la imagen se puede visualizar las reglas que Windows crea por defecto, cuando todo está activo.

Figura 3: Reglas por defecto en AppLocker

Si analizamos vemos que nos dan acceso, a cualquier usuario del sistema, a ejecutar binarios que se encuentren en Program Files y Windows, pero en ninguna ruta más. Es decir, si tuviéramos un binario en el escritorio no podríamos ejecutarlo.

Para comprobar este hecho, utilizamos el propio binario del accesschk.exe que hemos bajado con anterioridad. Si ejecutamos el fichero accesschk.exe en la ruta del escritorio, por ejemplo, obtendremos una denegación en la ejecución del fichero, tal y como se puede ver en la imagen.

Figura 4: Denegación de acceso en accesschk

Pero bien, si utilizamos una ruta que se encuentre en \Windows, dónde el usuario puede copiar archivos y utilizar dicha ruta como válida, ante la configuración por defecto de AppLocker, tendremos la posibilidad de hacer el bypass.

Como se puede ver en la anterior imagen, cuando lanzamos el fichero accesschk.exe en una ruta como \Windows\tasks, la cual está permitida por defecto por AppLocker, podemos lograr la ejecución. Esto es un riesgo grande de las rutas por defecto. Además, en sistemas como Windows 2008 R2 se probó que usuarios sin privilegios pueden lograr la ejecución en dicha ubicación.

PoC 2: Meterpreteando el AppLocker por defecto

En esta segunda prueba de concepto, la idea es utilizar esta característica de Windows y su configuración por defecto, para lograr ejecutar un Meterpreter a través de un binario utilizando la técnica denominada Weak Path Rules.

Lo primero es generarse un binario con Metasploit, por ejemplo. Utilizamos el módulo payload/windows/meterpreter/reverse_tcp y configuramos LHOST para que apunte a la dirección IP de la máquina del atacante/auditor. Después, utilizamos el comando generate para generar el binario en el formato que queramos.

En la siguiente imagen, se puede ver el fichero app.exe, ya creado. Este fichero contiene un Meterpreter apuntando a la dirección IP del atacante/auditor. Si probamos a lanzarlo desde el escritorio no podremos hacerlo, pero si utilizamos la ruta de \Windows\tasks lograremos su ejecución.

Figura 5: app.exe con Meterpreter apuntando a la dirección IP del atacante.

En la siguiente imagen, se puede ver como se genera el binario y como se configura el módulo handler en Metasploit para recibir la conexión inversa. Además, cuando se consigue el bypass de AppLocker vemos como logramos la sesión inversa en nuestra máquina proveniente del equipo Windows.

Figura 6: Sesión recibida en Metasploit tras la ejecución saltándose AppLocker

Para ejemplificar este proceso os dejamos dos videos que muestran en qué consiste el bypass del AppLocker y en el segundo vemos cómo aprovecharlo para lograr ejecutar una Meterpreter en el equipo Windows.

Figura 7: PoC ByPass de AppLocker por Weak Path Rules

Sin lugar a la duda, una interesante técnica a tener en cuenta y utilizable en un ethical hacking. Desde el punto de vista de la fortificación de Windows, puede ser interesante utilizar reglas más concretas para evitar este tipo de técnicas, que muestran lo sencillo, que, en algunas ocasiones, puede ser esto.

Figura 8: PoC ejecución de Meterpreter y recepción de shell saltándose AppLocker

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths

lunes, junio 19, 2017

El creador de WannaCry es fan de Messi, no es muy ambicioso y usa Microsoft Word habitualmente en coreano

Esta semana, nuestros compañeros del laboratorio de ElevenPaths terminaban por publicar su análisis de WannaCry desde el punto de vista de los metadatos. Un enfoque no se había puesto encima de la mesa aún y que ellos han querido tocar de forma minuciosa y que, desde el punto de la investigación forense ha dado muchos frutos en el pasado.

Figura 1: Un análisis de WannaCry desde el punto de vista de los metadatos

No quiero en este post repetir el sesudo análisis que han hecho mis compañeros del laboratorio, así que os invito a leerlo completamente para entender todos los detalles - que es donde suele estar el diablo - pero si os voy a hacer un resumen de los datos más importantes para que tengáis una lectura rápida.

Al atacante le gusta Messi

O puede que lo odie, lo cierto es que es analizando los metadatos de los ficheros RTF con los que WannaCry configura los textos en la pantalla en la que informa a la víctima que ha sido infectado, es el usuario que aparece.

Figura 2: Textos multi-idioma en WannaDecryptor
Puedes utilizar cualquier herramienta que extraiga metadatos de documentos RTF como nuestro MetaShield Clean-Up Online y analizar los resultados que se obtienen. En las cadenas se puede ver el nombre del usuario que es Messi.

Figura 3: Messi en el análisis de metadatos de los textos RTF de WannaCry con MetaShield Clean-Up Online

Este nombre de usuario es el que el atacante utilizó para crear o modificar con su editor de textos los ficheros RTF.

Utilización de Microsoft Word

Averiguar que el atacante utiliza Microsoft Word para crear los documentos RTF no es demasiado complejo, ya que, como sucede con muchas otras herramientas, Microsoft Word deja "Información Oculta" en los ficheros RTF. En las versiones más antiguas de Microsoft Office, es fácil localizar esta versión en el atributo \generator, pero no siempre aparece cuando son versiones modernas.

Figura 4: Especificación RTF para el campo Generator

Sin embargo, analizando cómo implementa las especificaciones RTF se puede ver que el Internal Version Number - donde se guarda información de la versión del documento -sigue el estilo de Microsoft Office. Generalmente es un campo de 5 dígitos, no muy bien documentado, y que otras herramientas utilizan de forma distinta. Para analizar los RTF utilizamos nuestra nueva herramienta MetaShield Clean-Up Online, donde se puede subir un documento en este formato y ver qué metadatos tiene.

Utiliza Microsoft Word en Coreano

El indicio que nos lleva a pensar a que con gran probabilidad es Microsoft Office y con idioma en Coreano es, precisamente, la forma en que se comporta Microsoft Word con los idiomas cuando se hace esa configuración.

Figura 5: Idiomas en el documento RTF de WannaCry

En los documentos RTF usados en WannaCry salen tres idiomas, como se puede ver en la siguiente imagen que son Coreano, Inglés y Árabe. El primero de ellos aparece en la etiqueta del metadato \deflang con el control \plain, lo que indica que es el de por defecto.  La cadena de metadatos exacta es:
\rtf1\adeflang1025\ansi\ansicpg1252\uc2\adeff31507\deff0\stshfdbch31505\stshfloch31506\stshfhich31506\stshfbi0\deflang1033\deflangfe1042\
El que se utilice el inglés es porque si se configurar una versión de Microsoft Word con el idioma Coreano, éste software siempre añade el idioma inglés - es el comportamiento de Microsoft Office y podéis comprobarlo -. Además, el que aparezca el idioma árabe es porque existen versiones de Microsoft Office "EMEA" en que el idioma por defecto para versiones asiáticas, y se mete en el metadato \adeflangfe.

Figura 6: Selección de idioma por defecto en Microsoft Office

En definitiva, analizando el comportamiento de Microsoft Word con este tipo de documentos hace pensar en que el idioma por defecto es Corenao, a pesar de que los documentos estén escritos en Chino o Letón.

Tiempos de edición y número de revisiones

Una cosa interesante es que se puede analizar cuánto es el tiempo que ha tardado en editar cada uno de los ficheros RTF que se usa para todos los idiomas, y parece que se tomó mucho más tiempo para la versión de Chino Simplificado, y luego un poco menos para Inglés y Búlgaro, mientras que para el resto de los idiomas casi no dedica tiempo.

Figura 7: Tiempo de edición por tipo de fichero de idioma

En el caso de las revisiones sucede lo mismo. Chino es la que más revisiones cuenta, lo que parece que le pudo llevar a matizar más el texto de ese idioma.

Figura 8: Número de revisiones por tipo de documento

¿Esto quiere decir algo? Pues lo que quieras interpretar, pero está claro que el que escribió esos documentos parecía tener más interés - o conocimiento - del Chino tradicional que de otros idiomas.

Las posibles zonas GMT

Esta parte del análisis es de las más curiosas, ya que no solo tenemos la información de los metadatos de RTF y contamos también con los metadatos de los ficheros ZIP. En las versiones de WannaCry se utiliza un fichero ZIP para descargar el ransomware, y en él se almacena la fecha del último acceso con su propia zona horaria. Analizando las fechas del ZIP se puede concluir que:
2017-04-27 17:25 (hora local del atacante): El atacante crea b.wnry, un fichero BMP en segundo plano y el r.wnry, que contiene el fichero "readme". 
2017-05-09 16:57: El atacante crea otro zip con herramientas para conectarse a la red Tor y negociar el rescate. Se descargaron en el sistema de archivos del atacante a las 16:57, 09/05/2017, hora local del atacante, y son empaquetados e introducidos en un nuevo zip, s.wnry. 
2017-05-10 01:16: El atacante crea en su sistema c.wnry, que contiene dominios onion de la red Tor y una cartera para bitcoins. 
2017-05-11 15:59: Crea r.wnry que contiene instrucciones de borrado. 
2017-05-11 16:47: Edita b.wnry. 
2017-05-11 20:11: Edita c.wnry de nuevo. 
2017-05-11 20:13: Introduce b.wnry en el zip y lo comprime con contraseña. 
2017-05-12 02:22: Añade los ficheros EXE: u.wnry y t.wnry. El atacante empaqueta y establece una contraseña. El payload de gusano está listo.
Teniendo en cuenta que cada vez que se infecta un equipo se accede al fichero ZIP para extraer el ransomware, y que las primeras infecciones fueron descubiertas en la zona de Tailandia sobre las UTC 00:00, entonces podemos asumir cuales serían las zonas GMT posibles, es decir, que dentro de ese mismo día fueran posteriores a la fecha de creación del ramsonware.

Figura 9: Zonas horarias válidas con las fechas de los archivos ZIP

Podría ser coreano (UTC+9),  pero también de cualquier zona entre UTC+3 y UTC+12 como podéis ver en la infografía superior.

No es muy ambicioso

Por último, el tema del dinero es bastante pecuiliar. A día de hoy, tal y como vimos al principio, el autor no ha retirado ningún BitCoin de los monederos, pero es que hemos revisado las carteras de la primera versión de WannaCry 1.0 (Sin contar con la "gusanificación" vía EternalBlue), y sigue sin haber retirado ningún bitCoin de ellas.

Figura 10: Billetera BitCoin utilizada en WannaCry 1.0

Es decir, que el creador de estas dos campañas WannaCry 1.0 y WannaCry 2.0 no ha retirado ningún dinero de lo obtenido co el malware. Vamos, que o no tenía ningún interés en ello desde el minuto uno, o se ha arrepentido.

Saludos Malignos!

PD: Más referencias.

- El ataque del ransomware WannaCry
- Telefónica WannaCry File Restorer
- Telefónica WannaCry File Restorer Desktop Version
- Telefónica WannaCry File Restorer en Active Directory
- Latch Antiransonware para luchar contra el ransomware

Entrada destacada

Nuevo libro "Máxima Seguridad en Windows: Secretos Técnicos 4ª Edición" de @0xWord

Desde 0xWord se ha acelerado para tener a tiempo antes del verano la 4ª Edición del libro "Máxima Seguridad en Windows: Secretos Técn...

Entradas populares