Introducción
En esta entrada, vamos a hablar sobre los servicios que envuelven a un Red Team o Red Team operations. Hace rato que vengo con ganas de escribir esta entrada. A diferencia de las que venimos escribiendo con mi compañero de aventuras (Javier), no va a ser técnica en sí (pero en la que vamos a clarificar los principales conceptos de este mundo).
Algo que nos viene pasando en los últimos tiempos es la necesidad de bajar a tierra los conceptos del mundo Red Team, versus lo que se encuentra a nivel papers y bibliografía (en relación a lo que realmente se puede poner en el contexto de un servicio mucho más tangible, más sencillo de explicar y/o de vender).
Hoy se habla mucho de Red Team (parece ser el nuevo «buzzword») así como desde hace mucho se habla también mucho de la «ciberseguridad», pese a que todavía mucha gente e incluso los profesionales de seguridad de la información, en algunos casos no siempre la pueden explicar con claridad.
Por esa razón vamos a introducirnos de lleno en explicar bien que es Red Team como servicio, sus implicancias y que diferencias tiene con el penetration test más tradicional.
¿Pentest / Red Team?
Lo primero que hay que desmitificar es que, más allá del nombre de «red team» las actividades que están implícitas dentro de dicho servicio o actividad por regla general son las mismas que están relacionadas a un pentest.
Entonces si esto es así, ¿cuál es la diferencia?, bueno básicamente el enfoque, por un lado, y por otro lado el scope o alcance. Como bien sabemos, un pentest suele tener un scope bastante definido, ya sea externo o interno en el cual se probará la seguridad de ciertos activos que la organización defina o desee que se testee, dentro del cual se probará tanto la seguridad a nivel de infraestructura cómo en muchos casos también la de los aplicativos web.
Normalmente muchas de las empresas que contratan servicios de pentest lo suelen hacer por algunas razones como cumplimiento normativo y/o regulatorio, o también, en el mejor de los casos, como proceso de buena práctica adoptada, pero normalmente dicho test se realiza una vez al año y sobre un número reducido de activos ya sea externo (típico caso) o en algunos casos también interno como complemento del anterior.
El problema es que esta modalidad tradicional representa una foto bastante parcial de la seguridad por varias razones, entre las que principalmente podemos mencionar que, estadísticamente las empresas cambian, migran o implementan nuevos componentes a nivel sistemas y por ende también de la infraestructura y red que la soporta, con lo cual la foto, en materia de seguridad, puede variar drásticamente de un año a otro.
Por otro lado, normalmente por un tema principalmente de costos y tiempos, los ejercicios de pentest suelen estar acotados a «una ventana de tiempo X dentro de la cual se pide testear ciertos activos que son de importancia para la compañía en materia de gestión de riesgos», pero se suelen dejar de lado algunos otros que en principio pueden parecer tener una importancia menor pero que no siempre es así.
Entonces ¿Qué es un read team?
Básicamente entonces, un servicio de Red Team, es un servicio en el cual, el scope o alcance es muchísimo más amplio y rico en relación a los activos y el tiempo para modelar los escenarios de ataque. Un servicio gestionado de Red Team no suele estar limitado en tiempos ni en infraestructura y aplicaciones a probar, y normalmente la ejecución del mismo suele ser tanto externo como interno, dando como resultado que el testeo de la postura de seguridad de la compañía sea mucho más real y completa que un penetration test tradicional.
Los Red Teamers tienen que identificar el riesgo para la infraestructura de red de una organización como una medida de pre evaluación para que la ejecución del compromiso pueda llevarse a cabo adecuadamente.
Para determinar tales riesgos, es responsabilidad principal de los operadores de Red Team reconocer las posibles amenazas o vulnerabilidades.
Los Red Teamers puede utilizar varias herramientas, ya sean de código abierto o comerciales, para reconocer vulnerabilidades y explotarlas en su beneficio. Sin embargo, el enfoque de Red Teaming es más profundo que el que siguen la mayoría de los atacantes potenciales porque intentan encontrar una sola vulnerabilidad, mientras que los profesionales de seguridad necesitan encontrar todas las vulnerabilidades posibles para una infraestructura determinada para evaluar el riesgo asociado.
En la siguiente imagen se muestra en letra roja algunas de las tareas diferenciadas entre un ejercicio de red team y un ejercicio de pentest:
Esta imagen en si misma muestra también, cómo un servicio de Red Team abarca 3 principales áreas clave a testear:
- Tecnología (A través del Pentesting)
- Personas (A través de la Ingeniería Social)
- Seguridad Física.
Cómo podemos Red Team ver es mucho más abarcativo que un simple pentest, ya que normalmente en un ejercicio de pentest rara vez se prueba la seguridad física (con todo lo que eso conlleva) o incluso no se generan actividades de OSINT y de perfilamiento de las personas clave que la componen (por un tema más que obvio, esto tendría un costo muchísimo más grande que un simple pentest a un número reducido de activos).
Dicho esto, podemos afirmar entonces que un servicio de red team, a diferencia de un pentest tradicional, tiene como finalidad probar la postura de seguridad real de una empresa, organismo o institución, desde una óptica mucho más real y profunda.
Ataque y Defensa – El Mundo de los colores de los TEAMS
El color «red» o rojo en el mundo de la seguridad informática para identificar a los que realizan las actividades ofensivas es tan antiguo como la seguridad informática en sí misma, de hecho, existen otros colores para identificar a otros grupos de especialistas como los siguientes:
El lector ya comprenderá que tengo debilidad por la franquicia de Marvel.
Los blue teams cómo se los conoce históricamente, son los equipos que engloban a los profesionales que se dedican a la defensa, a diferencia del red team. Son aquellos profesionales que trabajan en áreas de SOC (Security Operation Control), áreas de CSIRT (acrónimo ligado al concepto de respuesta ante incidentes) y otras áreas similares.
Normalmente estas áreas trabajan fuertemente en todo lo relacionado al monitoreo con tecnologías varias como los SIEM, generando junto al monitoreo, las diferentes correlaciones de eventos de las diferentes plataformas que se monitorean, enriquecimiento de los datos, triage y la generación de alarmas y niveles de escalamiento, etc.
Históricamente ambas partes siempre estuvieron separadas una de la otra o sin una colaboración mutua (que sea estrecha y con procedimientos compartidos). Para unir ambos mundos, eso es lo que representa a grandes rasgos el purple team. Un grupo de personas que trabaja colaborativamente como red o cómo blue, en dónde el espíritu en si es que las actividades del red team se compartan con la gente del blue («Offense informs Defense»). El objetivo es poder mejorar las defensas, el monitoreo y los protocolos de respuesta, para que, a medida que los equipos de red team ejecutan escenarios de ataque (Ya vamos a ver qué es esto) el equipo de blue team active los mecanismos de defensa correspondiente.
Está claro que más allá del enfoque que se tome, tener un área o servicio gestionado de Red Team maximiza la postura de seguridad de la compañía o entidad que adopte o contrate dicha práctica.
Algo de «Jargon»
Dentro de la jerga propia de la metodología de trabajo de un área o servicio de Red Team encontramos algunos términos cómo, por ejemplo:
- Threat (Amenaza)
- Threat Actor (Actor de Amenaza)
- Threat Vector (Vector de amenaza)
- External Threat Vector (Vector de amenaza externo)
- Internal Threat Vector (Vector de amenaza interna)
- TTPs (Técnicas, Tácticas y Procedimientos)
- Adversary Emulation (Emulación de Adversario)
- Adversary Simulation (Simulación del Adversario)
- Engagement (Ligado más al escenario de simulación o emulación)
Todos estos términos se acuñan y se complementan con los términos con los que normalmente estamos acostumbrados o familiarizados dentro de nuestro trabajo operacional como Riesgo (Risk), impacto operacional, etc.
Los términos «adversary emulation» y «adversary simulation» son MUY importantes porque definen GRAN parte de las actividades de un equipo de Red Team. ¿Porqué decimos esto? Sencillo porque definen las acciones que se realizarán, tanto manual cómo automáticas para reproducir un escenario en particular.
¿Qué prueba el red team?
Recordemos que el objetivo del Red Team, tal y como se menciona en el cuadro más arriba, es evaluar que tan bien el Blue Team monitorea, previene, detecta y acciona. Esta sentencia define en si misma el corazón del servicio de red team y su principal diferencia y foco de trabajo con un penetration test tradicional.
¿Porqué? Debido a que las actividades se planean con anterioridad y las mismas están basadas en escenarios y todas tienen SIEMPRE objetivos muy específicos en relación a lo que se quiere probar y testear:
- Defensas (Firewalls perimetrales e internos, Web application firewalls, ACLs de red, Seguridad en los sistemas operativos, Seguridad en bases de datos, IDS/IPS, Antivirus, EDR, Endpoint security, filtro de contenidos, etc)
- Monitoreo (SIEM, Registros de eventos, Alarmas, ofensas, etc.)
- Capacidades de respuesta (Tiempo de detección (TTD) y Tiempo de mitigación (TTM)
- Capacidad de Recupero
De acuerdo a los escenarios que el cliente quiera probar (o que el equipo de red team proponga), lo primero que se debe tener en cuenta es la premisa «¿Qué quiero exactamente probar?», «¿Que mecanismos de defensa o monitoreo o ambos quiero testear o poner a prueba?»
Adversary Emulation vs Adversary Simulation. ¿Cuál es la diferencia?
Emular puede significar reproducir una cosa con la intención de igualar o superar el original, mientras que una simulación es una imitación o aproximación y generalmente se basa en un modelo.
La diferencia es que en la emulación el red teamer utiliza cómo base los mismos TTPs (Tácticas, técnicas y procedimientos) que usan los adversarios y se basa en los mismos para diseñar un modelo de ataque en base a un escenario dado.
En el caso de la simulación (Adversary Simulation) el red teamer tiene que «literalmente» hacer lo mismo que el atacante o adversario y está más basado en toolkits y herramientas. La fase de adversary simulation puede ser tanto manual como automatizada (con herramientas como Caldera, Metta, Red Canary, etc.), cómo ya veremos un algún post posterior a este.
Tipos de emulación
La emulación de adversarios por parte de los equipos red team tiene muchas formas y se puede clasificar en términos generales como:
- un intento de compromiso «holístico«
- un intento de compromiso «específico«
- un compromiso «asumido«.
Emulación de compromiso «Holistico»:
Un intento de compromiso holístico es aquel en el que el equipo de red team persigue toda la superficie de ataque de la organización objetivo, con el objetivo de comprometer lo más posible.
El compromiso holístico puede considerarse la forma más auténtica y real de emulación del adversario, ya que el objetivo es un compromiso completo, y el punto de origen de quienes lo ejecutan, es probablemente Internet.
Ejemplo de compromiso Holístico:
Fuente: Professional Red Teaming. Jacob G. Oakley
En este modelo de escenario, la organización obtiene la simulación más realista para probar sus defensas, sistemas de detección y sistemas de respuesta. Sin embargo, este tipo de escenarios a veces puede ser menos eficiente y es muy probable que se provean resultados incompletos.
Si la evaluación de escenario holístico no puede comprometer una parte determinada de la organización debido a límites de tiempo o deficiencias de habilidades por parte del operador, los resultados del compromiso pueden ofrecer una falsa sensación de seguridad.
Emulación de compromiso «Específico»:
Los intentos de compromiso específicos son aquellos en los que se prioriza un determinado subconjunto de «superficies de ataque» para la evaluación y el resto de la organización está fuera de los límites.
Ejemplo:
Fuente: Professional Red Teaming. Jacob G. Oakley.
Los escenarios de compromiso específicos ofrecen una evaluación más eficiente y personalizada de una organización.
Normalmente se toman de acuerdo a un catálogo de escenarios conocidos propuestos, en relación a lo que se quiere lograr en cuanto a objetivos, y testeo de las defensas y respuestas, como así también muchas veces de acuerdo a ciertas tecnologías, plataformas de un escenario dado.
Este modelo no proporciona el potencial de tipo «big picture» de la postura de seguridad que muchas veces se logra con el escenario de «compromiso holístico», pero, sin embargo, dado que permite concentrarse en un subset específico de la organización en cuanto a superficies de ataque o tecnologías, la ejecución es más detallada más corta en su tiempo de duración y más factible para encontrar vulnerabilidades y sus mitigaciones.
El gran «factor» de diferencia entre el enfoque holístico y el específico es el «tiempo» por sobre todas las cosas.
Emulación de compromiso «Asumido»:
La emulación del escenario de tipo «asumido» es un tipo de tipo de escenario/actividad en el cual el equipo de red team comienza a operar con los accesos otorgados correspondientes, ya que se asume que el «breach» se seguridad ya ocurrió (y que se tiene un pie dentro de la red corporativa).
Son aquellos escenarios que se inclinan hacia ser más eficientes mientras dan una imagen potencialmente menos realista de un adversario.
Sin embargo, cuando se realiza y se analiza correctamente, este tipo de compromiso con el equipo de red team ofrece quizás, el mejor beneficio de costos para mejorar la postura de seguridad.
El compromiso asumido puede desglosarse en los tipos de acceso desde los que comienza la evaluación y su ubicación dentro de una organización.
Si los intentos de compromiso holísticos y específicos aprovechan una campaña de malware propagada por correo electrónico contra una organización, las evaluaciones de compromiso asumidas simplemente comienzan la evaluación del tipo de acceso que dicha campaña permitiría si fuera exitosa.
TTPs (Tácticas, Técnicas y Procedimientos)
Las TTPs o Tácticas técnicas y procedimientos son las técnicas en las cuales se basan las actividades usadas por los adversarios. Muchas veces no son tan concretas como los indicadores de compromiso (IOCs – indicators of compromise), los cuales suelen estar compuestos por hashes MD5/SHA1, nombres de archivo, claves de registro de Windows, direcciones IP, URLs, pero si describen como el adversario opera a alto nivel.
La emulación de adversarios (Adversary Emulation) debe basarse en los TTPs, por lo cual, un análisis de vulnerabilidad tradicional o una prueba de penetración interna que no se base en TTP «NO» debe considerarse un test de «Adversary Emulation».
La emulación de advesarios debe realizarse utilizando un enfoque estructurado el cual puede estar basado en la metodología de Kill Chain o también la de Mitre ATT&CK.
La Matriz de Mitre ATT&CK (https://attack.mitre.org/ ) es hoy por hoy la más aceptada y utilizada, ya que la misma es una base de datos viva en la cual la comunidad de Threat Intelligence trabaja activamente en su mantenimiento y actualización.
La misma está compuesta por una matriz de Pre Ataque junto a la matriz Enterprise con todas las Tácticas, técnicas y procedimientos documentados (TTPs) cómo se ve a continuación:
Escenarios
Dicho esto entonces, un escenario en dónde se «emula» un compromiso específico cómo vimos antes podría ser por ejemplo algo por el estilo:
Escenario de ejemplo: Proveedor malicioso que explota vulnerabilidades contra aplicaciones on line.
Por regla general los escenarios deberían contemplar ciertos componentes como:
- «Nombre del escenario»
- tipo de «cyber ataque» (en nuestro escenario de ejemplo sería «external threat vector» dado que la amenaza (Threat) es externa a la organización
- «Descripción» del mismo
- «Objetivo» del escenario (cómo por ejemplo que defensas se quieren probar o testear y las actividades mínimas involucradas.
Estas actividades involucradas son las que se corresponden con la metodología de trabajo propia del red team, las cuales van a tener tareas técnicas de base propias de un pentest asociadas a las mismas.
Cómo parte de la metodología de trabajo del red team para la ejecución de los escenarios, las actividades tienen que estar enfocadas en muchas tareas técnicas de un pentest. Estas actividades están orientadas a lograr acceder al objetivo, luego perpetuarse en él y por último generar acciones sobre el mismo.
Veamos un poco. Cómo parte del ciclo básico de un pentest las actividades a alto nivel siempre son:
Fases de red team
Estas fases son las que deben estar cómo actividades mínimas dentro de la metodología del red team. Para ellos las vamos a dividir en 3 fases principales y sub fases asociadas:
- GET IN: Reconocimiento – Enumeración y Explotación
- STAY IN: Post Explotación
- ACT: Actividades que se realizan sobre el objetivo. Fase ligada al impacto operacional.
Estas 3 fases y sub fases claramente van a tener otras actividades mínimas asociadas y tareas técnicas operativas asociadas a las mismas. En el siguiente gráfico se muestra metodológicamente las mismas:
Rules Of Engagement (ROE)
Los Rules of engagements o ROE como se las suele llamar, definen los lineamientos generales tanto de seguridad, cómo a nivel de operación que se deben considerar al momento de ejecutar el escenario elegido y modelado junto a sus actividades asociadas.
En nuestra experiencia hay varias formas de encarar los ROE. En nuestro caso particular nos gusta normalmente establecer los ROE a alto nivel y que los mismos sean parte contractual del servicio. Estos ROE en particular se deberían desarrollar y revisar para su aprobación con la empresa cliente, al igual que cuando definimos una política de seguridad con lineamiento generales y referencias a otros documentos como procesos o normas.
Creo que es importante, dado que muchas empresas u organismos en particular pueden estar muy regulados o también estar obligados a cumplir con determinadas normativas (tanto locales como internacionales en caso de tener casa matriz en el exterior o pertenecer a un conglomerado más grande).
ROE generales
Por dicha razón deberían tenerse las mismas como principal elemento de input para las ROE generales asociadas a servicio. En dichas rules of engagement, por regla general y cómo buena práctica recomiendo que tenga como mínimo:
- Actividades que el Red Team puede
- Actividades que el Red Team NO puede cumplir.
- Detalle de las personas involucradas en el servicio de red team
- Metodología de trabajo detallada. Asimismo, debería contener un listado de actividades detalladas y consensuadas con el cliente en relación a cómo se manejará la información sensitiva interna a la que el equipo podría llegar a acceder como parte de sus actividades. Tanto la resultante de sus operaciones cómo la que el cliente le provea para su análisis como input
- Personas responsables al servicio de red team por parte del cliente.
- Nivel detallado de trabajo de cómo el red team informará al cliente en relación a los hallazgos e impactos operacionales.
- Procesos de background check por parte de RRHH en relación a los operadores del red team.
- Documentación de anexo de los NDA (Non Disclosure Agreement) correspondientes a nivel contractual entre la empresa de servicio proveedora y el cliente.
- Documentos de NDA firmados propios de la empresa proveedora del servicio y los operadores o analistas del red team contratados o asignados al servicio.
- Documentación técnica operacional en relación a la configuración de los equipos de trabajo de los operadores de red team (cómo ser la cifrado de los volúmenes de disco, cifrado de carpetas y archivos sensibles, listado de herramientas que se utilizan, etc).
- Metodología de trabajo del red team a alto nivel.
- Detalle de la metodología de análisis de riesgo usada por el red team y consensuada con el cliente.
Estos ítems mencionados son un listado que contempla de mínima los ítems que deberían estar contenido, por supuesto que suelen ser varios más.
ROE especifico
Adicionalmente a estas Rules of engaments (ROE) mencionadas, deberían desarrollarse mediante algún documento de soporte un set adicional de Rules of engagement o ROE pero específicas a la ejecución de un escenario ya consensuado con el cliente.
Por regla general estas ROE deberían contemplar:
- Documentación del escenario a ejecutar y sus objetivos.
- Qué medidas de defensa se desean probar dentro del objetivo propuesto y mencionado (Defensa, Monitoreo, capacidades de respuesta, capacidades de recupero).
- Descripción de los activos tanto a nivel de direccionamientos IP, segmentos VLAN, servidores, aplicaciones y sistemas que entran en juego dentro de la ejecución de dicho escenario.
- Un detalle de los permisos de lo que está permitido realizar en dichos activos en la ejecución del escenario propuesto cómo también lo que no se puede realizar (ejemplo una modificación de clave de registro de uno de los servidores en particular).
- Listado de las personas de IT encargadas de dichas plataformas y sistemas (Activos). Al menos los referentes del área.
- Modelado del ataque y actividades mínimas involucradas.
- Esquema de aprobaciones (firmas) en la cual debe estar de mínima la persona encargada del servicio por parte del cliente junto a la del coordinador de red team y, en caso de ser un servicio contratado, la del dueño del servicio o consultora.
- Un esquema de escalamiento en caso de que ocurriera un incidente cuando el red teamer se encuentra testeando una plataforma en particular dentro de un escenario dado.
Pueden entrar en juego otros ítems por supuesto, pero menciono a grandes rasgos los que sin duda deben estar siempre contemplados.
Cierre de los escenarios
Una vez que se realiza la ejecución del escenario, es responsabilidad del equipo de red team remover y destruir de todos los ambientes alcanzados, todas las herramientas, artefactos, exploits y mecanismos de persistencia que se hayan utilizado.
En el caso de que se hayan deshabilitado los controles de seguridad del sistema de destino:
- Se deberán restaurar todos los controles de inmediato.
- Probar el control para garantizar la restauración.
- Notificar al personal de las áreas responsables correspondientes (previamente relevadas en el armado y modelado del escenario), en el caso de que alguno de los controles de seguridad no haya podido ser restaurado correctamente.
Otras modificaciones en los sistemas, que hayan sido parte del ejercicio, que se deberán revertir pueden ser (pero no se limitan a) las siguientes:
- Revertir modificaciones del sistema de archivos (Filesystem)
- Revertir modificación en ramas del registro de Windows.
- Eliminar mecanismos de acceso y / o puertas traseras.
- Remover los canales de command and control (C2) y mecanismos de persistencia utilizados.
- Terminar la comunicación que pueda quedar abierta de los canales de command and control (C2).
- Eliminar o reemplazar archivos de inicio con originales.
- Remover archivos binarios que se hayan subido al sistema a través de un método en particular.
Conclusión
Hasta este punto (creo no haberme olvidado nada) hemos llegado. Próximamente vamos a estar publicando una segunda parte de esta guía de introducción al Red Team. En ella cubriremos a nivel técnico/operacional otras cuestiones (cómo por ejemplo metodología a más bajo nivel y cuestiones relacionada a infraestructura mínima necesaria para la ejecución de un servicio de estas características).
La idea de esta serie de posts es mostrar e ir cubriendo los diferentes aspectos del servicio basado no sólo a las mejores prácticas que podemos encontrar en diferentes bibliografías, algunas de ellas recomendadas en el apartado «Bibliografia recomendada», sino también y por sobre todo, basado en la experiencia real aplicada en nuestros clientes en el día a día.
Es uno de los post o entradas más largas que hemos hecho hasta el momento. Creemos que la longitud vale la pena ya que, a diferencia del mundo del blue team cuya bibliografía está mucho más rica, madura y con existencia de frameworks técnicos operacionales, no sucede todavía lo mismo en el mundo del Red Team.
Si googleamos red team por supuesto que vamos a encontrar muchos links e información general y si buscamos fuentes de referencia o bibliográfica en lugares como Amazon, vamos a encontrar muchos libros, pero el 90 0 95% de esos libros terminan siendo libros técnicos de pentest en dónde tímidamente se menciona algo de red team.
Espero de corazón que esta guía les sea útil. Nos vemos en la próxima entrega.
Saludos.
Diego Bruno
Bibliografía recomendada
A continuación, hago mención a una serie de libros a modo de bibliografía que recomiendo, ya curada, en los que realmente encontré información útil en relación pura y exclusivamente a metodología de servicio de red team:
- Red Team Development and Operations: A practical guide. Joe Vest y James Tubberville ambos integrantes del fenomenal equipo de la empresa «SpecterOPS» quienes vienen siendo pioneros en este rubro.
- Professional Red Teaming: Conducting Successful Cybersecurity Engagements. Jacob G. Oakley. Apress. Libro que también recomiendo (puse un par de gráficos de referencia en la nota) por lo ameno de su lectura y lo bien escrito que está. Al igual que el anterior, está bien apuntado a los procesos y el entendimiento del servicio como tal.
- The Hacker Playbook 3: Practical Guide to Penetration Testing. De Peter Kim. Este libro es realmente excelente. Es de los primeros que trataron seriamente el tema. No es solo de metodología, sino que es bien técnico también. Es una obra imprescindible sin duda para quienes quieran profundizar en el tema.
- Hands-On Red Team Tactics: A practical guide to mastering Red Team operations. De Himanshu Sharma y Harpreet Singh. Este libro es una verdadera joya. Es posterior al de Hacker Playbook 3 pero explica increíblemente bien en los primeros dos capítulos todo lo relacionado al alcance de un red team y sus diferencias con el penetration test. Luego se mete por supuesto en cuestiones muy técnicas, pero excelentemente bien tratadas y explicadas. Importánte tener en cuenta que, al igual que el libro de The Hacker Playbook 3, son libros más bien técnicos y que por ende se desactualizan rápidamente a diferencia de los primeros dos recomendados que son púramente orientados a la metodología. Pero los menciono a ambos dado que son el ABC para entender en profundidad los conceptos técnicos relacionados al red team.
