A la caza del mutante, parte IV

Parte I

Parte II

Parte III

Parte V

Hola a tod@s!

En esta penúltima parte, vamos a realizar la búsqueda de MUTANT (MUTEX), a través de la herramienta volatility, y realizando para ello un análisis forense offline.

Para poder realizar esta búsqueda con éxito, el gran Andreas Schuster implementa un módulo para volatility, a través del cual,  y resumido en pocas palabras, realiza una búsqueda de la cadena Mut? En memoria paginada y no paginada.

Imagen 1.- Búsqueda de cadena Mut?

 El resultado es increíble, extrayendo no sólo la dirección de memoria y el nombre del Mutant, si no también información interesantísima, como por ejemplo el identificador de proceso (Client ID) que lo tiene referenciado.

Imagen 2.- Aplicación del módulo MutantScan en Volatility

En la próxima y última entrega, analizaremos la memoria offline, e intentaremos buscar evidencias, partiendo de los mismos principios que el estudio de Andreas Schuster. Lo único que vamos a cambiar esta vez, será la herramienta. En vez de utilizar Volatility Framework, se utilizará la herramienta WinDBG (Debugging Tools for Windows), y realizando las consultas de forma manual.

Saludetes!!

Referencias

Searching for Mutants

_KMUTANT Structure

Poolfind (MDSN)

parseando el fichero consolidated.db

Hola a tod@s!

Como ya conoceréis, Iphone, al igual que otros smartphones, guarda información geográfica sobre los puntos en donde ha estado «el móvil». Entre toda esta información, también se guarda la información de los puntos de acceso WI-FI que se encuentra en «el camino», incluyendo su MAC.

Imagen 1.- Fichero Consolidated.db

En Seguridad Apple tienen un artículo bastante interesante sobre las aplicaciones existentes en Windows, las cuales extraen esta información y las pintan en Google Maps.

En el curso de Análisis Forense de dispositivos móviles que estamos impartiendo Juan Luis García Rambla y un servidor, y en donde nos estamos peleando con una serie de dispositivos, incluyendo el Iphone, estamos analizando esta información, junto con otras muchas más.

Uno de los puntos que tenemos que tocar, es la creación de herramientas simples que consigan extraer la información necesaria en alguno de los puntos de recogida de información.

Para ello, hemos preparado algunas demos con Python. Una de ellas, es la creación de dos scripts, los cuales extraerán y pintarán en Google Maps la información del fichero Consolidated.db de un Iphone 4.

El script lo único que hace es extraer los campos latitude y longitude de las tablas CellLocation y WifiLocation.

Imagen 2.- Campos WI-FI

Para ello, hemos utilizado un Wrapper llamado PyMaps, el cual pinta el mapa añadiendo las coordenadas extraídas previamente del fichero.

Los scripts no toman ningún parámetro como entrada, y únicamente tendremos que poner en un directorio creado previamente los siguientes ficheros:

• el Wrapper PyMaps
• Los scripts de extracción
• El fichero consolidated.db 😉

Para el script GetCoords.py, una vez lanzado, éste devolverá un fichero HTML. Una vez abierto el fichero, podremos ver algo parecido a esto:

Imagen 3.- Extracción de coordenadas

En el caso del script GetWifi.py, una vez lanzado, éste devolverá un fichero HTML. Una vez abierto el fichero, podremos ver algo parecido a esto:

Imagen 4.- Extracción de coordenadas Wi-Fi

El código de los scripts….

GetCoords.py

#Horrible Script para extraer las coordenadas del fichero Consolidated.db
#El fichero se encuentra en el directorio private/var/root/Library/Caches/locationd
#Horriblemente codeado por Silverhack
import sys, sqlite3
from PyMaps import Map, PyMap
# Creamos un mapa
NewMap = Map()
NewMap.zoom = 3
connection = sqlite3.connect("consolidated.db")
cursor=connection.cursor()
cursor.execute("SELECT Latitude,Longitude from CellLocation")
for row in cursor:
 print "La latitud es %s, y la longitud es %s" % (str(row[0]),str(row[1]))
 </p>
     # Latitud y longitud
     # Importamos de la BD consolidated a las variables
     # que posteriormente pasaremos al Script PyMaps

 latitud= str(row[0])
 longitud = str(row[1])

  # Insertamos codigo html
 pointhtml = "I see you..."

     # Anyadimos el punto al mapa
 point = (latitud, longitud, pointhtml)

 NewMap.setpoint(point)
 gmap = PyMap(key="clave", maplist=[NewMap])

 mapcode = gmap.pymapjs()
showhtml = gmap.showhtml()
print showhtml
file = open('Coordenadas.html', 'w')
file.writelines(showhtml)
# Cerramos el fichero
file.close()

GetWifi.py

#Horrible Script para extraer las coordenadas WIFI junto con su MAC del fichero Consolidated.db
#El fichero se encuentra en el directorio private/var/root/Library/Caches/locationd
#Horriblemente codeado por Silverhack
import sys, sqlite3
from PyMaps import Map, PyMap
# Creamos un mapa
NewMap = Map()
NewMap.zoom = 3
connection = sqlite3.connect("consolidated.db")
cursor=connection.cursor()
cursor.execute("SELECT MAC, Latitude, Longitude from WifiLocation")
for row in cursor:
 print "La MAC es %s, La latitud es %s, y la longitud es %s" % (str(row[0]),str(row[1]),str(row[2]))
 

     # Latitud y longitud
     # Importamos de la BD consolidated a las variables
     # que posteriormente pasaremos al Script PyMaps

 latitud= str(row[1])
 longitud = str(row[2])

  # Insertamos codigo html
 pointhtml = str(row[0])

     # Anyadimos el punto al mapa
 point = (latitud, longitud, pointhtml)

 NewMap.setpoint(point)
 gmap = PyMap(key="clave", maplist=[NewMap])

 mapcode = gmap.pymapjs()
showhtml = gmap.showhtml()
print showhtml
file = open('WiFi.html', 'w')
file.writelines(showhtml)
# Cerramos el fichero
file.close()

 Para la ejecución de los scripts, tan sólo tendremos que utilizar Python 2.6 y pysqlite.

Saludos!

Volatility Framework Installer

Hola a tod@s!!

Hace tiempo que salió al público el estupendo trabajo de muchos investigadores que dio como resultado la herramienta Volafility Framework.

Los que me conocéis, sabéis que yo llevo dando por saco con el tema de la memoria RAM desde hace bastante tiempo. Gracias a Dios, que conforme más tiempo pasa, más información sobre este tema hay.

Yo mismo he dado algún que otro Webcast en Microsoft sobre este mismo tema, he hablado en las FIST, y en algún que otro Asegur@IT.

El Framework está escrito en su totalidad en Python. En su día, para hacer funcionar la herramienta, tanto en Windows como en Linux o MAC, tan sólo hacía falta instalar Python y vualá! Ya teníamos el Framework en funcionamiento.

Hoy día la cosa ha cambiado bastante. Existen multitud de Plugins que hacen de la herramienta una tool muy poderosa para analizar por completo la memoria RAM, pudiendo ahorrar costes en tiempo en un análisis forense corporativo o por proyecto. E incluso por diversión!!

El problema para gente que está empezando en esto, es que a día de hoy existen tantos plugins y dependencias, que instalar la herramienta desde cero, y dotarla de una funcionalidad aceptable, puede conllevar una inversión de tiempo importante.

Esto lo pensó en su día Jamie Levy (aka Gleeda), colaboradora habitual en el desarrollo de Volatility Framework, y desarrolló, entre otros impresionantes plugins, uno con la posibilidad de descargar todos los plugins de un tirón. El script para la versión 1.4 de la herramienta, e instalación bajo Linux, lo tenéis disponible aquí.

Yo he realizado mi particular script (en batch! con dos cojones!! jaja) para la total instalación de Volatility Framework, junto con todas sus dependencias. Entre las «capacidades» del Script de instalación se encuentran los siguientes puntos:

• Descarga e instalación de Python, MinGW
• Descarga e instalación de YARA (Gracias Hispasec!!), PYGame, PIL (Python Image Library), Distorm3
• Descarga e instalación de Volatility Framework 1.3 (Versión estable)
• Descarga e instalación de Plugins válidos para la versión 1.3
• Compilación automática e instalación de diversos plugins
• Procesado de Logs de todo lo que se descarga
• Procesado de HASH (MD5 y SHA1) de todo lo que se descarga
• Inclusión de rutas en PATH para dotar de máxima funcionalidad
• Inclusión de shell de comandos con el botón derecho del ratón para facilitar el análisis (Open cmd Here)

Ahora mismo, el script es totalmente funcional para instalarlo en Windows XP/Vista/7, y, como hoy en el FTSAI nos vamos a «pelear» con la memoria y todos sus componentes, me ha parecido buena idea colgarlo por aquí.

En su día, hablando con Lympex de opensec.es, éste me pasó una versión que desarrolló para Linux, la cual todavía no he puesto en el proyecto, debido a que tiene que actualizarse. Me ha prometido que cuando la tenga funcional la colgará en el proyecto.

El proyecto está alojado en Google, y ahora sí…. No tienes excusa para seguir ampliando conocimientos en materia Forense, porque documentación hay, y facilidades también!!

http://code.google.com/p/volatility-installer/

Esta semana he empezado a realizar el mismo script en PowerShell, debido a que como batch tiene muchas restricciones, he tenido que «tirar» de herramientas de terceros, como 7zip, wget y HashMyFiles para hacerla totalmente funcional. El script es muy sencillo de utilizar y no requiere parámetros. Sólo doble clic, y a jugar….

Nota: Tanto Python, como las dependencias, junto con MinGW, se instalan de manera interactiva con el usuario. Las instalaciones son del entorno Next–>Next, menos MinGW, que necesitaremos marcar las opciones de MAKE, más el compilador. Este paso de «interacción» es necesario, ya que de manera desatendida no se compilan bien algunas bibliotecas en Python bajo Windows.

Doy por supuesto (y por invitado!) que colaboraciones y ayudas, serán muy, pero que muy bien recibidas…..

Update.- Chema, de opensec, ya me ha pasado el script de instalación y está subido al proyecto. Su script soporta la instalación de Volatility Framework en los sistemas Arch, Debian y FreeBSD!

Buen fin de semana a tod@s!!

SYSTEM, causa y efecto. I de IV



SYSTEM, causa y efecto II de IV

SYSTEM, causa y efecto III de IV

SYSTEM, causa y efecto IV de IV

Hola a todos!!

En esta serie de 4 capítulos, examinaremos las sutiles diferencias entre un usuario administrador y un usuario de sistema (SYSTEM). Estas diferencias, serán cruciales a la hora de decidir qué tipo de cuenta será necesaria para la explotación de un fallo en el sistema, o decidir si es o no imprescindible el uso de técnicas para ganar una posible elevación de privilegios. También nos ayudarán a conocer el porqué de ciertos comportamientos dispares entre cuentas aparentemente similares.
A nivel de sistema operativo, tanto la cuenta Administrador como la cuenta de sistema, son cuentas con los mismos privilegios. Esta equidad, sólo se manifiesta a nivel de ficheros. A nivel de directorios, la cuenta SYSTEM tendrá, obligatoriamente por diseño del sistema operativo, mayores privilegios que una cuenta de tipo Administrador.
La cuenta SYSTEM, es usada por el sistema operativo para la carga o precarga de elementos cruciales en el inicio del sistema operativo. Servicios y procesos que necesita Windows para el buen funcionamiento del sistema, y para el inicio del mismo. La cuenta, diseñada para ese propósito, es una cuenta interna, y por tal motivo, no podemos administrarla utilizando funciones básicas de administración, como por ejemplo las siguientes:

• Administración de usuarios
• Añadir o eliminar de grupos
• Derechos especiales de usuario

Para demostrar esto, se pueden utilizar dos ejemplos básicos. Uno es a nivel de ficheros, y otro por ejemplo, es a nivel de Registro.
En Windows XP, por defecto la cuenta SYSTEM tiene control total en todos los ficheros y directorios del sistema operativo, y no como la cuenta Administrador, que tiene control total en casi todos los elementos del sistema. Un ejemplo válido es la carpeta SYSTEM VOLUME INFORMATION, ubicada en la raíz del sistema instalado, y que tiene como objetivo el almacenamiento de las copias de seguridad o puntos de restauración. Si se intenta obtener acceso a este directorio a través de una cuenta con privilegios únicamente de administrador, obtendremos un bonito error, ya que a nivel NTFS, no tenemos privilegios.

 
Imagen 1.- Acceso denegado en SYSTEM VOLUME INFORMATION

Otro ejemplo válido lo tenemos a la hora de visualizar elementos del registro de Windows. La cuenta SYSTEM tiene, por diseño del propio sistema operativo, control total sobre ciertas claves de registro, imprescindibles para el buen funcionamiento del mismo. Algunos de estos ejemplos son la clave SAM, en donde se almacenan los datos de los usuarios existentes en el sistema, y la totalidad de los permisos en la clave SECURITY, ubicada en la clave HKLM (HKEY LOCAL MACHINE). En la siguiente imagen, se puede visualizar un ejemplo de este tipo.

Imagen 2.- Elementos de registro visibles a través de la cuenta SYSTEM

 
A partir de Windows Vista en adelante, en el apartado referente al control de ficheros y directorios, y siempre hablando a nivel NTFS, se añade una nueva entidad con control total en el sistema. Esta entidad, llamada TrustedInstaller, es la encargada de una nueva característica en Windows Server 2008 y Windows Vista/7, llamada Windows Resource Protection.

Imagen 3.- Lista de control de acceso discrecional en Windows 7

En el siguiente post, repasaremos el funcionamiento de ambas cuentas a nivel de sesiones de usuario, evaluando el funcionamiento de las mismas en base a los perfiles que éstas crean.
Saludos!!
Referencias
Funcionamiento de ICACLS
http://technet.microsoft.com/es-es/library/cc753525(WS.10).aspx
Mecanismos reemplazados en Windows Server 2008
http://msdn.microsoft.com/en-us/library/aa382540(v=vs.85).aspx
Cómo es usada la cuenta SYSTEM en Windows
http://support.microsoft.com/kb/120929/en-us

Solución Network Puzzle 4

Hola a tod@s!

Este es el primer solucionario que vamos a publicar sobre el reto número 4 de SANS, enmarcado bajo el título Network Forensics Puzzle Contest.

Antes de continuar con el solucionario, tanto Pedro como yo, queremos dar la enhorabuena a todos los participantes del mismo. Allá vamos!

Lo primero que haremos antes de analizar cualquier evidencia, será comprobar la autenticidad de la misma. Para ello, el reto nos adjunta como argumento una firma MD5 que corresponde con el fichero original de captura. Para verificar la evidencia, utilizaremos la herramienta md5sum, con el siguiente argumento:

md5sum evidence04.pcap

Esto nos devuelve como resultado lo siguiente:

804648497410b18d9a7cb1d4b2252ef7 *evidence04.pcap

El siguiente paso a seguir será examinar el archivo de captura con un analizador de protocolos. Para este reto usaremos una herramienta ampliamente conocida. Esta herramienta es Wireshark. Utilizaremos esta herramienta por su versatilidad y eficiencia, así como por su potencia bajo línea de comandos.

Al abrir el archivo de captura lo primero que vemos es lo siguiente:

Imagen 1.- Evidencia en Wireshark

Según el supuesto, nos relata que el SR X, al infiltrarse en la subnet propiedad de ANFRF, realiza un reconocimiento de la Red. Para ello, supuestamente realiza un escaneo de la Red, cometiendo un grave error al no ocultar sus pasos. Así que lo primero que haremos será extraer las direcciones IP, tanto de origen como destino, implicadas en el caso.

Wireshark permite realizar esta tarea bajo línea de comandos utilizando para ello su herramienta Tshark. Para ello, utilizaremos el siguiente comando:

Tshark -r evidence04.pcap -T fields -E separator=, -e ip.src -e ip.dst > \Users\Silverhack\IP.txt

De esta lista se extraen el conjunto de direcciones implicadas en el caso forense, las cuales son las siguientes:

Imagen 2.- Direcciones IP implicadas

Una vez extraída esta información, necesitamos conocer los equipos que han tenido contacto entre ellos. El problema que se presenta es la gran cantidad de paquetes transmitidos y enviados y al número de direcciones IP implicadas. Para solucionar este problema, elaboraremos una estadística de conversaciones por dirección IP, y mostraremos el resultado de forma gráfica y por pantalla. Gracias a ello, nos permitirá comprobar, a través de dos formatos, el contacto de estos equipos entre sí.

Para construir una fotografía de las conexiones, necesitaremos hacer uso de librerías gráficas y scripts que permitan la creación de ficheros que relacionen estos datos. Para ello, utilizaremos la colección de scripts llamados AfterGlow. Esta colección de scripts facilitará la tarea a la hora de generar la gráfica.

Una vez descargado el conjunto de Scripts, y haciendo uso del comando anterior (Tshark), podemos tunelizar los datos de salida hacia el script, generando un nuevo fichero de gráficos.

Tshark -r evidence04.pcap -T fields -E separator=, -e ip.src -e ip.dst | Perl afterglow.pl > IPGraph.dot

Una vez generado el nuevo fichero, podemos utilizar cualquier aplicación válida para representar este fichero en un archivo gráfico. En el caso que nos ocupa, hemos utilizado la aplicación neato, incluida en la suite Graphviz.

Neato -Tgif -o IPGraph.gif ./IPGraph.dot

El resultado de aplicar los comandos anteriores es la siguiente imagen:

Imagen 3.- Mapa de direcciones IP

Según este gráfico, podemos extraer que el único equipo que ha tenido comunicación con el resto de participantes de la red ha sido la dirección IP 10.42.42.253. Gracias a este gráfico, podemos determinar con exactitud la dirección IP que ha realizado el descubrimiento de equipos.

Otra forma de llegar a esta conclusión es elaborar estadísticas por pantalla. Tshark permite la inclusión de este tipo de características en sus consultas. Un comando válido para ello sería el siguiente:

Tshark -r evidence04.pcap -q -z conv,ip,ip.src==10.42.42.25

Este comando, elaborará una estadística de conversaciones aplicando un filtro por dirección IP. En este caso, sólo muestra las conversaciones de la dirección IP 10.42.42.25

Imagen 4.- Estadísticas Tshark

Tan sólo necesitaríamos elaborar una estadística por cada dirección IP, y comprobar resultados.

El próximo punto a cubrir, será averiguar el tipo de fabricante que se esconde detrás de cada dirección MAC. Gracias al identificador único que poseen estas direcciones, unido al control que se tienen sobre ellas, y mediante listas actualizadas, se puede averiguar con cierta facilidad el fabricante de las mismas. El propio Wireshark, contiene una lista actualizada de estos fabricantes, aunque esta lista también puede ser consultada en la Web de IEEE. http://standards.ieee.org/regauth/oui/oui.txt

Una vez consultadas estas listas, el resultado es el siguiente:

Imagen 5.- Relación IP & MAC

El siguiente punto a cubrir será relacionar cada dirección IP con un sistema operativo.

Llegados a este punto, y gracias a la cantidad de paquetes que se encuentran en la evidencia, podemos realizar un fingerprinting del sistema operativo. Este fingerprint se puede llevar a cabo gracias a que principalmente, cada sistema operativo implementa la pila tcp/ip de forma diferente. El tamaño de la ventana, así como la cantidad de nops incluidos en el paquete, son pistas para averiguar el tipo de implementación de la pila, y, por consiguiente, el tipo de sistema operativo. Existen numerosas herramientas capaces de realizar un fingerprint pasivo en base a un archivo de captura. Una de ellas es NetworkMiner, que, entre otras cosas, posee las firmas de P0f y satori para realizar un fingerprint de sistemas operativos.

Imagen 6.- Network Miner

Una vez analizado la evidencia con esta herramienta, ésta es capaz de devolver el siguiente resultado:

Imagen 7.- Relación IP & MAC & OS

Antes de intentar averiguar el tipo de escaneo que se ha realizado, nos detendremos en averiguar si el escaneo descubrió algún tipo de puerto abierto en alguna de las máquinas. Para realizar esta tarea, se pueden emplear varios métodos. En una comunicación orientada a conexión entre dos equipos, como es el caso de la comunicación vía TCP, la comunicación se establece bajo una negociación en tres pasos. El cliente enviará un paquete con el flag SYN activo a un servidor. Si el puerto estuviese abierto, el servidor respondería con un paquete y los flags SYN y ACK activos. Si el puerto estuviese cerrado, el servidor enviaría un paquete con el flag RST activo. Un método lógico de búsqueda de puertos abiertos, es averiguar qué equipos respondieron a una llamada con un paquete y los flags SYN y ACK activos. Gracias a que estos flags tienen un valor asignado, se pueden rastrear con Wireshark de una forma sencilla. Los valores que tienen estos flags son los siguientes:

Imagen 8.- Tabla de asignación Flags

En Wireshark y Tshark, en su versión línea de comandos, es muy fácil filtrar esta información. Un comando válido en Tshark para esta tarea sería el siguiente:

Tshark -r evidence04.pcap tcp.flags==18 -T fields -E separator=, -e ip.src -e tcp.srcport

Este comando nos devuelve que el equipo que tiene puertos abiertos es el mostrado en la siguiente tabla:

Imagen 9.- Relación puertos abiertos

Llega el punto, una vez analizados todos los datos anteriores, de intentar averiguar qué tipo de escaneo utilizó el atacante para realizar el descubrimiento de puertos. Como ya sabemos la dirección IP que propició el escaneo (10.42.42.253), podemos aplicar un filtro en Wireshark que muestre sólo lo referente a esta dirección IP.

Imagen 10.- Filtro dirección IP en Wireshark

Analizando el archivo de captura de forma visual, notamos que bajo esta dirección IP, hay numerosas conexiones con el flag SYN activo. Además se observa que se intentan conexiones a diferentes puertos con este mismo procedimiento. Este procedimiento es común en escaneos de tipo TCP SYN o de TCP Connect. A continuación mostramos un cuadro comparativo de tipos de escaneo con respecto a flags activos.

Imagen 11.- Relación Flags con tipos de scan

Para confirmar el tipo de escaneo y la herramienta utilizada, podemos utilizar algún sistema de detección de intrusos y visualizar el log posterior. Para este reto, utilizaremos snort, debido a que tiene muchas firmas relativas a escaneo de puertos. Para ello, el comando utilizado es el siguiente:

snort.exe -A full -v -r c:\evidence04.pcap -c c:\Snort\etc\snort.conf

Analizando el log de salida, podemos visualizar numerosas entradas con la siguiente información:

[**] [1:2009582:1] ET SCAN NMAP -sS window 1024 [**]

[Classification: Attempted Information Leak] [Priority: 2]

02/03-00:43:10.186883 10.42.42.253:36020 -> 10.42.42.25:3389

TCP TTL:44 TOS:0x0 ID:19276 IpLen:20 DgmLen:44

******S* Seq: 0x113F23CF Ack: 0x0 Win: 0x400 TcpLen: 24

TCP Options (1) => MSS: 1460

Según Snort, parece claro que la herramienta NMAP es la causante del escaneo, así como que el tipo de escaneo es SYN Scan (-sS).

Aunque este tipo de escaneo pueda ser interpretado como TCP SYN Scan, nos decantamos por TCP Connect Scan, debido principalmente a varias características que a continuación exponemos:

La primera es que examinando el TimeLine de los paquetes, nos encontramos con que la primera respuesta recibida es un paquete con los flags RST+ACK. Esto demuestra que se ha establecido con éxito un intercambio a 3 vías o Three Way HandShake. Un escaneo del tipo TCP SYN SCAN no llega nunca a completar la conexión, de ahí a que sus creadores marquen este escaneo como STEALTH (Oculto).

Otro punto a destacar, típico de este tipo de escaneos, es la cantidad de paquetes necesarios para el descubrimiento de un puerto, llegando a intentar conectar desde varios puertos origen.

Imagen 12.- Connect Scan

En la captura de datos, la fragmentación de paquetes no es visible, por lo que este tipo de opción, también incorporada en NMAP, parece ser que no fue establecida en el escaneo.

Otro punto interesante, es el referente al tiempo de escaneo. En esta captura, se han intentado varias conexiones a un mismo puerto de destino, pero desde diferentes puertos origen. Analizando la captura, hemos encontrado, al menos, dos intentos de conexiones a un mismo puerto de destino, desde diferentes puertos origen. Este comportamiento es común en varios casos. Cuando se intenta realizar un fingerprint del sistema operativo, y cuando se ajusta las condiciones de Timing en NMAP, al parámetro INSANE. Este parámetro, indica a NMAP que intente una conexión tan rápido como sea posible.

Esperamos que os guste este primer solucionario!

Saludetes!

Estafa a las 3. Nicolai Prochenko SE01X02

Son las 10 de la mañana, y en la antigua Yugoslavia hace un día frío y lluvioso. Nicolai Prochenko es un individuo que ha estado entrando y saliendo del trullo desde los 19 años. Se había educado en la llamada Universidad de la Vida, pero con un pésimo profesorado. Experto en timos a pequeña escala y en engaños personalizados. La mala educación y un pensamiento sobre el dinero siempre ha estado presente en su educación y en suvida. La llamada del dinero fácil. Un sueño que todos quisiésemos alcanzar. Ganar mucho dinero invirtiendo y trabajando lo menos posible. Fruto de ese sueño, y con la cantidad de 200 Kunas, fruto de su último timo (Una venta de entradas caducadas), se reunió con un personaje de los bajos fondos que tenía un negocio para Nicolai. Algo llamado «fraude bancario».

Nicolai y su socio, se reunieron en el café Estafinski para dar forma a la «visión». Nicolai estaba nervioso porque no conocía a su nuevo socio, pero había leído sobre él en algo llamado Internet…. Tras pedir dos Marraskinos, resolvieron presentarse…

Nicolai: Hola amigo, me he enterado de tus hazañas y me gustaría que me ayudases a conseguir mi sueño. Cómo te llamas?

Desconocido: Me llamo Albert Gonzalez y te puedo ayudar con tu sueño. Mínima inversón, máxima repercusión…

Nicolai: Me gusta esa frase. Qué necesito para ponerme a ello?

Albert: Por 150 Kunas, puedo pasarte un CD con un programa. Este programa lo hará todo por tí con sólo unos clics de ratón. Si le dedicas algo de tiempo, dominarás países….

Nicolai: Pero tengo un problema. No entiendo de ordenadores….

Albert: Pero sabes encenderlo no? Coger el ratón?

Nicolai: Sí, esas nociones las tengo….

Albert: Sabes realizar transferencias bancarias?

Nicolai: Tengo a una persona que podría ayudarme a conseguirlo….

Albert: Pues reunes todas las condiciones! Este es un timo bastante fácil. Sólo tienes que montar el programa que te adjunto en el CD, y él se encargará de realizar todas las acciones por ti. Lo único que tienes que hacer es construir una gran mentira, y enviarla por e-mail a todas las personas que puedas. Puedes coger notas mirando estos artículos . De seguro que te ayudarán en tu «visión»….

Nicolai: Albert, aquí tienes tus 150 Kunas.

Albert: Toma tu CD. Vas a ser un hombre rico….

Nicolai: Me voy corriendo al concesionario, que he visto un Mercedes descapotable que me encanta….

Las 13:00 Horas. Un rayo de luz acaricia el rostro de Nicolai. Se fue corriendo a casa ya que tenía trabajo por hacer. Tenía un ordenador que había robado de una tienda de PC’S mediante la técnica del sillanizaje. Es similar a la del coche, pero utilizando una silla. Llegó a casa, se encenció un cigarrillo, y conectó el equipo.

El manual de instrucciones del CD era muy claro, y hablaba de una forma que Nicolai podía entender. Las instrucciones eran claras. La conexión a Internet debía pasar por una serie de Proxys anónimos, y, para entornos de pruebas, realizar la conexión desde una señal que no fuese la propia. Nicolai no entendió esta última parte y conectó su equipo a una Red WIFI que ponía OPEN. Primer paso realizado…

Una vez realizado este paso, tenía que ejecutar algo que ponía SETUP.EXE. Una vez realizado este paso, el CD instaló varias cosas:

• Un servidor Apache
• Soporte para PHP
• MySQL
• PHPMyAdmin

Todo ello a un clic de ratón. El sueño estaba cada vez más cerca. Ahora llegaba la parte difícil. Instalar lo que le separa de su ansiado Mercedes y sus buenas vacaciones en las Bahamas. El gancho.

El gancho venía en una serie de ficheros con extensión PHP, y no era más que el panel de Administración de un BOT para administrar Malware a través de Internet. La ruta de instalación era clara. Tan sólo tenía que dirigirse al directorio .install y él se encargaría de realizar el resto…

Imagen 1.- Instalación Zeus BotNet

Una vez instalada la aplicación, ésta muestra el proceso de la misma, indicando si ha habido algún fallo en la instalación.

Imagen 2.- Instalación finalizada y completada

El siguiente punto del manual es claro. Ya tienes tu panel de control! Ya puedes soñar con ese Mercedes y con las Bahamas y con las Morenacas!! Entra a tu panel de control siguiendo la ruta indicada a continuación:

http://IP_DEL_MALO/Zeus/Web/in.php

Imagen 3.- Panel de administración Zeus

El panel de Administración estaba vacío, pero su sueño cobraba vida. Una vez realizado este paso, le tocaba configurar el paso siguiente. «La gran mentira».

La gran mentira consistía en un fichero de configuración que posteriormente se incluiría como base de conocimiento a un Malware específico. El fichero de configuración, y una vez averiguada la dirección IP pública de Nicolai, presentaba el siguiente aspecto:

Imagen 4.- Fichero de configuración Zbot

Una vez configurado el fichero, el manual indicaba que había una aplicación para «montar» la «gran mentira». La aplicación constaba de un ejecutable, un fichero binario que contenía el código maligno, y un fichero de texto que contenía información sobre bancos y redes sociales. Esta información la utilizará después el Malware para enviar los datos seleccionados (Usuario, Password y firma electrónica) a la base de datos de Nicolai.

Imagen 5.- Inyección Web Malware Offline

Una vez modificado estos archivos de configuración, el montaje se hace muy rápido, gracias a la utilidad de montaje incorporada en el CD de Nicolai.

Imagen 6.- Builder Zbot Malware

Perfecto…. La «gran mentira» estaba montada. Ahora sólo hacía falta leerse los artículos anteriores y mandar correos y SPAM a diestro y siniestro.

Pasados unos meses, Nicolai gozaba de gran popularidad en la Red, y su sueño cobraba vida propia. Era un gran «administrador» y la gente le pedía muchos favores a cambio de dinero. Con el tiempo se dio cuenta de que «la gran mentira» podía «tumbar» a grandes corporaciones, gracias a que con el panel de administración podía crear grupos de trabajo, los cuales podían realizar una tarea en concreto.

Imagn 7.- Panel de Administración Zeus 

La aplicación proporcionada en el CD, era capaz de decodificar los datos enviados por el Malware, y que guardaba celosamente tanto en su base de datos, como en un fichero binario a modo de Backup.

Imagen 8.- Decodificación de Logs con Zbot

Las capturas eran claras y decisivas en post de su sueño. Gracias a ellas tenía una gran base de datos con usuarios, passwords y firmas electrónicas. Todo ello junto a las Webs de acceso y direcciones IP y nombres de equipo de sus víctimas. Todo ello bien ordenado en sus correspondientes tablas.

Imagen 9.- Captura de Claves en archivo Log

Había pasado un año desde que el proyecto «la gran mentira» empezó. Así que, nuestro amigo Nicolai, habiéndose convertido en un gran Administrador de este tipo de redes, se puso manos a la obra con «el plan B».

El plan lo había planificado con un año de antelación, y era bastante simple. Se había dedicado a capturar durante un año completo usuarios y passwords de diferentes cuentas y sitios de Internet. Gracias a estas capturas, consiguió una base de datos bastante consistente de información. Un año después, Nicolai estaba preparado para dar el gran salto. Se había dedicado todo este tiempo a recopilar información en Internet sobre cada una de sus víctimas. Había cuentas de banco que se correspondían con las cuentas de correo, y éstas, a su vez, con redes sociales. Gracias a los conocimientos adquiridos, creó otra base de datos con ese conocimiento. Esta base de datos conectaba a cada usuario con su red social, correo electrónico, cuentas bancarias y mensajería instantánea. También le dió lugar a crear otra base de datos con los usuarios a los que no llegaba a conseguir gran cantidad de información. Esta base de datos la vendía al mejor postor, vendiendo también, cada cierto tiempo, actualizaciones sobre la misma. La «gran mentira» era todo un éxito.

Nicolai planificó cada detalle de sus actos para llevar a cabo «El plan B». Gracias al dinero obtenido de ventas anteriores, llegó a contratar varios servidores alojados en países de «moral informática relajada» (Te lo copio Chema ;-)). En cada uno de ellos, instaló una aplicación que había conseguido encargar a un programador amigo suyo. La aplicación tan sólo recibia un fichero de configuración con unos datos específicos, y ésta, a su vez, realizaba todo el trabajo.

Nicolai se había empeñado en realizar una gran compra por Internet, utilizando la base de datos que le había costado un año llenar. El plazo de acción era realizar el trabajo en 24 horas.

Así que una mañana, sobre las 13:35 horas, Nicolai estaba sentado en pijama sobre su equipo, con un cigarrillo en la comisura de los labios, y un vaso con Marraskinos en el otro. Configuró todos los servidores, actualizó todas las víctimas, y pulsó el botón START.

Fin del capítulo II

Saludetes!!

 

 

Estafa a las 3. Dónde está mi inversión? SE01X01

Son las 3 de la tarde y el departamento de HelpDesk de la empresa Skynet recibe una llamada. Es el experto en IT Henry DansMerkt.

Henry DansMerkt: Hola buenas tardes. Es el departamento HelpDesk?

Técnico: Si señor Henry. Ha marcado los números correctos y este es el departamento de HelpDesk. Enhorabuena. En qué podemos ayudarle?

Henry DansMerkt: Puessss… La verdad es que no sé si es realmente un problema. El caso es que no encuentro un dinero para una inversión de IT. Este dinero estaba en una cuenta corriente y ahora no está.

Técnico: Señor Henry. Este problema tiene que ver con algún equipo? Verá, es que necesito saber si es un problema del equipo, para poder abrir un ticket de resolución. Los temas bancarios no los lleva el departamento de HelpDesk, así que no sé muy bien cómo ayudarle.

Henry DansMerkt: Verá, es que los números de cuenta los poseo únicamente yo, el departamento contable y el CEO de la empresa. He comunicado con ellos y me comentan que ellos no han realizado ningún tipo de acción sobre la cuenta mencionada. Todo este tipo de inversiones las hacemos siempre Online y nunca ha habido ningún problema. Así que tanto el CEO de la compañía y el jefe del departamento contable me han remitido a ustedes, por si el problema fuese del equipo corporativo.

Técnico: Ok. Vamos a realizar algún tipo de comprobación rutinaria. A qué tipo de banca online se refiere? Puede acceder a la página correctamente?

Henry DansMerkt: Las cuentas personales que utilizamos para este tipo de inversiones están alojadas en dos bancos. Uno es el Banco de Santander y el otro es Banesto. Y sí, acabo de probar a ingresar los datos en las cuentas y puedo acceder correctamente.

Técnico: Puede mandar alguna captura de su acceso a las cuentas?

Henry DansMerkt: Claro que puedo. Se las estoy enviando a través del correo electrónico. Un momento

Pasan unos 4 minutos….. (Tensa espera telefónica)

Henry DansMerkt: Le han llegado ya?

Técnico: Sí que me han llegado. Las estoy revisando

Imagen 1.- Banca personal Henry

Imagen 2.- Banca personal Henry

Técnico: Un momento por favor, estamos revisando el equipo en busca de Malware y monitorizando las conexiones. Manténgase a la espera por favor.

Henry DansMerkt: Ok

Técnico: Señor Henry. Hemos monitorizado el equipo y no vemos ninguna señal de Malware. Aparte, monitorizamos todo tipo de salida y entrada de datos mediante sistemas perimetrales de seguridad, y llevamos un control exhaustivo tanto de las políticas locales como del control de acceso a los recursos y ficheros de la compañía.

Henry DansMerkt: Ok. Pues muchas gracias. Ya me quedo mucho más tranquilo. Aunque no encuentre el dinero. Preguntaré al departamento contable y al CEO otra vez, no vaya a ser que se hayan olvidado de algo.

Técnico: OK. Pues doy por cerrado el Ticket. Muchas gracias por su llamada señor Henry y que pase un buen día.

Henry DansMerkt: Gracias chaval. Me iré a casa temprano hoy para seguir trabajando desde allí. Adiós!

Técnico: Oiga? Oiga? Señor Henry? Se encuentra ahí?

Henry DansMerkt: Sí sí, me encuentro aquí. Necesita algo?

Técnico: Ehhmmm… Verá, es que tengo su portátil aquí, ya sabe, el que me mandó la semana pasada para instalarle el nuevo sistema operativo de Microsoft. Windows 7. Recuerda?

Henry DansMerkt: Sí, sí, lo sé. Está terminado?

Técnico: No, no está terminado. Estamos incluyéndolo en el dominio y aplicando las políticas de seguridad. Recuerde que NO se debe trabajar con portátiles que no estén configurados por el departamento de IT. Fue idea suya… La pregunta es… DESDE QUÉ PORTÁTIL ESTÁ TRABAJANDO?

Henry DansMerkt: Ahhh, jajaja! Desde el portátil de mi compañero de piso, el cual amablemente me lo ha dejado hasta que me déis el corporativo. Lo tengo aquí ahora mismo.

Técnico: Puede encender el portátil por favor, y mandarme capturas de pantalla del inicio de sesión en la banca online? Es mera curiosidad y un trámite sin importancia….

Henry DansMerkt: Claro que sí, aunque no veo qué problema pudiese haber. Te mando las capturas en unos minutos.

Pasan unos 5 minutos. (Tensísima espera telefónica)

Henry DansMerkt: Te han llegado ya las capturas?

Técnico: Sí, ehhmmm… Espere, las estoy visualizando….

Imagen 3.- Imagen Portátil «neocorporativo» del compañero de piso

Imagen 4.- Imagen Portátil «neocorporativo» del compañero de piso

Técnico: Un momento por favor… (Sonido de fondo=on) ·$%##@@!!. Manuel! Llama corriendo a Javi de comunicaciones y que empiece a monitorizar tráfico en la red corporativa. Tenemos un ticket de nivel I. Ah! Y por favor, llama a Juanito Walker y a Juan Luigi «El drogata», y dile que tenemos un caso para ellos. «Drogata???»…. Sí, es que el tio lo esnifa «todo»….(Sonido de fondo=off). Señor DansMerkt, mucho me temo que va a tener que dejar el portátil aquí. Lo necesitamos para cerrar la incidencia.

Henry DansMerkt: La incidencia no estaba cerrada?

Técnico: No, la hemos abierto de nuevo.

Henry DansMerkt: Y cómo trabajo yo ahora desde casa?

Técnico: Veremos si sigue trabajando mañana aquí…..

Henry DansMerkt: Cómo ha dicho?

Técnico: Nada nada…. He dicho que inmediatamente le mandamos un portátil corporativo y nos quedamos con el de su compañero de piso para analizarlo con más profundidad.

Henry DansMerkt: Pero me lo devolverán hoy no? Es que mi compañero lo necesita para el Facebook y el Twitter…

Técnico: Lo intentaremos señor Henry, lo intentaremos….

Fin capítulo I

Saludetes!! 😉

 

Analizando Tráfico de Red III de III

Para el análisis forense de tramas de Red, existen herramientas que son capaces de automatizar el proceso de extracción, siendo válidas para extraer «de una tirada» conjuntos de datos que viajan a través de un protocolo.

Una herramienta bastante potente para realizar este tipo de extracciones es Xplico. Esta herramienta, de momento sólo existe para sistemas operativos Linux. Hasta la fecha es la herramienta más interesante, ya que de momento, está realizando una muy buena labor de soporte para muchos protocolos. Para saber más sobre la misma, aconsejo leer el post de Sergio Hernando, que habla sobre ella.

Para Windows, la única herramienta que vale la pena, se llama NetWork Miner. Es una herramienta bastante interesante, ya que, además de la extracción de datos, es capaz de realizar tareas de fingerprinting sobre los paquetes de datos para averiguar, por ejemplo, el sistema operativo que envía o recibe paquetes. Su funcionamiento se basa en las bases de datos que utilizan diversas herramientas de auditoría, como por ejemplo, NMap. Un buen artículo sobre esta herramienta, lo tenemos en la Web SoyForense.

Lamentablemente, y utlizando esta herramienta con un fichero PCAP, en cuyo interior se encontraban datos relativos a conversaciones de Vídeo, audio y datos, transmitidos todos ellos a través de mensajería instantánea con Windows Live Messenger, ésta no ofrece ningún avance positivo.

Imagen 1.- Extracción de datos fallida con NetWork Miner

Después de la prueba fallida, lo siguiente es analizar «a pelo» cada paquete de la captura, para encontrar una huella, o pista que nos de esperanza para continuar.

Para ello, decido leerme, sin mucho éxito, parte del documento que tiene Microsoft sobre la implementación de RTP en Streaming de audio o vídeo.

Analizando la captura de datos, me encuentro con un paquete algo especial, con el formato siguiente:

Imagen 2.- RecipientID en Windows Live Messenger

Observando varios foros sobrre desarrollo de aplicaciones para mensajería instantánea, comprendo que este paquete es utilizado por Windows Live Messenger para establecer la conexión. Una vez que la conexión está establecida, envía regularmente un paquete de las mismas características para asegurarse de que la conexión sigue permanente.

Wireshark tiene, como añadido a la herramienta, opciones de traducción de paquetes. Esta capacidad, dota a la herramienta con un decodificador de paquetes. Con este tipo de opciones, podemos escoger un paquete, y decirle a Wireshark que lo decodifique según un protocolo establecido.

Nuevo intento, fallido, de decodificar todo protocolo UDP como si fuese RTP. Resultados cero.

Inspeccionando el tráfico UDP, me encuentro con que existen patrones que se repiten a la hora del envío de paquetes a través de Windows Live Messenger. En cada envío de paquetes, me encuentro con unos mismos valores para distintos paquete. Este tipo de patrón da a pensar que podemos estar ante algún tipo de Payload. Para ello, voy copiando en una tabla, todos los valores repetidos que me voy encontrando. La lista que obtengo es la siguiente:

• 44
• 48
• 66
• 4A

Buscando y rebuscando en internet, me encuentro con un post en un foro, el cual ya no existe, en el que se retrata este mismo payload. Pero lo más interesante es que un tipo, llamado Ramiro Polla (No es coña…), ya lleva tiempo con esta investigación y ha recreado un un paper y una herramienta que realiza toda esta labor.

Los payloads anteriormente descritos, se refieren a qué tipo de acción va a realizar Windows Live Messenger. Es decir, si va a realizar una conexión, enviar una trama de audio, enviar una trama de vídeo, etc…

Hablando de la herramienta, cabe decir que la mayor característica de la misma, es la capacidad de trabar «offline» con capturas de datos. Una vez que se carga la captura de datos en la herramienta, se procede a la extracción de paquetes de audio y vídeo.

Imagen 3.- Añadido de capturas offline

Una vez que la herramienta ha realizado su trabajo, se puede proceder a exportar los datos, pudiéndose utilizar compresores de audio y vídeo, para que la captura final sea más pequeña.

Image 4.- Captura final y posibilidad de extracción de datos

Como nota final, vía Sergio Hernando me entero de que también existe una herramienta similar en Linux, llamada MSN Shadow. Leyendo el Blog del autor de la herramienta, me entero de que si queremos versión para Windows, tendremos que esperar un poco, ya que, según sus palabras:

So, to support my additional work on this project like a version for Windows, capture of file transfers and others improvements, I would like to ask for some donation if you can.
I would not like to stop providing this software in open source format, but I can not work for nothing!

Hasta un nuevo post!!

Saludetes!

Analizando tráfico de Red II de III

Hola a tod@s! Seguimos con esta entrega dedicada al análisis forense de tramas de Red. En esta entrada nos vamos a centrar en protocolos que no están muy documentados.  La gran mayoría de analizadores de red ofrecen soporte a protocolos que están bien documentados y dan parte de soporte o ninguno a protocolos que no están documentados. Este tipo de problemas se pueden dar en algún tipo de investigación forense, y casi seguro que alguno de los lectores se habrá visto en algún caso parecido.  

En nuestro caso, vamos a centrarnos en un protocolo que no está muy documentado, pero que es ampliamente utilizado. Es el caso de la mensajería instatánea con Windows Live Messenger y derivados.

Los primeros atisbos de información que nos encontramos, los tenemos en la Web del Internet Engineering Task Force. En dicha Web, mantienen un borrador de un protocolo llamado Messenger Service . Leyendo este documento, tendremos una idea básica de cómo el protocolo de Windows Live Messenger trabaja a la hora de enviar y recibir información.

Más adelante (hablando de tiempo), Webs como Hypotetic.org o MSNPiki documentarían más este protocolo, realizando ingeniería inversa sobre el mismo.

Wireshark implementa un único filtro para filtrar la comunicación a través de Messenger llamado MSNMS. Gracias a este filtro, podremos trabajar sólo con este protocolo.

Al ser un protocolo que envía los mensajes en texto plano, es fácil extraer una conversación de Messenger aplicando como búsqueda la cadena «Text/Plain» en el filtro de búsqueda por paquetes que dispne Wireshark.

Imagen 1.- Extracción conversación Messenger con Wireshark

Herramientas comerciales como MSN-Sniffer, pueden capturar este tráfico y parsearlo directamente a una salida más «humana».

Lo malo de todo esto, es que no toda la información enviada a través de este cliente de mensajería se envía a través del protocolo MSNMS. El envío de mensajes de Voz, ficheros o vídeo se realiza a través de protocolos comunes como TCP o UDP. Y, en este caso, ni MSN-Sniffer ni ninguna otra herramienta (que yo conozca) es capaz de detectarlo y extraerlo.

En el caso del envío de ficheros a través de Messenger, y leyendo la valiosa información de la Web MSNPiki, nos encontramos con que primeramente se envía un número de identificador único (GUID), el cual se especifica para determinar que lo que se va a transmitir es un fichero. En el mismo paquete, se añade un identificador llamado APPID.

Imagen 2.- Envío de ficheros a través de Messenger

Si se observa con atención este paquete, en el contexto de este campo (AppID), aparecen una serie de caracteres codificados en Base64. Decodificando este texto nos daría el nombre del fichero que se está enviando.

Imagen 3.- Decodificando mensaje Base64

Una vez recibida esta información se empieza con el envío de datos. La transmisión de ficheros a través de Messenger es algo complicada, ya que se pueden enviar a través de TCP o UDP, y, en mi caso, no conozco ninguna herramienta que, a través de un archivo PCAP y en modo Offline, pueda reconstruir los ficheros enviados a través de este cliente de mensajería instantánea. Tanto el señor Maligno como Dani Kachakil tienen muy buenos artículos sobre cómo extraer ficheros enviados a través de Messenger. La idea básica es ir recopilando cada paquete (ya sea TCP o UDP), para después unir todas las tramas y formar el fichero extraído.

Imagen 4.- Follow TCP transmisión de paquetes en Messenger

Como esto se complica cuando se transmiten varios ficheros simultáneamente, nuestro compañero Rodol, de informática64, se curró una herramienta muy chula hace tiempo que realizaba esto mismo. Capturar todos los paquetes transmitidos a través de messenger, para después reconstruir los ficheros realizando un fingerprinting de los mismos.

Imagen 5.- Sniffer de Messenger con funciones de recomposición de ficheros

Esta herramienta, junto con muchas más, las damos en exclusiva a las personas que se apunten a los cursos FTSAI que impartimos en informática64.

Hasta la próxima entrega!

 

Analizando Tráfico de Red I de III

Hola a tod@s!

En esta tanda de 4 artículos nos vamos a entretener en conocer cómo podremos analizar nuestra Red en busca de patrones. El análisis del tráfico de red, junto con su contenido, es esencial para conocer qué uso se le ha dado a la red en un momento determinado.

Imagináos un servidor infectado mediante un exploit lanzado de forma remota. O conocer a ciencia cierta que están robando información confidencial de la empresa. Gracias a la reconstrucción del tráfico de red, es posible que se puedan dar respuesta a un buen número de cuestiones.

Mi amigo Pedro, de Conexión Inversa, tiene un estupendo artículo sobre redes trampa de baja y alta interacción que recomiendo que leáis. Por lo que comentaba en el artículo, parece ser que nos deleitará con más series de éstos, dedicados al análisis forense de la Red.

En mi caso, yo me centraré más en la reconstrucción de ciertos tipos de datos capturados por la red y en última instancia recomendaciones para la automatización en este tipo de tareas.

Para ello, y en mi laboratorio de pruebas, he procedido a capturar tráfico de dos puntos en una LAN y guardarlos en un archivo PCAP. Las siglas PCAP (Packet Capture) corresponden a una API desarrollada para capturar tráfico de una red. En el laboratorio de pruebas, utilizaré el port para Windows WinPcaP. Posteriormente utilizaremos la herramienta Wireshark para la extracción de posibles datos.

Comenzamos!

Algo que puede que nos interese, en lo referente al análisis de la red, es la reconstrucción de la navegación Web, guardado en un determinado fichero de captura PCAP.

Para intentar reconstruir ese tráfico, Wireshark implementa varios filtros con los que podemos jugar. En un principio puede que nos interese todo el tráfico, pero gracias a los filtros, podremos centrarnos en ciertas partes del tráfico que más nos interese.

Para captura Web, Wireshark implementa el filtro HTTP. Gracias a este filtro, podremos extraer prácticamente todos los objetos enviados y recibidos mediante este protocolo.

Imagen 1.- Aplicando filtro http en Wireshark

¿Y cómo podemos extraer datos una vez aplicado este filtro?. Wireshark implementa varias formas de realizarlo con el protocolo HTTP.

Una de ellas es la capacidad de poder exportar un conjunto de bytes, utilizando únicamente para ello el botón derecho del ratón.

Imagen 2.- Exportar Bytes Wireshark

Otra forma de realizar esta exportación de datos, es utilizando el filtro http.content_type, el cual nos mostrará sólo los paquetes que contengan algún tipo de dato y hayan viajado a través de ese protocolo.

Imagen 3.- Filtro http Wireshark

Como podéis observar en la imagen, el tipo de dato o recurso que viaja por HTTP no siempre es texto. De ahí que se deba analizar con cuidado, por si nos encontramos con el lanzamiento de un exploit, un ataque de denegación de servicio, aplicaciones, objetos comprimidos, etc…

Desde hace algún tiempo, Wireshark implementa una forma rápida de agrupar todos los objetos HTTP en una sola ventana, para que así nos resulte más fácil «ver» qué viaja por este protocolo. Para disfrutar de esta característica, debemos ir a File –> Export –> Objects –> HTTP

Imagen 4.- HTTP Objects List

Otro filtro importante que tenemos a nivel de HTTP, es el filtro HTTP.Date. Este filtro, nos situará exactamente en la cabecera de HTTP que contenga el campo fecha. Esta acción nos puede ser muy útil para realizar un timeline de peticiones y poder reconstruir una sesión de navegación, por ejemplo.

Imagen 5.- Filtro http.date

Visto lo visto. Wireshark puede reconstruir todo el tráfico de cualquier protocolo?. La respuesta es que NO. Wireshark permite capturar todo tipo de paquetes pero eso no quiere decir que pueda diseccionarlos todos. Existen protocolos que están docuentados o se basan en una RFC, y protocolos para los que no hay apenas documentación pública. Para este tipo de protocolos es en donde entra en juego la ingeniería inversa. En el siguiente artículo nos centraremos en reconstruir datos partiendo de protocolos que Wireshark no es capaz de entender.

Espero que esta primera aproximación al análisis forense de la Red os haya gustado. Hasta la próxima entrega!

Saludetes!

Referencias

http://en.wikipedia.org/wiki/Pcap

http://www.wireshark.org/docs/dfref/h/http.html

http://www.wireshark.org/docs/wsug_html_chunked/ChIOExportSection.html