Red Teaming: terreno de pasiones, mitos y fantasías

Dentro de los servicios ofrecidos por las empresas de ciberseguridad, uno de los que más pasiones levanta es el de Red Teaming. Cada vez es más habitual escuchar este término en todo tipo de conferencias y artículos, con detalladas explicaciones sobre cómo saltarse la seguridad física de un entorno para colocar un implante hardware que nos permita conectarnos remotamente, con explicaciones de diversos ataques de ingeniería social y phishings a los empleados de una organización, o con listas y explicaciones sobre cómo usar los últimos “Living-Off-the-Land Binaries” o LOLBins, aplicaciones, scripts y librerías nativas que pueden ser usadas y abusadas para ejecutar código adicional, como podrían ser rundll32, regsvr32, msbuild, y muchísimas otras más. Sin embargo, ¿tenemos todos claro lo que significa Red Teaming?

Pruebas con Lolbins

Cuando un cliente solicita un análisis de vulnerabilidades, casi todos estaremos de acuerdo en que busca escanear una aplicación, servicio o infraestructura (interna o externa) con herramientas automáticas de detección de vulnerabilidades. Al final, el objetivo será conseguir un informe con todas las vulnerabilidades detectadas, que con suerte, nos entregarán limpio de falsos positivos, y podremos finalizar el proyecto. 

Cuando los clientes requieren un test de penetración, las cosas empiezan a dejar de estar tan claras y suele ser necesario aclarar qué busca exactamente el cliente. Bajo el mismo paraguas de “test de penetración” se suelen requerir una gran variedad de servicios: 

• Una revisión completa (automática y manual) sobre una aplicación, estando el pentester en listas blancas, con el objetivo de detectar el mayor número posible de vulnerabilidades para su posterior corrección.

• Una demostración sobre si somos capaces de penetrar en el perímetro de la organización a través de una aplicación con todas las defensas levantadas… en ocasiones bajo la premisa del "realismo". Eso sí, indicando que las denegaciones de servicio, la ingeniería social al personal, o los ataques a cualquiera de las otras 200 direcciones IP identificadas en la organización no están permitidas. Es decir, que se busca un escenario "realista" en el que el realismo consiste en que el atacante está limitado a atacar un único activo, altamente bastionado, monitorizado y protegido por todo tipo de soluciones de seguridad. Este tipo de proyectos, aunque necesarios para revisar, por ejemplo, la correcta configuración de las medidas de seguridad desplegadas para proteger un activo, desde luego no deberían ser justificados con el “realismo”, porque por todos es conocido que el adversario ataca siempre al eslabón más débil, y nunca al más protegido.

• Una auditoría de seguridad interna con más o menos limitaciones, en la que se suelen permitir tanto el uso de equipos informáticos de los auditores, como de equipos plataformados por la organización. El objetivo es demostrar hasta qué punto lograrían penetrar, simulando por ejemplo, a un usuario que se convierta en malicioso. Este tipo de proyectos suelen acabar con el pentester alcanzando permisos de Domain/Enterprise Admin, desgraciadamente, con más frecuencia de la que debería.

• Y cualquier combinación más o menos acertada de las anteriores.

Por este motivo, cuando empezamos a hablar de Pentesting siempre nos sentamos con el cliente para que nos explique su nivel de madurez percibido, qué busca exactamente conseguir a través del proyecto, e intentamos guiarle y sugerirle la forma de obtener el mayor beneficio frente a su inversión. 

Y finalmente llegamos al Red Teaming: terreno de pasiones, mitos y fantasías. Desconozco si es una cuestión de oportunismo, de curiosa fascinación ante la terminología militar que atrae a todo tipo de perfiles, o de falta de conocimiento y consenso alrededor del término, pero es en este terreno donde apreciamos mayor falta de precisión. ¿Tiene que ver todo esto con que cada vez más directores, managers y otros responsables en el lado del cliente reconozcan en privado que no están, para nada, del todo satisfechos con los servicios que les han ofrecido hasta el momento en este tipo de proyectos?  

Cuando se habla de Red Teaming con alguien, la respuesta suele derivar rápido a una suerte de proyectos de pentesting avanzado en el que no hay reglas, todo está dentro del alcance, y el equipo de seguridad puede hacer lo que desee para entrar hasta la cocina. Y a ser posible, en proyectos de larga duración con perfiles muy senior, debido a que van a tocar sin límites. Al menos, déjame que te garantice que no van a cometer ningún error que pueda impactar a tu negocio. Pero… ¿de verdad no hay reglas y todo está en el alcance? 

No solo puede, sino que debe haber reglas en cualquier proyecto de Red Teaming. 

¿De qué hablamos cuando decimos que no hay reglas? ¿De la posibilidad de utilizar ataques lógicos, físicos, e ingeniería social? En un proyecto de Red Teaming es posible evaluar cualquiera de esos planos de la seguridad de la organización de forma independiente, o una combinación de ellos, pero no tienen por qué incluirse en el proyecto para que se trate de un proyecto de Red Teaming.

No solo puede, sino que hay restricciones en cualquier proyecto de estas características.

¿Qué pretendemos con esta supuesta carencia de restricciones, emular el auténtico comportamiento de un adversario real, un auténtico APT? ¿Darle realismo al proyecto? Se sabe de actores maliciosos que han atacado a los activos personales de los empleados, como el correo electrónico o el ordenador personal, para así poder atacar a la organización. ¿Estará esto también dentro del alcance? También es cada vez más habitual atacar a los proveedores o a la cadena de suministro. A ver como explicamos a todos los proveedores para que firmen un consentimiento expreso..., ya no sólo para ser auditados, sino para recibir ataques sin límites, en cualquier momento y por parte de un equipo de seguridad avanzado. Suerte con esto de intentar modelar la auténtica ausencia de reglas que tienen los criminales de verdad o un grupo amparado por el estado, así como los recursos y tiempo del que ellos disponen.

¿Hace falta invertir tanto dinero para demostrar la obviedad de que sin reglas, con recursos y suficiente tiempo se pueden colar en casi cualquier sistema? La respuesta es ¡no!, no hace falta que se demuestre, ya que la respuesta os la podemos dar en este mismo artículo, ¡y gratis! Esto hace tiempo que está superado y se llama modelo de compromiso asumido. Es necesario asumir que se van a colar en un sistema y empezar a trabajar en las capacidades de monitorización, detección y respuesta de la organización. Se debe preparar el entorno interno para que, dando por hecho que se van a colar, su capacidad de movimiento esté muy restringida, que va a ser detectado lo antes posible, y que la respuesta ante dicha detección va a ser la adecuada.

Por tanto, es necesario realizar pentests para verificar que la seguridad lógica está debidamente implementada, es necesario realizar pentest físico para verificar que nadie puede saltarse el perímetro de seguridad de nuestras instalaciones, y es necesario evaluar la concienciación de nuestros empleados frente a ataques de ingeniería social. Por separado o todo a la vez. Pero si en un proyecto se te cuelan, te entregan un informe con la metodología y las vulnerabilidades explotadas, y acto seguido se acaba el proyecto, entonces difícilmente te habrán hecho un ejercicio de Red Teaming. Te habrán hecho un pentest, más o menos avanzado, pero, al fin y al cabo, un pentest.

¿Entonces qué es el Red Teaming, y qué lo hace diferente? 

Para empezar, es importante entender que cualquier organización está formada por un conjunto de personas con una cultura, forma de pensar y de trabajar propias. Como cualquier sistema humano, la organización puede fallar, es susceptible a creencias, prejuicios y tiene sus propias limitaciones que pueden provocar sesgos en la capacidad de análisis y toma de decisiones.

El objetivo del Red Team es, en general, someter las ideas, planes, programas o suposiciones de la organización a un estricto análisis, con el objetivo de identificar suposiciones incorrectas, opciones alternativas no contempladas, y detectar vulnerabilidades o riesgos que puedan afectarla. Una de las formas más habituales de hacer esto, como podemos imaginar, es tomar la perspectiva del adversario. Sin embargo, debemos dejar claro que es igualmente válido como Red Teaming el sentar a una persona ajena a la organización y por tanto a sus prejuicios y suposiciones, junto a los responsables de ejecutar la respuesta a incidentes, con la finalidad de evaluar y cuestionar los planes definidos sobre el papel, como ejecutar un ejercicio en vivo para verificar si además de los planes correctos, existen las adecuadas capacidades de ejecución y coordinación necesarias en dichos planes. En función de la madurez de la organización, se necesitará una u otra cosa.

Por otro lado, es fundamental conocer la organización para entender su modo de operar y sus procesos internos. Es importante entender que no se evalúan simplemente las tecnologías, sino que también se quieren evaluar los procesos y personas que las acompañan. Una gran parte de las ocasiones, son los propios responsables dentro de la organización los que ya tienen identificadas posibles debilidades y procesos que pueden generar riesgos a la organización. Son ellos los que pueden guiar al Red Team hacia procesos o tecnologías que deben ser analizadas, eso sí, con la experiencia particular que este grupo tan especializado puede aportar. Por ejemplo, si se han tenido numerosos incidentes relacionados con el malware recientemente, quizás merezca la pena incorporar a un especialista para analizar tanto las soluciones tecnológicas antimalware desplegadas en la organización a todos los niveles, como los procesos y personas que deberían acompañar a estas tecnologías para que realmente sean efectivas. ¿Es nuestro sistema antimalware tan bueno como creemos? ¿Cubrimos realmente todas las vías de entrada de malware a la organización? Cuando detectamos malware en un dispositivo, ¿realmente actuamos de la forma correcta? ¿Cómo sería de fácil para un malware que no ha sido detectado propagarse a través de nuestra red? ¿Tenemos definidos los planes de actuación para responder en casos como este? ¿Están las personas adecuadas informadas, entrenadas y preparadas para actuar acorde a estos planes? Estas y otras preguntas son preguntas que puede responder un Red Team, siendo posible utilizar sus conclusiones para el apoyo a la toma de decisiones internas.

En general, a no ser que el nivel de madurez en seguridad de la organización sea muy alto y los recursos no supongan un problema, donde un ejercicio Red vs. Blue a gran escala y en escenarios muy realistas tenga sentido, para la gran mayoría de las organizaciones la aproximación basada en la colaboración constante entre el personal interno y el externo es la que más valor aportará. Y es que esta es una de las claves de cualquier ejercicio de Red Teaming, una de las cosas que más valor aporta con respecto a un pentest genérico, el entrenamiento al personal interno, incluyendo al Blue Team.

Si al final del proyecto la organización no ha aprendido, y el Blue Team lo único que puede afirmar es que ha sido evadido, entonces el proyecto no ha sido un éxito.

Supongamos que desplegamos una infraestructura de Red Teaming con las siguientes características:

• Direccionamiento IP repartido entre diferentes proveedores a lo largo del mundo.
• Con dominios registrados de forma anónima.
• Usando hosts de redirección para proteger la infraestructura real usada por los operadores.
• Con mecanismos preparados para evitar la entrega de payloads al Blue Team, por ejemplo, a través de la detección de sistemas operativos y/o navegadores no utilizados por la fuerza de trabajo común.
• Usando cifrado y Domain Fronting para proteger y camuflar las comunicaciones. 
• Generando agentes de alta y baja interacción, que permitan recuperarnos en el caso de que los primeros caigan. 
• Etc.

De nada serviría hacerlo si luego resulta que, después de todo, el nivel de madurez de la monitorización, detección y respuesta interna no es el adecuado para enfrentarse a este tipo de ejercicio, y, por tanto, el personal interno no aprenderá en el proceso.

Todo ejercicio de Red Teaming debe ser correctamente medido, escalado, y adaptado a cada organización, y esto empieza por la colaboración constante entre ambas partes, que nos permita decidir si lo que se requiere es un escenario como el que arriba se plantea, o si sólo es necesario generar, partiendo del compromiso asumido, determinados eventos de seguridad para confirmar si nuestros sistemas de detección están correctamente parametrizados o no, si es necesario realizar una mayor inversión en tecnología o personal que permita una mejor detección y respuesta, o si nuestro proveedor de servicios de CSOC es el adecuado.