sábado, 23 de enero de 2016

Análisis de un Bitcoin Miner malicioso y sus formas de esconderse

El payload que puede tirar un código malicioso al infectar un sistema puede tener los más diversos objetivos; entre algunas de las acciones que nos podemos encontrar se encuentran los Bitcoin Miners. Los cibercriminales buscan aprovecharse de los recursos de los sistemas que infectan y así tomar el control, robar información, o como veremos en este post, minar ciertas monedas criptográficas para generarle una ganancia al atacante.
El archivo malicioso que vamos a analizar es detectado por los productos de ESET como una variante de Win32/CoinMiner.LV y utiliza diferentes técnicas para evitar ser analizado, como así también evitar ejecutarse en entornos virtuales. Cuando comenzamos el análisis de esta amenaza en un desensamblador como IDA Pro, nos encontramos con diferentes comprobaciones para saber si estaba siendo analizado con un debugger:
desensamblador
Entre las técnicas que nos encontramos están la llamada a IsDebuggerPresent,CheckRemoteDebuggerPresent y la comprobación de PEB (Process Environment Block) del proceso para ver si estaba habilitado el flag de debug. Luego de pasar las comprobaciones, el malware pasa a la sección principal, donde busca tres recursos diferentes que se encuentran en la sección .rsrsc:
recursos-directorio
De la imagen anterior podemos ver que existen los recursos RT_RCDATA 01 y 2 que son cargados antes de realizar cualquier otra acción al cargar la segunda parte de este código malicioso:
GetResources Code
Más adelante, vimos que utilizaba estos recursos repetidamente a lo largo de su ejecución; luego de analizar el binario vimos que cada uno de ellos se convertía en:

  • Resource “0”: contiene la URL del pool al que se va a conectar el miner. El contenido está cifrado
  • Resource “1”: contiene la clave de cifrado para descifrar los otros dos resources
  • Resource “2”: es el más grande y contiene un archivo ejecutable cifrado

Para descifrar los recursos que están cifrados dentro del ejecutable utiliza la función con el siguiente prototipo para descifrar los recursos:
int descifrarRes(void* cifrado, void* clave, int size_clave, void* buffer)
El mismo está compuesto por algunas comprobaciones y dos xor:
xor
En forma simplificada, cada caracter descifrado se obtiene de la siguiente forma:
descifrada[i] = clave[i] XOR cifrada[(size_cifrada – 1) – 32 + (i mod 32)] XOR cifrada[i]
Es decir que en primera instancia se va tomando cada byte de la clave y se le aplica una operación de XOR. Para el segundo operando se toman los últimos 32 bytes del texto cifrado, también de a uno por vez. Cuando se pasa del final, se vuelve al comienzo del intervalo (por ello se toma el resto de la división por 32). Y luego se aplica el segundo XOR, con cada byte de la cadena cifrada, pero esta vez desde el comienzo.
Así, el resource “0” se vuelve visible:
“-a scrypt -o stratum+tcp://eu.ltcrabbit.com:3333 -u YouMother92.Miner -p x -g no -t 2”
Vemos que son los parámetros para la ejecución de un miner que se conecta a ltcrabbit.com(Litecoins) con el usuario “YouMother92.Miner” y contraseña “x”. También vemos que el algoritmo usado es scrypt, aunque el sitio también ofrece la alternativa de X11. Si bien X11 puede llegar a ser más rápido, requiere el uso intensivo de GPU. No pudiendo garantizar que la máquina infectada posea GPU, entendemos la elección de los cibercriminales de usar scrypt.
Luego se aplica la misma rutina de descifrado al resource “2”. Sin embargo, esto devuelve un contenido que tiene una capa más de cifrado, para lo cual se invoca a otra subrutina. Vemos la estructura de esta segunda función de descifrado en la siguiente imagen:
Funciones-descifrado
Luego del descifrado, queda un ejecutable en memoria que podemos volcar. El archivo resultante tiene SHA-1 igual a 5f3d01baa567d8b5e32ae933f94472d1d40aaf0e. Que no es más ni menos que una aplicación para minar Bitcoins, o Litecoins este caso. Así, y con lo que hemos visto hasta el momento, podemos suponer que el malware va a ejecutar un cliente de mining, con los parámetros y la URL que se descifraron previamente.
Sin embargo, el ejecutable que ha sido descifrado en memoria no será escrito al disco, sino que será inyectado en la imagen de otro proceso, a través de la técnica conocida como Process Replacement. Para ello, la siguiente acción que realiza el malware consiste en buscar y ejecutar “C:\Windows\Microsoft.NET\Framework\v2.0.50727\vbc.exe”.
A continuación la imagen del respectivo CreateProcess:
CreateProcess
Se observa cómo se lanza una aplicación no maliciosa (vbc.exe, el compilador de Microsoft Visual Basic) con los argumentos que vimos antes. En la misma rutina que se invoca CreateProcesstambién se llama a NtUnmapViewofSectionWriteProcessMemory y ResumeThread, con lo cual se remplaza la imagen de vbc.exe con el miner que se descifró en memoria. Esa rutina tiene una disposición lineal, y en la siguiente imagen mostramos una parte:
Process Replacement
Luego de esto, el miner queda trabajando bajo el nombre de vbc.exe, mientras que el malware entra en un bucle de comprobación de procesos de análisis.
Process Check
Así, cada segundo se itera por los procesos que están en memoria, buscando los que se observan en la imagen anterior. Si alguno de ellos es encontrado (es decir, si alguno de ellos está siendo ejecutado) se termina la ejecución, evitando así que se estudie el programa malicioso o el usuario se dé cuenta de que alguien está minando Litecoins con su sistema sin su permiso.
Por otro lado, resulta curioso que en la lista no aparezcan aplicaciones de monitoreo de tráfico de red, tal como Wireshark. De hecho, si capturamos el tráfico en la máquina infectada, vemos la comunicación con el servidor:
Wireshark-miner
Esta familia de malware es normalmente distribuida por otros códigos maliciosos, que además de robar información utilizan este tipo de acciones para generar otro tipo de ganancia a los atacantes. Por otro lado, en este post vimos algunas técnicas que los cibercriminales suelen utilizar para ocultar diferentes amenazas dentro de un mismo código malicioso, ya sea utilizando una imagen osimplemente ocultándolos en los recursos del programa.

viernes, 22 de enero de 2016

Bloquea a los usuarios infectados con ransomware con CryptoBlocker

es un script en powershell sencillo pero bastante útil para bloquear a los usuarios infectados por distintas variantes de ransomware.



Lo ideal es instalarlo en los servidores de ficheros de tal manera que, cuando se detecte que un usuario escribe algún fichero malicioso en un recurso compartido, deniege inmediata y automáticamente el acceso para impedir que continúe cifrando el resto.

Paso a paso lo que hace es lo siguiente:

1. Revisa los recursos de red compartidos
2. Instala File Server Resource Manager (FSRM)
3. Crea los scripts batch/PowerShell usados por FSRM
4. Crea un Grupo de Ficheros en FSRM que contiene los nombres de archivos y extensiones maliciosos
5. Crear una Pantalla de Ficheros usando el grupo creado anteriormente, con notificaciones de eventos y comandos
6. Crea Pantallas de Ficheros usando esa plantilla para cada unidad que contenga recursos de red compartidos

Recordar que este script no parará las variantes de ransomware que utilicen extesiones aleatorias ni borrará los ficheros README. También es posible utilizar el evento "Source = SRMSVC, ID = 8215" para personalizar alarmas si se dispone de un sistema de monitorización. 


Evidentemente también podemos añadir más nombres de fichero / extensiones a $monitoredExtensions y volverlo a desplegar cuando sea necesario.

Fuentehttps://github.com/m-dwyer/CryptoBlocker/

jueves, 21 de enero de 2016

Nueva ola de ataques contra la industria energética ucraniana

El pasado 19 de enero descubrimos una nueva ola de ataques, donde una vez más las víctimas fueron una serie de empresas de distribución de electricidad en Ucrania tras los apagones energéticos de diciembre. Lo que resulta particularmente interesante es que el malware utilizado en esta ocasión no es BlackEnergy, planteando así más preguntas acerca de los autores detrás de la operación en curso. El malware se basa en un backdoor de código abierto disponible en forma gratuita: algo que nadie podría esperar de un presunto operador de malware patrocinado por el estado.

Detalles sobre el ataque

El escenario de ataque en sí no ha cambiado mucho con respecto al descrito en nuestra publicación anterior de este blog. Durante el pasado martes 19, los atacantes enviaron correos electrónicos de phishing dirigidos a las posibles víctimas. Cada correo electrónico contenía un archivo adjunto con un .XLS malicioso:

Correo electrónico de phishing dirigido, enviado el 19 de enero de 2016html-pngarchivo-XLScodigo-ejecutablepython_codigo
  • VBA/TrojanDropper.Agent.EY
  • Win32/TrojanDownloader.Agent.CBC
  • Python/Agent.N
Reflexiones y conclusiones
  1. Probablemente se trate del primer caso en que un ciberataque de malware haya provocado un corte de energía eléctrica a gran escala.
  1. Los principales medios de comunicación le atribuyeron popularmente los ataques a Rusia, a partir de los reclamos de varias empresas de seguridad de que la organización que utiliza BlackEnergy (también conocido como Sandworm o Quedagh) está patrocinada por el estado ruso.
Indicadores de sistemas comprometidos
62.210.83.213BC63A99F494DE6731B7F08DD729B355341F6BF3D


El pasado 19 de enero descubrimos una nueva ola de ataques, donde una vez más las víctimas fueron una serie de empresas de distribución de electricidad en Ucrania tras los apagones energéticos de diciembre. Lo que resulta particularmente interesante es que el malware utilizado en esta ocasión no es BlackEnergy, planteando así más preguntas acerca de los autores detrás de la operación en curso. El malware se basa en un backdoor de código abierto disponible en forma gratuita: algo que nadie podría esperar de un presunto operador de malware patrocinado por el estado.
El escenario de ataque en sí no ha cambiado mucho con respecto al descrito en nuestra publicación anterior de este blog. Durante el pasado martes 19, los atacantes enviaron correos electrónicos de phishing dirigidos a las posibles víctimas. Cada correo electrónico contenía un archivo adjunto con un .XLS malicioso:
Correo electrónico de phishing dirigido, enviado el 19 de enero de 2016
El correo electrónico incluye contenido HTML con un enlace a un archivo .PNG ubicado en un servidor remoto para que los atacantes reciban una notificación cuando el correo electrónico es entregado y abierto por la víctima deseada. Sabemos que el grupo BlackEnergy ha utilizado esta misma técnica interesante en el pasado.
Fragmento del contenido HTML del correo donde figura el archivo PNG
También resulta curioso que el nombre del archivo PNG sea la cadena de texto “enviar_a_correo_electrónico_ de_la_víctima”, codificada en base64.
Archivo XLS utilizado en los ataques
El archivo XLS malicioso habilitado para macros es similar a los que ya hemos visto en olas de ataques anteriores. Mediante el uso de Ingeniería Social, intenta engañar al destinatario para que haga caso omiso de la advertencia de seguridad de Microsoft Ofifice y ejecute la macro de todas formas. El texto del documento, traducido del ucraniano, dice:
¡Atención! Este documento se creó con una versión más reciente de Microsoft Office. Es necesario habilitar macros para mostrar el contenido del documento.
La ejecución de la macro activa un trojandownloader malicioso que intenta descargar y ejecutar el payload final desde un servidor remoto.
Fragmento de código extraído del archivo ejecutable
El servidor que aloja el payload final está ubicado en Ucrania y se cerró tras la notificación de CERT-UA y de CyS-CERT.
Esperábamos encontrar el malware BlackEnergy como payload final, pero en cambio, en este caso se utilizó un malware diferente. Los atacantes emplearon versiones modificadas de un backdoor gcat de código abierto escrito en el lenguaje de programación Python. Luego se utilizó el programa PyInstaller para convertir el script en python a un archivo ejecutable autosostenible.
Código ofuscado del backdoor GCat
Este backdoor es capaz de descargar archivos ejecutables y ejecutar comandos de shell. Las demás funcionalidades del backdoor GCat (como tomar capturas de pantalla, registrar las pulsaciones del teclado o subir archivos) fueron eliminadas del código fuente. Los atacantes lo controlan mediante una cuenta de Gmail, lo que dificulta la detección de este tipo de tráfico en la red.
Las soluciones de seguridad de ESET detectan esta amenaza como:
Desde que descubrimos estos ataques y comenzaron a aparecer las primeras publicaciones en blogs, se han ganado la atención mediática en todo el mundo. Las razones para ello son dos:
El primer punto ha sido un tema de debate en cuanto a si el malware realmente causó el corte de luz o si solo “lo hizo posible”. Si bien existe una diferencia en los aspectos técnicos de ambas opciones y como naturalmente estamos interesados en los detalles más minuciosos cuando analizamos el malware, en el plano superior en realidad no importa. De hecho, esa es la esencia misma de los backdoors maliciosos: concederles a los atacantes el acceso remoto a un sistema infectado.
El segundo punto es aún más controversial. Como ya mencionamos antes, hay que tener mucho cuidado antes de acusar a un actor específico, sobre todo si es un estado nación. Actualmente no tenemos ninguna evidencia que indique quién está detrás de estos ataques, e intentar atribuirle la culpa a alguien por simple deducción basada en la situación política actual podría llevarnos a la respuesta correcta, o tal vez no. De una forma u otra, no deja de ser mera especulación. El descubrimiento actual sugiere que también habría que contemplar la posibilidad de que se trate de una operación de bandera falsa.
En resumen, el descubrimiento actual no nos ayuda a dilucidar el origen de los ataques en Ucrania. Por el contrario, nos recuerda que debemos evitar llegar a conclusiones precipitadas.
Seguimos monitoreando la situación para conocer su desarrollo futuro. Ante cualquier duda o para enviar muestras relacionadas con este tema, escríbenos a: threatintel@eset.com
Direcciones de IP:
193.239.152.131
SHA-1 del archivo XLS malicioso:
1DD4241835BD741F8D40BE63CA14E38BBDB0A816
SHA-1 de los archivos ejecutables:
920EB07BC8321EC6DE67D02236CF1C56A90FEA7D

miércoles, 20 de enero de 2016

Hospital que todavia usa windows XP infactado con malware

A pesar de que en abril de 2014 Microsoft puso fin al soporte para Windows XP, y de que tanto la compañía como expertos de seguridad han insistido en la necesidad de migrar hacia sistemas operativos más modernos, sigue habiendo organizaciones que utilizan esa vieja distribución. Tal es el caso del hospital Royal Melbourne de Australia, que fue víctima de un malware en sus sistemas.
Su último comunicado oficial dice: “Si bien el virus fue disruptivo para la organización, debido al trabajo incansable del personal hemos sido capaces de minimizar esta interrupción a nuestros pacientes y garantizar que su seguridad se ha mantenido”. Desde ayer, “muchos programas afectados por el virus están funcionando incluyendo patología y farmacia”.
Las computadoras de varios sistemas del hospital ya han sido desinfectadas, afirma, y el equipo de IT continúa trabajando para restaurar algunas otras tan pronto como sea posible. Todas ellasutilizan Windows XP, sistema operativo lanzado en 2001 que dejó de recibir actualizaciones y soporte de Microsoft el 8 de abril de 2014. A partir de ese momento, utilizarlo implica un grave riesgo de seguridad ya que los equipos quedan expuestos a potenciales vulnerabilidades 0-day que no serían corregidas.
Y en el caso puntual de las instituciones de salud, como lo es el hospital Royal Melbourne, hay mucha información sensible que debe ser reguardada con las medidas de seguridad adecuadas – entre las cuales está contar con sistemas y aplicaciones actualizados.
Tras la intrusión del virus, según informa Softpedia, algunos departamentos del hospital debieron hacer en forma manual procesos que ya se habían automatizado con las máquinas con Windows XP, como por ejemplo el procesamiento de sangre y tejidos, o la asignación de raciones de comida. El personal recibió el alerta de no acceder a ningún enlace o sitio web que parezca sospechoso ni ingresar credenciales en páginas a las que fueran redireccionados.
Ciertamente, lo ideal sería que no hubiera organizaciones con sistemas obsoletos, pero claro que la migración requiere de una inversión que no todas están dispuestas a afrontar. En casos en que no fuera posible la actualización a versiones como Windows 7, Windows 8.1 o Windows 10, es primordial contar con copias de respaldo de la información (backup) y una solución de seguridad que ayuden a mantener los niveles de seguridad más altos posibles en el entorno.

martes, 19 de enero de 2016

malware que mejora tu seguridad.

Alguien está comprometiendo miles de routers en varios países pero con el único objetivo de fortificarlos. De momento no se sabe exactamente quién está detrás, pero se trata de una pieza de malware que Symantec ha bautizado como "Linux.Wifatch". El software malicioso comprueba que la contraseña existente no es la de por defecto y, si la es, obliga a cambiarla. También elimina otros tipos de malware conocido y fuerza la actualización de software.



Paradójico, ¿verdad? Un malware que se encarga de mejorar la seguridad de los dispositivos de IoT para que no les afecten otro tipos de malware...
"No hemos visto ninguna actividad maliciosa en absoluto", dijo Val Saengphaibul de Symantec. "Sin embargo, en el sentido jurídico, se trata de una actividad ilegal. Están accediendo a dispositivos de red sin el permiso del propietario".
De momento ya ha infectado a más de 10.000 routers basados en Linux, la mayoría en China y Brasil. ¿Serán totalmente altruistas las intenciones de este Robin Hood de los hackers?
Fuentes:Is there an Internet-of-Things vigilante out there? New ‘Vigilante’ Malware Protects Routers Against Security Threats A vigilante hacker is forcing you to change your password A vigilante hacker is changing 10,000 WiFi passwords Linux.Wifatch ‘malware’ is actually making routers more secure

lunes, 18 de enero de 2016

Escalando privilegios cuando existe una mala configuracion.

En numerosas ocasiones, algunos de los programas que instalamos en el ordenador requieren un servicio que se ejecute en segundo plano, ya sea de forma contínua o una única ejecución al iniciar el sistema. Estos servicios acostumbran a utilizarse para tareas de actualización, sincronización y demás utilidades que requieran un chequeo periódico. La mayoría de estos servicios se ejecutan con el usuario de sistema local (system) y ejecutan un binario que se encarga de la tarea a realizar.

Ayer veíamos con la técnica de Hot Potato como podíamos aprovechar las conexiones que intentan hacer estos servicios para llamar a ejecutables con sus privilegios, redireccionando las peticiones HTTP a SMB.

Sin embargo, hay una forma mucho más sencilla que es sustituyendo el ejecutable del servicio por otro que, por ejemplo, nos cree un usuario administrador. Evidentemente esto es posible sólo debido a una mala configuración, porque para hacerlo necesitamos que estén mal asignados los permisos. Sin embargo, aunque parezca mentira, en muchísimos servidores me he encontrado servicios que usan ejecutables con acceso total para todos o para el grupo de usuarios (sobretodo con herramientas propias o desarrollos a medida).

El escenario es el siguiente:


-    Tenemos acceso a una maquina con un usuario local, sin permisos de administrador.



-  Detectamos un binario que es llamado por un servicio y que tiene permisos totales para el grupo Usuarios (para el PoC, hemos modificado los permisos del Updater.exe de Skype):



Una vez en este punto, debemos crear un pequeño exe que se encargará de crear una cuenta de administrador y lo sustituiremos por el original, para que al reiniciar el servicio o la máquina se ejecute nuestro código:



La segunda línea se encargará de añadir el nuevo usuario al grupo administradores.Evidentemente en la vida real tendremos que poner una contraseña que cumpla los requisitos normales de complejidad y un nombre de usuario no existente para evitar duplicidades.


Como podemos observar, no podemos ejecutar el .exe sin permisos de administrador, pero el servicio se encargará de ejecutarlo por nosotros.
Reiniciamos la maquina y comprobamos los usuarios:




Y ya podemos acceder con el nuevo usuario con permisos de administrador.

domingo, 17 de enero de 2016

Escalado de privilegios en Windows 7,8,10, Server 2008, Server 2012 mediante Hot Potato

Hot Potato de @breenmachine son varias técnicas para escalar privilegios en Güindous. Básicamente podríamos decir que primero redirecciona todo el tráfico HTTP a local para capturar las peticiones de los servicios de la máquina, luego las responde mediante solicitudes de peticiones de autenticación NTLM que reenvía a un servidor SMB local, que finalmente crea un servicio que ejecuta un comando (un cmd.exe por ejemplo) con los privilegios correspondientes.


Así dicho de golpe parece un embrollo, así que vamos a ver paso a paso cómo hacerlo...

En una red local cualquier aplicación puede utilizar Web Proxy Auto Discovery Protocol (en adelante WPAD) para encontrar proxies para poder salir a Internet. Esa información con sus reglas y demás está en un fichero javascript wpad.dat que está en un servidor WPAP accesible mediante la URL: http://wpad/wpad.dat. Esto lo implementó Netscape en 1996 y la verdad es que después de tantos años no ha cambiado demasiado.

En el primer paso del ataque debemos hacer que nuestra máquina no envíe las peticiones HTTP a un proxy real si no a nuestro propio equipo, y eso pasa por falsificar la URL para que apunte a localhost.

1. Falsificador local Netbios

Los clientes pueden recibir la ubicación de wpad.dat mediante DHCP (opción 252) o resolviendo el nombre del servidor WPAD y haciendo un HTTP GET a la URL. Como sabéis el orden normal de resolución de nombres es el fichero host, luego la resolución DNS y finalmente un broadcast UDP mediante NetBIOS Name Service (NBNS).

Un equipo Windows por defecto no tendrá entrada 'wpad' en el fichero host así que el siguiente paso será la consulta al servidor DNS. Normalmente no suele haber ningún registro A 'wpad' pero por si acaso se utiliza una técnica llamada 'agotamiento de puertos UDP' que consiste en usar todos los puertos UDP disponibles (esto en localhost se consigue bastante rápido) para que, a la hora de intentar realizar una consulta DNS, falle porque no hay puertos UDP origen disponibles.
A continuación la tercera vía será la consulta Netbios que tendremos que falsificar para que 'wpad' nos devuelva 127.0.0.1. En principio y sin privilegios no podremos esnifar el tráfico para hacer un MiTM, así que lo que haremos será inundar el host con respuestas NBNS (ya que es un protocolo UDP). Una complicación es que el paquete NBNS tiene un campo de 2 bytes, el IDTX, que no podemos ver y que debe coincidir en la solicitud y la respuesta. Sin embargo podemos iterar sobre todos los 65536 valores posibles al hacerlo rápidamente.


2. Servidor WPAD falso

Una vez que hemos conseguido que 'wpad' resuelva 127.0.0.1, debemos levantar un servidor HTTP en local que cuando reciba una petición a "http://wpad/wpad.dat" responda algo como:

FindProxyForURL(url,host){
if (dnsDomainIs(host, "localhost")) return "DIRECT";
return "PROXY 127.0.0.1:80";}


Esto hará que todo el tráfico HTTP sea redirigido a través de nuestro servidor se ejecuta en local/127.0.0.1.

Lo curioso que además afectará a todos los usuarios de la máquina, incluyendo administradores y cuentas del sistema.

3. HTTP -> SMB NTLM Relay

Anteriormente el protocolo NTLM era vulnerable a ataques MiTM. Por ejemplo un atacante capturaba los intentos de autenticación mediante el protocolo SMB y los podía reenviar contra la propia máquina de la víctima o a otro servidor para obtener acceso mediante psexec o similar. No obstante, Microsoft ya parcheó ésto desactivando la posibilidad de usar la misma autenticación NTLM con un challenge ya en uso, algo que sin embargo sigue funcionando desde otros protocolos como HTTP (HTTP->SMB) como ya vimos recientemente en el blog.

Como en los dos pasos anteriores hemos trabajado para redireccionar todo el tráfico HTTP a través de un servidor local que controlamos, podemos hacer cosas comoredirigirlos a algún sitio que solicite la autenticación NTLM.

Con el exploit de Potato, todas las peticiones HTTP se redirigen a una redirección 302 a "http://localhost/GETHASHESxxxxx", donde xxxxx es un identificador único. Las solicitudes de "http://localhost/GETHASHESxxxxx" responden con una petición 401 para autenticación NTLM.

A continuación, las credenciales NTLM son retransmitidas a un listener SMB local que crea un nuevo servicio de sistema que ejecuta un comando definido por el usuario.

Cuando la solicitud HTTP en cuestión se origina desde una cuenta de privilegios elevados, por ejemplo, cuando se trata de una solicitud del servicio de Windows Update, este comando se ejecutará con el privilegio "NT AUTHORITY\ SYSTEM"... bingo!

Usando el exploit

Su uso depende del sistema operativo.

También es un poco extraño a veces, debido a las peculiaridades en la forma en que Windows maneja la configuración del proxy y el archivo WPAD. A menudo, cuando el exploit no funciona, es necesario dejarlo correr y esperar. Cuando Windows ya tiene una entrada de caché para WPAD o está permitiendo el acceso directo a Internet, porque no se encontró WPAD, podría tomar 30-60 minutos para que se actualice el archivo WPAD. Es necesario dejar el exploit se ejecute y tratar de probar de nuevo más tarde, una vez transcurrido este tiempo.

Las técnicas que se enumeran aquí se ordenan de menor a mayor complejidad. Las técnicas del final de la lista deberían funcionar en todas las versiones anteriores. Se incluyen vídeos y capturas de pantalla para cada uno.


Windows 7 - ver https://youtu.be/Nd6f5P3LSNM

Windows 7 puede explotarse de forma fiable a través del mecanismo de actualización de Windows Defender.

Potato.exe tiene código para desencadenar automáticamente ésteBasta con ejecutarlosiguiente:

Potato.exe -ip -cmd [cmd to run] -disable_exhaust true

Esto hará funcionar al Spoofer NBNS, falsificando "WPAD" a 127.0.0.1, y a continuación,comprobará si hay actualizaciones de Windows Defender.

Si la red tiene una entrada DNS para "WPAD" puedes intentar "-disable_exhaust false".Esto debería hacer que la búsqueda de DNS falle e intente la resolución por NBNSEsto parece funcionar bastante bien en Windows 7.


Windows Server 2008 - Ver https://youtu.be/z_IGPWgL5SY

Como Windows Server no viene con Defender, necesitamos un método alternativo. En su lugar vamos a comprobar simplemente las actualizaciones de Windows. La otra advertencia es que en algunos dominios el servidor 2K8 pregunta por WPAD.DOMAIN.TLD en lugar de sólo WPAD. El siguiente es un ejemplo de uso:

Potato.exe -ip -cmd [cmd to run] -disable_exhaust true -disable_defender true -spoof_host WPAD.EMC.LOCAL

Después de se ejecute correctamente, basta con comprobar si hay actualizaciones de Windows. Si no se activa, espera unos 30 minutos con el exploit funcionando y vuelve a intentarlo. Si aún así no funciona, intenta descargar alguna actualización.

Si en la red hay una entrada DNS para "WPAD", de igual forma que antes puedes intentar usar "-disable_exhaust false". Sin embargo, el agotamiento DNS hace que TODAS las búsquedas fallen y el proceso de actualización de Windows podría tener que hacer algunas búsquedas de DNS antes de llegar a WPAD... por lo que tendría que hacerse en el momento oportuno para que funcione en este caso.


Windows 8/10/Server 2012 - Ver https://youtu.be/Kan58VeYpb8

En las últimas versiones de Windows, parece que la actualización de Windows ya no "respeta" la configuración de proxy fijada en "Opciones de Internet" ni detecta WPAD. En su lugar, las configuración del proxy para Windows Update se controla con “netsh winhttp proxy…”

Aunque también contamos con una característica nueva de Windows, el "actualizador automático de certificados no confiables". Los detalles se pueden encontrar enhttps://support.microsoft.com/en-us/kb/2677070 y https://technet.microsoft.com/en-us/library/dn265983.aspx

Desde el artículo de TechNet "Windows Server 2012 R2, Windows Server 2012, de Windows 8.1 y Windows 8 incluyen un mecanismo de actualización automática que descarga las listas de confianza de certificados (CTL) diariamente".

Parece que esta parte de Windows todavía utiliza WPAD, incluso cuando la configuración del proxy se controle mediante winhttp.

En este caso el uso de Potato es el siguiente:

Potato.exe -ip -cmd [cmd to run] -disable_exhaust true -disable_defender true

En este punto, tendremos que esperar hasta 24 horas o encontrar otra manera de accionar esta actualización.

Si la red tiene una entrada DNS para "WPAD", consulta la documentación en Server 2008. El agotamiento de puerto podría ser complicado... 


TODO: Firma SMB?

No está claro si este ataque va a funcionar cuando SMB signing esté habilitado. El exploit actual no lo hace, pero puede ser debido a la falta de soporte en la librería CIFS usada. La razón para sospechar que puede funcionar es que todo está sucediendo en 127.0.0.1. Si las firmas se basan en host, ¿podrían coincidir?

Un nuevo ataque de red

Pensemos de nuevo en el ataque de suplantación NBNS.

Utilizando la misma técnica de fuerza bruta TxID, técnicamente podríamos realizar ataques de suplantación NBNS fuera de nuestra red local. De hecho, en teoría, siempre y cuando haya una conexión lo suficientemente rápida como para soportarlo, debemos ser capaces de realizar ataques de suplantación NBNS contra cualquier hosts de Windows con el que podemos hablar a través del puerto UDP 137.

En realidad, aunque funciona en la práctica en la red local, todavía se tiene que probar más y verificarlo a través de Internet.

Estan lanzando una versión modificada de la herramienta "Responder.py" que lleva a cabo este ataque. El siguiente video muestra el ataque a una red distribuida de la siguiente manera:

     - firewall pfSense
     - 10.0.0.0/24 -> LAN corporativa
     - 10.0.1.0/ 24 -> Servidor de red
     - Desde la red de la empresa, vamos a atacar a una máquina en la red de servidores.

Demostraciónhttps://youtu.be/Mzn7ozkyG5g


Página de GitHubhttps://github.com/foxglovesec/Potato

Fuentehttp://foxglovesecurity.com/2016/01/16/hot-potato/