#Triage en #Windows – #FastIR Collector

Hola secuaces:

En esta entrada quiero hablaros del triaje, (o triage).

El tiempo es algo crítico cuando ocurre un Incidente de Seguridad. En ese punto, se hace necesaria una intervención rápida para identificar qué Sistemas están comprometidos y gestionar estos Sistemas. Ahí es donde entra en juego el Triage.

Primero, definamos el triaje, según la RAE:

“Acción y efecto de triar.”

Bueno, vale, ¡pues, para variar, sí que me ha sacado de dudas la RAE! Busquemos triar:

Nos quedamos con el punto 1, “Escoger, separar, entresacar”.

Pero, ¿Qué es el triage? “Es el proceso de determinar la prioridad de los tratamientos de los pacientes, en base a la gravedad de su condición…” ¡No! Espera, que no es esa definición. Que nos estamos refiriendo al triage informático, o ciber triage. No al triaje de urgencias sanitarias. ¿O sí? Veámoslo.

No voy a entrar a definir ni a explicar qué es un Incidente de Seguridad y qué plan y respuesta hay que tener para ello.

Todo esto se me escapa, (creo que entramos en labores administrativas y ejecutivas). Además, sinceramente, no tengo conocimiento teórico alguno de esta materia. Así que…

A ver si consigo dar mi propia explicación… Bajo mi humilde punto de vista, el triage es ‘Un proceso para analizar y poder priorizar las respuestas ante sistemas comprometidos, en base a la gravedad de su condición, escogiendo, separando y analizando evidencias, de una forma rápida, para identificar, contener y erradicar el daño, e iniciar la pertinente investigación y análisis forense del Sistema.’

Pues parece que no iban mal enfocadas ninguna de las definiciones que hemos dado antes, siempre bajo mi punto de vista.

Dado que solo se hacer cosas con cosas que hacen cosas, y no soy ningún experto, ni en definir, ni en explicar las cosas, os propongo como lectura algunos documentos:

Un documento publicado por INCIBE: “Identificación y reporte de Incidentes de Seguridad para operadores estratégicos”

Un documento publicado por Alient Vault: “The Art of Triage: Types of Security Incidents”

Un documento publicado por OWASP: “Top 10 considerations for Incident Response”

Y como no podía ser menos, el ciberdebate de @Palabradehacker: Equipos de respuesta a Incidentes de Seguridad

Recoger evidencias para responder a un Incidente puede ser una ardua tarea, y muy, muy dura. Para ello hay unas maravillosas personas que desarrollan aplicaciones que automatizan el proceso.

En cuanto a herramientas de triage, existen docenas, pero docenas de ellas. Podéis preguntarle a Google y daros una vuelta por Github para ver la cantidad de ellas, solamente ubicadas en GitHub.

Para esta ocasión voy a hacer uso de una de esas aplicaciones de Triage de “botón gordo”, de esas de ejecutar y listo, (o no tanto).

Se trata de FastIR_Collector, una herramienta desarrollada por Sekoia, una Start-Up de Ciberseguridad. Como su propio nombre indica, se trata de una utilidad para respuestas ante Incidentes, de recolección rápida de evidencias, (¿Se dice así? Es que mi inglés…).

¿Por qué he escogido esta en concreto? Porque trabaja tanto en entornos Windows como en entornos Linux. Espero mostrároslo en futuras entradas.

Leyendo su sitio https://sekoialab.github.io/Fastir_Collector/ me doy cuenta de que dice una verdad como un templo: “Con el crecimiento exponencial del tamaño de los discos duros, su copia puede durar varias horas y el volumen de los datos puede ser demasiado grande para un análisis rápido y eficiente.” Al fin y al cabo, cuando tratamos con un Incidente de Seguridad, debemos dar una respuesta rápida y eficiente. De momento, me gusta. No voy a entrar más en detalle en la descripción de esta herramienta, que ya llevamos un rato escribiendo y leyendo 😉

Vamos a la ‘chicha’. Le echamos un vistazo a la “Guía final del usuario de FastIR_Collector” y comenzamos a proceder tal y como detallan.

Tras descargar la herramienta desde su sitio oficial, descomprimirla y copiarla a una unidad extraíble, listamos los directorios y carpetas que tenemos.

Como podemos observar, los ejecutables se encuentran en la carpeta ‘build’. Visto esto, nos dirigimos a ese directorio con el explorador de Windows, clicamos con el botón derecho en el ejecutable de nuestra arquitectura y le damos a ‘Ejecutar como administrador’.

Ahora, como Windows es así de simpático, (hay que reconocer que es una medida de seguridad), nos saltará la ventana para ejecutar la aplicación con los privilegios de administración. Le damos a ‘Sí’.

Comienza el proceso de extracción de datos…

… Y finaliza. Justo antes de cerrarse la ventana de la consola, nos indica que se ha creado una carpeta con la salida de todos los datos.

Nos dirigimos a ese directorio y lo listamos.

Basta un vistazo rápido para ver que no está nada mal la adquisición. Pero nada mal. Historiales de navegación, carpeta Prefetch, conexiones, procesos, servicios, dispositivos USB conectados, etc.

Además, se ha generado un fichero ‘FastIR.log’, que contiene todas esas líneas que han ido pasando por la consola. Todas, así que tranquilos. No hace falta estar pendiente de cada proceso, dejándonos la vista en la consola.

Abrimos el log con cualquier aplicación. Yo he elegido a Chrome. Está realmente completo. Muy bien detallado.

 

Y con esto ya estaría realizado el triage, ¿o no?

Pues yo no me quedo tranquilo. Pero nada tranquilo. Echo de menos algunas adquisiciones de evidencias. Me parece poca información la que se ha extraído y me parece un auténtico dolor tener que estar dando permisos a Windows para que ejecute. (O quizás sea que soy un enamorado de las líneas de la consola)

Y como no me quedo tranquilo, pues le echamos un vistazo a otro documento que hay. La Documentación de FastIR_Collector, y vemos que tiene otras opciones. Así pues, nos vamos a la consola, al CMD, con privilegios de administración.

Nos colocamos en la ruta del ejecutable y pedimos ayuda desesperadamente, con el parámetro ‘-h’.

Pues vaya. Parece que tiene más opciones de las que aparenta. Y unas muy curiosas.

Volvemos a ejecutar esta estupenda herramienta, con los siguientes parámetros: ‘–packages memory,registry,evt,fs,health,filecatcher,dump –output_dir F:’

Quizás os preguntéis que, puestos a tirar de todos los parámetros, ¿Por qué no le he dicho que me dumpee la memoria RAM con el parámetro ‘–dump ram’? Pues porque considero, (opinión personal), que la extracción de la memoria RAM debe ser un proceso único y aislado, el primero a realizar.

NOTA: No ejecuto el parámetro ‘all’ porque, en este día en que estoy redactando esta entrada, no trabajaba. A ver si lo solucionan 🙂

Como en el caso anterior, cuando presionamos la tecla ‘Enter’, comienza el trabajo de adquisición…

… Y finaliza indicándonos la ruta donde ha generado la salida de todos los datos. Esta vez, no se cierra la consola.

Igualmente, como en el caso anterior, tenemos un bonito log que podemos, y debemos, revisar, muy completito.

 

¿Y el listado de esta última adquisición con los parámetros dados a través de la consola? Pues lo he dejado para que veáis la diferencia. Comparar vosotros mismos La adquisición de un método y la adquisición de otro método. De entre todos ellos voy a destacar el ‘mbr_raw’, el ‘*_mft_C.mft’ y el ‘dump_registry.zip’. Por destacar algunos importantes que no son adquiridos si se ejecuta esta aplicación de forma gráfica.

Como siempre digo, daros cuenta de la importancia de leer la documentación de cualquier software que usemos.

En entradas futuras espero poder analizar algunas de estas evidencias recogidas.

Para terminar ya, que hoy me he extendido demasiado, y si estáis interesados en saber más de esta herramienta, debo recomendar dos lecturas más:

“Complex malware & forensics investigation” y “FastIR Collector in advanced threats”.

Esto es todo, por ahora. Nos leemos en la siguiente entrada. Se despide este minion, entregado y leal, de vosotros… por ahora.

Marcos @_N4rr34n6_