Red Team: guía completa, TLPT de DORA, TIBER-EU y MITRE ATT&CK

Un Red Team es un ejercicio en el que un equipo ofensivo simula a un adversario real contra una organización, con un objetivo concreto y unas reglas acordadas, para comprobar si las personas, los procesos y la tecnología detectan y frenan el ataque. No busca todas las vulnerabilidades de un sistema, como hace un pentest: busca responder hasta dónde llegaría un atacante y qué vería la defensa por el camino.

Esta guía explica qué es y qué no es un Red Team, en qué se diferencia del pentest y del purple team, qué exige DORA con las pruebas TLPT (artículos 26 y 27), cómo se relaciona con TIBER-EU y TIBER-ES, las fases de un ejercicio, el papel de MITRE ATT&CK, los límites legales y cómo medir el resultado sin prometer cifras. El servicio está en pentesting y Red Team.

Qué es un Red Team

El marco europeo TIBER-EU describe una prueba de este tipo como una prueba controlada, a medida y guiada por inteligencia sobre las funciones críticas o importantes de una entidad y los sistemas que las sostienen (personas, procesos y tecnologías), que imita las tácticas, técnicas y procedimientos de atacantes reales [5]. Ayuda a evaluar las capacidades de protección, detección y respuesta [5].

Tres rasgos:

• Tiene un objetivo, no una lista de comprobación. En un TLPT de DORA, los objetivos se llaman «flags» (banderas): objetivos clave en los sistemas que soportan funciones críticas o importantes, que los testers intentan alcanzar [2].
• Es encubierto. Quien defiende no sabe que hay un ejercicio en marcha. El Reglamento Delegado 2025/1190 explica la razón: si el personal de seguridad lo supiera, estaría más atento que en condiciones normales y el resultado cambiaría [2].
• No se aprueba ni se suspende. TIBER-EU lo dice expresamente: el resultado no es «apto» o «no apto», sino una visión de fortalezas y debilidades para que la entidad aprenda y mejore su madurez [3].

En el Reglamento Delegado, «red team» designa a los testers (internos o externos) del ejercicio y «blue team» a quienes defienden los sistemas sin saber que hay un ejercicio [2]. En el uso corriente, «Red Team» nombra también el tipo de ejercicio.

Red Team, pentest, escaneo de vulnerabilidades y purple team

Son cosas distintas y se complementan. DORA lo refleja: su programa de pruebas enumera por separado, entre otras, las evaluaciones y escaneos de vulnerabilidades y las pruebas de penetración (artículo 25), y reserva las pruebas avanzadas basadas en amenazas (TLPT) para el artículo 26 [1].

Sobre la columna del pentest, el considerando 12 del Reglamento Delegado dice que las pruebas de penetración convencionales dan una evaluación detallada y útil de vulnerabilidades técnicas y de configuración, a menudo de un solo sistema aislado, pero no evalúan el escenario completo de un ataque dirigido contra toda una entidad, con sus personas, procesos y tecnologías; por eso pide a las entidades que, al elegir proveedores, comprueben que saben hacer red team guiado por inteligencia y no solo pentests [2].

El escaneo de vulnerabilidades es otra pieza: DORA lo cita como prueba distinta de la prueba de penetración [1]. Según el servicio de Hodeitek, los escaneos automatizados no detectan la lógica de negocio explotable, que sí analiza un pentest con metodologías como OWASP, PTES y MITRE ATT&CK.

El purple team merece una aclaración. El Reglamento Delegado lo define como una actividad colaborativa en la que participan los testers y el blue team [2]. En un TLPT aparece como recurso excepcional durante la fase activa, si no hay otra forma de continuar (por ejemplo, «catch-and-release» o «war gaming»), y como ejercicio obligatorio en la fase de cierre [2].

Cuándo tiene sentido un Red Team

TIBER-EU está pensado para entidades con importancia sistémica nacional o europea y suficiente madurez en TIC, aunque cualquier tipo o tamaño de entidad puede usarlo [5]. La guía TIBER-ES añade que las pruebas se hacen sobre producción y con proveedores externos, con un riesgo inherente y un coste alto que asume la entidad probada [6].

Conclusión nuestra, no exigencia de ninguna norma: un Red Team rinde más cuando ya existen controles, monitorización y respuesta a incidentes que poner a prueba. Si esa base aún no existe, un pentest dirigido puede ser más útil.

TLPT en DORA: artículos 26 y 27

DORA, el Reglamento (UE) 2022/2554, se aplica desde el 17 de enero de 2025 [1]. El artículo 24 pide a las entidades financieras (salvo las microempresas) un programa de pruebas y, al menos una vez al año, pruebas adecuadas de los sistemas y aplicaciones TIC que soportan funciones críticas o importantes [1]. El artículo 26 añade, para las entidades identificadas por las autoridades, las pruebas avanzadas basadas en amenazas, TLPT por sus siglas en inglés.

Fuente de la tabla: artículo 26 del Reglamento (UE) 2022/2554 [1]. Las entidades de crédito significativas (artículo 6(4) del Reglamento (UE) n.º 1024/2013) solo pueden usar testers externos conforme al artículo 27(1), letras a) a e) [1].

A quién se le exige

El artículo 26 deja en manos de las autoridades la identificación de las entidades, según el impacto, el carácter sistémico y el perfil de riesgo TIC [1]. El Reglamento Delegado (UE) 2025/1190, que desarrolla ese apartado, fija los criterios en su artículo 2 [2]. El apartado 2 enumera los tipos de entidad a los que las autoridades exigirán TLPT, salvo que su evaluación indique que no está justificado: entidades de crédito identificadas como G-SII u O-SII o integradas en sus grupos, entidades de pago y de dinero electrónico que superan ciertos umbrales de volumen, depositarios centrales de valores, entidades de contrapartida central, determinados centros de negociación y las aseguradoras y reaseguradoras que superan umbrales de primas, provisiones técnicas y activos [2]. Las autoridades pueden evaluar también otros tipos de entidad con los criterios del apartado 1 [2]. Si no sabes si tu entidad está identificada, la respuesta la da tu autoridad.

Requisitos de los testers (artículo 27)

El artículo 27(1) de DORA dice que las entidades solo usarán testers que [1]:

• tengan la máxima idoneidad y reputación;
• posean capacidades técnicas y organizativas y demuestren experiencia específica en inteligencia de amenazas, pruebas de penetración y red teaming;
• estén certificados por un organismo de acreditación de un Estado miembro o se adhieran a códigos de conducta formales o marcos éticos;
• aporten una garantía independiente o un informe de auditoría sobre la buena gestión de los riesgos asociados al TLPT, incluida la protección de la información confidencial de la entidad y la reparación de sus riesgos de negocio;
• tengan seguros de responsabilidad civil profesional adecuados, también frente a conductas indebidas y negligencia.

El Reglamento Delegado concreta cómo comprobarlo (artículo 7) [2]:

En circunstancias excepcionales, una entidad puede contratar proveedores que no cumplan alguno de los requisitos de documentación, seguro, referencias y composición del equipo, siempre que adopte y registre medidas que mitiguen ese riesgo (artículo 7(2)) [2].

Con testers internos, el artículo 27(2) exige además aprobación de la autoridad competente, recursos dedicados suficientes, ausencia de conflictos de interés y un proveedor de inteligencia externo [1]; el artículo 15 del Reglamento Delegado pide un equipo con un jefe de prueba y al menos dos miembros más, empleados de la entidad o de un proveedor intragrupo en los 12 meses anteriores [2].

TIBER-EU y TIBER-ES

TIBER-EU es el marco europeo de red teaming ético basado en inteligencia de amenazas. Lo desarrollaron conjuntamente el BCE y los bancos centrales nacionales de la UE y se publicó en mayo de 2018 [3]. Busca armonizar estas pruebas en Europa y facilitar su reconocimiento mutuo [5]. El BCE actualizó el marco para alinearlo con el RTS de DORA sobre TLPT (nota del 11 de febrero de 2025): el proceso se ajusta a los entregables y plazos del RTS, el purple teaming es obligatorio y el «White Team» pasó a llamarse «Control Team» [4].

Su relación con DORA tiene dos lados:

• El Reglamento Delegado 2025/1190 se redactó conforme a TIBER-EU y refleja su metodología, proceso y estructura. Las entidades pueden consultar y aplicar TIBER-EU o una de sus implantaciones nacionales en la medida en que sea coherente con los artículos 26 y 27 de DORA y con el propio Reglamento Delegado [2].
• Según el propio marco, una entidad que complete una prueba con una implantación nacional o europea de TIBER-EU cumplirá el TLPT de DORA, siempre que cumpla los requisitos formales que fijen las autoridades competentes [5]. Es una afirmación del BCE sobre su marco, no una decisión de tu autoridad.

TIBER-ES es la adopción española. En diciembre de 2020, la Comisión Ejecutiva del Banco de España aprobó adoptar el marco TIBER-EU, con la asistencia de la CNMV y de la DGSFP en las entidades de su ámbito [6]. La guía de implantación del Banco de España es de enero de 2022 y, según su texto, la participación de las entidades en esas pruebas era entonces voluntaria [6]. Es anterior a la aplicación de DORA: para el TLPT obligatorio de una entidad concreta, consulta a su autoridad y la documentación vigente; esta guía no determina qué autoridad es la competente.

Fases de un ejercicio

TIBER-EU define un proceso de tres fases obligatorias: preparación, pruebas y cierre [5]. El Reglamento Delegado 2025/1190 fija plazos para el TLPT de DORA [2]:

Las fases y los entregables son los de los artículos 9 a 14 del Reglamento Delegado [2]. El plan de corrección debe incluir, para cada hallazgo, la descripción de las deficiencias, las medidas propuestas con su prioridad y plazo previsto, el análisis de causa raíz, los responsables y los riesgos de no aplicarlas (artículo 13) [2]. Estos plazos son los del TLPT de DORA; un ejercicio voluntario puede tener otros.

Reglas de enfrentamiento y seguridad del ejercicio

Un Red Team toca sistemas reales, y las reglas de enfrentamiento (rules of engagement) acordadas antes son una de las formas de controlar el riesgo. En un TLPT de DORA se concretan así [2]:

• Evaluación de riesgos antes de empezar. El equipo de control evalúa los riesgos de probar sistemas de producción de funciones críticas o importantes, incluidos el de interrumpir actividades o corromper datos, el acceso de los testers a información sensible y la restauración incompleta de los sistemas (artículo 5).
• Secreto. Acceso limitado a quien necesita saber y, cuando es posible, nombre en clave (artículo 4).
• Plan de pruebas aprobado. Los testers elaboran un plan que incluye comunicación y uso de «leg-ups»; los cambios posteriores de calendario, alcance, sistemas objetivo o banderas los aprueban el responsable del control y los gestores de prueba (artículo 11).
• «Leg-ups». Son ayudas o información que el equipo de control da a los testers cuando no pueden avanzar por sí solos y no hay otra alternativa razonable, por ejemplo por falta de tiempo o de recursos (artículo 1). Los aprueban el equipo de control y los gestores de prueba (artículo 11) y, según TIBER-EU, se registran [5].
• Detección durante la prueba. Si alguien detecta la actividad, el equipo de control propone medidas para seguir manteniendo el secreto, que validan los gestores de prueba (artículo 11).
• Suspensión. En circunstancias excepcionales, con riesgo de impacto en datos, daños en activos o interrupción de funciones críticas, el responsable puede suspender el ejercicio o, como último recurso y con validación de la autoridad, continuar con un purple teaming limitado (artículo 11).
• Cierre limpio. Los testers restauran lo que han tocado y no pueden destruir equipos sin autorización, modificar de forma descontrolada información o activos, comprometer intencionadamente la continuidad de funciones críticas o importantes, incluir sin autorización sistemas fuera de alcance ni revelar resultados sin autorización (artículo 7).

Un ejercicio fuera de DORA no está obligado a seguir estos artículos, pero son una buena referencia de lo que acordar: alcance, exclusiones, ventanas, canal de emergencia y criterio de parada (criterio nuestro). En el servicio de Hodeitek, el primer paso es el scoping y las reglas de engagement: se definen alcance, objetivos, restricciones y canales de comunicación, y se firman acuerdos de confidencialidad y autorizaciones legales.

Límites legales en España

El Código Penal castiga, en el artículo 197 bis.1, al que «sin estar debidamente autorizado» acceda, o facilite a otro el acceso, a un sistema de información, o a una parte de él, vulnerando las medidas de seguridad, o se mantenga en él contra la voluntad de quien tenga derecho a excluirlo, y en el 197 bis.2 la interceptación no autorizada de transmisiones no públicas de datos informáticos [11]. El artículo 264.1 castiga borrar, dañar, alterar o hacer inaccesibles datos o programas informáticos ajenos, «sin autorización» y de manera grave, cuando el resultado es grave [11].

Qué suele hacer falta en la práctica (criterio nuestro, no asesoramiento jurídico):

• Autorización escrita y previa de quien puede darla, con sistemas, direcciones y ventanas concretos. Lo que queda fuera del alcance acordado no está autorizado.
• Acuerdo con los terceros afectados. Si el ejercicio puede tocar infraestructura de un proveedor (nube, hosting, proveedor TIC), tu autorización no basta. DORA lo prevé así para los proveedores TIC incluidos en un TLPT: la entidad debe garantizar su participación (artículo 26) [1].
• Autorización también para ingeniería social y acceso físico, con personas y sedes concretas.

Esta sección es información general: antes de un ejercicio, el contrato y las autorizaciones deben revisarlos quienes tengan la responsabilidad jurídica. Se cita el texto consolidado del BOE (última actualización publicada: 9 de abril de 2026).

MITRE ATT&CK

MITRE ATT&CK es una base de conocimiento de acceso global sobre tácticas y técnicas de adversarios basada en observaciones del mundo real. MITRE indica que sirve de fundamento para modelos de amenazas y metodologías en el sector privado, el gobierno y la comunidad de ciberseguridad, y que es de uso gratuito para cualquier persona u organización [7]. En la fecha de consulta, la versión vigente era la ATT&CK v20.1, del 13 de octubre de 2026 [9].

La matriz Enterprise ordena las técnicas por tácticas. En la versión consultada, las columnas eran Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Stealth, Defense Impairment, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration e Impact [8]. Esa lista cambia entre versiones: comprueba la vigente.

Usos habituales en un Red Team (criterio nuestro): un lenguaje común para describir lo que hizo el atacante y lo que vio la defensa, comprobar qué técnicas se probaron y cuáles no, y vincular cada acción ofensiva con su detección o con su ausencia.

Una precisión: ni TIBER-EU ni el Reglamento Delegado 2025/1190 exigen usar ATT&CK. El Reglamento pide documentar las tácticas, técnicas y procedimientos (TTP) usados con éxito y sin él [2], y el vocabulario con el que se documenten lo acuerdan las partes. En el servicio de Hodeitek, las metodologías declaradas son OWASP, PTES y MITRE ATT&CK.

Cómo medir los resultados sin prometer cifras

TIBER-EU no califica con aprobado o suspenso [3], y ninguna fuente de esta guía fija un umbral numérico de éxito. Los anexos del Reglamento Delegado sí definen qué contienen los informes de un TLPT, una buena lista de lo que medir [2]:

Dos lecturas útiles (criterio nuestro): cuántos «leg-ups» hicieron falta indica dónde se detuvo el atacante sin ayuda, y la correspondencia entre acciones y detecciones muestra qué ve y qué no ve la defensa. Ninguna es un resultado que se pueda prometer antes del ejercicio: depende del alcance, de los escenarios y de la organización.

El Red Team en Hodeitek

Hodeitek describe así su servicio de pentesting y Red Team: simulación de ataques reales sobre infraestructura, aplicaciones y personas, con metodologías OWASP, PTES y MITRE ATT&CK. El Red Team completo es una simulación de adversario avanzado con objetivos definidos, que combina técnicas digitales, sociales y físicas durante semanas de operación encubierta. El proceso incluye scoping y reglas de engagement, reconocimiento, explotación, post-explotación y pivoting, y un informe en dos niveles (resumen ejecutivo e informe técnico con evidencias) con vulnerabilidades clasificadas por criticidad (CVSS) y plan de remediación priorizado. El retest posterior es opcional y se presupuesta aparte.

Para el TLPT de DORA, el propio servicio avisa de que ayuda a cubrir el programa de pruebas pero no sustituye por sí solo los requisitos que el artículo 27 de DORA fija para los testers. Esa comprobación se hace caso por caso con la autoridad y con el proveedor.

Dónde encaja HodeiShield. Entre ejercicios, HodeiShield ofrece un radar de exposición que cruza los CVE críticos y altos de tus activos con los proveedores que los poseen, con sincronización periódica de sus fuentes, además de la puntuación de proveedores y los escaneos programados con seguimiento periódico. No sustituye a un Red Team: no simula a un adversario, no mide la detección y la respuesta y no sustituye a un TLPT.

Si tu duda es qué ejercicio elegir, tienes la comparación en Red Team frente a pentest. Para ver cómo se documenta un resultado, hay un informe de pentest de ejemplo con datos ficticios.

Relación con DORA y NIS2

Un Red Team no es una certificación ni cumple por sí solo un marco, pero puede aportar evidencia:

Esta guía no analiza el ENS ni ISO/IEC 27001: consulta la guía del ENS y la guía de ISO 27001. Si necesitas ordenar el cumplimiento antes de elegir pruebas, está la consultoría de GRC y cumplimiento.

Lista de comprobación antes de contratar un ejercicio

Errores habituales

• Esperar un aprobado o suspenso. TIBER-EU lo descarta: se busca aprender [3].
• Avisar a todo el equipo de seguridad. Si el personal que defiende lo sabe, estará más alerta y el resultado cambia [2].
• Empezar sin reglas, autorización ni acuerdo con los terceros afectados. Sin ellos, el ejercicio puede quedar fuera de lo permitido (véase la sección legal).
• Elegir al proveedor solo por precio. En un TLPT, DORA y el Reglamento Delegado fijan requisitos de idoneidad, referencias y seguro [1] [2].
• Saltarse el cierre. La repetición con el blue team y el purple teaming son parte del proceso, no un extra [2].
• Creer que un Red Team sustituye al resto de pruebas. DORA pide además un programa con pruebas periódicas [1], y un escaneo o un pentest responden a otras preguntas.

Esta guía es informativa y no sustituye al texto de las normas, a la decisión de la autoridad competente ni al asesoramiento jurídico. Actualizada el 13 de noviembre de 2026.