Infraestructura Red Team: Configuración de Redirectores C2

Si la IP de tu servidor C2 termina en un feed de inteligencia de amenazas, el ejercicio terminó. Los redirectores existen precisamente para evitar eso.

Un redirector se interpone entre tu máquina de operador y tu implante. El implante solo habla con el redirector. Tu C2 real — Sliver, Havoc, Cobalt Strike — permanece detrás de él, invisible. Si el equipo azul quema el redirector, levantas otro en diez minutos. El C2 sigue funcionando.

Esta guía cubre cómo construir esa infraestructura: redirectores con Apache y Nginx, reglas de filtrado, fronting a través de CDN y las consideraciones de OPSEC que realmente importan.

Qué Estás Construyendo

El modelo básico:

Implante → Redirector (VPS) → Servidor C2 (backend protegido)

El redirector reenvía el tráfico legítimo del implante hacia tu C2. Todo lo demás — escáneres, analistas del equipo azul, herramientas automatizadas — recibe una respuesta de señuelo o se descarta directamente.

Necesitas al menos dos instancias VPS:

Redirector — desechable, expuesto a internet, sin herramientas sensibles
Backend C2 — bloqueado, firewall que solo acepta tráfico de las IPs del redirector

Vultr y DigitalOcean son opciones sólidas para los nodos redirectores. Lanza instancias baratas, úsalas y quémalas cuando sea necesario.

Paso 1: Endurecer el Backend C2

Antes de tocar el redirector, bloquea el servidor C2. Debe aceptar tráfico relacionado con el implante solo desde tus redirectores.

# Permitir SSH únicamente desde tu IP de operador
ufw allow from TU_IP_OPERADOR to any port 22

# Permitir tráfico C2 solo desde IPs del redirector
ufw allow from IP_REDIRECTOR to any port 443
ufw allow from IP_REDIRECTOR to any port 80

# Denegar todo lo demás
ufw default deny incoming
ufw enable

Nunca expongas el backend C2 directamente a internet. Con un escaneo de Shodan bastará para que te descubran.

Paso 2: Redirector Apache con mod_rewrite

Apache es la opción clásica. mod_rewrite te da control preciso sobre qué se reenvía.

Instalar y habilitar módulos

apt update && apt install -y apache2
a2enmod rewrite proxy proxy_http ssl headers
systemctl restart apache2

Crear el conjunto de reglas de reescritura

El concepto clave: solo reenvía tráfico que coincida con el user-agent y los patrones de URI esperados por tu implante. Todo lo demás va a un señuelo convincente o devuelve un 404.

Crea /etc/apache2/sites-available/redirector.conf:

<VirtualHost *:443>
    ServerName tu-dominio-redirector.com

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/tu-cert.pem
    SSLCertificateKeyFile /etc/ssl/private/tu-clave.pem

    # Registrar accesos para visibilidad operacional
    LogLevel warn
    ErrorLog /var/log/apache2/redirector_error.log
    CustomLog /var/log/apache2/redirector_access.log combined

    RewriteEngine On

    # Bloquear herramientas de escaneo/análisis por user-agent
    RewriteCond %{HTTP_USER_AGENT} "(?:curl|wget|python|masscan|nmap|zgrab|shodan)" [NC]
    RewriteRule .* - [F,L]

    # Bloquear solicitudes que no coincidan con los patrones URI esperados
    # (hacer coincidir con las URIs de check-in del perfil C2)
    RewriteCond %{REQUEST_URI} !^/(updates|api/v2/check|static/js/app) [NC]
    RewriteRule .* https://www.microsoft.com/ [L,R=302]

    # Reenviar tráfico coincidente al C2
    RewriteRule ^/(.*)$ http://IP_BACKEND_C2:80/$1 [P,L]

    # Preservar las cabeceras originales para que el C2 registre el contexto de origen
    ProxyPassReverse / http://IP_BACKEND_C2:80/
    RequestHeader set X-Forwarded-For "%{REMOTE_ADDR}e"
</VirtualHost>

Habilitar el sitio:

a2ensite redirector.conf
systemctl reload apache2

Ajustar la lista blanca de URIs para que coincida con tu perfil C2

La lista blanca de URIs en RewriteCond debe coincidir exactamente con lo que especifica tu perfil malleable. Si tu implante de Sliver hace check-in en /api/v2/check, eso es lo que incluyes en la lista. Los desajustes significan beacons perdidos silenciosamente.

Paso 3: Redirector Nginx

Nginx es más ligero y maneja mejor la alta concurrencia. La lógica es la misma: filtrar primero y luego hacer proxy del tráfico legítimo.

Instalar

apt update && apt install -y nginx

Crear `/etc/nginx/sites-available/redirector`:

server {
    listen 443 ssl;
    server_name tu-dominio-redirector.com;

    ssl_certificate /etc/ssl/certs/tu-cert.pem;
    ssl_certificate_key /etc/ssl/private/tu-clave.pem;

    access_log /var/log/nginx/redirector_access.log;
    error_log /var/log/nginx/redirector_error.log warn;

    # Bloquear escáneres
    if ($http_user_agent ~* "(curl|wget|python|masscan|nmap|zgrab|shodan)") {
        return 403;
    }

    # Solo hacer proxy a URIs coincidentes
    location ~ ^/(updates|api/v2/check|static/js/app) {
        proxy_pass http://IP_BACKEND_C2:80;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Todo lo demás: señuelo o redirección
    location / {
        return 302 https://www.microsoft.com/;
    }
}

Habilitarlo:

ln -s /etc/nginx/sites-available/redirector /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

Paso 4: Obtener un Certificado (Let’s Encrypt)

Tu redirector necesita un certificado TLS válido. Los certificados autofirmados levantan banderas. Let’s Encrypt es gratuito y automatizado.

apt install -y certbot python3-certbot-apache  # o python3-certbot-nginx
certbot --apache -d tu-dominio-redirector.com  # o --nginx

# Renovación automática
certbot renew --dry-run

Elige un dominio creíble para el redirector. Algo que parezca un CDN, plataforma de analítica o endpoint SaaS funciona bien. cdn-assets-prod.io se lee de forma muy diferente a c2-redirector.net.

Paso 5: Configurar el Listener del C2

El listener backend del C2 debe aceptar conexiones del redirector.

Ejemplo con Sliver

sliver > https --lhost 0.0.0.0 --lport 443 --domain tu-dominio-redirector.com

El dominio debe coincidir con el del redirector. El listener HTTPS de Sliver gestionará las conexiones reenviadas entrantes.

Ejemplo con Havoc

En teamserver.yaml, configura el listener para que se enlace solo en la IP interna:

Listeners:
  - Name: "https-prod"
    Protocol: https
    Host: "0.0.0.0"
    Port: 443
    Secure: true

Añade una regla de firewall para aceptar solo desde la IP del redirector (el Paso 1 ya lo cubre).

Paso 6: Verificar la Cadena

Prueba cada pieza antes de ejecutar un ejercicio:

# Desde una máquina de prueba — la URI del implante debe hacer proxy correctamente
curl -sk -A "Mozilla/5.0" https://tu-dominio-redirector.com/api/v2/check

# Un user-agent tipo escáner debe ser bloqueado
curl -sk -A "python-requests/2.28" https://tu-dominio-redirector.com/api/v2/check
# → Debe devolver 403 o redirigir al señuelo

# Una URI incorrecta debe redirigir al señuelo
curl -sk https://tu-dominio-redirector.com/admin
# → Debe redirigir a microsoft.com o tu señuelo

Verifica desde el lado del C2 que las conexiones reenviadas llegan correctamente.

Paso 7: Fronting a través de CDN (Avanzado)

Para una ofuscación adicional, enruta el tráfico a través de un CDN. Cloudflare es el enfoque más común.

El concepto:

Implante → Edge de Cloudflare → Tu VPS redirector → C2

Desde la perspectiva del equipo azul, el tráfico del implante parece ir hacia IPs de Cloudflare, no hacia tu infraestructura. No puedes bloquear Cloudflare sin romper la mitad de internet.

Configuración:

Apunta el dominio de tu redirector a Cloudflare
Activa el proxy de Cloudflare (nube naranja)
Configura el modo SSL en “Full” en Cloudflare
Configura la cabecera Host del perfil C2 para que coincida con el dominio proxificado

Limitaciones: Los términos de servicio de Cloudflare prohíben el uso para C2. Esta técnica está documentada con fines educativos de red team — verifica las reglas de enfrentamiento con el cliente antes de usarla.

Lista de Verificación de OPSEC

Antes de operar:

El firewall del backend C2 solo acepta tráfico de las IPs del redirector
El redirector no tiene herramientas instaladas — es un proxy tonto
Las URIs del perfil malleable coinciden exactamente con la lista blanca del redirector
La respuesta señuelo parece convincente — 302 a un sitio real o sirve una página falsa
El certificado TLS en el redirector es válido (no autofirmado)
El dominio del redirector tiene un WHOIS plausible y parece un servicio real
La rotación de logs está habilitada — los logs del redirector deben ser mínimos y rotar
Tienes un redirector de reemplazo listo para levantar en menos de 15 minutos
El servidor C2 no tiene exposición directa a internet — confirmado con escaneo de puertos desde una IP externa

Errores Comunes

Exponer la IP del C2 directamente. Un solo escaneo de Shodan y te queman. El punto de los redirectores es precisamente que el backend del C2 nunca toca internet abierto de forma directa.

Usar dominios de prueba obvios. c2test.net o redteam-infra.com van a activar cada feed de inteligencia de amenazas desde el primer día. Elige algo que parezca un servicio real.

No sincronizar el perfil C2 con la lista blanca del redirector. Si el perfil envía tráfico a /updates/check pero el redirector solo permite /updates, tus beacons mueren en silencio.

Omitir el señuelo. Un redirector que devuelve un 200 con cuerpo vacío para solicitudes desconocidas es una huella digital. Redirige a algo real.

Ejecutar herramientas persistentes en el redirector. Si el redirector es capturado e inspeccionado, no debe tener nada sensible. El backend C2 es donde viven las herramientas.

Múltiples Redirectores

Para ejercicios prolongados, ejecuta varios redirectores bajo distintos dominios. Rota cuál usa cada implante en el perfil malleable. Si uno es bloqueado, los demás siguen funcionando.

Implante A → Redirector 1 (cdn-analytics-prod.io)
Implante B → Redirector 2 (api-gateway-service.net)
Implante C → Redirector 3 (telemetry-update-svc.com)
             ↓
     Backend C2 (bloqueado, solo interno)

Cada redirector es barato — un VPS de $6/mes de Vultr o DigitalOcean funciona perfectamente. El costo de la resiliencia es bajo.

Qué Sigue

Con la infraestructura de redirectores lista, el siguiente nivel es la evasión de payloads y la resiliencia del implante. Lecturas relacionadas:

¿Necesitas contenido de red team redactado rápido? CipherWrite entrega artículos técnicos, whitepapers y contenido de LinkedIn para empresas de ciberseguridad.

Qué Estás Construyendo#

Paso 1: Endurecer el Backend C2#

Paso 2: Redirector Apache con mod_rewrite#

Instalar y habilitar módulos#

Crear el conjunto de reglas de reescritura#

Ajustar la lista blanca de URIs para que coincida con tu perfil C2#

Paso 3: Redirector Nginx#

Instalar#

Crear /etc/nginx/sites-available/redirector:#

Paso 4: Obtener un Certificado (Let’s Encrypt)#

Paso 5: Configurar el Listener del C2#

Ejemplo con Sliver#

Ejemplo con Havoc#

Paso 6: Verificar la Cadena#

Paso 7: Fronting a través de CDN (Avanzado)#

Lista de Verificación de OPSEC#

Errores Comunes#

Múltiples Redirectores#

Qué Sigue#