Certified Red Team Infrastructure Developer (CRT-ID)

Esta certificación te enseña y prepara para poder levantar una infraestructura de ataque completa no solo On-Premise, sino tambien desde AWS o Azure Front Door. En esta certificación desplegarás infraestructura completa desde el servidor C2, servidores de phishing hasta el servidor de payloads, junto con conceptos de arquitectura, diseño e implementación de redirectores y conceptos OpSec.

Preparación para la CTR-ID

Para prepararme la certificación, en mi caso particular monté un laboratorio en local realizando una simulación de despliegue de infraestructura APT (salvando las distancias), con diversas máquinas virtuales Ubuntu aplicando conceptos como: El principio de separación funcional.

El laboratorio que desplegué, constaba de 3 redirectores cuya implementación la realicé con nginx (ya que es lo que se enseña en la certificación) y en donde cada uno de ellos era asignado a un servidor de la infraestructura backend (Pwndrop como servidor de payloads, Mythic C2 y GoPhish + Evilginx).

Además, para no pegarme con iptables en los redirectores, hice uso de UFW (Uncomplicated Firewall).

Después, aislé la infraestructura backend haciéndola solamente visible desde la interfaz de loopback y con UFW permitiendo solamente trafico desde el 80/443 de los redirectores, simulando la exposición del puerto HTTP/s.

Principio de Separación Funcional

Dicho principio establece una implementación y operativa de la infraestructura de ataque aislada por funcionalidades y objetivos. Cada capacidad ofensiva (Servidores de payloads, servidores C2, servidores de phishing, etcétera) opera en canales y fases del ciclo de vida del ataque independientes. De esta forma, si un “nodo” es detectado y posteriormente “quemado”, no afectaría de manera total al desempeño de un red team.

De forma concreta, el post de Mandiant sobre Russian Nesting Doll o, en español, “Muñeca rusa matrioska” habla sobre esto precisamente, y cómo el grupo APT29 es fuertemente disciplinado con este principio OpSec a nivel de infraestructura.

En dicho post encontramos la siguiente citación:

[!quote]+ APT29 es conocido por su rigurosa disciplina operativa y su continuación de mantener un alto nivel de seguridad operativa en todas sus operaciones. APT29 demuestra un nivel elevado de seguridad operativa para proteger las backdoors secundarias, los intentos de movimiento lateral y la exfiltración de datos.

Por ejemplo, APT29 hizo todo lo posible por ocultar su backdoor SUNBURST dentro del código legítimo de «SolarWinds» durante la campaña inicial. Además, Mandiant identificó anteriormente que el grupo intentó comprometer varias cuentas dentro de un entorno, manteniendo el uso de cada cuenta separado por función: una para el reconocimiento y las demás para el movimiento lateral.

Esto reduce la probabilidad de que la detección de la actividad de una cuenta comprometida pueda exponer el alcance total de la intrusión.

Por lo cual, aplicar dicho principio nos permite una mayor celeridad para volver al ataque en el menor tiempo posible.

Laboratorio de Preparación

La arquitectura del laboratorio que implementé es como se muestra en la siguiente imagen:

De esta forma, si la dirección IP de cualesquiera de los redirectores se viese afectada mediante la detección y posterior quemado, la infraestructura de ataque queda totalmente a salvo y fuera del “blast radius”.

Redirectores Nginx

En esta fase, me lo pasé francamente muy bien. Disfruté de las configuraciones que se les podía realizar a los redirectores. En mi caso, implemente un doble cerrojo aplicando las directivas map en vez de hacer mútliples if en la parte del location.

1. String personalizada para el User-Agent.
2. Lista blanca de IP o rangos de IP.

map $http_user_agent $valid_agent {
    default 0;
    "~*CUSTOM_STRING" 1;
}

map $remote_addr $valid_ip {
    default 0;
    "IP2" 1;
    "IP1" 1;
}

Cuando ambas condiciones se cumplan, entonces se permitirá el paso hacia la infraestructura interna y en caso de que alguna de estas dos condiciones no se cumplieran, se realizará una redirección hacia una página distinta.

Si alguna de las dos no se cumple, se detectará en la siguiente parte:

# Cerrojo 1: User-Agent incorrecto -> redirigir a sitio legítimo
        if ($valid_agent = 0) {
            return 302 https://httpd.apache.org;
        }

        # Cerrojo 2: IP no autorizada -> redirigir a sitio legítimo
        if ($valid_ip = 0) {
            return 302 https://httpd.apache.org;
        }

En mi caso usé la página de apache para redirigir.

[!Info] A la hora de hacer una redirección, lo suyo es redirigir a una página o dominio en posesión de la víctima y de la cual no sospeche.

Para realizar dicha implementación bastará con hacer nuestro redirector.conf en la siguiente ruta:

# Ubicación de nuestra configuración
/etc/nginx/conf.d/redirector.conf

Servidor de Payloads

En este caso tuve dos alternativas

1. Montar uno con Nginx más una implementacion de facade files
2. Desplegar Pwndrop

Para el que no conozca la utilidad de Pwndrop, es un servidor de payloads de código abierto, el cual nos permitirá desplegar nuestro malware en el Host de la víctima mediante una interfaz Web por HTTP/s. Además, también implementa los facade files por defecto.

Facade Files

Los facade files o archivos de señuelo o fachada entrarán en juego cuando después de haber desplegado el malware en el host de la víctima, el SoC quiera revisar el origen de la URL o IP. Con esta opción activa, cuando se intente acceder a él, el SoC verá un documento legítimo, por ejemplo un .docx.

A modo de ejemplo, se puede ver su configuración en la siguiente imagen:

En Redirect Path establecemos la ruta real del malware que queremos descargar en la víctima, en este caso un ps1. Sin embargo en la variable Name y en Path de la sección inferior aparecerá el fichero ’legítimo’ junto con el Content-Type cambiado a la hora de realizar la descarga ya que algunos proxies podría levantar alertas.

C2 Mythic

En este punto la premisa es sencilla, una vez se haga entrega del Beacon a través de Pwndrop, este se intentará conectar con el redirector (con la configuración IP + User-Agent preconfigurada desde el C2), y se permitirá el tráfico a los backend servers realizando una redirección desde el redirector hacia servidor C2 desplegado.

De esta forma, y como ya se ha mencionado antes, en caso de que la telemetría levante alertas y quemen la IP del Redirector del C2, simplemente tendremos que levantar otro redirector desde otra IP y continuar con la operativa.

Despliegue de Mythic

Para desplegarlo instalé los agentes

1. Poseidon (Agente Linux/MacOS)
2. Apollo (Agente Windows)

Así como el perfil HTTP/s

Además es muy sencillo de levantar Mythic ya que todo se ejecuta en contenedores (tiene una arquitectura bastante modular) y con un simple ./mythic-cli start se levantan todos los servicios necesarios.

Infraestructura de Phishing

GoPhish + Evilginx

Empezando por Evilginx, se trata de una herramienta de codigo abierto, la cual es un servidor de relay, que actúa como proxy web inverso. El usuario víctima interactúa con el sitio legítimo real, mientras Evilginx captura todo el tráfico que pasa entre ambas partes. El requisito es tener un dominio parecido del objetivo.

El caso de uso principal es el bypass o evasión del MFA. Capturando, tanto las credenciales como los tokens de sesión, que son válidos mientras estos no expiren. Es decir, tendremos una ventana temporal para realizar el compromiso de la cuenta.

Aquí entran en juego dos conceptos principalmente

1. Phishlets
2. Lures

Los Phishlets son básicamente las plantillas que le dicen a Evilginx cómo gestionar las peticiones y cómo capturar los datos entre la víctima y el servicio legitimo en el cual la victima se esta autenticando.

En cambio, los Lures es básicamente el enlace que se genera con Evilginx y, por el cual, la víctima interactúa redirigiéndole al servicio legítimo pudiéndose llevar a cabo el ataque Adversary in the Middle.

AitM vs MitM

Seguro que muchos habréis oído hablar o ejecutado ataques Adversary in the Middle y Man in the Middle. Pero ¿Son iguales?¿En qué son distintos?

Hasta donde tengo conocimiento, en un contexto de autenticación moderna, donde los flujos de autenticación se realizan entre el cliente y el servidor de manera cifrada, los ataques MitM suelen ser más oportunistas y aplicándose a ataques de DNS Spoofing o ARP Poisoning fallando ante dichos flujos de autenticación cifrados. Los ataques AitM por el contrario, no se centran tanto en el cifrado, sino que el proxy gestiona las comunicaciones entre el cliente y el servidor extrayendo credenciales y tokens de sesión válidos.

En estos posts beyond-mitm-rising-danger-adversary-middle-attacks what-is-an-adversary-in-the-middle-aitm-attack describen y detallan esto mismo.

La siguiente imagen extraída del primer post, nos compara estas dos técnicas de manera breve y resumida

Con todo esto, en la plantilla que generemos en GoPhish embeberemos el Lure que pondrá de manifiesto nuestro ataque AitM y en caso de que la víctima interactúe e inicie sesión, obtendremos sus credenciales y token de acceso.

Examen CRT-ID

Después de esta preparación, el examen no me supuso ninguna dificultad, ya que las preguntas iban todas dirigidas a la implementación de un redirector que necesitaba estar operativo para llegar a rutas, implementar condicionantes, redirecciones, etcétera.

Para realizar el examen, tienes 6 horas, empezando por tener que conectarte mediante ssh al servidor del examen donde te decían la ruta tanto del payload como del .conf del redirector. A partir de aquí, tenías que configurar el redirector y hacerlo funcionar con los comandos correctos.

En mi experiencia propia tardé como 45 minutos, eran preguntas bastante directas que si habias visto y hecho el curso, indagado en los materiales e implementado y desplegado la infraestructura vista, el examen no supone ninguna dificultad añadida.

Antes de realizar el examen, es recomendable tener una base de redes e infraestructura en general. No es una certificación compleja pero requiere algo de base en esos aspectos.

En total fueron 6 o 7 preguntas que respondí de manera correcta, aprobando el examen y obteniendo la certificación.

Como conclusión, recomiendo mucho esta certificación, pero no solo dejándose llevar por los videos, sino saliendo de la caja e indagando todo lo posible sobre implementaciones de todo tipo, herramientas, e incluso implementar más capas de redirectores y, sobre todo, conectar cada concepto y estrategia con operaciones APTs reales y TTPs del Mitre para sacar el máximo provecho.

Gracias por llegar hasta aqui y si te ha resultado útil no dudes en compartirlo.

Referencias