Red Team 101

Conceptos de arquitectura en ejercicios de Red Team y C2s.

Red Teaming Intro

En este curso no vamos a entrar en discusión en cuáles son la definición de Red Team ni mucho menos, porque creo que excede a la temática del curso, aparte creemos que el Red Team incluye muchos subconjuntos de áreas que no estarían contenidas dentro de este curso. Pero si lo vamos a enmarcar y dentro de esto.

Definición escueta - Red Team = Simular un ataque real.

Lo más importante para un Red Team es pasar por debajo del radar y siempre usar los menores privilegios posibles. Es importante saber que un Red Team no es solo comprometer el AD, sino poder trabajar en conjunto con la organización para poder detectar y responder mejores a las TTPs ( Tactics, Techniques and Procedures).

C2 Básico

Descripción

1. El operador define en el C2 Web GUI una tarea a ser realizada por el agente.

2. El C2 Web GUI envía la tarea al listener a disponibilidad para el agente.

3. El agente que se encuentra haciendo polling sobre el listener:

   • Obtiene la tarea

   • La ejecuta

   • Envía el resultado de vuelta al listener

4. El C2 Web GUI que se encuentra haciendo polling sobre el listener obtiene el resultado

5. El agente visualiza el resultado.

Si bien este diseño resuelve nuestras necesidades básicas. Esto no evita la capacidad del personal de seguridad informática de poder parar el ataque baneando la IP con la que el listener está escuchando. También otro problema que tenemos es que esto no se encuentra segmentado estamos tratando de realizar todas las actividades a través de un solo servidor. Es bastante fácil perder la resiliencia de toda la operación que estamos teniendo, después de haber tenido un initial foot, para poder realizar nuestras actividades.

Consideraciones en el diseño para resiliencia

Los ejercicios que realizamos a la hora de un ejercicio Red Team suelen ser largos. Por eso es importante segregar cada una de las tareas y servidores según sus funciones. Esto nos va a dar la capacidad de poder tener más resiliencia en el caso de que uno de nuestros agentes sea descubiertos tirando por la borda el tiempo que cuesta la configuración de estos servicios.

En ejemplo de arriba podemos ver un modelo, donde se segregan cada uno de los servidores según su función.

Vamos a usar dos tipos de C2:

• Long Haul(LT) - Este C2 lo vamos a usar pocas veces. Ya que la intensión es que una vez que tengamos el acceso a la red lo mantengamos lo más posible. Podemos configurarlo que este se conecte una vez al día cada X días o incluso semanas, la idea principal de este C2 es garantizar la persistencia.

• Short Haul (ST) : Estos van a ser nuestra principal herramienta a la hora de operar el c2 y movernos dentro de la red, estos agentes se van a conectar al servidor cada 1/5 minutos.

Usando Redirectors

Para aumentar todavía más la resiliencia, lo que podemos hacer también es configurar redirectors. La idea de esto es tener siempre un host, adelante de nuestros servidores. Esto hace que no tengamos que empezar todo de vuelta cada vez que somos descubiertos y también se encargan de redirigir el tráfico para ofuscar la ubicación real de nuestra infra.

Los redirectors pueden ser:

• Para DNS o Revers shells - Dum pipe

• HTTPS, casi siempre para payloads, phishing y los C2 que van por HTTPS

Fuentes

• Designing a C2 Infrastructure (https://shogunlab.gitbook.io/building-c2-implants-in-cpp-a-primer/chapter-1-designing-a-c2-infrastructure)

• Red Team-Infrastructure Wiki ( https://github.com/bluscreenofjeff/Red-Team-Infrastructure-Wiki)

• Automating Red Team Infrastructure with Terraform (https://www.ired.team/offensive-security/red-team-infrastructure/automating-red-team-infrastructure-with-terraform)