Red Team vs Test de Intrusión

Muy buenas a todos y feliz año 2019. Este primer artículo del año hemos querido dedicárselo al Red Team, uno de los servicios que en estos últimos 12 meses ha experimentado un crecimiento más exponencial, pero que sin embargo, no deja de ser un gran desconocido para muchos clientes y proveedores de servicios de ciberseguridad, por sus constantes confusiones con los ya tradicionales Test de Intrusión, utilizados habitualmente para descubrir si una organización es insegura. 

Hace unos meses publicamos el artículo Red Teaming: terreno de pasiones, mitos y fantasías, donde a modo introductorio comentabamos las principales diferencias sobre un Vulnerability Assessment, un Test de Intrusión y un Red Team. 

En ese artículo describíamos el objetivo del Red Team como un procedimiento para someter las ideas, planes, programas o suposiciones de una 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. 

Dando una definición más técnica, el Red Team podría definirse como un proceso de emulación de escenarios de amenazas a los que se puede enfrentar una organización, analizando la seguridad desde el punto de vista del adversario. 

El objetivo del Red Team, de forma general, es dar al equipo de seguridad de una organización la ocasión de defenderse frente a escenarios de ataques reales, de forma controlada y constructiva. Haciendo uso de las tácticas, técnicas y procedimientos observados en compromisos reales recientes, evaluando la capacidad real que tiene la compañía para proteger sus activos críticos, así como sus capacidades de detección y respuesta, y evaluando tanto el plano tecnológico, como el de procesos y el humano.

¿Esto qué quiere decir? Que el Red Team no es simplemente un proceso de intrusión, con movimientos laterales, ingeniería social y demás pruebas hacking, sino que es un proceso de entrenamiento. Un Red Team debe entrenar al Blue Team, y debe comprobar que los tres planos comentados, el tecnológico, los procesos y el humano, funcionan adecuadamente y de forma coordinada.

En la realidad de la empresa y a excepción de grandes entidades bancarias, infraestructuras críticas y algunos estados, cuyo nivel de madurez en seguridad es muy alto y donde un ejercicio Red vs. Blue a gran escala y en escenarios muy realistas tendría 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 aporta. Es necesario formar al Blue Team para que sepa reaccionar ante las amenazas reales. ¿De qué sirve un proceso de intrusión que finaliza con un informe, si el equipo de supervisión y respuesta no ha aprendido nada?

Esa es la clave del Red Team frente al Test de Intrusión, el entrenamiento, y es necesario que el Red Team se ponga al nivel del Blue Team para ello. Es ridículo sostener la visión del Red Teamer abusador, que quiere a toda costa demostrar al Blue Team que es mejor que él, y que no va a ser detectado bajo ningún concepto. ¿Qué aprendería un Blue Team en tal caso? Nada, sería un fracaso estrepitoso para el proyecto.

Bajo este enfoque colaborativo, desde Zerolynx abordamos los servicios de Red Teaming a través de dos ópticas diferentes:

Operaciones de Red Team

Este enfoque consiste en la realización de un ataque completo, con el objetivo de alcanzar una serie de objetivos que han sido previamente predefinidos junto al cliente. Normalmente, estos objetivos están relacionados con los peores casos posibles que pueden materializarse a nivel de negocio. En este caso, el equipo agresor realiza todas las etapas comunes de un ataque, desde el reconocimiento inicial, hasta alcanzar el objetivo.

Esta aproximación es la más agresiva, y está recomendada para aquellas organizaciones que, teniendo un nivel de madurez más alto, quieren poner a prueba su capacidad de protección de activos críticos frente a ataques dirigidos.

Red Team para la evaluación del SOC 

Este enfoque consiste en la simulación de ataques dirigidos en todas y cada una de las fases del ciclo del ataque, pudiendo además simular el comportamiento de uno o varios actores maliciosos diferentes. El objetivo de este servicio no es detectar vulnerabilidades, sino evaluar la capacidad de detección y respuesta de la compañía, por lo que un responsable de nuestro equipo acompaña en todo momento al SOC para guiar y evaluar su respuesta.

Esta aproximación ayuda a detectar deficiencias en la capacidad de detección y respuesta de la compañía, y a tomar decisiones de inversión en función de las evidencias recogidas, por lo que ofrece un valor muy importante a todas las organizaciones. Además, su aproximación menos agresiva a las Operaciones de Red Team, la hace especialmente recomendada para compañías con un menor nivel de madurez.

En la actualidad, existen diversas metodologías y frameworks, como la matriz ATT&CK del Mitre, y herramientas como Caldera o Infection Monkey, que facilitan en gran medida las tareas del Red Team, que por definición requieren de un equipo mucho más experimentado que el que colabora generalmente en un proceso de Pentesting tradicional. Con ellas, y con muchas otras llevamos trabajando bastante tiempo en Zerolynx para poder ofrecer servicios de Red Team de última generación, útiles y realistas y adaptados a las necesidades actuales de nuestros clientes.

Si deseas contactar con nosotros para hacernos algún tipo de consulta sobre nuestros servicios de Red Team, puedes hacerlo por los medios de contacto que figuran en la parte inferior el sitio web.

¡Saludos!

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.

Threat Emulation y TTPs

Una parte crucial de la Simulación de Adversarios en ciberseguridad es la utilización de TTP’s que usan los actores maliciosos reales. 

El concepto de TTP origina en la doctrina militar, y es acrónico de Tácticas, Técnicas y Procedimientos. Sin entrar en una descripción concreta de cada uno de los términos, sí que es importante entender a alto nivel dos conceptos clave:

• Las TTP sirven para caracterizar el modus operandi de un determinado adversario en el plano cyber, y para ello, describen qué es lo que hace y cómo lo hace. 

• Todos son descriptivos en su naturaleza, pero el nivel de especificación aumenta progresivamente. Así, las Tácticas son menos específicas que las Técnicas, y estas a su vez son menos específicas que los Procedimientos. En cierto modo, se comportan como una pirámide en la que cada nivel sirve para soportar al que tiene justo encima de él. 

Por ejemplo, una Táctica podría ser la obtención de un acceso inicial a la organización sin explotación de vulnerabilidades. Como vemos, es un concepto bastante genérico. Bajando un poco de nivel nos encontraríamos las Técnicas, que describen métodos de conseguir ese objetivo. En nuestro ejemplo, una técnica podría ser el uso de ataques de Spearphishing. Finalmente nos encontramos con los Procedimientos, que describen cómo el actor malicioso realiza la técnica paso a paso. Por ejemplo, el procedimiento podría ser recopilar información del sujeto a atacar, registrar un dominio parecido al de la organización, y mandar un email incluyendo un enlace que lleva a un clon de un portal corporativo con el objetivo de robar credenciales en claro que posteriormente se usarán para el acceso a la organización. 

Una parte esencial de la Simulación de Adversarios consiste en replicar con la mayor precisión posible a un actor malicioso concreto, y esto nos fuerza a conocer sus TTPs y nos restringe dentro de ese comportamiento. Utilizando estos conceptos podemos simular amenazas avanzadas dentro de nuestra organización y evaluar nuestras capacidades de detección y respuesta. 

En próximas entradas haremos hincapié en otro motivo por el cual es tan importante hacer uso de TTPs para afinar nuestros procedimientos de detección y respuesta ante amenazas.