Arquitectura y fronteras de confianza

La arquitectura define qué componente puede autenticar, enrutar, leer, modificar y recuperar. El objetivo no es añadir capas por apariencia, sino impedir que un frontal expuesto otorgue acceso directo al estado más sensible.

operador
     |
     | identidad administrativa + MFA
     v
ruta de acceso ------> team server
                         |
                         | estado del listener, claves y tareas
                         v
              listener/servicio de origen
                         ^
                         | proxy inverso autenticado
                         |
agente en el objetivo -> Internet -> redirector HTTP/S

El redirector conoce el origen de la petición, su contenido y la ubicación del servicio de origen (upstream). No necesita credenciales administrativas del team server. El team server no necesita escuchar públicamente si solo acepta conexiones del redirector y del canal de operadores.

El team server concentra:

• configuración de listeners
• claves y perfiles
• identidades de operadores
• agentes y asignación de tareas
• resultados y archivos
• credenciales o secretos recogidos

Reduce los servicios, separa la administración del C2, cifra el almacenamiento y registra las acciones de cada operador. Una instantánea (snapshot) en caliente puede reducir el tiempo de recuperación, pero también puede contener sesiones, claves y estado inconsistente. Prueba la copia de seguridad y su restauración con la versión exacta del framework.

Un listener recibe un protocolo y lo asocia con un perfil, unas claves y un comportamiento. Un agente implementa el transporte, los intervalos de espera (sleep), su variación (jitter), la recepción de tareas y la ejecución. La comprobación de salud del listener debe verificar más que un puerto:

1. resolución y TLS desde el redirector
2. ruta admitida por el perfil
3. autenticación del protocolo
4. registro en team server
5. ida y vuelta de una tarea no modificadora mediante un simulador

No uses un agente implantado en un objetivo para la única prueba de salud. Necesitas un simulador o un entorno de preproducción.

Un redirector HTTP/S filtra y reenvía tráfico. Un nodo de salida cambia el origen de una operación. Pueden compartir software, pero resuelven problemas distintos.

El filtrado puede usar:

• nombre y SNI
• método
• ruta HTTP
• cabeceras
• cookie o token de perfil
• horario o origen
• versión de protocolo

Cada condición añade una forma de bloquear también al agente legítimo. Prueba positivos y negativos.

Separa:

• acceso administrativo
• acceso público al redirector
• comprobaciones de estado
• errores del proxy inverso
• listener y framework
• acciones de operador
• recursos del proveedor

Sin separación, una comprobación de estado puede parecer tráfico procedente del objetivo. Sin un reloj sincronizado, no se puede reconstruir una ruta entre proveedores.

Los registros pueden contener direcciones del objetivo, rutas, identificadores y payloads. Define minimización, acceso y retención. Eliminar toda observabilidad para reducir indicadores también elimina información necesaria para recuperar la operación.

Cada fallo tiene una ruta de recuperación que no depende del componente roto.

• OWASP: Transport Layer Security Cheat Sheet
• NIST SP 800-207: Zero Trust Architecture