NOTA:Podéis leer algo más sobre este registro aquí 

Pero dicho formato tiene un “problema”, que si quieres ampliar el espacio del disco duro más allá de 2 TB, no te lo permite debido a que la estructura del registro no está preparada para ello.

Para ello, se creó el formato GPT (GUID Partition Table), que sustituye al formato MBR y que se asocia con los sistemas UEFI.

Intente pasar mi tabla de partición del formato MBR al formato GPT para poder ampliar el espacio de mi disco duro virtual, pero todos los intentos que realice con la aplicación: gdisk (mi máquina virtual tiene instalado un sistema Centos), fueron infructuosos.

NOTA:Para convertir un disco con formato MBR a GPT sólo hay que ejecutar el comando: gdisk <disco duro> y atrevernos a pulsar la opción: w, después: y (yes), para confirmar.

Todo esto bajo tú responsabilidad, porque puedes perderlo todo

NOTA: Siempre he pensado que el VMWare comprobaba los requisitos seleccionados relativos al espacio de disco… y es así siempre que selecciones que quieres gestionar un solo fichero. Por lo tanto, si seleccionamos la opción de VMWare “Split  virtual disk into multiple files”, podremos seleccionar la capacidad de disco que necesitemos.

Información reportado por el sistema operativo relativa al espacio del disco duro y a sus particiones

Seleccionar 3TB de disco duro, implica tras un mensaje de VMWare que nuestro formato de registro de arranque principal será GPT.

Por lo tanto, en mi caso, una posible solución sería crear directamente una máquina virtual con el espacio que realmente necesito e reinstalar todo lo que necesito sobre ella.

Lo sé no es lo optimo, pero algo es algo

Y ya se sabe, hay que ser previsor, por lo que cuando vayáis a trabajar con discos duros de TB en entornos virtualizados, ser previsores y trabajar con GPT

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

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 MBRpara 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.

Elbloque 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 seguridadde 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

Losbloques 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.

Losbloques 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.

 

 

 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.

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.

Visite el elemento 7.

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.

En cualquier caso…

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

En este reto de HTB, lo primero que nos encontramos es un archivo con magic number: regf, es decir, un archivo de registro de Windows incompleto. Por lo tanto, ni podemos leerlo abiertamente con un editor hexadecimal ni con un intérprete ni mucho menos podremos leerlo directamente abriéndolo con el registro de Windows.

Pero eso no es problema, buscando en Internet no sólo encontramos la estructura de este tipo de archivo: https://www.taksati.org/regf/, sino también un parser de dicho archivos, así como ayuda para su uso:

·         https://cyberforensicator.com/2018/01/13/carving-fragmented-registry-files/

·         https://dfir.ru/tools/

·         https://github.com/msuhanov/yarp

Para una mejor inspección, salvamos el contenido en un archivo mediante el comando: yarp-print <fichero> >> <fichero a almacenar>

Una vez obtenido lo que buscamos, y sabiendo que las flag de HTB son del estilo: HTB{….}, y que a la gente que pone los retos le gusta sobremanera la codificación en base64, buscamos dentro del archivo las cadenas en base64 que comiencen por: SFRC = HTB.

Al hacerlo encontramos una cadena:

DE INTERES:la cadena pertenece al nombre de un archivo, que será ejecutado siempre que el sistema se inicie, por estar dentro de: Software\Microsoft\Windows\CurrentVersion\Run

Si decodificamos dicha cadena obtenemos:

Parece que la intuición no ha fallado.

En cualquier caso…

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

Pepito:Logs de RDP, ¡que Dios nos pille confesados!

Juanito:Que si, te vuelvo a repetir

Pepito:Y después de esto…

Juanito:Después de esto, encontré un reto en HTB que trataba precisamente de esto.

Pepito:¿Cómo lo resolviste?

Juanito:Lo resolví gracias a la herramienta denominada: bmc-tools.py.

Pepito:¿Pero cómo llegaste hasta dicha herramienta?

Juanito:Gracias a la búsqueda del magic number del archivo, que por cierto es: rdp8bmp.

Simplemente con poner el magic number en San Google podrás encuentrar en una de las entradas referencia al proyecto de Github.

Pepito:Pero, ¿logs de RDP?

Juanito:Pues sí, desde la versión 5.0 de RDP, Microsoft introdujo un mecanismo de caché para mapas de bits.

El objetivo era fue reducir la latencia de las comunicaciones entre el servidor RDP y el cliente RDP, por lo que las imágenes eran trasferidas al disco duro del cliente RDP y luego este la mostraba por pantalla.

Desde Windows 7, los archivos cacheados se encuentran ubicados en: "% USERPROFILE% \ AppData \ Local \ Microsoft \ Terminal Server Client \ Cache \".

En dicha ubicación nos podemos encontrar archivos de tipo “binario”, con la siguiente nomenclatura: cache{dddd}.bin(dddd = cuatro dígitos incrementales que comienzan desde 0000). Estos archivos pueden llegar a pesar cada uno: 100MB

En cuanto a la estructura de estos archivos, estos  tienen un encabezado fijo que es claramente identificable gracias al magic number: RDP8bmp, como ya hemos visto al hacer el reto. Tras el magic number, veremos un carácter nulo seguido de cuatro bytes correspondientes a una versión, es decir, el encabezado tiene doce bytes.

Cada elemento gráfico tiene un encabezado de tamaño reducido en comparación con los archivos con extensión ".bmc"^{ver NOTA}:

·         un hash del elemento gráfico almacenado en ocho bytes

·         el ancho del elemento gráfico almacenado en dos bytes

·         la altura del elemento gráfico almacenado en dos bytes

Los datos subyacentes a cada elemento gráfico están en formato de 32 bpp.

NOTA:Hasta Windows XP, la caché se encontraba en: "%USERPROFILE%\Local Settings\Application Data\Microsoft\Terminal Server Client\Cache\".

En dicha ubicación, se podían encontrar los siguientes archivos, que podían alcanzar hasta 10 MB de peso.

·         "Bcache2.bmc" que contiene los elementos gráficos en calidad de 8 bpp,

·         "Bcache22.bmc" que contiene los elementos gráficos en calidad de 16 bpp,

·         "Bcache24.bmc" que contiene los elementos gráficos en calidad de 32 bpp;

Estos archivos ".bmc" no tienen ningún encabezado fijo que permita su identificación inmediata, pero cada elemento gráfico en su interior tiene un encabezado de veinte bytes estructurado de la siguiente manera:

·         un hash del elemento gráfico almacenado en ocho bytes

·         el ancho del elemento gráfico almacenado en dos bytes

·         la altura del elemento gráfico almacenado en dos bytes

·         el tamaño en bytes de los datos que siguen al encabezado y que corresponden a la imagen almacenada en cuatro bytes

·         los parámetros específicos para el elemento gráfico almacenados en cuatro bytes.Uno de ellos define si el contenido de la imagen está comprimido o no, aunque se desconoce el algoritmo de compresión, por lo que ante una imagen comprimida no es posible recuperar los datos.

Si quieres más información, e incluso desarrollar tu propia herramienta en powershell, puedes ver las siguientes URL:

https://www.cert.ssi.gouv.fr/actualite/CERTFR-2016-ACT-017/

https://cbtgeeks.com/2018/05/22/digital-forensics-on-rdp-cache/

Pepito:Y el reto, ¿cómo fue?

Juanito: Pues ya te digo, aplique la herramienta y obtuve está foto que tengo en el móvil. Mira, mira…

En cualquier caso

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

Para resolverlo empezamos por abrir el archivo comprimido.

Dentro se pueden ver dos carpetas, de las cuales nos quedamos con la carpeta de nombre: Logs, ya que es la única que tiene información tras visualizar el tamaño de ambas.

Dentro de esta carpetas nos encontramos multitud de ficheros catalogados como “Registros de eventos” (extensión .evtx), por lo que necesitaremos visualizarlos. Pues descomprimimos la carpeta: Logs en un entorno seguro con sistema Windows.

El sistema operativo de dicho entorno ya se encargará de visualizar el contenido de cada archivo que seleccionemos mediante la ejecución del visor de eventos del sistema.

Si nos fijamos en la pista del reto, tenemos que buscar un comando de PowerShell, por lo que lo primero que deberemos hacer será cargar en el visor los eventos todos los archivos de eventos relacionados con PowerShell, pero antes de cargar los cuatro archivos que se puede relacionar con PowerShell, comprobemos su tamaño.

Se puede ver que tres de ellos sólo tienen 68KB, mientras que el cuarto tiene 5Mb. Por lo tanto, nos quedaremos con este último archivo, ya que si comprobamos los otros, estos están vacios.

Al abrir el registro de eventos: Microsoft-Windows-PowerShell%4Operational, vemos contenido de interés, de hecho, al abrirlo el primer evento que me apareció resulto ser de mucho interés, ya que se podía ver la ejecución de un comando en powershell que intentaba descargar un archivo de tipo “PowerShell” (extensión .ps1), desde un página en github.

 Si nos fijamos en el nombre del archivo: SFRCezhMdTNfNzM0bV9GMHIzdjNSfSAg.ps1, podemos decir que estamos ante un texto codificado.

Si probamos con la codificación más utilizada en este tipo de retos (base64) obtenemos nuestro premio

En cualquier caso

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

 Este reto empieza abriendo el archivo “.pcap” que trae el archivo comprimido.

En él se observa dos tipos de comunicaciones:

1.       DNS

2.       HTTP

Se hace una primera aproximación a la información de los paquetes de tipo DNS, pero sólo se ve morralla.

Se pasa a las comunicaciones del protocolo HTTP y se realiza un filtro buscando los primeros paquetes de toda comunicación TCP, los famosos paquetes SYN.

Encontramos 6.

Solicitamos al WireShark que siga el flujo de dicha comunicación y nos muestre todas las comunicaciones de manera “legible”, obtenemos:

Como se puede ver, la conexión al puerto 4444 pertenece a una Shell de Windows.

Lo que llama la atención de los distintos comandos ejecutado en dicha Shell es, el intento de descarga de un fichero de nombre: JBKEE62NIFXF6ODMOUZV6NZTMFGV6URQMNMH2IBA.txt

El nombre podría estar codificado de alguna manera, aunque no parece que este usando base64 para ello. Aún así, investiguemos

Con el nombre del archivo, nos dirigimos a la herramienta online CyberChef, y empezamos a jugar con las distintas codificaciones hasta que encontramos la codificación adecuada: base32.

Con ella obtenemos nuestro premio

Pero ahora la pregunta es, ¿cómo podemos distinguir de una sola pasada que estamos ante una codificación base32?

Pues si miramos en nuestra amada Wikipedia, podemos ver que la codificación en base32, sólo permite los siguientes caracteres

Ahora comparémosla con la codificación en base64, que admite los siguientes caracteres:

1.- Base32 SOLO maneja caracteres MAYÚSCULAS

2.- Base32 SOLO maneja números del 2 al 7

Referencias:

   https://es.wikipedia.org/wiki/Base64

   https://es.wikipedia.org/wiki/Base32

Al abrir el archivo comprimido vemos dos archivos:

1.- rsa_private.key

2.- how_to_make_meth.txt

Como es obvio el archivo de texto no contiene la flag que buscamos, pero se puede intuir que el archivo de texto tiene que ser descifrado mediante la clave privada.

Pero, ¡siempre hay un pero!, si abrimos el archivo  con extensión “.key” podemos ver que la clave no se encuentra correctamente formada.

A. Formato de codificación binario en DER / Binary DER-encoded format, también llamado: ASN.1 VER.encoded

B.    Formato  PEM o Base64.

El formato PEM (Privacy-Enhanced Mail) es un formato para almacenamiento y envío de claves criptográficas, certificados y otros datos basados en el conjunto IETF 1993

 C.     Formato XML

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

Por lo tanto, la clave de este reto se encuentra en pasar la clave privada RSA a un formato correcto.

Para ello tiramos de la herramienta online “ciberchef” y, aplicamos las siguientes operaciones: PEM to HEX > From HEX (delimitador: None) > Raw ínflate

Ahora sólo falta probar a descifrar el archivo: how_to_make_meth.txt, mediante el siguiente comando:

En cualquier caso

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

Empezamos extrayendo el archivo: WIN-LQS146OE2S1-20201027-142607.raw

La primera impresión es que tenemos un volcado de memoria, por lo que sacamos el volatility a la palestra y probamos a ver si es posible determinar el perfil del archivo.

Siguiente paso, buscar procesos que se estuvieran ejecutando durante el volcado de memoria y que mejor manera de hacerlo que mediante los módulos: pslist y pstree. Personalmente y a día de hoy me gusta más el segundo.

Me llama la atención los siguientes procesos:

            1.- DumpIt.exe (Pid: 2004 y PPid: 808)

Pero siempre que veo en ejecución el proceso: cmd.exe, mi sentido arácnido me alerta, por lo que  paso a comprobar lo que realmente se está ejecutando por consola, para lo cual utilizo el módulo: cmdscan

Al ejecutarlo, se obtiene:

Pero lo más curioso es que la URI de la URL tiene formato en base64, probemos a decodificarla.

¡Premio!

En cualquier caso

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

Con la única pista que nos dan: @blue_shad0w_ , se busca información en San Google. Se encuentra un perfil en Twitter, que tiene posteados nada más y nada menos que 58 tweets compuestos de cadenas de 0’s y 1’s.

La primera impresión es que nos encontramos ante un programa codificado en binario, que debe ser transformado para que podamos ejecutarlo.

Para comprobarlo, se decide a coger el primer tweet publicado -por tanto el más antiguo-, porque si la intuición no falla dicha parte contendrá el magic number del fichero. Con lo cual podremos saber contra que nos enfrentamos

Los pasos para la transformación serían:

1.- Copiar y pegar la primer cadena de 0’s y 1’s en un archivo

Para ello yo he utilizado el siguiente código.

3.- Tras obtener la cadena en hexadecimal, ahora debemos pasarla a un formato “ejecutable”, para ello utilizaremos la herramienta: xxd, con los parámetros: -ps (output in postscript plain hexdump style.) y –r (reverse operation: convert (or patch) hexdump into binary.).

 ¡Perfecto!, la intuición no nos ha fallado, tenemos un fichero: ELF, que no es otra cosa que un fichero ejecutable en sistemas *NIX.

Ahora nos toca hacer lo mismo pero con todas la cadenas de 0’s y 1’s puestas unas detrás de las otras.

Una vez realizado esto, se procede a ejecutar el archivo obtenido.

Buscamos entre las cadenas del propio programa el antídoto, para lo cual utilizamos el comando: strings

Pasamos a bucear por Internet, en dicho universo encontramos referencia de un episodio de Stars Wars denominado: “Blue Shadow Virus”, en donde se habla de su antídoto: reeksa roots (raíces de reeksa). Se decide probar con ello.

A862BC50162B5BFA6ED8167898E843E4

Ahora solo hay que añadir el formato adecuado y probarlo.

En cualquier caso

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

Buscando por Internet información sobre un reto de HTB, me encontré con esto:

Realmente el enlace dirige hacía un archivo de texto que contiene flags de los retos de HTB (enlace: hxxps://linguinielruso.com/Soplones/soplon_HTB_ALL.txt)

No intentes ir a la web, ¡no funciona!, pero aún así se puede extraer toda la información del documento… o se podía. ¿Por qué?

¡Porque Google ha/había cacheado el contenido del archivo .txt!, por lo tanto, podemos utilizar forks para recuperar toda la información del documento.

Ejemplos al respecto:

La fork es sencilla, no me hagas escribirla

Y antes de que vayas a sacar flags de HTB, comentarte que el contenido del documento no se encontraba muy actualizado. Pero, lo más importante y que ya se ha comentado

¡Google cachea el contenido de archivos con extensión .txt!

Y, ahora, ya puedes ir a por las flags… o no (el autor posteriormente a bloqueado a los spider).

 

Una manera rápida de encontrar máquinas en un entorno de directorio activo, es preguntarle al directorio activo.

Para ello, se necesitará un usuario válido que tenga permisos para hacer consultas.

Si ya lo tienes, lo único que necesitas algún programita que te permita hacer dichas consultas, personalmente me gusta trabajar con el módulo de Windows ActiveDirectory.

Entre sus comandos tenemos: Get-ADComputer, por lo que mediante el siguiente comando podemos extraer todas las máquinas dadas de alta en el Directorio Activo, siempre y cuando se encuentren activas.

 Si queremos hilar un poquito más…

Y obtendremos

Ahora sólo nos queda obtener las direcciones IP, pero preguntando al servidor DNS lo tenemos resuelto

NOTA: Y cómo esto, tenemos todo el campo libre para obtener información sobre usuarios, grupos, etc. Ejemplos:

Grupos de seguridad global y universal que tiene el patrón “admin” en el nombre 

...

En cualquier caso

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

¿Qué es?

Este ataque se basa en construir un TGS (ticket Kerberos) válido para un servicio, una vez se ha obtenido el hash NTLM del propietario del susodicho servicio. De esta manera, es posible acceder a este servicio con un TGS personalizado que contenga los más elevados privilegios.

Ejemplo de este tipo de ataque

El siguiente ejemplo parte de una máquina de HTB (intelligence).

Paso 1.

Tenemos un usuario y su hash NTLMv2, que incluso ha sido posible crackear, pero esto último no es relevante en este caso.

Hash NTLMv2 del usuario Ted.Graves

Paso 2.

Comprobamos si existe algún servicio sobre el cual el usuario sea propietario.

Para comprobar esto se utilizará la herramienta: gMSADumper (https://github.com/micahvandeusen/gMSADumper), ya que la herramienta “impacket”, no trae ninguna herramienta para hacer esto. Al menos hasta dónde mi conocimiento llega.

***** NOTA: *****

Esta herramienta, busca Group Managed Service Accounts (gMSA), pero, ¿qué son?

Los gMSAsson cuentas de servicio que ofrecen una manera segura para ejecutar aplicaciones, servicios y tareas de manera automatizada. Fueron introducidas en Windows Server 2016 pero pueden ser aprovechadas en Windows Server 2012 y versiones anteriores

Las característicasde estas cuentas son que las contraseñas de las mismas son generadas aleatoriamente, cambian automáticamente y no es necesario que ningún usuario las conozca. Además, estas cuentas de servicio son “instaladas” únicamente en el servidor (por lo tanto será necesario utilizar una cuenta de máquina) que solicitara su uso al AD en tiempo de ejecución. Por lo dicho,

Las  gMSAs son un tipo específico de objeto dentro de Active Directory, concretamente: msDS-GroupManagedServiceAccount. Dentro de este objeto, la propiedad/atributo más importante es: msDS-ManagedPassword, este atributo contiene un BLOB con información de la contraseña actual

Bibliografía:

·         https://stealthbits.com/blog/what-are-group-managed-service-accounts-gmsa/

********************

El uso de la herramienta nos devuelve el siguiente dato:

Paso 3.

Procedemos a utilizar la herramienta de impacket: getST, para generar un ticket de servicio que nos permita elevar permisos sobre la máquina.

El resultado es:

***** NOTA: *****

En un entorno de AD, es muy importante tener la hora sincronizada con el controlador de dominio, ya que Kerberos no funciona correctamente si la fecha y hora de nuestro equipo no va acorde con la fecha y hora del controlador de dominio/servidor

Para mejorar esto, necesitamos configurar el servicio NTP de nuestra máquina para que utilice el servidor NTP del servidor y así corregir el problema

Repetimos la solicitud para generar un ticket de servicio, y conseguimos nuestro objetivo

Ahora sólo queda utilizar el ticket generado mediante Pass-The-Ticket

En cualquier caso

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

En una máquina de HTB, en la fase de la escalada de privilegios me encontré un código en python que trabaja con la función: eval(), y que podían ser ejecutado como root.

Dicha función “eval()” sin entrar en definiciones académicas, evaluará el contenido de lo pasado, es decir, ejecutará lo que se le pase como parámetro.

Un ejemplo sencillo:

Pero… ¿evalúa comparaciones?

Y si… ¿a la función “eval()” le metemos código de python?, ¿probamos a importar la librería “os”?

NOTA: la intención de solicitar una shell de bash.

La forma correcta de importar un librería cuando utilizamos la función: eval(), es: __import__(‘<librería>’)

Comprobemos:

 

¡¡Conseguido!!

Ok, probemos ahora a simular lo comentado antes, lo recordamos, ejecutamos un código de python con permisos elevados gracias a sudo.

¡¡Ahí esta!!

Como  conclusión… a la hora de programar cuidado con lo que se hace, pero a la hora de elevar privilegios nunca te olvides de nuestro querido ascensorista.

En cualquier caso

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

Abrimos el archivo comprimido que nos hemos descargado, y vemos que contiene un archivo de tipo ofimático.

Pues como ya comente en alguna otra entrada que no recuerdo, suelo seguir los siguientes pasos:

1.- Abrir el archivo ofimático con un gestor de archivos comprimidos, como por ejemplo: winrar, con lo que analizo la estructura interna del fichero. Aunque en muchos casos la información obtenida no es muy prometedora.

2.- Abrir el documento, y comprobar si el documento tiene macros. Es fácil, si el gestor de archivos ofimáticos con el que abramos el documento no sugiere activar las macros, es que obviamente hay macros dentro del documento.

Si tenemos macros, sugiero la modificación de la/s susodicha/s para así poder analizar el código y, si se considera, ejecutar la macro paso a paso.

En este caso, la macro solicita una contraseña para poder acceder a su contenido, por lo tanto, estamos en vía muerta

3.- Usar la herramienta: oledump, de Didier Steven, para analizar el contenido. Si el contenido tuviera macros, las detectaría e incluso podría extraerlas para su posterior análisis.

Por este motivo, pasamos a ejecutar el archivo, teniendo el programa visor de procesos: Process Explorer.exe , en ejecución.

Pues bien, uno de los procesos que se crean y que son hijos del archivo ofimático, es un proceso de PowerShell que si pausamos, podemos ver el comando que se ejecuta… o eso creía

Como se ve, el comando a ejecutar viene codificado en base64, pero el problema no es ese, el problema es que no es posible copiar todo el mensaje codificado para decodificarlo. Los campos de texto en Visual Basic tienen limitado en número de caracteres.

¿Y ahora qué?... Pues hay varias opciones:

1.- Un dumpeo de la memoria del proceso anterior, mediante el propio programa: Process Explorer

Para ello sólo tenemos que botón derecho sobre nuestro proceso de PowerShell parado y seleccionar: Create Dump > Create Full Dump > Seleccionar ubicación y nombre del archivo.

Ahora ya sólo nos queda abrir un editor hexadecimal y buscar por alguna parte el código en base64 encontrado anteriormente.

Pues para eso nos vamos al visor de eventos y buscamos: Registros de aplicaciones y servicios > Microsoft > Windows > Sysmon > Operational.

Tras unos minutos buscando, llegamos hasta el premio.

Bueno, tras extraer nuestra preciada materia prima, procedemos a decodificar y obtenemos nuestro ansiado código fuente:

Lo primero que llama la atención es una parte del código en dónde se utiliza la función: downloadfile, que creo que no hace falta explicar lo que hace. Se extraen las distintas URLs que contiene el código pero, ni sus visitas ni la estructura de las URLs nos facilita pistas.

Por lo tanto, nos toma ahondar en el código de nuevo.

Revisandolo vemos que hay una condición que nunca se dará y que depende de la descarga de un archivo desde cualquiera de las anteriores URL. Pero qué ocurre si comentamos dicha condición.

Pues que tras la ejecución del código vemos que se ha creado la estructura de directorio: Jrbevk4/Ccwr_2h. Y que dentro aparece un archivo de nombre: Ale7g_8.conf, que contiene el siguiente texto en base64

Ok, pues apliquemos la función XOR con clave:0xdf, a texto codificación en base64.

¡Perfecto!, hemos obtenido nuestro premio.

En cualquier caso

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

Sí, siempre y cuando sepas dónde mirar

En el caso del PIN de desbloqueo, deberíamos encontrar el hash de dicho PIN y el SALT que se utilizó en el momento de la definición del PIN.

El primero se puede encontrar almacenado en:/data/system/password.key, y el segundo se puede encontrar en: /data/system/locksettings.db

Para no perder mucho tiempo en la búsqueda del SALT, concretar que  ejecutando la siguiente consulta podríamos obtenerlo rápidamente: SELECT value FROM locksettings WHERE name=”lockscreen.password_salt”

…

Ahora, ¿cómo se obtiene en texto claro el PIN teniendo el hash y el salt?, o, ¿cómo se obtiene el patrón de desbloqueo teniendo el hash?

Fácil, para ello sólo se necesita una herramienta, dicha herramienta se puede encontrar en el recurso: https://github.com/georgenicolaou/androidlockcracker 

Pero, pongamos un par de ejemplos:

Ejemplo 1.- Averiguar el PIN de desbloqueo a partir del Hash + SALT

Para ello tenemos los siguientes datos:

Hash del PIN:1136656D5C6718C1DEFC71B431B2CB5652A8AD550E20BDCF52B00002C8DF35C963B71298
Salt: 3582477098377895419

Ahora sólo nos queda ejecutar la herramienta comentada anteriormente:

Recuadro naranja: hash del PIN

Recuadro rojo:        salt

Recuadro verde:     contraseña

Ejemplo 2.- Averiguar el patrón de desbloqueo

Para ello tenemos el siguiente dato:

Hash del patrón:82790AD0ADEB07AC2A78AC07038BC93A26691F12

Ahora sólo nos queda ejecutar la herramienta comentada anteriormente:

Recuadro rojo:        salt

Recuadro verde:    números con los que se forma el patrón.

Para PINES más complicados, la herramienta tiene la posibilidad de utilizar diccionarios o añadir otros juegos de caracteres además de los numéricos, que es el tipo de caracteres utilizados si no se indica nada.

En cualquier caso

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

En un reto de forense en análisis de memoria, aparece la siguiente pista/pregunta a resolver:

A SIP VoIP client software was running on the machine. What is the IP address of the server that the client was hardcoded to use?.

Para resolverlo seguí los siguientes pasos:

NOTA: No saltaremos el paso previo de averiguar el tipo de sistema operativo del cual se extrajo el volcado de memoria.

1.- Averiguar cuál de todos los procesos de los que corrían en el sistema es el cliente de VoIP, para ello se ejecutó el siguiente comando:

 vol.py -f memory_dump.mem --profile=Win10x64 pstree

 El resultado es bastante extenso, por lo que sólo pondré de los procesos donde aparece el proceso que buscamos.

En la imagen anterior se puede ver un proceso denominado: microsip.exe (PID: 4284), el cual según el sitio web: https[:]//www.microsip.org, se trata de un móvil software basado en el protocolo SIP. 

En dicho softphone se puede establecer el servidor SIP a utilizar, ¡y eso es lo que buscamos!

2.- Averiguar las conexiones de red establecidas en el momento del volcado, para determinar si dicho proceso tiene establecida alguna conexión que nos pudiera dar la dirección IP buscada.

NOTA: Aquí muestro mi forma de pensar

Adelanto que este no es el camino.

3.- Ya que la configuración se establece tras lanzar el proceso, revisar el espacio de memoria asignado al proceso que se está investigando. Para ello, se debe volcar el contenido de la memoria en un archivo, lo cual se consigue mediante el comando:

 vol.py -f memory_dump.mem --profile=Win10x64 memdump -p 4284 --dump-dir .

4.- De todo lo volcado, que es mucho, extraemos aquellas cadenas “inteligibles”. Para ello utilizamos el famosísimo comando: strings. Concretamente, lance el siguiente comando:

strings 4284.dmp >> Cadenas_memoria_microsip.txt

Antes de avanzar comentar que, desde este punto existen múltiples maneras de obtener nuestra flag, y aunque yo abordé una muy directa que se basaba en el concepto “fuerza bruta” , explicaré la que creo que es más sutil y eficiente.

Para ello sólo tenemos que tener en cuenta que el cliente software utiliza el protocolo de VoIP: SIP. Este protocolo utiliza el método SIP: INVITE, que permite invitar a un usuario o servicio a participar en una sesión  o modificar los parámetros de una sesión ya existente.

En la estructura de un mensaje INVITE, existen  dos cabeceras que para este reto son interesantes, estas son: From y To. Tras ellas, aparece una URI (Uniform Resource Identifier o Identificador Uniforme de Recurso) que tiene la siguiente estructura:

sip:<usuario o extensión>@<dominio>[:puerto]

Un ejemplo sería: 

From: <sip:100@192.168.1.100:5064>;tag=2d3ce7700b58c2d9

To: sip:100@192.168.1.100

Por lo tanto, con buscar cualquier de las dos cadenas anteriores,  obtendremos un usuario y la IP que solicita el reto.

Aunque el reto no era muy complicado, me gustó y por ello está aquí

En cualquier caso

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

El reto comienza visitando la entorno web: 206.189.25.173:32614/layoffs.doc, esto conlleva la descarga del documento indicado en la URI.

Al analizar el documento de manera estática (se debe abrir el archivo como si fuera un archivo comprimido) se pueden apreciar dos puntos de interés:

                En el archivo: document.xml

Lo más sencillo es visitar de nuevo la nueva URL, pero tal y como nos dice la descripción del reto, la resolución DNS no funciona, por lo tanto tenemos que irnos a la URL: http://206.189.25.173:32614/223_index_style_fancy.html

Al visitarla obtendremos una bonita página en blanco, pero su código nos abrirá los ojos:

¡Vaya!¡Follina ha llegado a nuestras vidas!

Del código que se ve, nos quedamos con lo interesante:

El resto del código en base64 puede ser música para tus oídos, pero depende de ti

Si decodificamos, obtenemos:

Ahora sólo falta interpretarlo, pero para eso tenemos nuestro amigo el powershell y las enseñanzas de Jack el Destripador, por lo tanto, iremos por partes definidas por los paréntesis.

Si empezamos por el principio debemos coger:

Fácil, ¡no!, pues ya tenemos nuestro premio. 

En cualquier caso

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

¿Qué es un archivo con extensión PFX?

Un archivo con la extensión PFX es un certificado en formato PKCS#12.

En dicho certificado se encuentra guardado el certificado, el certificado intermedio de la autoridadnecesario para una credibilidad del certificado y la clave privada para el certificado. Es decir, puedes imaginarte dicho certificado como un archivo con clave de acceso en el que está guardado todo lo que necesita para instalar el certificado o como una copia de seguridad de un certificado con clave privada de acceso (exportado desde Internet Explorer).

Importante, el archivo PFX está siempre protegido con una contraseña

NOTA:   ¿Cuándo se necesita crear un archivo PFX?

                Sobre todo de las siguientes situaciones:

·       Cuando instalamos el certificado en Windows Server (IIS) pero CSR request no fue creado en ISS.

·       Cuando se necesita el certificado para Windows Server pero no disponemos de IIS para generar CSR.

·     Cuando hemos creado CSR y guardado la clave privada, y necesitamos instalar el certificado en Windows Server.

·       Cuando tenemos el certificado Code Signing y necesitamos PFX para firmar.

Si, para ello podemos entre varias cosas realizar un ataque de diccionario con la herramienta: John The Ripper.

Para esto lo primero es preparar el archivo .PFX para que John lo entienda

Y ahora, dejamos que John haga su trabajo

 https[:]//www.ibm.com/docs/en/arl/9.7?topic=certification-extracting-certificate-keys-from-pfx-file

Es decir:

1.- Extraemos la clave privada del certificado contenido en el archivo PFX (sin crackear)

2.- Extraemos el certificado contenido en el archivo PFX

A partir de aquí ya podremos utilizar el certificado y la clave del mismo, sin haberla crackeado,  para lo que se pueda, como por ejemplo: intentar conectarnos al servicio SSH con el certificado extraído.

En cualquier caso

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