Infraestructura ofensiva

Una operación remota necesita algún lugar desde el que administrar sistemas, entregar contenido, recibir conexiones y conservar evidencia. La solución mínima puede ser un VPS con un listener. También es la que más fácilmente concentra secretos, tráfico operativo, logs y acceso administrativo en una sola dirección pública.

La infraestructura ofensiva aparece cuando esos caminos se diseñan como un sistema en vez de como servidores aislados. Su tarea es separar funciones con niveles de confianza distintos, controlar qué componente puede hablar con cuál y hacer posible la recuperación cuando una dirección, un dominio, una credencial o un proveedor dejan de ser utilizables.

Esta necesidad no pertenece exclusivamente al Red Team. Un pentest interno puede usar un nodo de transferencia y un VPS para recibir resultados. Una evaluación externa puede necesitar orígenes estables y evidencia centralizada. El Red Team amplía el problema porque añade continuidad, perfiles de tráfico, redirectors, C2 y rotación durante una operación. La arquitectura debe indicar qué funciones existen en cada caso y omitir las que no aportan una capacidad necesaria.

Supongamos que un team server expone directamente su listener y su acceso SSH. El mismo host acepta tráfico de agentes, administración de operadores y almacenamiento de resultados. Un bloqueo de la dirección interrumpe el control. Una regla de firewall incorrecta expone la administración. Un compromiso del frontal alcanza el componente que posee claves, tareas y datos del objetivo.

Añadir un redirector cambia esa relación. El componente expuesto puede validar el tráfico y reenviar solo el que cumpla el perfil esperado. El team server deja de necesitar exposición directa al mismo origen. Sin embargo, la separación solo existe si las reglas de red impiden rodear el redirector, si el servicio de origen autentica al frontal y si la administración utiliza otro camino.

Este razonamiento procede de una idea más general: una frontera de confianza debe describirse por los datos y capacidades que la cruzan. NIST SP 800-207 aplica ese enfoque a arquitecturas Zero Trust. En una infraestructura ofensiva, el principio permite revisar cada flujo sin asumir que un host es fiable por encontrarse “dentro”.

MITRE ATT&CK agrupa la adquisición de dominios, servidores, cuentas, certificados y otros recursos dentro de Resource Development. La taxonomía describe capacidades que un adversario puede preparar antes de actuar. Para diseñar una infraestructura profesional, esa vista necesita completarse con administración, evidencia, salud, recuperación y retirada.

Los nombres de productos vienen después. Un redirector puede implementarse con un reverse proxy, un balanceador o funciones gestionadas. Un canal administrativo puede depender de SSH, una red privada o un acceso basado en identidad. La elección cambia logs, puntos de fallo, costes operativos y observadores externos, pero no elimina la función que debe cumplirse.

Un nodo puede desempeñar varias funciones en un laboratorio pequeño. Esa concentración se registra como una decisión de confianza, no como si los límites siguieran existiendo. En producción, combinar funciones exige explicar qué ocurre si el nodo falla, se bloquea o es observado.

La arquitectura se vuelve legible cuando separa los flujos por propósito:

management plane: operator -> access gateway -> team server
control plane:    agent -> redirector -> listener
data plane:       payloads, task output, files, logs
recovery plane:   provider console, backups, break-glass identity

El management plane transporta administración. El control plane mantiene la relación con agentes o implantes. El data plane mueve artefactos y resultados. El recovery plane permite recuperar el sistema cuando los caminos normales han fallado.

La separación produce decisiones comprobables. Una regla del control plane no abre el panel administrativo. El almacenamiento de logs no acepta escritura desde cualquier componente. La consola de recuperación no depende de la misma clave SSH que se está rotando. Si dos planos comparten red, cuenta o host, el diagrama lo muestra y el riesgo se acepta de forma explícita.

Las fronteras también explican la telemetría. El registrador observa la compra y los cambios del dominio. Certificate Transparency publica certificados de confianza pública. El proveedor ve aprovisionamiento, direcciones y métricas. Proxies, firewalls e IDS observan destinos, temporización y propiedades del protocolo. El sistema final puede registrar procesos, conexiones y archivos. OPSEC consiste en relacionar esas observaciones con la operación y reducir correlaciones innecesarias, no en suponer invisibilidad.

Mantén por recurso:

• infra_id
• proveedor y región
• dirección pública y privada
• dominio y TTL
• función
• servicio de origen y consumidores
• puertos administrativos y operativos
• identidad que lo administra
• registros y retención
• comprobación de estado
• condición de rotación
• limpieza

El inventario responde dos preguntas antes de una incidencia: qué depende de este recurso y qué debe cambiar si deja de estar disponible. Un dominio sin lista de listeners y certificados consumidores no puede rotarse con seguridad. Un redirector sin servicio de origen, comprobación de estado y propietario se convierte en una dependencia cuya retirada nadie puede demostrar.

Las plantillas de control operacional contienen un esquema inicial. Los secretos se referencian mediante identificadores, no se copian en el inventario. Los registros conservan tiempos coherentes, procedencia y políticas de acceso separadas de las credenciales operativas.

Una infraestructura no está lista cuando los procesos escuchan. Antes de utilizarla se validan resolución, TLS, rutas, filtrado, administración, sincronización horaria, registros, comprobaciones de estado y recuperación. Cada prueba debe realizarse desde la posición que utilizará el flujo real. Un listener accesible desde el propio servidor no demuestra que el redirector lo alcance ni que el agente reciba una respuesta coherente.

Durante la operación se vigilan cambios de certificado, reputación, errores del servicio de origen, latencia, volumen y disponibilidad. La rotación se activa por una condición definida, no por intuición. Puede responder a pérdida de una cuenta, bloqueo de un dominio, exposición de una dirección, fallo del proveedor o final de una fase.

La retirada es otra fase técnica. Incluye revocar claves y tokens, eliminar DNS, destruir instancias, verificar backups, cerrar accesos, conservar evidencia autorizada y comprobar que no quedan servicios públicos. Borrar una VM sin revisar certificados, objetos de storage y cuentas deja componentes activos fuera del inventario.

• Arquitectura y fronteras de confianza convierte funciones en flujos permitidos y dependencias.
• Dominios, DNS y certificados explica propiedad, delegación, TLS, observadores y rotación.
• Redirectors HTTP/S desarrolla filtrado, reenvío, autenticación del servicio de origen y fallos de encaminamiento.
• Ciclo de vida, rotación y retirada recorre aprovisionamiento, validación, operación, incidente y retirada.
• Checklist de readiness verifica que cada plano puede utilizarse y recuperarse.
• Cheatsheet de operación recupera comprobaciones ya explicadas sin duplicar el modelo.
• OPSEC y gestión de indicadores relaciona decisiones técnicas con los observadores de cada fase.

Las futuras páginas de C2 desarrollarán frameworks, perfiles y operación de agentes cuando la formación justifique activarlas. Esta rama conserva la arquitectura independiente del producto para que un cambio de framework no obligue a reaprender las fronteras.

El resultado esperado no es una topología grande. Es una topología explicable: cada componente tiene una función, cada flujo una razón, cada secreto un propietario y cada dependencia un procedimiento de recuperación o retirada.

• NIST SP 800-207: Zero Trust Architecture
• MITRE ATT&CK: Acquire Infrastructure
• MITRE ATT&CK: Command and Control