Este documento no pretende ni tiene la finalidad de convertirse en manual de referencia. Este documento relata los aspectos básicos relacionados en el campo de la informática forense, explicando de una forma simple y concisa las herramientas utilizadas para la captura de evidencias. También explicará los aspectos técnicos relativos a la arquitectura de un sistema Windows. Probablemente esto ayudará al lector a comprender mejor cómo un sistema Windows recopila y almacena la información, ayudando también a entender la arquitectura del sistema.

Prohibida la reproducción total o parcial de este texto sin poner la fuente (http://www.elhacker.net)
Prohibida la modificación o eliminación de enlaces e imágenes en este documento.
Redactado por Silverhack el 07 de Marzo de 2007
Versión 0.1

 

General

Recogida de información (puertos, servicios, procesos)

Analizando una pantalla azul (BSOD)

Alternate Data Streams (ADS)

 

Entradas anteriores

Introducción a la informática forense en entornos Windows 1ª Parte

Introducción a la informática forense en entornos Windows 2ª Parte

 

Material relacionado a este documento

Comportamiento de Virus en plataformas Windows

 

Recogida de información (puertos, servicios, procesos)

La evidencia digital, por su naturaleza, es bastante frágil. Ésta puede ser alterada, dañada y/o destruida, principalmente por un mal manejo y/o recogida de estos datos. Por estas razones (intentamos hacer) tanto hincapié en la recogida y manejo de estos datos. La falta de este principio, puede ocasionar que estas evidencias sean inutilizables o no válidas en un proceso judicial, por no decir que podemos llegar a una conclusión inexacta. Debemos recopilar las evidencias que nos encontremos de tal forma que las protejamos y mantengamos su fiabilidad.
Una guía para este propósito, podemos encontrarla en esta URL del departamento de Justicia de EE.UU.

http://www.ncjrs.gov/txtfiles1/nij/187736.txt (Inglés)

En este capítulo nos centraremos más en la recogida práctica de información que en la teoría, para no hacer tan extenso el paper. En internet hay muchísima información sobre aspectos legales en este tipo de materia, y abundante información también en lo referente al correcto manejo y recogida de evidencias.

El primer paso que vamos a realizar será una captura de los datos físicos de la máquina, es decir, recoger diversos datos como:

  • Dueño de la máquina (Organización)
  • Tipo de BIOS
  • Uptime del sistema (Time to live)
  • Directorios del sistema
  • Número de tarjetas de red
  • Número de servipacks o updates del sistema
  • Ubicación del archivo de paginación
  • Tipo de procesador
  • Fabricante y modelo del sistema
  • Número de procesadores
  • Tamaño de la memoria RAM
  • Versión del sistema operativo
  • Etc…


Esto lo podemos hacer con varias herramientas, de las cuales vamos a describir dos.

SystemInfo (Nativa de Windows)

Aplicación nativa de Windows que nos muestra información acerca de la configuración del sistema y el tipo y versión del sistema operativo. También nos muestra información relevante a seguridad, propiedades del Hardware, memoria RAM, espacio total del disco e información sobre las tarjetas de red.
Su sintaxis es la siguiente:

Systeminfo [/s equipo [/u dominio\nombreUsuario [/p contraseña]]] [/fo {TABLE | LIST | CSV}] [/nh]

Podríamos redireccionar la salida del comando a un fichero de texto y fechado, para saber con exactitud cuándo se tomó la evidencia. El comando que podríamos poner sería el siguiente:

Systeminfo /FO list >SystemInfo.txt &date /t >>SystemInfo.txt &time /t >>SystemInfo.txt

PsInfo (SysInternals)

Esta herramienta es similar a la nativa de Windows, y podremos conseguir prácticamente los mismos resultados. Ambas herramientas permiten su uso tanto en local como en remoto. Su sintaxis es la siguiente:

psinfo [[\\computer [, computer [,..] | @file [-u user [-p psswd]]] [-h] [-s] [-d] [-c [-t delimiter]] [filter]

No necesita más explicación.

El segundo paso que vamos a realizar será recopilar información acerca de los servicios que hay corriendo en la máquina con sus estadísticas. En este punto voy a utilizar el comando nativo de Windows net y el comando SC.

Con el comando net statistics vamos a recabar información acerca de los bytes recibidos por el sistema, el número de inicios de sesión fallidos, las cuentas de uso fallidas, etc… Toda esta información la almacenaremos en un archivo de texto con fecha y hora incluida para su posterior análisis. El comando resultante podría ser el siguiente:

Net statistics Workstation >Estadisticas.txt &date /t >>Estadisticas.txt &time /t >>Estadisticas.txt

El comando SC me va a permitir conseguir una lista de los servicios que actualmente están corriendo en la máquina. Aunque SC posee muchos comandos para poder regular su salida, un comando resultante válido podría ser el siguiente:

SC query >ServiceOpen.txt &date /t >>ServiceOpen.txt &time /t >>ServiceOpen.txt

El tercer paso que vamos a realizar será la recopilación de supuestos procesos maliciosos, puertos de escucha, identificación de aplicaciones no autorizadas y la finalización de procesos legítimos.
Para saber cuantas conexiones tengo abiertas puedo utilizar el comando nativo de Windows netstat.
Utilizaré la opción –a para conocer todas las conexiones y puertos de escucha, y la juntaré con la opción
-b para conocer el ejecutable que crea la conexión necesaria para llegar al TCP/IP. El comando resultante fechado para su posterior análisis quedaría:

netstat –ab >Conexiones.txt &date /t >>Conexiones.txt &time /t Conexiones.txt

Para saber los procesos que tenemos actualmente corriendo en nuestro sistema utilizaremos la aplicación nativa de Windows tasklist, o en su defecto pslist (sysinternals). También utilizaremos la herramienta Fport. Ambas herramientas (tasklist, pslist) permiten realizar esta operación en local como en remoto. El comando resultante quedaría:

Tasklist >Procesos.txt &date /t >>Procesos.txt &time /t >>Procesos.txt

También vamos a recopilar información sobre los servicios que dependen de los procesos que están en funcionamiento. Tasklist también contempla esta situación. El comando sería:

Tasklist /SVC >ProcesosYServicios.txt &date /t >>ProcesosYServicios.txt &time /t >>ProcesosYServicios.txt

Muchas veces cuando en el sistema hay determinados rootkits, virus o troyanos, éste no nos muestra una salida “coherente”, de ahí a que siempre que podamos utilicemos aplicaciones que sean lo menos intrusivas en el sistema. Si somos un poco “paranoicos” en ese tema, para ver los puertos abiertos en un sistema podemos utilizar la herramienta fport. Por regla general, no nos debemos fiar de un sistema en el que haya corriendo este tipo de virus.
Básicamente fport nos muestra la misma salida que si ejecutásemos el comando nativo netstat con el filtro –a y –n.  También puede identificar puertos desconocidos que estén abiertos, con sus correspondientes procesos y PID.  La salida a este comando sería la siguiente:

C:\>fport
FPort v2.0 - TCP/IP Process to Port Mapper
Copyright 2000 by Foundstone, Inc.
http://www.foundstone.com

Pid Process Port Proto Path
392 svchost -> 135 TCP C:\WINNT\system32\svchost.exe
8 System -> 139 TCP
8 System -> 445 TCP
508 MSTask -> 1025 TCP C:\WINNT\system32\MSTask.exe
392 svchost -> 135 UDP C:\WINNT\system32\svchost.exe
8 System -> 137 UDP
8 System -> 138 UDP
8 System -> 445 UDP
224 lsass -> 500 UDP C:\WINNT\system32\lsass.exe
212 services -> 1026 UDP C:\WINNT\system32\services.exe


También podremos ver los procesos que corren en la máquina de forma gráfica con la herramienta de sysinternals ProcessExplorer.exe, la cual nos mucha más información pero de forma gráfica. Una captura de pantalla de la aplicación:

También podríamos recabar información sobre los módulos que cargan estos procesos. Podemos averiguar por ejemplo qué DLL están asociadas a un determinado proceso. Así tendremos un control más exhaustivo sobre los procesos. Para recabar esta información podemos utilizar la herramienta de sysinternals ListDLLS.exe.
Por ejemplo, si quisiésemos averiguar qué DLL dependen del proceso con PID 1548 utilizaríamos la siguiente sintaxis:

ListDLLS.exe 1548 >DLL1548.txt &date /t >>DLL1548.txt &time /t>>DLL1548.txt

El cuarto paso que vamos a realizar será una recopilación de los últimos accesos a ficheros, clasificados por fechas. Esta lista nos servirá de referencia a la hora de realizar el análisis, y podremos comprobar qué ficheros se modificaron en el día o los días en los que el sistema estuvo comprometido.
Podremos utilizar varias herramientas destinadas a tal fin, pero vamos utilizar sólo dos.
En una primera instancia podremos utilizar el comando nativo de Windows DIR, con algunas reglas para que nos muestre los ficheros modificados conforme a la fecha. Podríamos utilizar el siguiente comando:

DIR /t: a /a /s /o: d c:\ >Directory.txt &date /t >>Directory.txt &time /t >>Directory.txt

  • /t:a  Nos muestra el campo del último acceso (Fecha)
  • /a    Muestra todos los ficheros
  • /s    Muestra todos los archivos del directorio especificado, incluidos los subdirectorios
  • /o    Lista los archivos indicados
  • d     Muestra los más antiguos primero (Por fecha y hora)


Como siempre poniéndole la fecha al final para saber cuándo tomamos esa prueba.

En varias ocasiones esta lista puede ser larguísima y el fichero puede ocuparnos unos cuantos megas. La herramienta que vamos a describir a continuación puede ayudarnos a buscar archivos en fechas concretas. La herramienta en sí se llama MacMatch.exe. Ésta herramienta básicamente buscará ficheros modificados en un intervalo de tiempo, que lógicamente se lo daremos nosotros.
Una captura de imagen con la sintaxis:


 

Por ejemplo, si quisiésemos saber qué ficheros se “tocaron” o modificaron entre el 10 y el 12 de Noviembre, sobre las 15 horas, el comando a poner sería el siguiente:

Macmatch.exe c:\ -a 2006-11-10:15.00 2006-11-12:15.59

Recopilemos información sobre diversos aspectos de los usuarios. Trataremos de recabar la siguiente información:

  • Relación de usuarios creados en el sistema
  • Relación de las últimas sesiones (LogOn) fallidas en el sistema
  • Relación de las últimas sesiones establecidas remotamente en el sistema
  • Relación de las actividades de los usuarios remotos
  • Tiempo de logeo en el sistema
  • Histórico de los usuarios logeados localmente en el sistema


Para utilizar estas herramientas es necesario verificar que estén activados los controles de auditoria.
Para realizar estas operaciones vamos a utilizar tres aplicaciones. Una aplicación llamada netusers, otra llamada ntlast y una aplicación llamada psloggedon

Con  netusers podremos comprobar los usuarios que están conectados actualmente a una máquina remota o local. Su sintaxis es la siguiente:


 

Para ver los usuarios que actualmente están conectados a la máquina local tan solo tendríamos que poner el comando:

netusers >usuarios.txt &date /t >>usuarios.txt &time /t>>usuarios.txt

Si queremos que nos muestre un histórico de usuarios que se han logueado anteriormente, pondríamos:

netusers /history >UsersHistory.txt &date /t >>UsersHistory.txt &time /t >>UsersHistory.txt.

Otra aplicación que nos sirve para el mismo propósito es PsLoggedOn. Esta herramienta la podemos utilizar tanto en local como en remoto, y la salida que nos muestra por defecto es la siguiente:

  • Usuarios locales autentificados en el sistema
  • Usuarios logueados a través de recursos compartidos
  • Hora de inicio de sesión


En artículos anteriores, hemos podido comprobar cómo funciona el archivo de registro de Windows, y cómo podemos sacar información de ellos.
Para auditar los sucesos relativos a los inicios de sesión, el archivo de seguridad del visor de sucesos nos mostrará todos los sucesos auditados, como inicios de sesión fallidos, inicios de sesión correctos,  alguna operación con privilegios, etc…
Si tuviésemos que mirar uno a uno todos esos sucesos en un entorno de producción, prácticamente nos sería casi imposible de terminar, debido a la longitud del fichero. Aquí es donde actúa la herramienta NtLast.
Por medio de esta herramienta podremos averiguar de forma sencilla todos y cada uno de los sucesos del sistema.

En una primera instancia vamos a sacar un fichero con los últimos 100 inicios de sesión exitosos, incluidas las sesiones nulas en caso de que el sistema no tuviese parcheada esta opción. El comando resultante sería:

NtLast  -null –v –n 100 >>SuccessFulLogons.txt &date /t >>SuccessFulLogons.txt &time /t >>SuccessFulLogons.txt

Ahora vamos a sacar un listado con los últimos 100 inicios de sesión fallidos. El comando resultante sería:

NtLast –v –n 100 >>LogonsFailed.txt &date /t >>LogonsFailed.txt &time /t >>LogonsFailed.txt

Puede que también queramos sacar un listado con los últimos 100 inicios de sesión remotos. El comando resultante sería:

NtLast –v –n 100 –r >>RemoteLogin.txt &date /t >>RemoteLogin.txt &time /t >>RemoteLogin.txt

NtLast es una aplicación que puede dar mucho juego a la hora de sacar listados. Además de todo esto, que ya es mucho, podremos sacar todo esto pero referente a un solo usuario, por si tuviésemos alguna pista y tuviésemos que estrechar el cerco.
Por poner algún ejemplo, y si en la empresa X tuviésemos sospechas de que el  usuario Silverhack está cometiendo actividades impropias o no encomendadas, podríamos hacer lo siguiente:

NtLast –v –n 100 –r –u Silverhack >>RemoteLoginSilverhack.txt &date /t >>RemoteLoginSilverhack.txt &time /t >> RemoteLoginSilverhack.txt

Con este comando lo que obtenemos es una lista con los últimos 100 inicios de sesión remotos del usuario Silverhack.

Desde el propio visor de sucesos (eventvwr.exe) también podemos hacer esto mismo, aplicando un filtro al archivo. Por ejemplo, si quisiésemos mirar quién inició sesión de forma exitosa en los últimos 100 días, podríamos poner:

 

 

Analizando una pantalla azul (BSOD)

Cuando Windows encuentra una sentencia que pueda llegar a comprometer el sistema, éste se para. Esta sentencia se llama KeBugCheckEx. Esta llamada al sistema la podríamos llamar fallo de sistema, error de kernel, STOP, etc.. , y toma 5 argumentos:

Código de STOP

Cuatro parámetros que indican el código de STOP

Si hemos configurado nuestro sistema para que nos vuelque el contenido de la memoria, éste nos generará un archivo para su posterior análisis. Estos archivos se dividen en:

Small Memory Dump.- El más pequeño de todos y el más limitado (en cuanto a investigación). Solo ocupa 64 Kb y en este archivo irá incluida la siguiente información:

  • El mensaje de detención, parámetros y otros datos
    El contexto del procesador (PRCB) para el procesador que se colgó.
  • La información de proceso y contexto del kernel (EPROCESS) del proceso que se colgó.
  • La información de proceso y contexto del kernel (ETHREAD) del thread que se colgó.
  • La pila de llamadas del modo kernel para el subproceso que se colgó.  Si éste tiene un tamaño mayor que 16 Kb, sólo los primeros 16 Kb serán almacenados.
  • Una lista de controladores cargados
  • Una lista de módulos cargados y no cargados
  • Bloque de datos de depuración. Contiene información básica de depuración acerca del sistema.
  • Páginas adicionales de memoria. Windows también almacena estos datos para que así podamos obtener una mayor “versión” de lo que cascó. Esto nos ayudará a identificar mucho mejor el error ya que contienen las últimas páginas de datos a las que señalaban los registros cuando el sistema se colgó.



Kernel Memory Dump.- Escribe el contenido de la memoria excepto los procesos.

Complete Memory Dump.- Escribe todo el contenido de la memoria. [/li][/list]

En muchos casos, la información que viene contenida en un MiniDump, no es suficiente para analizar en profundidad un error. Hace años el espacio en disco podría ser un problema para almacenar este tipo de datos, pero hoy en día esto ya no es un problema. Si queremos analizar mejor el error, configurad vuestro sistema para generar o un volcado de memoria completo (Complete Memory Dump) o un volcado del Kernel (Kernel Memory Dump).

Para configurar el volcado de memoria iremos a Inicio à Ejecutar à sysdm.cpl y pulsaremos Enter.

Una vez dentro nos dirigiremos a la pestaña Configuración, y una vez dentro, en la parte de Inicio y Recuperación pulsaremos Configuración

 

Como podréis ver en la imagen, hemos configurado nuestro Windows de prueba, para que NO reinicie cuando muestre una pantalla de STOP, así podremos ver la pantalla azul en todo su esplendor, y aparte le decimos que cuando muestre una pantalla de error, nos vuelque el contenido completo de la memoria, para que podamos debugearlo, y así practicar!

Y para poder practicar, qué mejor que una maquina virtual no? Podemos instalar una máquina virtual desde 0, o descargarnos una de las muchas imágenes para Virtual PC que podemos encontrar en Microsoft. En cuestión yo utilizaré esta:

http://www.microsoft.com/downloads/details.aspx?FamilyId=21EABB90-958F-4B64-B5F1-73D0A413C8EF&displaylang=en

En este blog también hay puestas algunas imágenes en descarga directa con algunas plataformas servidoras, por si queréis descargarlas también. Y gratis!!

http://windowstips.wordpress.com/2007/01/18/practica-practica/

Bien. Ya tenemos nuestra máquina virtual funcionando. Hemos configurado nuestro sistema para que nos haga un volcado de memoria completo. Qué hacemos ahora? Esperar? Instalar drivers y aplicaciones hasta que pete por algún lado?

Como no queremos esperar a tener un BSOD para practicar, Mr. Mark Russinovich, autor de grandes herramientas, principal fundador de la Web Sysinternals y fichado por Microsoft, se ha codeado una herramienta muy chula para que podamos practicar. La herramienta en cuestión se llama NotMyFault.

 

Esta herramienta nos ayudará a crear los típicos escenarios que nos podemos encontrar en nuestro trabajo. Esta herramienta carga un driver llamado MyFault.sys, y este es el que va a implementar las diferentes BSOD que nos podemos encontrar.

La herramienta en cuestión la podéis descargar de la siguiente dirección:

http://download.sysinternals.com/Files/Notmyfault.zip

También necesitaremos un debuggeador, para poder analizar los volcados de memoria. Utilizaremos el debugeador de Microsoft WinDbg, el cual lo podemos descargar de:

http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

José Manuel Tella Llop, MVP de Windows, escribió un artículo en su día sobre cómo debíamos comportarnos ante una pantalla azul. El artículo original lo podéis encontrar aquí y nos servirá de guía en todo momento:

http://multingles.net/docs/jmt/bsod.html

En el artículo de Tella viene cómo instalar tanto las herramientas de debugeo como los símbolos necesarios para poder analizar un volcado de memoria, así como un casque real, a modo de ejemplo, en el que nos muestra la sencillez con la que se saca un error. A partir de aquí asumiremos que tienes instalado WinDbg y tienes configurado correctamente el path de símbolos.

Manos a la obra! Abrimos nuestra máquina virtual, iniciamos nuestro Windows, ejecutamos NotMyFault.exe y pulsaremos la primera opción que viene en el Interface. High IRQL fault (kernel mode). Acto seguido pulsamos en Do Bug.

 

Upppssss. Pantallaco azul al canto. Formateamos el equipo? Reiniciamos? Reinstalamos el sistema operativo? Por qué Windows es tan malo con nosotros?? J

Detengámonos un momento a analizar el BSOD.

Primera pista: DRIVER_IRQL_NOT_LESS_OR_EQUAL

Explicación: Un driver en modo kernel ha intentado acceder a memoria paginable desde un proceso o aplicación

Causa: Un driver que ha intentado acceder a memoria paginable mientras había una interrupción, o incluso intentó acceder a memoria inválida o no presente.

Efecto: Casque real del sistema. Estamos jodidos…

Como podemos ver en el pantallazo azul, éste nos muestra varias cosas que tenemos que tener en cuenta en un primer momento:

  • Nos muestra el BugCheck o mensaje de STOP.
  • Nos muestra el posible causante del fallo (MyFault.sys)



Pero como no estamos seguros, vamos a analizar el error debugeando un poquito.

Una vez que el volcado de memoria haya finalizado, reiniciaremos la máquina y en nuestro directorio Windows, tendremos un archivo llamado MEMORY.DUMP, el cual contiene toda la memoria, ejecutables, threads, etc..

En WinDbg, pulsaremos en File-->Open Crash Dump (Acordaos del path de los símbolos explicados perfectamente en el artículo de JM Tella)


 

Esto es lo que nos sale en primera instancia:

Use !analyze -v to get detailed debugging information. BugCheck D1, {e1071800, 1c, 0, f7cda403} *** ERROR: Module load completed but symbols could not be loaded for myfault.sys*** WARNING: Unable to verify checksum for NotMyfault.exe*** ERROR: Module load completed but symbols could not be loaded for NotMyfault.exe Probably caused by : memory_corruption Followup: memory_corruption

El debugeador nos dice que casi con toda seguridad es una corrupción de memoria. El código del BugCheck es D1 (DRIVER_IRQL_…..)

Microsoft tiene registrado más de 150 posibles códigos de error. Todos ellos podemos encontrarlo en la ayuda de la misma aplicación. Más concretamente en:Debuggin tools for Windows-->Debuggin Techniques-->Blue Screen-->Bug Check Code Reference

También nos pone que si queremos un análisis más exhaustivo podemos escribir el comando !analyze –v. Así que escribimos en kd> el mencionado comando, con lo que obtendremos una respuesta parecida a esta:

 

Vaya. Nos da el código exacto de la pantalla azul, el bugcheck reference (D1), los 4 argumentos restantes de la pantalla azul y nos dice que el proceso que cascó es el proceso NotMyfault.exe. Ya tenemos a nuestro culpable, pero no nos dice nada del driver (MyFault.sys) que provoca el casque real.

Cuando el debugeador no nos dice realmente quién es el culpable, y queremos averiguar más sobre dicho casque, podemos hacer varias cosas:

Ejecutar el comando !Thread

Con el comando !Thread conseguimos que nos muestre qué llamadas hizo el subproceso en el sistema.

Llamando al comando !Thread, el debugeador nos muestra las siguientes líneas:

kd> !threadTHREAD 842f6600 Cid 049c.04ac Teb: 7ffdf000 Win32Thread: e1a99168 RUNNING on processor 0 IRP List: 8428cc98: (0006,0094) Flags: 00000000 Mdl: 00000000 WARNING: Stack unwind information not available. Following frames may be wrong.f3eb4c58 80579a8a 841d8f18 8428cc98 842b6ad0 myfault+0×403

El proceso NotMyFault.exe hace una serie de llamadas, hasta que una pone en peligro la estabilidad del sistema. En nuestro caso es:

f3eb4c58 80579a8a 841d8f18 8428cc98 842b6ad0 myfault+0×403

Una vez que realiza la llamada, el sistema nos avisa de que la pila posiblemente esté corrompida y que los frames pueden estar corruptos.

WARNING: Stack unwind information not available. Following frames may be wrong.También nos muestra la IRP (The I/O request packet) que solicitó. IRP List:    8428cc98: (0006,0094) Flags: 00000000  Mdl: 00000000

Con lo que tendríamos que llamar a esa IRP para que nos muestre el contenido de esa IRP.

kd> !irp 8428cc98 Irp is active with 1 stacks 1 is current (= 0×8428cd08) No Mdl: No System Buffer: Thread 842f6600: Irp stack trace. cmd flg cl Device File Completion-Context>[ e, 0] 5 0 841d8f18 842b6ad0 00000000-00000000 \Driver\MYFAULT Args: 00000000 00000000 83360018 00000000

Ya tenemos a nuestro culpable. El driver MYFAULT.SYS.

También podremos ver los procesos que actualmente corrían en esa máquina antes del casque, con el comando !process 0 0. La salida es parecida a esta:

kd> !process 0 0**** NT ACTIVE PROCESS DUMP ****PROCESS 843cab98 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000 DirBase: 00039000 ObjectTable: e1000d68 HandleCount: 232. Image: System PROCESS 841d8550 SessionId: none Cid: 0134 Peb: 7ffdf000 ParentCid: 0004 DirBase: 091af000 ObjectTable: e1007790 HandleCount: 21. Image: smss.exe

Pero qué pasa cuando el pantallazo no nos muestra información relevante? Ni muestra driver que cause el error, ni aplicación, ni tipo de error… Nada. Qué hacemos en este caso? Pues lo mismo. J Con una serie de comandos en el debugeador podremos sacar toda la información que necesitemos para un análisis post-mortem.

En este caso vamos a utilizar de nuevo la aplicación NotMyFault. En este caso vamos a marcar el apartado Stack Trash y pulsamos en Do Bug, con lo que nos debería de salir el siguiente BSOD.



 

Sabemos por la misma ayuda que nos brinda el debuggeador, que el código de STOP (0X0000008E) se corresponde al error KERNEL_MODE_EXCEPTION_NOT_HANDLED, y que la primera dirección que nos muestra el error (0XC0000005), se corresponde a STATUS_ACCESS_VIOLATION. La misma ayuda nos dice que ha habido una violación en el acceso a memoria. Y todo esto con sólo mirar la ayuda!

Cargando el CrashDump en el debugeador, vemos que este no nos muestra nada a simple vista:

BugCheck 8E, {c0000005, 0, f3c61b8c, 0} *** WARNING: Unable to verify checksum for NotMyfault.exe*** ERROR: Module load completed but symbols could not be loaded for NotMyfault.exeProbably caused by : memory_corruption Followup: memory_corruption

Nos dice que es un error de tipo 8E y que la causa probable es una corrupción de memoria. Toca analizar con el comando !analyze –v

Analizando con este comando, vemos que la salida ya nos va mostrando otras cositas interesantes:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - La instrucci n en “0x%08lx” hace referencia a la memoria en “0x%08lx”. La memoria no se puede “%s”. FAULTING_IP: +0 00000000 ?? ??? TRAP_FRAME: f3c61b8c — (.trap fffffffff3c61b8c) ErrCode = 00000000 eax=00000120 ebx=841c53c8 ecx=83360010 edx=83360010 esi=841c53c8 edi=00000000 eip=00000000 esp=f3c61c00 ebp=f3c61c58 iopl=0 nv up ei ng nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286 0008:00000000 ?? ???Resetting default scope DEFAULT_BUCKET_ID: CODE_CORRUPTION BUGCHECK_STR: 0×8E PROCESS_NAME: NotMyfault.exe

Nos dice que la causa del cuelgue se podría dar por haber utilizado la aplicación NotMyFault.exe. Pero nuevamente tampoco nos dice nada del driver. Podemos utilizar el comando !thread, para que nos muestre el subproceso que logró colgar a nuestro sistema. Llamando a este comando conseguimos más información, como por ejemplo las llamadas que realizó la aplicación al sistema, así como también nos muestra la IRP:

THREAD 842f3610 Cid 0118.0328 Teb: 7ffde000 Win32Thread: e1b11968 RUNNING on processor 0IRP List: 841c53b0: (0006,0094) Flags: 00000000 Mdl: 00000000Not impersonatingDeviceMap e183ac28Owning Process 842f2608 Image: NotMyfault.exeWait Start TickCount 12895 Ticks: 0Context Switch Count 557 LargeStack UserTime 00:00:00.0050 KernelTime 00:00:00.0140 Win32 Start Address NotMyfault (0×00401ccb)

Llamando al comando !irp <IRP>, este nos muestra el driver que nos faltaba por descubrir:

kd> !irp 841c53b0Irp is active with 1 stacks 1 is current (= 0×841c5420) No Mdl: No System Buffer: Thread 842f3610: Irp stack trace. cmd flg cl Device File Completion-Context>[ e, 0] 5 0 842f76a8 84153028 00000000-00000000 *** ERROR: Module load completed but symbols could not be loaded for myfault.sys \Driver\MYFAULT Args: 00000000 00000000 83360010 00000000kd> !irp 841c53b0Irp is active with 1 stacks 1 is current (= 0×841c5420) No Mdl: No System Buffer: Thread 842f3610: Irp stack trace. cmd flg cl Device File Completion-Context >[ e, 0] 5 0 842f76a8 84153028 00000000-00000000 \Driver\MYFAULT Args: 00000000 00000000 83360010 00000000

Nuevamente tenemos a nuestro culpable!!

Otros comandos que podemos utilizar:

!cpuinfo.- Muestra información acerca del procesador instalado.

kd> !cpuinfo CP F/M/S Manufacturer MHz PRCB Signature MSR 8B Signature Features TargetInfo::ReadMsr is not available in the current debug session 0 15,2,4 GenuineIntel 1195 0000000d00000000 80073fff Cached Update Signature 0000002000000000 Initial Update Signature 0000000d00000000

!peb.- Válido para comprobar por ejemplo el nombre de equipo, path de instalación, número de procesadores, ruta de instalación, etc…

!token.- Muestra información sobre los objetos de seguridad

.cls.- Igual que la shell de Windows. Limpia la pantalla

Se puede analizar desde el entorno de comandos (cmd.exe)??

El debuggeador de Windows viene con una herramienta llamada kd.exe, la cual la podemos invocar desde la shell de Windows. Los comandos son prácticamente los mismos, al igual que la información que nos es mostrada por la shell. La forma de invocar un crashdump desde la shell de Windows es la siguiente:

kd.exe -z “Ruta donde está el volcado de memoria en formato DMP” -y “Ruta donde se encuentran los ficheros de símbolos” -i “Ruta de búsqueda de símbolos”

Tienes las herramientas para poder hacerlo, y ya sabes cómo enfocar un problema de estas características. Lo único que te queda es practicar!

 

Alternate Data Streams (ADS). Qué es y como funciona

Hablando desde el punto de vista NTFS, un fichero no es más que un conjunto de data streams. Un stream por ejemplo, puede contener información acerca del nivel de acceso a ese fichero (directivas ACL, permisos, etc..), otro stream contendrá los datos del fichero en sí almacenados en el contenedor. Si el fichero es un acceso directo o link, un stream puede contener la dirección en donde se ubica el fichero original, etc, etc..
Si por ejemplo leyésemos un fichero en un sistema de archivos que no fuese NTFS, ej: FAT16 o FAT32, el sistema leería tan sólo el stream que contiene los datos del fichero.
La estructura de un fichero con múltipes streams es parecida a esta:

Aunque muchos piensen que es una falla o Bug del sistema, lo cierto es que ADS no es más que un feature (característica) del sistema, y generalmente se usa para mantener información asociada a un fichero.
Microsoft tiene amplia documentación sobre ADS, en el que se incluye tutoriales, scripts para creación de ADS, etc..

Limitaciones de un ADS

Por defecto cualquier usuario del sistema puede usar esta característica. Tan sólo se limita a aquellos ficheros en los que tengamos permiso de escritura. Es decir, un Administrador, podrá añadir un ADS en prácticamente todos los ficheros del sistema, mientras que un usuario se limitará sólo a los ficheros y directorios en donde tenga acceso de escritura (Por defecto su perfil).
Por defecto ADS sólo está limitado a volúmenes NTFS como hemos visto. A través de red local (LAN) podremos mandar ficheros con ADS, siempre y cuando los volúmenes intermedios tengan el sistema de archivos NTFS.
La limitación teórica es mandar un ADS a través de Internet. Teóricamente no podemos mandar un fichero con ADS (sea malicioso o no), ya que nuestro cliente de correo, el medio (Internet) y el destinatario, sólo mandaría el stream con los datos, sin procesar los demás. A lo largo de este documento podremos ver que en la práctica y bajo una serie de factores, se podría mandar ADS ocultos en un fichero.

No vamos a hablar sobre creación, modificación y eliminación  de ADS, porque es una característica ampliamente documentada en la red. Al final de este documento se proporcionarán enlaces a investigaciones pasadas sobre éste tema en concreto.

Microsoft no tiene de forma directa ninguna aplicación para el escaneo ADS. De forma indirecta tenemos dos opciones:

A través del administrador de tareas (taskmgr.exe)

Como se puede comprobar en la imagen adjunta, el Administrador de tareas de XP muestra el proceso ejecutado.
Nota: En versiones anteriores a XP (NT,2K), este proceso de visualización no es del todo transparente. NT y 2K tratan de forma diferente el manejo de los ADS.

A través de la librería StrmExt.dll

Esta librería, añade un nuevo Tab a las propiedades del Explorer, que nos permitirá ver los posibles Streams que pueda tener un archivo, directorio o unidad.
Para añadir un Tab a las propiedades de Explorer descargamos de Microsoft el siguiente código fuente:

NtfSext.exe

Dentro nos encontramos con algunos ejemplos de creación de Streams. El fichero que nos interesará es la librería compilada StrmExt.dll (Se adjunta código fuente de la librería).

La extraemos y la depositaremos en el directorio System32 de nuestro sistema. Acto seguido la registramos en el registro con el siguiente comando:

Regsvr32.exe StrmExt.dll

Una vez ejecutado el comando Windows registrará la librería, y podremos disponer en las propiedades del Explorer de un nuevo Tab para visualizar si un fichero tiene alojado algún Stream.

Registrando esta librería, conseguimos visualizar el Tab Streams sólo para ficheros. Si queremos que nos muestre el Tab Streams para analizar los streams de alguna unidad (ej. C:) o por ejemplo de algún directorio, tendremos que incluir un par de entradas en el registro.

--------------------No copies esta línea---------------------------
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\shellex\PropertySheetHandlers\{C3ED1679-814B-4DA9-AB00-1CAC71F5E337}]

[HKEY_CLASSES_ROOT\Drive\shellex\PropertySheetHandlers\{C3ED1679-814B-4DA9-AB00-1CAC71F5E337}]

-------------------No copies esta línea----------------------------

Guarda este fichero como AddTabStream.reg. Clickea dos veces en el archivo que has creado y añadirá las entradas al registro necesarias para añadir el Tab en el explorer.

Para un directorio:

Para una unidad:

Escaneo de ADS

Frank Heyne ha desarrollado una herramienta que escanea documentos en busca de ADS. La herramienta en cuestión es LADS.
Su funcionamiento es muy sencillo:

IMAGEN

Si quisiésemos escanear nuestra unidad C: (incluyendo subdirectorios) en busca y captura de ADS, ejecutaríamos un comando tal que:

Lads C:\ /S

Cómo un usuario malicioso podría mandarnos un fichero con ADS? Ejemplo práctico

Hemos explicado antes, que si creamos un archivo con más de un stream de datos (sea malicioso o no), éste sólo será soportado por un sistema que utilice el sistema de archivos NTFS, lo que lo limita sólo a ese campo. No podríamos guardarlo en un pendrive, mandarlo por mail, colgarlo en una Web para su descarga, etc...

El ejemplo que os pongo a continuación, de libre descarga, es una prueba de concepto que demuestra que efectivamente se pueden mandar ficheros que contengan ADS, aprovechando un feature (característica) de una herramienta ampliamente utilizada por usuarios y empresas corporativas. La utilidad de copia de seguridad de Windows (ntbackup).
Esta herramienta sí incluye tanto el fichero como sus streams, lo que la convierte en una gran herramienta para usuarios con perfiles muy distintos:

  • Una gran herramienta de copia de seguridad
  • Una potencial herramienta para usuarios maliciosos

En el ejemplo (empaquetado en zip) se incluyen estos archivos:

  • Un fichero de texto que contiene un stream con código VB inofensivo
  • Un archivo Bat para ejecutarlo
  • Todo ello va empaquetado en un archivo .bkf (Copia de seguridad)


Sólo tenéis que descargar la copia de seguridad, desempaquetarla en algún directorio y ejecutad el archivo setup.bat.
Es un archivo inofensivo, a modo de broma, que prueba la capacidad de esta técnica, utilizada hoy en día por muchos virus y troyanos.

Un ejemplo de este tipo de virus, y de aparición reciente, lo podemos visualizar aquí:

Rustock.NAH Descarga otros archivos, utiliza rootkit

Recordad que este riesgo se minimiza en más de un 90% si navegamos y utilizamos nuestro equipo bajo una cuenta con permisos mínimos. Este y otros ejemplos parten sobre la base de un usuario medio navegando e iniciando sesión bajo una cuenta administrativa.

Descarga Ejemplo ADS (Guardar destino como...)

Si queréis saber en mayor profundidad qué es ADS, podéis visitar estas Webs:

Características desconocidas del NTFS. José Manuel Tella

A Programmer’s Perspective on NTFS 2000 Part 1 by Dino Esposito

Hidden Threat: Alternate Data Streams by Ray Zadjmool