Red Team en la práctica: ocho semanas dentro de una empresa
Lo esencial
- Ocho semanas de ejercicio: el perímetro expuesto aguantó entero y el dominio cayó igual
- La entrada no fue técnica, fue humana y física: ropa de trabajo, un papel con membrete, una sala de reuniones y una toma de red libre
- Una campaña de phishing dirigida produjo 260 credenciales válidas, devueltas de forma agregada y sin nombres
- Una autoridad de certificación mal configurada (ESC8) bastó para llegar a administrador de dominio, el privilegio más alto de un dominio de Active Directory
- Ninguna defensa generó una alerta. El hallazgo principal no es una vulnerabilidad: es un déficit de visibilidad
- En España eso tiene una consecuencia jurídica inmediata: sin detección no hay notificación en 72 horas ante la AEPD
- El tramo físico se ejecutó fuera de España. Aquí se encaja caso por caso, con mandato escrito y sobre instalaciones propias del cliente
¿De verdad hace falta un ejercicio de Red Team?
Imagina una organización de varios miles de personas. Se toma la seguridad en serio, invierte todos los años en proteger a su gente y su infraestructura, y tiene los deberes hechos: parcheo al día, cortafuegos revisado, doble factor. Aun así quedaba una pregunta sin responder, y es la que nos trajo el encargo. ¿Qué pasaría si alguien decidido y organizado la eligiera como objetivo, sin prisa y sin las restricciones de alcance que acepta un proveedor?
Durante ocho semanas simulamos exactamente eso. Lanzamos una campaña de phishing desde un dominio propio —260 credenciales válidas—, explotamos información de fuentes abiertas, cruzamos el perímetro físico con un pretexto, una tarjeta clonada y un implante de red, y terminamos abusando de una autoridad de certificación de Active Directory mal configurada para obtener privilegios de administrador de dominio.
Lo que deja ese recorrido completo, del primer reconocimiento al control de la infraestructura, no es una lista de fallos. Es otra cosa, y cuesta más de asumir: cada eslabón, mirado por separado, parecía menor. Una dirección de correo publicada. Un visitante no acompañado. Una plantilla de certificado con una opción de más. El riesgo no estaba en ninguno de ellos, sino en el hecho de que se encadenaran sin que nadie los viera pasar.
Qué evalúa un ejercicio de Red Team
Un ejercicio de Red Team mide la postura de seguridad de una organización entera, desde la frontera digital hasta el comportamiento de las personas. Reproduce lo que haría un atacante motivado, o una amenaza persistente avanzada (APT), si eligiera esa organización como objetivo: sin limitarse a un sistema, sin limitarse a una técnica y con tiempo para esperar.
La pregunta que responde no es «¿este sistema es atacable?», que es la que responde el pentesting. Es esta otra: ¿veríamos pasar un ataque real, y hasta dónde llegaría antes de que alguien reaccionara? Los dos ejercicios son complementarios y el orden importa; si todavía aparecen vulnerabilidades conocidas en lo que tienes expuesto a internet, empieza por ahí y vuelve después.
Este relato es la versión anonimizada de un ejercicio realmente ejecutado, publicada con el acuerdo del cliente. Todas las acciones descritas se realizaron dentro de un alcance pactado de antemano, con mandato escrito de una persona con poder para autorizar las pruebas y bajo reglas de enfrentamiento formalizadas. Ese mandato es lo que separa el trabajo de los tipos de los arts. 197 bis y 264 del Código Penal en su parte técnica, y del art. 203 del Código Penal en su parte física. Última verificación: 12 de septiembre de 2026.
Las fases del ejercicio
Dedicamos tanto tiempo a la preparación como a la ejecución. Por debajo hay un conjunto de metodologías de Red Team orientadas a identificar vulnerabilidades, valorar el riesgo y comprobar la eficacia real de las medidas en varios dominios a la vez. El ejercicio se dividió en fases distintas pero encadenadas:
- Reconocimiento de la superficie de exposición a partir de fuentes abiertas (OSINT)
- Pruebas sobre la infraestructura externa
- Pruebas internas en dos escenarios
- Intentos de intrusión física en tres sedes del cliente
- Campaña de phishing dirigida a la mayor parte de la plantilla
El perímetro externo aguantó
Como en todo ejercicio dirigido, empezamos por las pruebas externas: todo lo accesible desde internet. Revisamos con detalle las aplicaciones web, las pasarelas VPN, los servidores de correo y el resto de servicios publicados, buscando debilidades, software sin actualizar, errores de configuración o defectos de desarrollo.
El cliente estaba bien preparado. Los servidores tenían el parcheo al día y no había ninguna CVE conocida que explotar. El cortafuegos estaba correctamente configurado y los sistemas IDS/IPS vigilaban el tráfico sin dejarnos un hueco. Los intentos sobre la red Wi-Fi tampoco prosperaron, porque el acceso exigía certificado de cliente y autenticación multifactor.
Conviene decirlo tal cual, porque es un resultado en sí mismo: la parte del trabajo que se mide con una herramienta estaba hecha. Lo que viene a continuación es exactamente lo que esa medida no cubre. Si tu organización todavía no ha llegado a ese punto, el camino corto pasa por un análisis de vulnerabilidades antes que por un ejercicio como este; la diferencia entre ambos está contada en análisis de vulnerabilidades o pentest.
El OSINT demostró después su valor. Tras agotar los medios disponibles para reunir información publicada sobre la compañía, teníamos un organigrama, los nombres que aparecían en fuentes abiertas, direcciones IP, subdominios y datos sobre acuerdos y contratos. Poca gente declaraba su vínculo con la empresa en LinkedIn, señal de que ahí había una consigna de discreción que se respetaba. Aun así, el tamaño de la organización nos dio perfiles de sobra para seguir. Cruzamos lo obtenido con antiguas bases de datos filtradas y verificamos las direcciones de correo. El momento decisivo llegó por un defecto en un sistema interno, que nos reveló el formato exacto de las direcciones: nombre.apellido@empresa.com. Una precisión que importa, y que fijamos en el contrato: lo que se reúne en esta fase es superficie de exposición de la organización dentro del alcance contratado, no un expediente sobre personas concretas.
Después buscamos cruzar el perímetro físico en varias sedes. En una primera visita anotamos las entradas, los horarios y las rondas del personal de seguridad del edificio, los ángulos muertos de las cámaras y algún detalle más. Delante del inmueble había aparcado un vehículo de una empresa de revisión de equipos contra incendios, y decidimos que esa sería la vía. Tras una preparación breve de OSINT, uno de nuestros operadores se presentó como técnico de extintores, con la ropa de trabajo y el logotipo de la empresa inspectora, y un papel con membrete que autorizaba por escrito la revisión de los extintores y el acceso al edificio. El «técnico de extintores» consiguió quedarse solo en una sala de reuniones, donde localizamos una toma de red RJ45 oculta detrás de una pantalla de televisión. En pocos minutos instalamos un implante propio con conectividad 4G, lo camuflamos y salimos sin activar una sola alarma. A partir de ahí teníamos acceso persistente e invisible a la red interna, y montada la fase siguiente.
Ya teníamos acceso de red, pero el objetivo seguía siendo conseguir credenciales de dominio válidas. Partiendo de las direcciones verificadas en la fase de OSINT, lanzamos una campaña de phishing muy dirigida: nada de envíos masivos, sino typosquatting preciso sobre un dominio parecido al corporativo. Presentada como el anuncio de un nuevo sistema interno de incentivos, la página falsa de acceso a la intranet capturó credenciales, y cerramos la campaña de inmediato para reducir la probabilidad de detección. Esas credenciales recién obtenidas abrieron la exploración interna y prepararon la escalada de privilegios. Los resultados se devolvieron solo de forma agregada: ninguna persona de la plantilla fue puntuada ni identificada individualmente.
Las pruebas internas consistieron en la simulación de un puesto robado y en el trabajo sobre la red interna. Ahí apareció una vulnerabilidad ESC8 en la autoridad de certificación del cliente, que permitía solicitar cualquier certificado de Active Directory, incluido el del controlador de dominio. Confirmado el fallo con Certipy, usamos el módulo Coerce_Plus de Netexec para forzar al controlador de dominio a autenticarse contra nuestro servidor de retransmisión, y capturamos y retransmitimos esa autenticación con NTLMRelayX. La autoridad de certificación emitió un certificado de controlador de dominio y con él obtuvimos derechos de administrador de dominio. Es la prueba de que una defensa sólida se sigue rodeando con tácticas precisas. Ser administrador de dominio es el privilegio más alto al que puede llegar un atacante en un dominio de Active Directory: equivale al compromiso completo de la infraestructura, con acceso a todos los servicios y a los datos sensibles. Ese recorrido es el mismo que trabajamos en un test de intrusión de infraestructura, con la diferencia de que allí se avisa y aquí no.
Resultados
- Credenciales comprometidas. Una campaña de phishing de precisión produjo 260 credenciales de usuario válidas, lo que dejó a la vista debilidades tanto en el filtrado del correo como en la reacción de la plantilla.
- Acceso físico conseguido. Nuestro operador pasó el mostrador de recepción y clonó tarjetas RFID sin que nadie le preguntara nada, lo que permitió colocar equipamiento dentro de zonas restringidas.
- Escalada hasta administrador de dominio. Explotando la mala configuración de la autoridad de certificación de Active Directory (ESC8) conseguimos que se emitiera un certificado de confianza y obtuvimos el control administrativo completo, sin ser detectados.
- Detección nula. Ni los controles perimetrales, ni los IDS/IPS, ni los sistemas de registro señalaron nuestra actividad. El déficit de visibilidad es importante y es medible.
Por qué el cuarto resultado pesa más que los otros tres
Los tres primeros hallazgos se corrigen. Se cambia una plantilla de certificado, se revisa un procedimiento de visitas, se refuerza el filtrado del correo. El cuarto no se corrige: se construye. Una capacidad de detección son fuentes de registro, reglas, personas de guardia y un procedimiento escrito que alguien ha ensayado alguna vez.
Y ahí es donde este resultado deja de ser un asunto técnico. El art. 32.1.d) del RGPD exige «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas», y un ejercicio como este es precisamente eso. Pero hay una consecuencia más incómoda: el art. 33 del RGPD obliga a notificar una brecha de datos personales a la AEPD en un plazo de 72 horas desde que se tiene conocimiento de ella. Una organización que no detecta no puede cumplir ese plazo, porque el reloj no llega a arrancar. En este ejercicio, ocho semanas de actividad dentro de la red no produjeron un solo conocimiento del que partir.
El punto de contacto técnico en España para una empresa privada es INCIBE-CERT, que presta respuesta a incidentes y publica avisos de seguridad; INCIBE mantiene además la línea 017. Son recursos reales y gratuitos, pero solo entran en juego cuando alguien de dentro descuelga el teléfono. Es un buen resumen del problema: todo el plan de respuesta empieza en una detección que aquí no se produjo.
Sobre normativa, un apunte y seguimos. La gestión de incidentes figura entre las medidas de la Directiva (UE) 2022/2555 (NIS2), que no está transpuesta en España a 12 de septiembre de 2026; lo que sí obliga hoy y lo que no está explicado en NIS2 en España: qué obliga hoy y qué no. Lo que ya se aplica sin esperar a ninguna ley española es el Reglamento de Ejecución (UE) 2024/2690, que para determinadas entidades digitales exige una política de pruebas de seguridad y un procedimiento documentado de tratamiento de vulnerabilidades.
Recomendaciones
- Refuerza la seguridad física y el procedimiento de visitas. Barreras contra el paso en doble (tailgating), comprobación estricta de identidad y acompañamiento de la visita hasta que sale del edificio. La clave no es el torno: es que alguien tenga la obligación escrita de preguntar.
- Audita cada vector con regularidad. Perímetro expuesto, sistemas internos, sistemas de terceros, autoridades de certificación e infraestructura de red. Una autoridad de certificación es infraestructura crítica interna, aunque casi nunca figure en el inventario como tal.
- Trabaja el phishing y la ingeniería social con la plantilla. Escenarios realistas repetidos en el tiempo mantienen el reflejo mucho mejor que un correo anual; ese es el sentido de un programa de concienciación en ciberseguridad y de las campañas con PhishGun. Y mide la tasa de notificación, no solo la de clic: lo que salva a una organización no es que nadie pique, es que alguien avise deprisa.
- Vigila en tiempo real el equipamiento y la actividad internos. Un dispositivo que aparece en una toma de red de una sala de reuniones debería generar un aviso el mismo día, y un comportamiento de red anómalo también.
La ciberseguridad no se agota en la tecnología: es la combinación de personas, procesos y herramientas. Probar, aprender y construir resiliencia de forma continuada sigue siendo imprescindible, porque un atacante buscará siempre el eslabón más débil. La protección de verdad empieza en los reflejos y en la actitud de tu equipo.
Cómo encajamos un ejercicio de Red Team en España
El ejercicio que acabas de leer incluía un tramo físico, ejecutado fuera de España. Para el mercado español conviene poner tres cosas por escrito antes de hablar de escenarios, porque salen en todas las reuniones de alcance.
El tramo físico se estudia caso por caso. Una prueba de intrusión física autorizada por escrito por el cliente sobre sus propias instalaciones es lícita, y lo que la separa del art. 203 del Código Penal es ese mandato. El problema aparece cuando el recorrido atraviesa lo que el cliente no puede autorizar: un edificio compartido, un arrendador, un espacio de coworking, personal de seguridad subcontratado a un tercero. Ahí el consentimiento deja de cubrir la escena, y la respuesta correcta es recortar el alcance, no confiar en una cláusula. Cuando el tramo físico no cabe, el ejercicio se sostiene igual sobre los vectores digitales y humanos: reconocimiento OSINT, ataque al perímetro expuesto, phishing y pretexto telefónico, movimiento lateral interno y escalada de privilegios.
Una campaña de phishing sobre tu plantilla trata datos personales. Eso exige un trámite previo que en España es más exigente de lo que suele suponerse: los criterios de utilización de los dispositivos digitales se elaboran con participación de la representación legal de los trabajadores, por el art. 87.3 de la LOPDGDD, y el Tribunal Supremo declaró ese precepto imperativo el 6 de febrero de 2024. A eso se suma la información previa al personal, la base jurídica del RGPD con su juicio de ponderación, y resultados estrictamente agregados, sin informe nominal y sin sanción individual. Lo aplicamos por defecto, también cuando el cliente no lo pide. El detalle completo está en simulación de phishing y derechos de los trabajadores, y las técnicas que hay detrás de los pretextos, en qué es la ingeniería social.
Un ejercicio de Red Team no es un TLPT. El Reglamento (UE) 2022/2554 (DORA) regula las pruebas avanzadas basadas en amenazas para determinadas entidades financieras y fija en su art. 27 requisitos propios para quien las ejecuta. Es un régimen distinto, con su propia exigencia de acreditación: no lo prestamos ni decimos prestarlo. Un ejercicio de Red Team contractual como el descrito aquí puede ser una preparación previa razonable, pero responde a una necesidad de evaluación, no a una obligación regulatoria sectorial.
Un apunte final sobre tratamiento de datos. Haxoris es un proveedor europeo, con oficinas en Bratislava y Praga. Las evidencias recogidas durante el ejercicio, las capturas y el informe permanecen en la Unión Europea, con un plazo de conservación acordado en contrato y su supresión al vencimiento: sin transferencia internacional del capítulo V del RGPD y sin cláusulas contractuales tipo. Si tu pliego o tu comité de compras plantea la cuestión del proveedor no establecido en España, está tratada en contratar una empresa de pentesting no española.
Red Team en la práctica: preguntas frecuentes
01¿Cuánto dura un ejercicio de Red Team?
El que se cuenta aquí duró ocho semanas. La duración depende del número de escenarios acordados, de cuántas sedes entran en el alcance y del objetivo fijado: no es lo mismo demostrar acceso a una aplicación concreta que llegar al control del dominio. Se cierra en la reunión de alcance, contigo delante, y nunca antes de saber qué se quiere demostrar.
02¿Se avisa al equipo de defensa antes de empezar?
No, y ese es justamente el punto del ejercicio. Solo un círculo reducido de personas autorizadas lo conoce, con nombre y apellidos recogidos en las reglas de enfrentamiento. Ese círculo guarda el contacto de emergencia y puede detener el trabajo en cualquier momento, lo que además evita que un equipo de respuesta acabe activando un plan de crisis real contra un ataque que no lo es.
03¿Se evalúa individualmente a quien cae en el phishing?
No. Los resultados de ingeniería social se devuelven agregados, sin lista de nombres y sin consecuencias disciplinarias. El ejercicio mide a la organización, no a la persona que hizo clic un martes a las nueve de la mañana. Y hay además un motivo práctico que pesa más: si sancionas el error, compras silencio, y el silencio es exactamente lo que un atacante necesita.
04¿Se puede incluir el tramo físico en un ejercicio en España?
Se estudia caso por caso. Lo que hace lícita una prueba de intrusión física es el mandato escrito de quien puede autorizarla sobre instalaciones propias de la organización; sin ese mandato, los mismos actos entran en el art. 203 del Código Penal. El escenario se complica cuando hay edificios compartidos, arrendador, coworking o personal de seguridad subcontratado, porque entonces el consentimiento del cliente ya no cubre todo el recorrido. En esos casos se recorta el alcance o se sustituye por vectores digitales y humanos.
05¿Sirve para cumplir la NIS2 o DORA?
Sirve como evidencia de que se comprueba la eficacia real de las medidas, que es lo que pide el art. 32.1.d) del RGPD. No sustituye a un régimen sectorial. La Directiva (UE) 2022/2555 (NIS2) no está transpuesta en España a 12 de septiembre de 2026. Y un ejercicio de Red Team contractual puede ser preparación previa a un TLPT formal en el sector financiero, pero no lo sustituye ni lo realizamos: ese ejercicio exige proveedores que cumplan el art. 27 de DORA.
06¿Qué se entrega al terminar?
Un informe en español que reconstruye la cadena de ataque paso a paso, con las evidencias, el momento exacto en el que cada acción debería haber generado una alerta y las recomendaciones priorizadas por esfuerzo y por impacto. A eso se suma una sesión de presentación de resultados por videoconferencia con tu equipo técnico y con la dirección, y un retest para comprobar las correcciones aplicadas.
07¿Por dónde conviene empezar si nunca se ha probado nada?
Por el pentesting. Un test de intrusión te dice qué es vulnerable dentro de un alcance definido, y eso se corrige con una lista de tareas. Un ejercicio de Red Team responde a otra pregunta: si alguien explotara esas debilidades, ¿lo verías? Encargarlo antes de haber corregido lo conocido suele producir un informe caro que repite lo que un análisis de vulnerabilidades ya habría dicho. Para el orden de magnitud del presupuesto, mira cuánto cuesta un pentest en España.
En resumen
Este cliente hizo bien casi todo lo que se puede medir con una herramienta, y aun así perdió el dominio en ocho semanas. No por una vulnerabilidad espectacular, sino porque nadie miraba. Si te quedas con una sola frase de todo el artículo, que sea esta: un ejercicio de Red Team no mide el estado de tu parcheo, mide tu capacidad de ver y de reaccionar.
¿Quieres saber hasta dónde llegaría un atacante en tu organización? Hablemos del alcance y de los escenarios: solicita tu presupuesto, o mira cómo trabajamos el Red Team, el test de ingeniería social y la concienciación en ciberseguridad.
