Qué hace realmente un red team.

La mayoría imagina a un red teamer como alguien con capucha tecleando a toda velocidad hasta que una pantalla parpadea con un "ACCESO CONCEDIDO". La realidad se parece más a un proyecto largo, paciente y minuciosamente documentado que empieza con un contrato firmado y termina con un informe escrito lleno de recomendaciones. El trabajo de un red team no es "entrar hackeando": es responder con honestidad a una pregunta de negocio incómoda: si un adversario real y decidido se propusiera ir a por nosotros, ¿lo detectaríamos y lo detendríamos antes de que llegara a lo que de verdad importa?

Este es un análisis a fondo de cómo se responde a esa pregunta. Si primero quieres el mapa más amplio de quién ataca, quién defiende y cómo encajan los colores, nuestro desglose de los equipos red, blue y purple cubre esa bifurcación; este artículo da por hecho que ya sabes que el red team es el lado ofensivo y quieres ver por dentro un engagement real: la autorización que lo hace legal, el ciclo que sigue, las herramientas que utiliza y lo que acaba sobre la mesa del cliente al final.

Basado en objetivos, no en vulnerabilidades

El rasgo que define a un engagement de red team es que se construye en torno a un objetivo, no a una lista de comprobación. En lugar de "encontrar todas las vulnerabilidades", el mandato es algo como "demostrar que un atacante podría llegar al controlador de dominio", "demostrar que la base de datos de clientes podría exfiltrarse" o "probar que es posible un compromiso de correo corporativo (BEC) que derive en una transferencia fraudulenta". Todo lo demás —qué host comprometer, qué camino tomar— es un medio para ese fin.

Esa sola decisión cambia por completo el carácter del trabajo. Un red team ignorará cien vulnerabilidades reales si ninguna acerca al objetivo, y en cambio encadenará tres errores de configuración de baja severidad que un escáner califica como "informativos" hasta lograr un compromiso total, porque esa cadena es el camino realista. El resultado no es una lista de hallazgos ordenada por puntuación CVSS: es una historia: así es exactamente como alguien pasa de la internet pública a tus joyas de la corona, y cada punto del recorrido en el que podrías haberlo detenido y no lo hiciste.

La palabra que lo hace legal: autorización

Antes de enviar un solo paquete, el engagement vive por completo sobre el papel. Esto es lo que separa a un red teamer de un criminal que ejecuta comandos idénticos, y merece más que una nota al pie. El acceso no autorizado a un sistema informático es un delito en casi todo el mundo: la Computer Fraud and Abuse Act en EE. UU., la Computer Misuse Act 1990 en el Reino Unido y equivalentes en prácticamente cualquier país. Las herramientas que usa un red team son, despojadas de contexto, las mismas que usa un grupo de ransomware. La única diferencia es la autorización explícita, por escrito e informada de alguien con potestad para concederla.

Esa autorización se plasma en un alcance (scope) y un conjunto de Reglas de Enfrentamiento (RoE), negociadas y firmadas antes de que empiece nada. Un documento de RoE serio suele fijar:

• Qué está dentro y fuera del alcance: rangos de IP concretos, dominios, aplicaciones, ubicaciones físicas y personas. Todo lo que no se nombre queda vetado por defecto, no por omisión.
• Qué técnicas se permiten: ¿se admite el phishing? ¿La intrusión física? ¿Los ataques contra infraestructura de terceros o en la nube que el cliente no posee (que el proveedor también debe autorizar)? La denegación de servicio se excluye casi siempre.
• Fechas y ventanas: fechas de inicio y fin, horas permitidas y periodos de exclusión en torno a eventos críticos para el negocio.
• Tratamiento de datos: qué ocurre con cualquier dato sensible que el equipo toque, cómo se almacena y cómo se captura la "prueba" sin llegar a robar registros reales de clientes.
• Escalado y aborto: un punto de contacto designado y condiciones claras de "detener el ejercicio" si algo se rompe o se descubre un incidente genuino.
• Desconflicción: una forma de que el blue team o las autoridades sepan "¿esto es el red team o un atacante real?" durante el engagement.

Los operadores llevan consigo una carta de autorización —una especie de "carta de salir de la cárcel"— para mostrarla si un guardia o un administrador de sistemas presa del pánico los sorprende a mitad del ejercicio. Marcos impulsados por reguladores estandarizan todo esto: el marco TIBER-EU del Banco Central Europeo para red teaming basado en inteligencia de amenazas, y estándares de testing como NIST SP 800-115. Mantenerse con precisión dentro del límite firmado —y no "lo bastante cerca"— es una habilidad profesional esencial, no papeleo que despachar con prisa.

La forma de un engagement: el ciclo de vida del ataque

Una vez autorizado, un red team recorre un ciclo de vida reconocible. Dos modelos lo describen. La Cyber Kill Chain de Lockheed Martin ofrece una narrativa de siete etapas (reconocimiento, armamentización, entrega, explotación, instalación, mando y control, y acciones sobre los objetivos). MITRE ATT&CK es el modelo más granular y hoy dominante: una matriz viva de tácticas (el "porqué", el objetivo del atacante en cada paso) y técnicas (el "cómo"), catalogadas a partir de intrusiones reales. Los red teams planifican y elaboran sus informes sobre ATT&CK porque les da, a ellos y a los defensores, un vocabulario común. Este es el ciclo de vida, fase a fase.

Reconocimiento

Qué ocurre: el equipo aprende todo lo que puede sobre el objetivo sin tocarlo: estructura corporativa, nombres de empleados y formatos de correo, infraestructura expuesta, tecnologías en uso, credenciales filtradas. Gran parte de esto es puro OSINT. Ejemplo: recopilar correos y cargos de empleados desde LinkedIn y buscadores para armar una lista de phishing, y luego perfilar los servicios expuestos a internet con un escáner como Nmap o un mapeador de superficie de ataque como OWASP Amass (T1589, T1590).

Acceso inicial

Qué ocurre: el primer punto de apoyo autorizado dentro del perímetro. Ejemplo: un correo de spearphishing con un documento o enlace malicioso dirigido a una población de usuarios que ha dado su consentimiento (T1566), la explotación de una aplicación web expuesta y vulnerable (T1190), o sencillamente iniciar sesión con credenciales válidas encontradas en un volcado de brechas (T1078). Los engagements realistas demuestran a menudo que la opción aburrida —una contraseña reutilizada— funciona mejor que cualquier exploit.

Ejecución

Qué ocurre: el payload ejecuta código en el host comprometido. Ejemplo: una macro o un script que lanza PowerShell para cargar el implante del equipo en memoria (T1059.001). Este es el momento en que un producto de detección de endpoints (EDR) bien afinado debería gritar, y donde el red team descubre si lo hace.

Mando y control (C2)

Qué ocurre: el implante "llama a casa", abriendo un canal encubierto y resistente que el operador usa para controlar el host de forma remota. Ejemplo: un beacon que se camufla en el tráfico normal tunelizando sobre HTTPS hacia un dominio de apariencia legítima, con comprobaciones a un ritmo lento y con jitter para no destacar (T1071.001). El C2 es la columna vertebral de la fase de "mantenerse callado y persistente", y la elección del framework de C2 es una de las decisiones de mayor calado que toma un equipo (más sobre esto abajo).

Escalada de privilegios

Qué ocurre: convertir el acceso de un usuario normal en administrador o SYSTEM. Ejemplo: explotar una vulnerabilidad local sin parchear (T1068), abusar de un servicio mal configurado o volcar credenciales de memoria para encontrar una cuenta con más privilegios (T1003). En entornos Windows/Active Directory —donde ocurre la mayor parte del red teaming empresarial— mapear las rutas de ataque con BloodHound suele revelar una cadena de configuraciones incorrectas que lleva directa a administrador de dominio.

Movimiento lateral

Qué ocurre: saltar del primer host hacia los sistemas que de verdad contienen el objetivo. Ejemplo: reutilizar un hash de contraseña robado para autenticarse en otra máquina sin llegar a crackearlo —un ataque pass-the-hash (T1550.002)— o usar herramientas de ejecución remota como Impacket sobre SMB. La persistencia (sobrevivir a los reinicios, p. ej. mediante tareas programadas, T1053) y la evasión de defensas (ofuscación, deshabilitar el registro de eventos, T1027/T1562) corren en paralelo a lo largo de cada fase, no como un paso único.

Acciones sobre el objetivo y exfiltración

Qué ocurre: el equipo alcanza el objetivo acordado y lo demuestra, y después evidencia que los datos podrían salir. Ejemplo: extraer una muestra de registros de un repositorio sensible (T1213) y exfiltrar un archivo "canario" marcado y no real por el canal de C2 existente para probar que la ruta funciona de extremo a extremo (T1041), sin llegar nunca a sustraer datos reales de clientes, conforme a las RoE. Lo importante es la prueba; el robo nunca llega a producirse.

El ciclo de vida de un vistazo

"Assumed breach": saltar a la parte interesante

Conseguir ese primerísimo punto de apoyo puede llevarse semanas y, en un objetivo maduro, quizá no se logre nunca dentro de la ventana del engagement. Es un desenlace realista, pero es una forma cara de descubrir que el resto de tus defensas internas nunca se pusieron a prueba. Por eso muchos engagements modernos usan un modelo de assumed breach: el cliente entrega deliberadamente al red team una posición de partida —un portátil corporativo estándar, una cuenta de dominio con pocos privilegios o un implante ya instalado— como si un correo de phishing ya hubiera tenido éxito.

Esto no es hacer trampa; es economía y realismo. Los atacantes decididos acaban consiguiendo un punto de apoyo; la pregunta interesante es qué pasa después. El assumed breach garantiza que el presupuesto pone a prueba la detección y la respuesta a lo largo de la escalada de privilegios, el movimiento lateral y la exfiltración, en vez de consumirse todo en la puerta de entrada. Refleja el modelo de amenaza que la mayoría de las organizaciones afronta en realidad: no "¿puede entrar alguien?", sino "¿hasta dónde puede llegar antes de que lo notemos?".

Emulación de adversarios frente a simulación de adversarios

No todas las pruebas ofensivas intentan encarnar a un villano concreto. Dos enfoques relacionados pero distintos conviven bajo el paraguas del red team:

• La emulación de adversarios reproduce el modus operandi específico de un actor de amenazas real y con nombre propio. Si tu organización es un objetivo realista para un grupo como FIN7 o APT29, el equipo replica las TTP documentadas de ese grupo, en su orden, para comprobar si detectarías al adversario al que de verdad es probable que te enfrentes. La Adversary Emulation Library de MITRE publica planes ya preparados justo para esto.
• La simulación de adversarios es más amplia: ejercita un comportamiento de atacante realista en general para poner a prueba personas, procesos y tecnología, sin necesariamente suplantar a un grupo concreto.

Dos herramientas de código abierto vertebran este terreno. Atomic Red Team es una biblioteca de pruebas pequeñas y autocontenidas mapeadas a técnicas de ATT&CK: ejecutas un "atómico", compruebas si saltó tu detección y pasas a la siguiente. MITRE CALDERA automatiza cadenas enteras de técnicas para que una emulación completa se ejecute casi sin intervención. Ambas las usan también, y mucho, los defensores para validar sus detecciones: justo el punto en el que el trabajo rojo se vuelve púrpura, un bucle que nuestro desglose de roles del SOC muestra desde el lado azul.

La caja de herramientas

El instrumental de un red team se agrupa en torno al ciclo de vida. Para el reconocimiento: recopiladores de OSINT, Nmap, Amass y mapeadores de nube y de superficie de ataque. Para la post-explotación dentro de un parque Windows: BloodHound para el análisis de rutas de ataque, herramientas de credenciales como Mimikatz e Impacket para la ejecución remota.

La pieza central es el framework de mando y control (C2): la plataforma que gestiona los implantes, les asigna tareas y mueve datos. El estándar comercial es Cobalt Strike, tan extendido (y pirateado por criminales) que detectar sus valores por defecto es toda una industria artesanal defensiva. Eso ha empujado a los equipos hacia alternativas modernas, a menudo de código abierto: Sliver (basado en Go, multiplataforma y gratuito), Mythic (modular, con agentes intercambiables) y Havoc. La distinción entre un framework de explotación clásico y un C2 diseñado a propósito importa: nuestra comparativa Metasploit vs Sliver repasa en qué se diferencian de verdad dos de ellos.

Atravesándolo todo está la evasión y el OPSEC: la disciplina de no ser descubierto. Conceptualmente eso significa moldear el tráfico para que parezca normal, controlar cómo y cuándo llaman a casa los implantes, minimizar la huella en disco y ser deliberado con el ruido que genera cada acción. Los buenos operadores piensan como el blue team que los vigila: un red teamer que entiende lo que ve un analista de SOC en su SIEM le gana a uno que se limita a lanzar herramientas. Qué técnicas son aceptables lo delimitan las RoE.

Red team frente a pentest frente a purple team

Estos tres términos se usan indistintamente en las ofertas de empleo, pero son actividades realmente distintas con objetivos distintos.

Lo que realmente obtienes: los entregables

Un engagement vale exactamente lo que el cliente pueda accionar después. Un buen informe tiene partes bien diferenciadas. El resumen ejecutivo responde a la pregunta de negocio en lenguaje llano para la dirección: ¿se logró el objetivo?, ¿cuál es el riesgo?, ¿qué debería cambiar? La narrativa del ataque es el corazón del informe: un relato cronológico y legible de toda la intrusión, mapeado a ATT&CK con marcas de tiempo y evidencias, para que un defensor pueda reproducir cada paso. Y algo clave: empareja cada acción del atacante con la oportunidad de detección correspondiente: qué debería haber visto el blue team y por qué no lo vio.

Después llegan las recomendaciones priorizadas: no solo "parchea esta máquina", sino arreglos sistémicos: corregir esta configuración incorrecta de Active Directory, añadir esta regla de detección, segmentar esta red, retirar este protocolo heredado. Los mejores informes alimentan directamente la forma en que la organización decide qué proteger y dónde están sus puntos débiles: el mismo razonamiento que enfoques estructurados como el modelado de amenazas con STRIDE aportan a la fase de diseño. Muchos engagements terminan con un debrief de purple team y una nueva prueba, para que la lección cale en el lado defensivo en vez de acumular polvo en un PDF.

Cómo convertirte en red teamer

El red teaming no es un trabajo de nivel inicial, y tratarlo como tal es el error más común de quien empieza. No puedes atacar con credibilidad sistemas que antes no entiendes cómo construir y defender. Los mejores red teamers tienen una base real en redes, sistemas operativos (sobre todo Windows y Active Directory) y, a menudo, algo de tiempo en el blue team o como administradores de sistemas. Empieza por los fundamentos y luego añade la ofensiva por encima.

Para practicar de forma práctica, los laboratorios alojados son la vía de entrada habitual: Hack The Box y TryHackMe te permiten ejercitar el ciclo de vida completo de forma legal, contra máquinas creadas para ser atacadas. Monta un laboratorio casero con un pequeño dominio Windows y rómpelo una y otra vez.

En cuanto a certificaciones, tres forman una progresión realista. La OSCP (la PEN-200 de OffSec) es el referente práctico y conocido de los fundamentos ofensivos. A partir de ahí, las certificaciones específicas de red team profundizan en el oficio del engagement: la CRTO (Red Team Ops de Zero-Point Security, con mucho peso en C2 y Active Directory) y la PNPT (TCM Security), cuyo examen de cinco días termina en un informe y un debrief reales, más cerca del trabajo de verdad que un capture-the-flag puro. Las certificaciones abren puertas; la capacidad de razonar una ruta de ataque y redactarla con claridad es lo que las mantiene abiertas.

Una nota sobre autorización y ética. Todo lo que describe este artículo es trabajo realizado con permiso explícito y firmado contra sistemas que el cliente posee o está autorizado a probar. Las mismas herramientas y técnicas usadas contra un sistema para el que no tienes autorización por escrito son delitos, y punto, con independencia de la intención o la curiosidad. No hay zona gris ni defensa del tipo "solo estaba probando". Practica exclusivamente en sistemas de tu propiedad, en laboratorios deliberadamente vulnerables o en plataformas como Hack The Box y TryHackMe que te conceden ese permiso. La autorización por escrito no es una formalidad que rodea al trabajo: es el trabajo.

Preguntas frecuentes