CRT-ID

INTRODUCCIÓN

Certified Red Team Infra Dev (CRT-ID) es un curso especializado diseñado para dotar a los profesionales de las habilidades necesarias para desarrollar una infraestructura de Red Team segura para OPSEC, tanto para operaciones internas como externas. Los participantes aprenderán a utilizar servicios legítimos en la nube y locales, a crear redireccionadores personalizados y funciones de servidor de carga útil, y a implementar una infraestructura que refleje escenarios de amenazas del mundo real. El curso también incluye un estudio de caso detallado sobre ataques del Red Team, lo que permite a los alumnos aplicar sus conocimientos en un contexto profesional.

PREPARACIÓN

La certificación se lleva a cabo mediante el siguiente RoadMap:

En concreto, el contenido del curso se divide en los siguientes módulos:

• Introducción
• Intraestructura C2
• Configuración Redirector On-premise y Cloud
• Servidor Payload
• Infraestructura Phising
• Caso de estudio Red Team

En concreto, cada uno de estos módulos está fragmentados en una serie de videos en el que se explica tanto de manera teórica como práctica cada uno de los conocimientos. En este sentido creo que es algo muy bueno que el alumnado tenga la posibilidad de seguir al docente y simular una infraestructura propio de Red Team.

Es cierto que por ejemplo desde el punto de vista de creación de payloads no se tiene en cuenta evasión de EDR para infectar a un target y que esto corresponde a posteriores certificaciones pero da un punto óptimo de configuración y uso de un C2 como Mythic.

Para instalar Mythic se utiliza una instancia de AWS EC2 por medio del sistema operativo Ubuntu, el proceso de conexión se establece por medio de túneles SSH.

La configuración del Redirector está basada en Nginx con diferentes reglas que puedan evadir la detección de un equipo de Blue Team como el cambio del User-Agent por un macheo concreto para redirigir el tráfico hasta el C2, el uso de Cloudfront que será el dominio expuesto a Internet y filtrar el tráfico, etc.

Generación de phising mediante herramientas como Evilginx, Gophish que simulen la captación de credenciales por una posible víctima.

PRECIO

El precio es de 9$, es decir, casi gratis. Evidentemente por este precio es incomparable a otras certificaciones como la gente de Offsec, desde un punto de vista de precio como es obvio pero también de contenidos. No se puede comparar estar certificación con el OSCP por ejemplo porque son mundos distintos.

Por el precio que lo oferta la gente de CWL creo que se puede llegar a aprender de algunos aspectos interesantes como instancias en AWS, C2 Mythic, Redirector, ELB, Agentes (Apollo), tipos de Payloads, etc:

Link: https://cyberwarfare.live/

EXAMEN

El examen tiene una duración total de 6 horas (tiempo más que suficiente) en el que tienes que ir contestando una serie de preguntas a modo CTF e introducir una serie de flags. Se enfoca sobre todo en el proceso de configuración del Redirector que como operador debes completar.

COMMAND AND CONTROL (C2) MYTHIC – GUÍA PASO A PASO DE CONFIGURACIÓN

Mythic es un framework de C2 multiplataforma que permite a un operador controlar agents desplegados en máquinas comprometidas.
Estos agents (llamados payload types) permiten ejecutar comandos, moverse lateralmente, recopilar información, cargar módulos, etc.

Está escrito principalmente en Python y Go, y usa Docker para desplegarse.

Los componentes de la infraestructura de Red Team que se verán son:

• Servidor Command and Control (C2)
• Servidor Payload
• Servidor Redirector
• Servidor Phising

Una vez que se ha definido cada uno de los componentes, pasaré a detallar la configurar para levantar una instancia de C2 Mythic que es Open Source. Algunas de las características de C2 Mythic son:

• Gran compatibilidad con Windows, Linux y Mac.
• Es de código abierto y tiene aspectos comparables con otros C2 comerciales.
• Se pueden personalizar perfiles C2.

La configuración que se llevará a cabo es la siguiente:

Para levantar una instancia en EC2 hay que iniciar sesión en la consola de AWS, luego vamos al panel principal EC2 > Instancias:

A continuación, pinchamos en una nueva instancia:

A continuación, seleccionamos el nombre, SO y el tipo de instancia, por ejemplo t2.large:

A continuación, en par de clave ponemos las que hemos creado previamente:

Finalmente, solamente permitir el tráfico SSH desde tu IP:

Obtendremos ya la instancia:

Ahora, para conectarnos por SSH a la instancia accedemos a ella y en el margen superior derecho pinchamos en Conectar > Cliente SSH y ya veremos la petición para copiar y pegarla en una shell:

AWS EC2 Profile:

1. Elige una imagen como plantilla como por ejemplo Ubuntu 20.04
2. Levanta la máquina y descargar un par de claves SSH

Instalación C2:

a. Terminal 1:
ssh -i <Key_File> user@AWS_EC_IP
git clone https://github.com/its-a-feature/Mythic.git
cd Mythic
sudo ./install_docker_ubuntu.sh

Instalación del agente Apollo (Válido para víctimas en Windows):
sudo -E ./mythic-cli install github https://github.com/MythicAgents/Apollo.git

Instalación perfil C2:
sudo -E ./mythic-cli install github https://github.com/MythicC2Profiles/http.git
sudo ./mythic-cli start
cat .env

A continuación, hay que hacer port forwarding para levantar el puerto 7443 de la máquina remota a nivel local:
ssh -L 7443:127.0.0.1:7443 -i <Key_File> user@AWS_EC_IP

Solo nos quedaría navegar a https://127.0.0.1:7443 para ver el panel de inicio de sesión de Mythic

En este punto, tenemos que ir al directorio de Mythic y hacer un cat .env para ver las credenciales de acceso al panel de inicio de sesión:

cd Mythic

sudo cat .env

Veremos las credenciales de acceso al panel de inicio de sesión:

Una vez que hayamos podido acceder, tendremos una vista como esta:

Una vez tenemos configurado Mythic podemos ver la configuración del entorno AWS:

Por un lado las víctimas que pueden tener varios SO (en este caso al haber instalado el agente de Apollo solo atentaría contra Windows), luego el flujo de la conexión se lleva a cabo a través de un redirector. Un redirector (a veces llamado redirector server o traffic redirector) es una pieza intermedia que se coloca entre el atacante/analista y el objetivo para redirigir, ocultar o modular el tráfico, manteniendo tu infraestructura real protegida o añadiendo una capa de control.
En ciberseguridad ofensiva y red team es muy común.

Amazon CloudFront no es un redirector por definición, es un CDN. Pero se puede usar como redirector cuando configuras el CDN para:

1. Apuntar a un origin que tú controlas (tu C2, tu servidor, tu panel, etc.).
2. Servir tráfico hacia ese origin solo cuando venga a través del endpoint de CloudFront.
3. Permitir controlar / filtrar / camuflar el tráfico aprovechando IPs de AWS en lugar de tus propias IPs.

En ese escenario, CloudFront actúa como redirector porque:

• Oculta tu servidor real.
• Añade un punto intermedio por donde pasa todo el tráfico.
• Puede aplicar reglas (WAF, geofilters, headers, paths).
• Te da un dominio “limpio” o camuflado (ej. d123abcd.cloudfront.net).
• Permite domain fronting en algunas configuraciones (cuando está permitido).

Ejemplos de uso (Offensive / Red Team)

• C2 redirector:
  El C2 real está en un VPS, pero solo acepta conexiones desde CloudFront. Los agentes hablan con CloudFront → CloudFront reenvía al origin → origin responde → vuelve a CloudFront → al agente.
• Ocultación de infraestructura:
  Evitas que tu IP real aparezca en logs, Threat Intel o listas negras.
• Bypass de detecciones basadas en IP:
  Al usar IPs de AWS (muy comunes), evitas detecciones triviales.

ELB (Elastic Load Balancer)

Un ELB (Elastic Load Balancer) es un servicio de AWS que reparte el tráfico entrante entre varios servidores backend para mejorar disponibilidad, estabilidad y redundancia.
Su función principal es:

• distribuir conexiones entre varias instancias,
• evitar sobrecarga en un único servidor,
• proporcionar un único punto de entrada controlado,
• y permitir reglas de salud y enrutamiento.

El ELB no procesa lógica de aplicación:
solo recibe tráfico y lo envía al servidor adecuado según su configuración.

El papel del ELB cuando se usa entre CloudFront y Mythic

En un entorno donde usas CloudFront como redirector y un C2 como Mythic en el backend, el ELB actúa como capa intermedia obligatoria antes de llegar al servidor de Mythic.

Su papel es:

1. Recibe el tráfico que CloudFront redirige.
   CloudFront nunca se conecta directamente a la instancia de Mythic,
   sino al ELB configurado como origin.
2. Oculta y protege la instancia de Mythic.
   La IP real del servidor de Mythic no es visible desde Internet;
   solo se expone la IP del ELB.
3. Controla quién puede llegar al servidor Mythic.
   Puedes usar reglas, grupos de seguridad o health checks para limitar qué tráfico acepta.
   El ELB solo aceptará lo que venga desde CloudFront si así lo configuras.
4. Distribuye tráfico si tienes varios redirectores backend o varios listeners.
   Aunque Mythic sea un solo servidor, puedes añadir más instancias para escalar,
   o usar ELB solo como punto único de entrada con reglas específicas.
5. Sirve como punto estable en caso de reinicios o cambios de IP.
   Mythic puede cambiar de IP o de instancia.
   El ELB mantiene siempre el mismo endpoint para CloudFront.

Flujo completo explicado

1. El cliente se conecta a CloudFront.
2. CloudFront actúa como redirector y pasa el tráfico al ELB, que es su origin.
3. El ELB recibe esa conexión y la reenvía al servidor Mythic.
4. Mythic responde → vuelve al ELB → vuelve a CloudFront → vuelve al cliente.

Flujo textual final:

Cliente → CloudFront → ELB → Mythic
Mythic → ELB → CloudFront → Cliente

Configuración ELB (Load Balancer)

En este punto, se establece el proceso de configuración de un balanceador de carga:

Ahora, creamos un grupo de seguridad:

Editar Reglas Entrada – Tráfico HTTP

En este punto hay que crear una reglas de entrada dentro de Instancias > Grupo de Seguridad, para redirigir todo el tráfico web hacia nuestro C2:

Cloudfront

Al final te quedará un dominio que es el que se expone por Cloudfront y el dominio origen como tu instancia AWS EC2:

Creación Payload en C2 Mythic

En este paso y tal y como se observa hay que poner en el callback_host el dominio que nos ha proporcionado Cloudfront: <dominio.cloudfront.net> y el puerto, en este caso 443