Reto Forense - HTB: Lure

 

El otro día realice un reto de HTB, fácil pero muy divertido e instructivo ya que te permite entrenar las habilidades para analizar un archivo de tipo ofimático.

Para lo cual “levante” la máquina virtual donde realizo los análisis de malware, y por tal motivo tiene herramientas para tales trabajos y, por supuesto, no tiene salida a Internet. 

Tras arrancar la máquina virtual y transferir el fichero, lo primero que hice fue abrir el documento “doc” con winrar, ya que dichos documentos se encuentran estructurados en formato XML. Tras abrir el documento, abrí el documento: [Content_Type].xml, que viene a ser un índice del contenido del documento ofimático 

En el contenido encontrado, lo que llamó mi interés fueron los documentos: e2oDoc.xml y downrev.xml, los cuales se encontrabann dentro del directorio: /Drs/

 

Tras detectar el contenido mencionado anteriormente, pasé a revisar ambos documentos con más atención.

En: Downrev.xml, sólo encontré una cadena en base64 que tras decodificarla determiné que no es lo que estaba buscando y en: e2oDoc.xml, tampoco encontré algo sugerente.

Así que, ¡¡try harder!!

El siguiente paso fue abrir el documento.Al abrirlo vi la advertencia de seguridad relacionada con la ejecución de macros, pues fui a ojearlas

 Al intentar modificarla, la contraseña me lo impidio.

Pero no pasa nada, pasé a utilizar la herramienta de nuestro querido amigo Didier Stevens: oledump.

Tras ejecutarla vi dos macros, detrás de los objetos con los caracteres: M y m

Visite el elemento 7.

Encontré un comando de poweshell encriptado, pues ni corto y perezoso, lo ejecute

 

Obtuve un error, pero también obtuve el comando en texto claro.

Al analizarlo vislumbre que tenemos un texto partido en múltiples partes y que debemos ordenarlo según la secuencia:

{5}{25}{8}{7}{0}{14}{3}{21}{2}{22}{15}{16}{31}{28}{11}{26}{17}{23}{27}{29}{10}{1}{6}{24}{30}{18}{13}{19}{12}{9}{20}{4}

Pues nada, empecé ordenando y numerando las distintas cadenas a ordenar según la secuencia anterior.

Al final, obtuve la siguiente cadena:

Tras sustituir los valores en hexadecimal por valores ascii, obtuve lo que andaba buscando:

En cualquier caso…

Lo que hagas con la información es cosa tuya, no mía... pero ten conciencia.

 

 

 

Proyecto: MiShodan

 Buenas

Quiero en esta entrada liberar mi trabajo fin de master por si a alguien le puede llegar a interesar.

Sin más os presento el resumen del trabajo y el enlace a mi github donde reside, y no por ese orden.

El enlace es este  y el RESUMEN es:

Siempre que una empresa contrata a un auditor en su plantilla con el objetivo de mantener sus sistemas tanto externos como internos seguros, el auditor solicitara una relación de activos y su criticidad para la empresa, así como la infraestructura de red en donde aparezcan todos los sistemas, ya sean servicios web, bases de datos, sistemas de seguridad, etc.

El problema empieza cuando la empresa no sabe dar respuesta a esa pregunta, ya que a partir de ahí el auditor tendrá que encontrarlos, principalmente entrevistando a los distintos miembros de la empresa. Esta tarea puede llegar a ser un ejercicio sencillo, arduo o extenuante dependiendo de la empresa en donde se desarrolle la actividad.

Pero, si a ese enfoque se le añade una labor de caja negra de localización de direcciones IP activas dentro de la empresa, teniendo en cuenta que cada IP se corresponde con un activo de la empresa, el tiempo de investigación se reduciría.

En la búsqueda de esas IPs, el auditor empezarán sus pesquisas desde el equipo que se le haya asignado dentro de la empresa mirando la IP de su equipo y las IPs de los servidores DNS para hacerse una idea del los rangos de IPs manejados por la empresa. A partir de ahí, empezará a trabajar con distintas herramientas para el descubrimiento de activos, una de esas herramientas puede ser la archiconocida: nmap.

Sin embargo esa tarea necesita un tiempo que el auditor puede no tener debido a la cantidad de entrevistas a realizar.

Por dicho motivo, sería necesario automatizar dicho proceso, lo que implicaría una reducción del tiempo de investigación que el auditor emplearía.

Ese proceso de automatización es lo que se describe en este documento que está usted leyendo.

Espero que sea de su agrado.

OVERVIEW

When one company hires a auditor inside its staff with the objective to keep theirs computer systems such internal as external safe, the auditor asks for the assets relationship and their criticality for the company, just like the network structure where every systems are, such as web service, data base, security system, etc.

The problem starts when the company doesn’t know to response that question, since there the auditor will have to find it mainly interviewing all of the members of the staff. This task could became a easy,a difficult or exhausting task, depending the company where the auditor is.

But if to the previous point of view we adds a black box task of localization the IP directions inside the company, considering that each IP is a asset of the company, the investigation time will be less

For the search of those IPs, the auditor will start her/his search from the computer inside the company, seeing her/his IP and the IPs of the DNS servers. With these data the auditor could know the ranges of IPs of the company. From there, the auditor will start to work with several tools for descovering the assets, one of these tools can be: nmap

However, that task needs a time what the auditor couldn’t have due to the number of interviews to be conducted

That’s why, it will be neccesary to automative this task, this will get to have less time of investigation by auditor

That task of automation is described in this document.

I hope it’s to your liking

FIN

 

Por último y en cualquier caso…  

Lo que hagas con la información es cosa tuya, no mía... pero ten conciencia.

 

 

Serie: Cuadernos forenses - GPT

Ya se ha hablado aquí de la MBR, Master Boot Record, y se ha comentado que su estructura limita el espacio de cada una de las particiones declaradas en la misma a 2 TB.

Tamaño suficiente, ¿no?

Pues tal y como expuse en mi último post, hay veces en la que 2 TB no es suficiente y se necesita un poco más de espacio.

Una posible solución para poder hacer esto es sustituir la MBR por la GPT, tabla de particiones GUID o GUID table partition. 

-----------------------------------------------------------------------------------------------------------------------------------------------------------

NOTA: GPT es parte del estándar: Unified Extensible Firmware Interface (UEFI), que es una especificación que define la interfaz entre el firmware y los sistemas operativos durante el proceso de arranque.

Fue propuesto por Intel para reemplazar la vieja BIOS del PC, heredada del PC IBM original, es decir, la GPT sustituye al Master Boot Record (MBR) usado por BIOS.

-----------------------------------------------------------------------------------------------------------------------------------------------------------

Pero, ¿cuál es la estructura de la GPT?

GPT usa un modo de direccionamiento lógico por bloques, LBA (logical block addressing / direccionamiento de bloque lógico)  en vez del que utiliza la MBR: CHS (Cilindro-Cabeza-Sector / cylinder-head-sector)

Estos bloques lógicos como mínimo pueden ser de 512 bytes por sector para mantener una compatibilidad hacia atrás. Otros valores pueden ser: 1024, 2048, 4096 bytes o más.

Los bloques se encuentran numerados basándose en un índice que va de 0 a 34,  y de -34 a -1, siendo su estructura a grandes rangos de la siguiente:

1.       LBA 0 o Protective MBR 

2.       LBA 1 o Primary GPT Header.

3.       LBA 2 a 33

4.       LBA 34 o Particiones

5.       LBA -33 a -1Tabla de partición GUID secundaria:.

Visualmente.

El bloque número 0,  contiene una MBR para permitir que el firmware que no detecta GPT pueda detectar el disco. Es más, dicha MBR tiene definida una sola partición de tipo: 0xEE (GPT), por lo que las BIOS antiguas detectaran el disco y la partición aunque la presentarán como inaccesible. Por el contrarío nuestra “BIOS” de tipo EFI/UEFI ignorará la MBR.

Es en definitiva, una manera de garantizar la compatibilidad con los sistemas de arranque basados en BIOS y por tanto en MBR.

El bloque número 1, se conoce como: Cabecera de tabla de particiones o Primary GPT Header, y su estructura es como sigue.

 

 

 

De la estructura anterior cabe destacar:

 

1.- El CRC32, dicha suma de verificación garantiza la integridad de la cabecera GPT, ya que permiten detectar los sectores defectuosos que la dañan, entre otras cosas.

 

Del byte 16 al 20.

 ----------------------------------------------------------------------------------------------------------------------------------------------------------

NOTA: Las suma de verificación CRC32 es generada automáticamente para la cabecera y las entradas de partición, y  son verificadas por el firmware, el gestor de arranque o el sistema operativo.

-----------------------------------------------------------------------------------------------------------------------------------------------------------

 

2.- La localización de la copia de seguridad de esta misma estructura.

 

Del byte 32 al 40

 

3.- La identificación unívoca del disco duro.

 

Del byte 56 al 72

 

4.- El número y el tamaño de las entradas de las particiones que conforman la tabla de particiones

Del byte 80 al byte 92

Los bloques del número 2 al 33, contienen cada uno la siguiente estructura, que define el tipo de partición y su ubicación en el disco, en términos de LBA.

Como se puede ver cada partición tendrá un identificador unívoco definido desde el byte 16 al byte 32.

El bloque número 34, como se ha visto y se puede intuir, contiene las distintas particiones enumeradas en el GPT y los valiosos datos del usuario/s.

Los bloques del número -33 al -1, contienen la copia de seguridad comentada anteriormente.

Ahora que sabemos un poco más sobre GPT, podemos comparar la estructura de la MBR y de GPT, por supuesto, de manera visual.

 

 

 

En cualquier caso…  

Lo que hagas con la información es cosa tuya, no mía... pero ten conciencia.