Categorías
Hacking Networking Programacion

Sliver – Command and Control multiplayer para Red Team – Parte 1 de 2

En este blog se han venido publicando posts relacionados con soluciones C2 y por supuesto, no podía faltar Sliver. Es un proyecto que actualmente se encuentra bastante activo y que sigue la misma filosofía de otras soluciones C2 pero como siempre, cada herramienta aporta elementos o características que le hacen ideal en contextos concretos. Conocer estas alternativas es importante ya que nunca se sabe qué cosas se encontrarán en el proceso de una campaña de Red Team o incluso de un pentest en el que el alcance de la auditoría es lo suficientemente amplio como para probar este tipo de herramientas y utilidades. En este orden de ideas, puede ser interesante revisar los siguientes posts antes de continuar leyendo.

Uso de Empire Framework contra sistemas Windows.
RedTeaming: Command and Control con Pupy Parte I
RedTeaming: Command and Control con Pupy Parte II
RedTeaming: Command and Control con Pupy Parte III
Post-explotación con Koadic: COM Command and Control basado en Windows Script Host.
Merlin – Command and Control sobre HTTP/2 y QUIC para Red Team
Entornos C2 sobre sistemas Windows con Shad0w: Evasión de mecanismos de seguridad – Parte 1 de 2.
Entornos C2 sobre sistemas Windows con Shad0w: Evasión de mecanismos de seguridad – Parte 2 de 2.
Entornos C2 sobre sistemas Windows con Shad0w: Uso de Beacons – Parte 1 de 2.
Entornos C2 sobre sistemas Windows con Shad0w: Uso de Beacons – Parte 2 de 2.

Instalación y uso de Sliver.

Ahora bien, Sliver es una herramienta que permite crear canales de comunicación con un C2 del tipo HTTP/HTTPS o DNS. La ventaja que tiene con respecto a otras soluciones radica en el proceso de compilación y ofuscación única que se realiza sobre cada uno de los payloads generados con la herramienta. Si bien es un proceso que lleva tiempo, los resultados pueden ser muy favorables de cara a la evasión de soluciones de seguridad perimetral, de hecho, se han realizado pruebas sobre Windows 8.1, Windows 10 y Windows Server 2019 debidamente actualizados y ninguno de estos sistemas ha detectado la muestra como maliciosa. Por otro lado, las conexiones que se reciben en un servidor de Sliver se pueden compartir con otros integrantes de una campaña gracias al modo multiplayer de la herramienta, esto viene estupendamente cuando se trabaja en equipo que es precisamente, como se suele trabajar en campañas de Red Team.
El primer paso para utilizar Sliver es levantar el servidor y para ello se puede descargar la última versión disponible desde la sección de RELEASES o compilar desde código fuente. Si se descarga la última versión disponible que ya se encuentra compilada y preparada en el repositorio de GitHub, solamente hace falta descomprimir, darle permisos de ejecución al fichero «sliver-server» y ejecutar. Nuevamente, como en muchas otras herramientas modernas para C2, aparece un interprete de comandos, en donde entre otras cosas, se puede generar un «implante» que no es más que la muestra maliciosa que se enviará a la máquina objetivo.

Lo primero que hay que considerar es que es un proceso que puede tardar varios minutos ya que genera un binario con los símbolos de ofuscación habilitados por defecto, lo que también significa que cada Sliver o implante será único y de hecho, se le asigna un nombre que estará registrado en el C2 (algo que recuerda a las etiquetas que genera Docker cuando se crea un nuevo contenedor). Cuando termina el proceso de compilación el binario se almacenará en la ruta indicada con un nombre asignado por la herramienta a menos que se indique lo contrario con la opción «-n». Como se puede ver en la imagen anterior, el comando «generate» es el encargado de producir los binarios y cuenta con varias opciones interesantes que se listan con «-h».

Es un comando muy completo en el que se pueden usar múltiples opciones a la hora de generar el implante, algunas de ellas aplican técnicas de evasión sobre el binario y permiten especificar el tipo de comunicación que tendrá el implante con el correspondiente listener, el cual puede ser HTTP(S)/MTLS o DNS. Como ocurre con cualquier solución del tipo C2 es importante levantar el listener correspondiente para recibir la conexión del implante. En la generación del binario que se ha enseñado en la primera imagen del post, se ha especificado que el listener es del tipo MTLS, por lo tanto se debe levantar este tipo de servicio antes de transferir y ejecutar el implante. Tan simple como ejecutar el comando «mtls» desde el interprete de Sliver.
Una vez hecho esto, se debe ejecutar el implante en el objetivo para recibir una nueva conexión y poder controlar dicho sistema.

A continuación se procede a interactuar con dicha sesión, basta con ejecutar el comando «sessions interact» y seleccionar la sesión concreta. A partir de ese punto, el interprete de Sliver se ubicará en la sesión correspondiente al sistema comprometido y se podrán ejecutar comandos sobre él.

Los comandos disponibles en cada sesión son los habituales. Es decir, instrucciones comunes que permiten enumerar el sistema y subir/descargar ficheros. Son características que tienen prácticamente todas las herramientas del tipo C2.

Pero ademas de estos comandos simples, también permite desplegar un shellcode en el sistema infectado para establecer un mecanismo de persistencia, impersonalizar un usuario autenticado, ejecutar la técnica de Reflective DLL sobre un proceso, usar el sistema como un pivote o incluso inyectar un payload de MSF. Estas son solamente algunas de las operaciones que se pueden llevar a cabo sobre el objetivo gracias a Sliver.

Es una herramienta que en el momento de redactar este post sigue en desarrollo, por lo tanto es posible que algunos comandos no funcionen como se espera o dejen de hacerlo puntualmente en el futuro. Son cosas que pasan. Aún así es un proyecto que suele ser bastante estable y una alternativa a tener en cuenta. En el próximo post se enseñará el modo «multi-player» de esta herramienta.

Un saludo y Happy Hack!
Adastra.

Categorías
Hacking Networking Programacion Web Applications

Merlin – Command and Control sobre HTTP/2 y QUIC para Red Team

Existen muchas soluciones orientadas a la implementación de entornos C2, algunas ya se han mencionado anteriormente en este blog, sin embargo una alternativa que resulta interesante para campañas de Red Ream es Merlin. Este programa se encuentra desarrollado en Go y tiene dos características que rápidamente llaman la atención: Es independiente de plataforma al estar escrito en dicho lenguaje y funciona sobre protocolo HTTP/2 y HTTP/3. Lo primero significa que es posible crear agentes que se desplegarán y funcionarán en cualquier sistema (ojo, otra cosa es la detección/evasión de los mecanismos de seguridad implementados en el sistema) y lo segundo que posiblemente aportará ciertas ventajas de cara a la evasión de soluciones de seguridad perimetral como los sistemas de detección de intrusos. El autor de esta herramienta ha escrito un par de artículos sobre esta herramienta hace algunos años en los que da una introducción a sus funcionalidades y las razones por las que el protocolo HTTP/2 es una buena alternativa a la hora de evadir mecanismos de inspección de tráfico. Aunque ambos artículos ya llevan tiempo publicados siguen siendo vigentes y el segundo, es especialmente interesante ya que además de explicar en detalle el funcionamiento de H2/H2C también menciona una de las características del protocolo que se encuentra definida en la RFC 7540 y es que se espera que todas las conexiones TLS entre cliente y servidor tengan habilitada una cipher suite que cumpla con el «PFS«, lo que a efectos prácticos dificulta la inspección de tráfico H2 (HTTP/2) y hace que las soluciones de seguridad perimetral que dependen del análisis de tráfico para su correcto funcionamiento (WAF, IDS o IPS) tengan problemas a la hora de detectar tráfico malicioso utilizando H2. De esto es precisamente de lo que intenta aprovecharse Merlin y la razón por la que su autor ha decidido crearla.
Llegados a este punto es interesante observar que esta herramienta, a la fecha de redactar este post, no solamente soporta HTTP/2, sino que también permite levantar un listener con HTTP/3 (QUIC) siguiendo la misma idea de usar un protocolo que no está del todo extendido y que muchas soluciones de seguridad perimetral no son capaces de procesar o interpretar adecuadamente.

Instalación del servidor de Merlin.

Tal como se indica en el fichero README disponible en el repositorio oficial del proyecto, existen 2 formas de instalar Merlin: Utilizando uno de los binarios preparados tanto para el servidor como para los agentes o instalar desde código fuente. La primera de ellas es la más sencilla y permite explorar la herramienta rápidamente sin tener que instalar GO y otras utilidades necesarias, será la alternativa para realizar las pruebas en este post.

Una vez lanzado el servidor por línea de comandos, lo primero que se debe hacer es iniciar un listener. Nuevamente, algo muy similar a herramientas que ya se han enseñado antes en este blog como es el caso de Empire Framework

Con el comando «listeners» se accede al menú principal, el cual permite listar y gestionar los listeners activos. En este menú se puede crear un nuevo listener fácilmente utilizando una de las plantillas disponibles con el comando «use», el cual admite las opciones «http» y «https» para protocolo HTTP/1.1, «http2» y «h2c» para protocolo HTTP/2 y «http3» para QUIC. Dependiendo del tipo de listener seleccionado se deben establecer una serie de opciones que en algunos casos son obligatorias y ya vienen con valores por defecto. Finalmente, se puede ejecutar el comando «start» o «execute» para lanzar el Listener.

Con el listener levantado es el momento de ejecutar un agente, que no es más que el sistema en el que se debe ejecutar la muestra maliciosa para recibir una sesión. Esta conexión será recibida en por el listener levantado previamente y permitirá ejecutar comandos contra la víctima. Nuevamente, el agente puede ser un binario preconfigurado o se puede compilar desde código fuente. Si se ha levantado el servidor de Merlin utilizando el binario disponible en la sección de «releases», al ejecutarlo se ha tenido que crear un directorio en <MERLIN_DIR>/data/bin en donde se encontrará el agente correspondiente a cada una de las arquitecturas soportadas por la herramienta.
Hay que tener el cuenta que el binario correspondiente al agente por defecto, está configurado para conectarse al servidor en la URL «https://127.0.0.1:443/» y utilizando «HTTP2». Por lo tanto, si se desea utilizar otro protocolo y el servidor está en otra IP (que es lo más habitual obviamente) se deben indicar esto en las opciones con «–url» y «-proto» tal como se explica en la documentación de Merlin aquí

Si el binario se ha ejecutado correctamente, se recibirá la conexión en el servidor de Merlin, la cual permitirá ejecutar diferentes tipos de instrucciones y controlar el sistema remotamente.

Como se puede ver en la imagen anterior, los comandos son simples y se explican perfectamente en la columna de descripción. De hecho, se podría decir que no es una herramienta tan potente como el payload de Meterpreter,  los agentes de Empire Framework o Pupy pero el hecho de poder establecer conexiones con protocolos como HTTP/2 o HTTP/3 (QUIC) es una característica muy interesante por las razones que se indicaban anteriormente. Es una herramienta en la que si bien, el agente no resulta muy interesante es un muy buen complemento para campañas de RedTeam en las que se deben llevar a cabo labores de evasión o exfiltración. Es algo muy similar a lo que se ha visto en el post publicado en este blog sobre Torat, aunque evidentemente en el caso de dicha herramienta la comunicación con el C2 es por medio de TOR.

Como se puede apreciar los comandos se ejecutan directamente sobre el sistema comprometido y en este caso la comunicación se realiza utilizando protocolo HTTP/3. Simplemente funciona. No hay que realizar ajustes muy complejos ni nada parecido. Se puede iniciar una captura de tráfico entre el agente y el servidor de Merlin para poder apreciar un continuo flujo de paquetes en ambos sentidos.

Se trata de una herramienta interesante que merece la pena incluir en el extenso arsenal de herramientas para campañas de Red Team o incluso (si el cliente lo permite) para alguna auditoría de pentesting.

Un saludo y Happy Hack!
Adastra.

Categorías
Hacking Services - Software Web Applications

Conoce el OWASP Web Security Testing Guide (WSTG)

Cuando se habla de pentesting sobre aplicaciones web casi todo el mundo automáticamente menciona el OWASP Top 10 y si bien es un proyecto genial, hay más «vida» en la comunidad OWASP además del Top 10. Lo cierto es que cuenta con proyectos fantásticos como ZAP del que ya he escrito hace algunas semanas en el post 5 funcionalidades interesantes en ZAP Proxy para Pentesting en aplicaciones web (aunque en realidad he listado 6). También cuenta con el proyecto Core Rule Set (CRS) para mod_security que ayuda a equipar mejor el servidor web ante posibles ataques o la aplicación web vulnerable por diseño Juice Shop la cual es probablemente uno de los mejores recursos libres para aprender las bases sobre pentesting web  y que se puede configurar con K8S para montar cosas como un cluster de «Juicy Shops» para entrenamientos, CTFs o competiciones. Todos estos proyectos son bastante conocidos pero el  Web Security Testing Guide (WSTG) probablemente es el menos sonado, posiblemente debido a que no es una guiá tan «ligera» como el OWASP Top 10, pero en mi opinión igual de importante o incluso puede que más, por ese motivo existe este post.

El WSTG es un manual bastante completo que no solamente cubre cuestiones relacionadas con el pentesting en aplicaciones web, sino que además su enfoque es integrador y pretende aportar una visión global de la seguridad de una aplicación web desde sus cimientos, considerando el desarrollo seguro como uno de los procesos más importantes (o puede que el más importante) en la seguridad de cualquier aplicación web. En la guía del OWASP Top 10 también se tiene el cuenta el desarrollo seguro, pero desde luego su enfoque se centra en la definición de actores, amenazas, factores de riesgo, prevalencia de las vulnerabilidades y su explotabilidad. Esto significa que no especifica con demasiada profundidad las cuestiones técnicas que hay que considerar a la hora de crear software y probar sus funcionalidades desde el punto de vista de la calidad y seguridad.

Contenidos y estructura de la guía WSTG.

En primer lugar el proyecto y por supuesto, la guía propiamente dicha se encuentra disponible aquí. En la introducción se explica que se trata de una guía completa con buenas prácticas para desarrolladores y profesionales de la seguridad que se deben de tener en cuenta para cumplir con su rol. Se plantean una serie de cuestiones importantes desde el punto de vista técnico y funcional como ocurre en el OWASP Top 10, pero con un nivel de detalle mucho más amplio tal como se puede ver en el índice y en cada uno de los apartados de la guía. Las secciones del documento se detallan a continuación y se expone un breve resumen sobre qué incluyen.

  1. Bienvenida, licencia e integrantes del proyecto.

    Es una sección muy corta en la que detalla una pequeña introducción sobre la guía, su licenciamiento (Creative Commons 4.0) y las personas que aportan al proyecto. Tal como se puede apreciar, hay aproximadamente unas 30 personas que colaboran en los contenidos de la guía.

  2. Introducción.

    En esta sección se detallan conceptos básicos sobre desarrollo de software y revisión de código, así como metodologías orientadas al SDLC y el enfoque que se le debe dar a las pruebas de intrusión en entornos web. Las ideas expuestas en esta sección son especialmente interesantes ya que hablan de problemáticas comunes en equipos de desarrollo, en los que desafortunadamente no se prueba adecuadamente lo que se desarrolla hasta que se llega a una etapa critica (que es precisamente la de entrega o pase a producción). Además, hace énfasis en los activos que hay que probar y cómo hacerlo: Personas, Procesos y Tecnología. En la guía afirman que sin un enfoque holístico no se puede medir adecuadamente el riesgo de una aplicación debido a que las vulnerabilidades pueden presentarse de diferentes formas y en diferentes fases operativas. Por otro lado, aparece una sección en la que se habla sobre la gestión de la conocida «ventana de riesgo».

  3. OWASP Testing Framework.

    En esta sección de la guía se describe el framework de testing que se puede implementar, definiendo cada una de las etapas de construcción del software, empezando por las fases iniciales correspondientes a la recolección de requisitos y diseño pasando por las etapas de desarrollo y despliegue hasta la puesta en producción, operaciones y mantenimiento del software. Esta es una de las secciones más importantes de la guía ya que en ella se definen una serie de buenas prácticas que, cualquiera que haya estado en un equipo de desarrollo, ha visto como muchas de ellas NO se aplican o se aplican de manera incompleta/incorrecta.

  4. Web Application Security Testing.

    En esta sección es la más extensa de todo el documento y precisamente la que más valor aporta a un técnico, ya que se detallan las pruebas que se deben realizar en 12 secciones claramente definidas y acotadas. Las pruebas que se indican pueden aplicar a cualquier aplicación web independiente de su tamaño, diseño o funcionalidad y van más allá de las típicas pruebas de seguridad que se definen en el OWASP Top 10. Estas secciones describen con todo lujo de detalle, lo que hace cualquier pentester cuando debe ejecutar una auditoría web, con casos prácticos, herramientas y ejemplos muy bien documentados. Las secciones son las siguientes:

    1. Information Gathering.
    2. Configuration and Deployment Management Testing.
    3. Identity Management Testing.
    4. Authentication Testing.
    5. Authorization Testing.
    6. Session Management Testing.
    7. Input Validation Testing.
    8. Testing for Error Handling.
    9. Testing for Weak Cryptography.
    10. Business Logic Testing.
    11. Client Site Testing.
    12. API Testing.
  5. Reporting

    En la última sección se habla de los detalles a tener en cuenta en el reporte que se debe entregar al finalizar una auditoría. Esta sección es interesante ya que indica cada uno de los elementos que incluye un informe profesional y orientado a enseñar la calidad de los trabajos realizados. Incluye algunas referencias en donde se explica cómo estructurar adecuadamente dicho documento que pueden ser útiles.

  6. Apéndices.

    Por último, pero no menos importante, se encuentran los apéndices en donde enumeran un conjunto de herramientas básicas para hacking web, lecturas recomendadas, referencias externas a vectores/técnicas de ataque y utilidades tanto para desarrolladores como para pentesters.

 

Si bien el OWASP Top 10 es una estupenda referencia metodológica para llevar a cabo pentesting web, lo cierto es que se queda «corta» cuando se trata de aplicaciones web modernas y que han aplicado unos mínimos de seguridad. Por ejemplo, si la aplicación web se ha desarrollado con un Framework de desarrollo reciente (y sin ninguna vulnerabilidad conocida) posiblemente las vulnerabilidades de inyección típicas como SQLi o XSS serán menos frecuentes y probablemente, los desarrolladores utilizarán las características propias del framework para el acceso a datos en lugar de utilizar, por ejemplo, SQL de forma directa (algo habitual si se utiliza un ORM como JPA, Hibernate, el entity framework de .Net o los models de Django). Las aplicaciones modernas requieren que el pentester aplique un enfoque orientado a realizar las pruebas en profundad y esto es precisamente lo que promueve la WSTG. Tanto si como si eres desarrollador o pentester, es una guía que merece la pena conocer en detalle y un estupendo recurso para mejorar conocimientos y habilidades técnicas.

Un saludo y Happy Hack!
Adastra.

 

Categorías
Programacion Services - Software

GitHub Actions para publicación de imágenes de Docker

En esta ocasión, vamos a explorar el servicio GitHub Actions. Se trata de un servicio de CI que nos ofrece GitHub de forma gratuita. La ventaja de usar este servicio es que nuestro código queda integrado con nuestro CI y puede interactuar directamente con otras funciones de GitHub.

En este caso, empezaremos explorando los conceptos básicos para el uso de esta herramienta y veremos cómo publicar nuestras imágenes de Docker en el registry de Docker.io.

Conceptos básicos de GitHub Actions

GitHub Actions usa lo que se define como workflows. Un workflow es un proceso automatizado configurable formado por uno o más trabajos. Cada workflow se compone, como mínimo, de dos secciones:

  • Triggers: Usando la palabra reservada on, definimos los eventos en los que un workflow se debe ejecutar. Por ejemplo, por cada commit sobre una rama, por cada pull-request, cada vez 5 minutos, etc. Accede aquí para consultar todas las posibilidades.
  • Jobs: Usando la palabra reservada jobs, indicamos lo que queremos ejecutar, donde lo queremos ejecutar, dependencias con otros jobs, etc. Cada job se compone de steps, es decir, módulos o acciones que componen el job y que se ejecutarán secuencialmente. Accede aquí para consultar el catálogo de acciones que se pueden usar.

Workflow «Hello World»

Lo primero que tenemos que hacer es crear el directorio .github/workflows/ en la raiz de nuestro repositorio. Todos los ficheros con extensión .yml serán procesados automáticamente por GitHub. Veamos un ejemplo:

Podemos hacer las siguientes observaciones:

  • Triggers: Se ejecutará cuando se realice un push sobre la rama helloworldbranch o cuando lo lancemos a mano.
  • Jobs: solo tenemos un job llamado my_hello_world_job. En el primer step, nos descargamos el repositorio y, en el segundo step, ejecutamos comandos.
Veamos nuestro workflow en acción:
$ git checkout -b helloworldbranch
$ git add .
$ git commit -m 'Workflow Hello World'
$ git push origin helloworldbranch

Nada más subir el cambio, vemos que en GitHub se ha ejecutado el workflow:

Uso de GitHub Actions para contruir y publicar imágenes de Docker

Ya hemos visto cómo podemos crear un workflow para hacer tareas automatizadas. Una tarea muy común es construir imágenes de Docker y subirlas a un registry. Supongamos que la imagen que queremos a construir se basa en el siguiente Dockerfile:

FROM python:3-slim
RUN mkdir /app && echo '<h1>Hello World!</h1>' > /app/index.html
WORKDIR /app
EXPOSE 8000
ENTRYPOINT [ "python3", "-m", "http.server", "8000" ]
Para la construcción y publicación de esta imagen, usaremos las siguientes acciones:
  • actions/checkout@v2: Nos permitirá descargar el código en el runner de GitHub Actions.
  • docker/login-action@v1: Lo usaremos para autenticarnos en el registry. Por defecto, se usa el registry de Docker.io, pero podemos indicar otro registry.
  • docker/build-push-action@v2: Nos permitirá construir la imagen y publicarla en el registry.

Adicionalmente, la versión v2 de la acción build-push-action usa buildx por lo que debemos ejecutar en steps previos dos dependencias (se indica en la documentación):

  • docker/setup-qemu-action@v1
  • docker/setup-buildx-action@v1

Con todo esto, nuestro workflow quedaría del siguiente modo:

Una vez subidos los secretos DOCKERHUB_USERNAME y DOCKERHUB_TOKEN al repositorio para la autenticación en el registry, podemos subir los cambios a la rama main. En este momento es cuando vemos que se ha ejecutado el workflow correspondiente al trigger de la rama main y que ha provocado la subida a Docker.io la imagen con la tag latest, como definimos para la rama main:

Ahora, si ponemos la tag v0.0.1 en el último commit (puntero HEAD), podemos ver que el workflow nos ha generado la imagen correspondiente a esa tag:

$ git tag v0.0.1 HEAD
$ git push --tags

Conclusiones

Existen múltiples herramientas de CI como pueden ser Jenkins, TravisCI, CircleCI, etc. Sin embargo, estas herramientas están conceptualmente separadas del código. La gran ventaja de tener el entorno de CI integrado con los repositorios es la gran versatilidad que tenemos a la hora de gestionar triggers, interactuar con issues y pull requests, etc.

Además, otra de las grandes ventajas de usar GitHub Actions es la cantidad de acciones que tenemos a nuestra disposición en el Marketplace para simplificar la sintaxis de nuestros workflows.

Como resumen, GitHub Actions es una solución de CI gratuita (hasta ciertos límites), se puede usar sin necesidad de tener infraestructura propia, con un abundante catálogo de acciones y con una gran integración con tus repositorios de GitHub. ¿Qué razón hay para no usarlo?

Álvaro Torres Cogollo.

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

 
Categorías
Hacking MetaSploit Networking Services - Software Web Applications

10 posts en TheHackerWay que te han interesado.

Precisamente con este post se completan los 500 artículos en este blog y viendo el tráfico que han generado las entradas, he decidido darle un repaso a las que más visitas han tenido desde sus inicios. Personalmente no son las que más me gustan ya que hay otras que me molan más por el nivel técnico que tienen y por el trabajo que he impreso en ellas, pero estas son las entradas que más reacciones y visitas han generado, por lo tanto merece la pena darles «cariño» y pulir cosas que se han quedado obsoletas o no aplican ya que algunos de estos posts datan de los años 2011/2012 y claro, mucho ha llovido desde entonces. Dicho esto… Aquí va.

1. 10 Sitios en la deep web que podrían interesarte – Parte 1 de 3.

La primera parte de esta serie de 3 posts relacionados con sitios onion que podrían ser interesantes y que han tenido cierta continuidad, aunque siempre hay que tener en cuenta que dada la «alta volatilidad» que tienen los contenidos en TOR es posible que en algunos meses, días o puede que horas, algunos de estos sitios ya no estén disponibles por diferentes motivos. Hay que tener esto en cuenta cuando se navega por los Hidden Services disponibles en TOR.

 

2. 10 Sitios en la deep web que podrían interesarte – Parte 2 de 3.

En este segundo post de la serie nuevamente he removido algunos sitios que ya no están disponibles desde hace algún tiempo y los he sustituido por otros que sí lo están. De hecho, del listado de 10 sitios, solamente se ha quedado 1 que sigue operativo aunque ya han pasado varios años, el resto han ido cayendo poco a poco por diferentes motivos y ahora mismo no se encuentran accesibles. La actualización de este post incluye por tanto, 9 servicios ocultos «nuevos» que pueden resultar interesantes desde un punto de vista práctico o académico.

 

3. 10 Sitios en la deep web que podrían interesarte – Parte 3 de 3.

10 sitios más para hacer un total de 30, los cuales se encuentran activos y pueden resultar interesantes o como mínimo, despertar curiosidad.

 

4. Hydra, Ataques de Fuerza Bruta

En este post se hablaba de la versión 6 de THC Hydra, lo he actualizado incluyendo más capturas de pantalla para facilitar la comprensión de lo que se explica, además se habla de la última versión disponible a la fecha de redactar este post y las opciones que incluye.

 

5. Conceptos Basicos de Meterpreter – MetaSploit Framework

Algunas instrucciones se han removido en los últimos años y como es natural, el payload de Meterpreter ha ido madurando. Este post lo he escrito hace cerca de 10 años, es un buen momento de reflejar en él las características más básicas y de uso común de este payload. En esta actualización del post he incluido imágenes que son mucho más fáciles de entender que el texto de los comandos y su salida.

 

6. Wireless Hacking – Descubriendo APs con SSID ocultos y evadiendo Mac Filters – Parte IV

En realidad han sido pocos los ajustes que he hecho en este post, simplemente le he puesto algunas referencias a otros artículos y contenidos externos. También he corregido alguna frase para que se comprenda mejor. Es un post básico sobre redes wireless y puede ser interesante para el descubrimiento de un SSID oculto.

 

7. Preservando el Anonimato y Extendiendo su Uso – Conceptos Esenciales de TOR – Parte I

Ha sido el primer post que publique hace casi una década sobre la serie de anonimato en TOR, lo que unos años después me ha permitido escribir un libro sobre DeepWeb en 0xWORD. También he aplicado algunos cambios para mejorar este post ya que se hace referencia a software que a día de hoy ya no se utiliza, como es el caso de Vidalia y TorButton.

 

8. Comandos y Conceptos Básicos MetaSploit Framework

En este post se explica el uso más básico de Metasploit Framework, se incluye una lista de comandos habituales y se explican algunas formas de interactuar con el Framework. Es una entrada publicada en el año 2011, por lo tanto merecía la pena quitar algunas cosas que se han quedado obsoletas desde hace varios años y reflejar un poco lo que se encuentra disponible actualmente.

 

9. Conceptos Básicos de Nikto – Técnicas de escaneo de Servidores y Aplicaciones Web

Aunque Nikto es una herramienta que ha tenido poco movimiento en los últimos años, es interesante conocer las técnicas de escaneo disponibles para analizar servidores web y en este post, se explican algunas de ellas desde un punto de vista práctico y enseñando los posibles valores que recibe cada técnica por línea de comandos.

 

10. Uso práctico de John The Ripper

Este post es bastante extenso pero interesante, dado que JTR es de esas herramientas que se suelen lanzar y «dejar que hagan lo suyo», sin embargo conocer las opciones que tiene disponibles ayuda a afinar un poco más esas ejecuciones y sacar los mejores resultados posibles. Nuevamente se trata de un post que he escrito hace varios años y que le hacia falta un repaso, ahora creo que ha quedado bastante bien y que puede ser útil para aprender a usar la herramienta.

Esto es todo, seguiré revisando posts que he ido publicando en los últimos años y que ahora se encuentran desactualizados o simplemente lo que se explica ya no es valido/no funciona. En todo caso, cualquier sugerencia es bienvenida para mejorar la calidad de los contenidos que registramos en este sitio (que hay otros colaboradores que también escriben aquí y merecen todo el reconocimiento por compartir lo que saben). 🙂

Un saludo y Happy Hack!
Adastra.

 

Categorías
Hacking Networking Programacion

20 Lecciones que aprendes cuando participas en campañas de Red Team.

Hay una serie de cuestiones que se van aprendiendo cuando se trabaja en auditorías de red, pentesting o en campañas de Red Team con equipos profesionales. Lecciones que a veces se nos pasan o simplemente las desconocemos en ese momento. Este post no pretende «sentar cátedra» ni mucho menos ya que en el mundo de la informática y muy concretamente en la ciberseguridad, son muchos los conocimientos que debes tener para considerarte experto y yo, desde luego, no me considero uno. Son muchas las cosas que desconozco y quiero aprender, pero creo que lo más importante es tener una actitud abierta y flexible. No dejar de investigar y no caer en la falacia de que se «es un crack», por mucho que otras personas lo repitan todo el tiempo. Dicho esto, las siguientes reflexiones reflejan cómo ha sido mi experiencia profesional hasta este momento. Ya sé que «nadie aprende en cabeza ajena», pero a lo mejor pueden ser consideraciones útiles para quien las quiera leer.

  1. Que el alcance se encuentre muy bien acotado y con las restricciones por escrito. Desde el minuto 0 es importante estar en un contexto legitimo y que el equipo sepa qué cosas NO se pueden hacer, de esta manera ante cualquier eventualidad o discrepancia con el cliente se puede utilizar ese documento para evitar males mayores.
  2. Se necesita invertir dinero. Es necesario contar con recursos suficientes para adquirir licencias, desplegar software, comprar herramientas o incluso dispositivos para llevar a cabo la campaña. Esto es algo que se debe estimar antes de generar un presupuesto, no vaya a ser que te pilles los dedos.
  3. Fuera egos y/o complejos. Los equipos que mejor funcionan son aquellos que trabajan al unísono y con una impecable coordinación para conseguir un objetivo común. Esto es así en todo y no solamente en proyectos de seguridad informática. Todos los integrantes del equipo deben aportan y cumplir sus funciones. Sin arrogancia ni soberbia, sin complejos o dudas. Sin excusas.
  4. Las campañas de Red Team las emprenden equipos de personas, no «lobos solitarios». Si bien es cierto que hay personas que a nivel técnico son excepcionales, es posible que una sola persona no pueda cubrir todas las etapas y actividades que se deben llevar a cabo en una campaña de Red Team. Esto es especialmente cierto cuando el «target» es una empresa u organización con una infraestructura robusta y bien definida.
  5. Las campañas de Red Team requieren coordinación. Requieren compromiso por parte de todos los integrantes y seguir las directrices que se han establecido para alcanzar el objetivo fijado. Por supuesto, la persona que se encarga de planificar debe tener dotes de líder y no de «jefe que delega» o «maestro del látigo». Los mejores lideres, los que mejor aceptación pueden llegar a tener en un equipo son aquellos con un perfil técnico y que apoyan a los integrantes con su trabajo, no esos que en lugar de aportar soluciones aportan más problemas.
  6. Planificar en cada etapa. Muy especialmente en las campañas de Red Team en las que no sabes qué te vas a encontrar en cada paso. Hay que definir una serie de pautas de actuación y sobre todo, adaptarse a las situaciones. El plan puede cambiar en el transcurso del engagement en función de lo que se vaya viendo en cada fase del proceso.
  7. Nunca se debe subestimar la información obtenida en la etapa de reconocimiento. Esto es interesante en campañas de Red Team en donde se busca comprometer el objetivo probando diferentes vías de acceso. En este sentido, la aplicación correcta de técnicas de ingeniería social como la elicitación y los pretextos suponen una buena alternativa para conseguir esa primera shell.
  8. Conocer los deseos y miedos del objetivo. Relacionado con el punto anterior, en un equipo de Red Team se necesitan expertos en ingeniería social (dependiendo del alcance y restricciones de la campaña, por supuesto) y estas personas utilizarán la información recolectada para descubrir qué es lo que desea y teme el objetivo. De esta manera será mucho más fácil elaborar pretextos que producirán los resultados esperados.
  9. Un equipo de Red Team suele estar conformado por especialistas. En este tipo de actividades se requiere perfiles muy específicos. Algo similar a lo que se puede ver en equipos de desarrollo en donde hay personas que están involucradas en el diseño y arquitectura de soluciones, implementación del backend o del frontend entre otras cosas. En un equipo de Red Team puede ser común encontrar integrantes que se especializan en temas como el reversing o el desarrollo de malware, en despliegues de infraestructuras para la campaña, en recolección de información y definición de los escenarios para ingeniería social, pueden haber expertos en hacking web, redes inalámbricas o hacking en dispositivos móviles. Como se ha mencionado antes, las campañas de Red Team de cierto tamaño requieren equipos, no hombres orquesta.
  10. Canales de comunicación seguros y anónimos. Esta puede ser una de las prioridades en una campaña dependiendo de sus características. Para ello es importante montar una infraestructura que mantengan el anonimato de cada uno de los integrantes del equipo. En este sentido una buena opción consiste en montar servidores VPN propios así como enrutar el tráfico por medio de TOR. Esto, de hecho, hace parte de las labores de «pre-engagement».
  11. Se cuenta con un solo disparo: Hay que apuntar bien. Un ataque informático es como disparar un arma de fuego, es una acción que puede generar mucho ruido y poner en alerta al objetivo, por lo tanto antes de «disparar» es importante asegurarse de que el impacto será certero y se conseguirá la meta de comprometer el sistema sin afectarlo o inquietar al usuario. Por ejemplo, si en la campaña se contempla la aplicación de técnicas de ingeniería social y se pretende aplicar un ataque del tipo «client-side», es vital conocer versiones de software y el sistema operativo de la víctima para reproducir fielmente dicho entorno y realizar pruebas. Cuanta más información se tenga sobre el objetivo mejor, eso significa «apuntar bien».
  12. Movimientos rápidos y precisos. Una vez se consigue acceso hay que tener un plan preparado. Hay que tener «una guía de actuación» con aquellas actividades que se deben realizar, hacerlas rápidamente y bien. El motivo de esto es que normalmente no se sabe cuánto tiempo pasará hasta que se detecte la intrusión, si hay alguien vigilando o si por cualquier otro motivo se perderá el acceso. En dicha guía se definen las directrices que debe seguir el equipo y sus prioridades. Por ejemplo, es posible que lo más importante sea pivotar a una red local cuanto antes para extender el engagement por toda la red de la víctima o a lo mejor el foco debe centrarse en explotar todas las posibles vulnerabilidades en el sistema comprometido. En cualquier caso, no se puede decir «vale, he comprometido el objetivo, y ahora qué hago?». Esa pregunta ya debería de estar contestada desde mucho antes de comprometer el sistema.
  13. Hay que conocer el noble arte de programar. Y hacerlo muy bien. Esto es algo que he debatido con muchas personas y sigo sosteniendo que no puedes considerarte un hacker si no sabes programar. No puedes decir que eres un hacker si no tienes la capacidad de crear, si no sabes construir o si son otros los que lo hacen por ti ya que tu no cuentas con las aptitudes y/o conocimientos para hacerlo. No son pocas las veces en las que hay que desarrollar rutinas, herramientas o exploits que permitan aprovecharse de una vulnerabilidad o extraer información, si no cuentas con esas habilidades siempre te quedarás a medio camino o dependerás de un tercero que sí pueda hacerlo. Saber programar en Pentesting o Red Teaming es tan importante como saber moverse por un sistema Linux.
  14. A veces es preferible exfiltrar primero y elevar después. Dependiendo de los objetivos de la campaña es posible que resulte conveniente exfiltrar la mayor cantidad de información a la que se pueda acceder, esto también hace referencia al punto anterior. Hay que tener un plan bien definido, eso es precisamente lo que hace un equipo rojo. Una buena estrategia y plan de acción es fundamental.
  15. Si un C2 has de instalar… Es posible que instalar una herramienta de este tipo en el objetivo no sea la mejor opción especialmente en entornos maduros, pero si es lo que se debe hacer, mejor que sea uno muy liviano aunque no sea tan potente en funcionalidades como Meterpreter, Pupy o cualquier otro y en la medida de lo posible anónimo o sin exponer de ninguna manera información real de cualquiera de los integrantes de la campaña. Posiblemente una buena alternativa puede ser Torat o el Offensive Tor Tookit del que ya se ha hablado anteriormente en este blog, en cualquier caso si un C2 has de instalar, que no sea uno fácil de detectar o que active alarmas en el objetivo. Es posible que haya que crear uno especifico para el objetivo en cuestión, aprende el noble arte de programar.
  16. Los mecanismos de persistencia instalados deben ser sutiles. Y además, se deben desplegar casi al final de la campaña y eso suponiendo que sea uno de los objetivos de la misma. Aunque es posible aplicar algunas técnicas de persistencia sin contar con privilegios elevados, es posible que sean fácilmente detectadas por los mecanismos de seguridad perimetral instalados en el objetivo. Es mejor tener la posibilidad de controlar completamente dicho sistema para aplicar las excepciones de seguridad adecuadas, las cuales permitirán desplegar rutinas o backdoors sin que generen alarmas.
  17. Una correcta limpieza del entorno. Y esto no siempre es lo típico de «limpia logs, elimina herramientas o ficheros subidos, deja los servicios funcionando correctamente, etc». Dependiendo de la guía de actuación definida, es posible que se busque desviar la atención. Hay sistemas en los que es muy difícil eliminar todas las trazas que se van dejando, por lo tanto se pueden dejar señuelos o pistas falsas. Esto a efectos prácticos puede significar envenenar los logs con eventos que no han ocurrido, subir ficheros o exploits escritos en un lenguaje concreto y preferiblemente escritos por una persona nativa, dejar conexiones establecidas con dominios o hosts que nada tienen que ver con la campaña e incluso, dejar indicios de que se trata un ataque realizado desde el interior de la organización.
  18. Hay que demostrar «la valía». Dependiendo del tipo de trabajos que se están realizando debe de haber un informe en donde se demuestre qué cosas se han hecho y cuáles han sido los descubrimientos. Esta es la forma clásica en la que se justifica al cliente los trabajos realizados y en cierta forma, por lo que paga. No obstante, hay campañas en las que los talentos del equipo se demuestran de otras formas, por ejemplo por medio de la información que se consigue exfiltrar, el acceso a secciones restringidas o el control de sistemas que se ejecutan en el entorno del objetivo. En cualquier caso el trabajo hecho siempre se debe evidenciar, no solamente basta con decir que «el equipo es muy bueno y está conformado por los mejores».
  19. Compañeros discretos y leales. Dado que las tareas a ejecutar en ocasiones son delicadas se exige profesionalidad y responsabilidad por parte de todos los integrantes. Esto significa que las personas que conforman el equipo no solo deben ser muy buenas técnicamente, sino que además deben ser personas en las que se pueda confiar.
  20. Mejor creer en lo que se hace. Cada integrante del equipo busca obtener un beneficio económico, esto en un hecho evidente. Sin embargo, es mejor buscar un impulso extra que esté relacionado con otros estímulos igual de importantes. Por ejemplo, el deseo por aprender algo o mejorar habilidades, participar en un proyecto interesante, hacer crecer un negocio que servirá de sustento a varias familias, colaborar con otras personas que buscan la misma meta, promover o afianzar una idea con la que los integrantes se sienten identificados, etc. Pueden ser motivaciones muy fuertes que para algunas personas llegan a ser más importantes que el dinero. Cada proyecto tiene una finalidad, se hace por un motivo y esto en las campañas de Red Team también aplica por eso es mejor creer en ese propósito. Es mejor creer que todo lo que se hace tiene un sentido, que no es algo inútil.

Un saludo y Happy Hack!
Adastra.

Categorías
Hacking Networking Services - Software

Entornos C2 sobre sistemas Windows con Shad0w: Uso de Beacons – Parte 2 de 2.

Este es el último post sobre el análisis a la herramienta Shad0w en el que se verá en más detalle el uso de los Beacons sobre sistemas Windows Server 2019 debidamente actualizados. Las referencias a los post anteriores se listan a continuación para entender lo que se ha hecho anteriormente y seguir el hilo de este artículo:

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

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

Entornos C2 sobre sistemas Windows con Shad0w: Uso de Beacons – Parte 1 de 2.

El Beacon de Shad0w sobre Windows Server 2019 actualizado.

Curiosamente en sistemas Windows Server 2019 los Beacons generados por Shad0w funcionan correctamente, tal como he explicado en post Entornos C2 sobre sistemas Windows con Shad0w: Evasión de mecanismos de seguridad – Parte 2 de 2. Partiendo de una sesión activa en dicho sistema se ha procedido a realizar pruebas con los comandos disponibles.

Comandos básicos de enumeración

Como ocurre con prácticamente todas las herramientas de post-explotación orientadas al «Command and Control», Shad0w cuenta con un conjunto de instrucciones que permiten enumerar el sistema rápidamente. Estos comandos permiten moverse por el sistema de archivos, crear directorios o ficheros y consultar información básica sobre la cuenta de usuario que se está utilizando para acceder al sistema.

Son comandos muy simples e intuitivos, pero hay que recordar que la herramienta responde de forma «asíncrona» a los comandos enviados, lo que significa que para no hacerse un lío con los resultados que devuelve la herramienta es conveniente esperar un poco, darle tiempo para que devuelva la salida correspondiente al último comando ejecutado.

Comandos para gestión de procesos y migración del Beacon

También cuenta con algunas instrucciones básicas para listar los procesos en ejecución y ver el proceso en el sistema comprometido que corresponde al Beacon.

Se trata de comandos simples y directos que permiten conocer el estado del sistema en ese momento y por supuesto, ver si existe la posibilidad de migrar a un proceso más estable o robusto. Esto último recuerda a Meterpreter ya que el Beacon de Shad0w también depende completamente de un proceso activo en el sistema y se ejecuta completamente en memoria, si dicho proceso muere la sesión también lo hará. En Shad0w existen algunos comandos que permiten: Migrar a otro proceso (migrate), Inyectar una copia del Beacon a otro proceso (binject) o inyectar un shellcode crudo (shinject) o una DLL en un proceso (dllinject). Para cada una de estas opciones hay un comando disponible en el interprete del Beacon.

Comandos para Post-explotación

Algunas instrucciones ayudan en el proceso de post-explotación en sistemas Windows que se debe llevar a cabo una vez se consigue acceso al sistema. Entre otras cosas, se encuentra disponible el comando «elevate» que incluye un exploit que intenta comprobar si la cuenta de usuario cuenta con el token SeImpersonate y si es el caso, intentar aprovecharse de dicha situación para elevar privilegios. A la fecha de redactar este post solamente está disponible dicho exploit y lo cierto es que no funciona siempre.


Por otro lado el comando «meterpreter» permite ejecutar en la memoria del proceso donde se ejecuta el Beacon un payload de Metasploit Framework, concretamente alguno de los de Meterpreter. Es una buena forma de obtener una sesión meterpreter y poder interactuar con el sistema utilizando todas las herramientas disponibles en Metasploit Framework, además el comando es bastante sencillo ya que basta con seleccionar el payload adecuado, establecer el host y puerto en donde se encuentra el handler de MSF en ejecución, lanzar y recibir la conexión.


Shad0w también cuenta con un soporte muy interesante a PowerShell, no solo para crear y/o ejecutar modulos o instrucciones en el sistema comprometido, sino que además se han implementado las herramientas disponibles en el proyecto GhostPack

Otro comando que resulta interesante y que nuevamente, se encuentra integrado en muchas herramientas similares a Shad0w es «mimikatz» el cual hace referencia a la herramienta del mismo nombre. Evidentemente, se trata de una herramienta que funcionará mejor si se cuenta con los privilegios adecuados para acceder a procesos y secciones de memoria sensibles.

Existen otras instrucciones adicionales que apoyan en cosas tan interesantes como la descarga o subida de ficheros o movimientos laterales por medio del establecimiento de servidor proxy y en el caso de Windows Server 2019, lo mejor de todo ha sido que no se ha quejado en ningún momento. Se han podido ejecutar todas y cada una de las instrucciones sin que los mecanismos de seguridad incluidos en el sistema detectarán la intrusión o interrumpieran la interacción del atacante.

Espero que el análisis de esta herramienta te haya parecido interesante o útil. Si es el caso, dale a compartir y escribe un comentario. 🙂

Un saludo y Happy Hack!
Adastra.

Categorías
Hacking Networking Services - Software

Entornos C2 sobre sistemas Windows con Shad0w: Uso de Beacons – Parte 1 de 2.

En los otros dos posts anteriores sobre Shad0w he realizado un análisis sobre las capacidades de evasión que tiene esta herramienta y los resultados han sido bastante satisfactorios sobre sistemas Windows actualizados y con versiones recientes o no, ya que solamente se ha probado la evasión y conexión con el C2, ahora es el momento de probar los beacons en funcionamiento. Si te los has perdido puedes leerlos aquí:

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

Hay que verificar si el funcionamiento de los Beacons es el esperado y si en algún momento durante su ejecución, son detectados por parte del sistema objetivo, teniendo en cuenta que como se ha mencionado anteriormente, el sistema se encuentra debidamente actualizado.

El Beacon de Shad0w sobre Windows 8.1 actualizado.

Lo primero, evidentemente, es generar el beacon, transferirlo a la víctima y ejecutarlo, lo cual permitirá generar una nueva sesión en el C2 de Shadow. Tal como se ha visto en el post anterior, los beacons generados en formato EXE han sido detectados rápidamente por Windows Defender, sin embargo en el caso del beacon en formato PowerShell se ha conseguido la evasión correctamente.

 

Existen algunos comandos básicos para interactuar con la máquina comprometida y que son precisamente los que ayudarán a probar que efectivamente, el payload que se está ejecutando en la víctima pasa desapercibido y no se detecta por parte del Windows Defender. Y este es el punto en el que me he llevado las manos a la cabeza:

Muy bien, supuestamente hay una conexión con el objetivo pero los comandos ejecutados no devuelven ningún resultado lo que significa a efectos prácticos, que aunque se han evadido las restricciones impuestas en el sistema objetivo el beacon resulta completamente inútil.
¿Cuál es el motivo de esto? como se ha comentado en el post anterior, a la hora de ejecutar el fichero PS1, el entorno de Powershell arroja un error y detiene su ejecución justo después de que se establece la conexión con el C2. Por lo tanto, el handler de Shad0w asume que hay una conexión establecida pero a la hora de intentar ejecutar cualquier comando que se le indica, simplemente no obtiene ninguna respuesta. Con las pruebas realizadas en los posts anteriores ninguno de los binarios generados («staged» y «static») era capaz de evadir las restricciones de seguridad del sistema, por lo tanto y muy a mi pesar, podría afirmar que Shad0w no tiene el mejor de los resultados en un sistema Windows 8.1. Y ojo, cambiando la frase que más he escuchado a amigos y conocidos («En mi local funciona»), diré que esto «En mi local NO funciona», lo que significa que puede que «En tu local funcione», así que te animo a lo que pruebes y si obtienes unos resultados distintos escribas un comentario en este post.

 

El Beacon de Shad0w sobre Windows 10 actualizado.

Nuevamente, se genera un beacon del tipo «staged» ya que como se ha comentado en los post anteriores, Windows 10 actualizado y con las medidas de seguridad activas, era capaz de detectar la muestra en formato PS1 y un binario PE con todas las instrucciones incluidas en él (static). Una vez recibida la conexión por parte del sistema objetivo se puede comprobar que a diferencia de lo visto en Windows 8.1, con esta sesión sí que se puede trabajar y ejecutar los comandos disponibles en los Beacons de Shad0w.

Una de las primeras cosas a tener en cuenta cuando se interactúa con los Beacons de Shad0w es que su comportamiento es muy similar a los agentes en Empire Framework ya que se ejecuta una instrucción y no hay que esperar la respuesta, ésta llega después de forma asíncrona. Esto puede ser confuso ya que en ocasiones los resultados de los comandos ejecutados tardan en llegar y se solapan con otras instrucciones que se están ejecutando en ese preciso momento o incluso, puede ocurrir que nunca llegue una respuesta a un comando ejecutado previamente. «Es lo que hay». Por otro lado, aunque en términos generales el Beacon funciona correctamente y se mantiene activa la sesión sin detección alguna por parte de la máquina comprometida, hay comandos que requieren otras dependencias (binarios) que no se encuentran disponibles en el contenedor Docker que se ha creado partiendo de la imagen oficial.

Esto tiene «fácil» solución, ya que basta simplemente con ubicar en el contenedor esos binarios que hacen falta para ejecutar las instrucciones con normalidad. Esto es  así porque en el repositorio oficial de la herramienta, en el directorio «bin» se hace referencia a otro repositorio externo (submodulo) y cuando se clona con «git clone» sin más parámetros, los contenidos de dicho submodulo no se copian. En cualquier caso, dichos binarios se encuentran disponibles  aquí y se pueden descargar y mover al contenedor en funcionamiento o volver a construir la imagen Docker asegurándose de que antes de hacerlo, dichos binarios están en su sitio, basta simplemente con clonar el repositorio incluyendo sus correspondientes submodulos: git clone –recurse-submodules https://github.com/bats3c/shad0w.

Como se puede ver en la imagen anterior funciona correctamente. A partir de este punto se han ejecutado varias pruebas sobre los comandos disponibles en el beacon y ninguna ha sido detectada por el sistema comprometido, excepto aquellas que subían o descargaban ficheros, es decir, las instrucciones «upload» y «download» hacían que el Windows Defender con el análisis en tiempo real detectara el payload y cortaba la conexión, por lo tanto es mejor no hacer uso de dichas instrucciones y si hace falta realizar procesos de exfiltración, posiblemente la mejor opción será utilizar alguno de los binarios disponibles en LOLBas, tal como ya se ha mencionado anteriormente en la serie sobre enumeración en sistemas Windows para post-explotación.

Un saludo y Happy Hack!
Adastra.

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

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

Como se ha comentado en el post anterior, Shad0w cuenta con una arquitectura que puede ser interesante a la hora de implementar campañas de Red Team cuyo objetivo son sistemas basados en Windows. En dicho post se han realizado pruebas sobre sistemas Windows 8.1 y Windows 10 con Windows Defender activo y con todas las actualizaciones aplicadas para determinar si eran capaces de detectar la amenaza o si por el contrario «se la comían». En este post siguen las pruebas, pero concretamente con otro formato diferente a un ejecutable PE para Windows y además, las mismas pruebas sobre un sistema Windows Server 2019 actualizado para verificar que tan cierto es que está pensado para entornos «maduros» tal como se indica en el sitio web oficial en GitHub y en la web del autor.

Beacons sobre Windows 8.1, Windows 10 y Formato PowerShell.

A la hora de generar Beacons es posible especificar un formato concreto, como por ejemplo PowerShell. Esto es precisamente lo que se pretende hacer a continuación y posteriormente, se realiza la prueba de transferir y ejecutar el script generado con los componentes habituales que se encuentran en PowerShell (concretamente usando el IEX).
En primer lugar se generan los beacons «static» y «staged» para transferirlos a la víctima tal como se ha visto en el post anterior, pero en este caso se generarán en formato PowerShell y posteriormente se levantará el listener. El primer problema detectado ha sido precisamente que a la fecha de redactar este post los beacons del tipo «staged» no soportan el formato Powershell por lo tanto será necesario crear un beacon estático con los problemas de detección que puede implicar.

Como se puede ver en la imagen anterior, se crea un fichero PS1 con el nombre «beacon-static.ps1» y en la segunda terminal se levanta el servidor HTTPS para recibir la conexión del Beacon en el caso de que se consiga ejecutar correctamente. Aunque los payloads estáticos pueden ser más pesados y «fáciles de detectar», utilizando el mismo Windows 8.1 recién instalado, con las actualizaciones al día y el Windows Defender y Windows SmartScreen activados, los resultados han sido satisfactorios ya que desde una terminal con PowerShell se ha conseguido descargar y posteriormente ejecutar el beacon, lo que ha dado como resultado una nueva conexión en el C2 levantado con Shad0w, aunque como se puede apreciar en la siguiente imagen, el interprete de PowerShell interrumpe inmediatamente su ejecución debido a una excepción. Aún así, se consigue el objetivo esperado de recibir una conexión.

Bien. Ahora es el momento de hacer lo mismo sobre un sistema Windows 10 con todas las medidas de seguridad habilitadas y se procede a descargar y ejecutar el script PS1 correspondiente al Beacon.


En este caso, como se puede apreciar no ha habido tanta suerte y el sistema ha conseguido detectar la amenaza y bloquearla antes de ejecutarla.

Evasión en Windows Server 2019.

Las últimas pruebas a realizar serán sobre Windows Server 2019, actualizado a la fecha de redactar este post y con las medidas de seguridad que cuenta este sistema. En este caso las pruebas que se harán serán las mismas que se han hecho sobre los sistemas Windows 10 y 8.1

Inicialmente se ha probado con PowerShell y efectivamente, tal como ha ocurrido con Windows 8.1 ha funcionado correctamente. No obstante tras unos instantes la terminal de PowerShell en el sistema Windows deja de responder y sale un mensaje de error, sin embargo se recibe la conexión por parte del beacon que es lo importante. Otro detalle que resulta curioso es que en la consola C2 de Shad0w detecta que la conexión proviene de un sistema Windows Server 2016 cuando en realidad el sistema es un Windows Server 2019, aunque a priori se podría decir que no es algo relevante para las operaciones que se ejecutarán sobre el sistema.

A continuación se realizan las mismas pruebas pero ahora utilizando un ejecutable en formato PE, tal como se ha hecho para los sistemas Windows 8.1 y Windows 10. Inicialmente se ha levantado un servidor web en la máquina del atacante para poder transferir los dos binarios generados en el primer post que corresponden a los beacons «staged» y «static». Posteriormente se han intentado descargar utilizando el navegador web Internet Explorer 11 que viene por defecto en Windows Server 2019. En ambos casos los ficheros se han descargado sin problema en el sistema aunque aparece una advertencia en el navegador sobre la «autenticidad del editor» la cual como resulta evidente no se puede comprobar. A continuación se han ejecutado y efectivamente, se ha recibido la conexión. En el caso del «staged», como ha ocurrido en los otros dos sistemas operativos, aparece el «Assertion Error» que se puede ver en la siguiente imagen pero aún así se recibe la conexión en el servidor C2 de Shad0w.

Como se ha mencionado, en ambos casos se recibe la conexión, aunque curiosamente detecta que la víctima es un Windows Server 2016 y en el caso del payload «static» aparecen algunos caracteres ilegibles en el texto que identifica la sesión.

Las pruebas realizadas han demostrado que Shad0w funciona bastante bien sobre un Windows Server 2019, con las restricciones de seguridad habilitadas por defecto.

Conclusiones sobre las pruebas realizadas con Shad0w.

Personalmente, me ha sorprendido el enfoque de la herramienta, las ideas y técnicas que explica el autor en su blog y que se plasman posteriormente en Shad0w, muy especialmente el siguiente post: https://blog.dylan.codes/defending-your-malware/
Durante las pruebas he intentado utilizar entornos actualizados y con versiones de sistemas operativos recientes, concretamente Windows 8.1, Windows 10 y Windows Server 2019. Hay que tener en cuenta que no he realizado las pruebas con ningún otro AV o solución de seguridad perimetral instalada en el sistema objetivo. Además, las pruebas de momento se han limitado a la transferencia de la muestra maliciosa en la máquina objetivo y su posterior ejecución para comprobar si efectivamente, el ataque es detectado correctamente o no. Los resultados han sido los siguientes.

PS1 Beacon Staged (Ejecutable PE)
Beacon static (Ejecutable PE)
Windows 8.1 NO DETECTADO. Aparece un error en el entorno de PowerShell pero se establece la conexión con el C2. DETECTADO. Windows Defender identifica el binario como una potencial amenaza y lo pone en cuarentena. DETECTADO. Windows Defender identifica el binario como una potencial amenaza y lo pone en cuarentena.
Windows 10 DETECTADO. Windows Defender identifica el script PowerShell como una potencial amenaza y lo pone en cuarentena. NO DETECTADO. Aparece una ventana de error pero se establece la conexión con el C2. DETECTADO. Windows Defender identifica el binario como una potencial amenaza y lo pone en cuarentena.
Windows Server 2019 NO DETECTADO. Aparece un error en el entorno de PowerShell pero se establece la conexión con el C2. NO DETECTADO. Aparece una ventana de error pero se establece la conexión con el C2. Además, detecta incorrectamente la versión del sistema (Windows Server 2016 en lugar de 2019). NO DETECTADO. Aparecen caracteres ilegibles en la consola del C2. Además, detecta incorrectamente la versión del sistema (Windows Server 2016 en lugar de 2019).

De los resultados anteriores lo que más llama la atención es que todas las pruebas realizadas contra Windows Server 2019 han sido positivas, es decir, que el sistema no ha podido detectar ningún comportamiento malicioso, tal como se puede ver en la imagen siguiente, el sistema con el que se han realizado las pruebas se encuentra actualizado y las medidas de seguridad están activas.

Al parecer el trabajo que se ha hecho en Shad0w sigue siendo vigente casi un año después y funciona en versiones recientes y actualizadas de Windows. Por último, solo queda mencionar que faltaría realizar pruebas con el beacon instalado para verificar que efectivamente, se puede operar con el sistema comprometido sin problema y con total normalidad o si por el contrario, a la hora de ejecutar instrucciones hay algún problema o la muestra es detectada como maliciosa, algo que suele ocurrir en otras soluciones C2 del mismo corte. Por este motivo, se publicará un post más que extenderán el análisis que se ha realizado hasta este punto sobre Shad0w.
Espero que te resulte interesante y por favor, el Beacon que te ha generado Shad0w NO LO SUBAS A VirusTotal o plataformas similares en internet. Gracias!

Un saludo y Happy Hack!
Adastra.