Como ya podéis suponer por anteriores spoilers, en esta tercera parte de la serie (ver primera parte y segunda parte), tras haber dejado claro el papel que juega la Inteligencia de Amenazas en la metodología Purple Team, entraremos un poco más en detalle sobre las fases de preparación, ejecución y lecciones aprendidas en un ejercicio.
Disclaimer: Como ya comenté en el primer episodio, no pretendo sentar cátedra con este artículo sino más bien, aportar mi punto de vista y aportar una visión de conjunto sobre el un tema del que no se encuentra gran cantidad de documentación (sobre todo en español), y la que se encuentra, está dispersada en múltiples fuentes.
Tras haber desarrollado un plan de ejecución tomando como referencia el mapeado de las amenazas sobre la MITRE ATT&CK MATRIX, es hora de llevar a la práctica todos los casos de uso. Para ello usaremos Vectr.io, una plataforma web de código abierto desarrollada por Security Risk Advisors.
Esta herramienta se encarga de centralizar todas las tareas de coordinación de los equipos Red y Blue. Pero lejos de ser una herramienta solo para coordinar los ejercicios, también está preparada para ser utilizada como una suerte de bitácora de todas las operaciones ejecutadas en diversos ejercicios a lo largo del tiempo, de forma que se pueda realizar un seguimiento de la evolución de la postura de seguridad de la organización a lo largo del tiempo.
Con una descripción abstracta como la anterior, puede ser difícil imaginar cómo se consigue todo esto. Por ello, el objetivo de este post es optar por un enfoque más práctico.
En aras de la brevedad, no vamos a entrar en detalle de todas las funcionalidades de esta herramienta sino que mostraremos las posibilidades que ofrece y como estas nos pueden ayudar con nuestro objetivo. Será de ahí en adelante tarea de cada uno explorar las funciones más avanzadas y evaluar si le son útiles para su caso particular.
Primeros pasos
Lo primero para poder aprovechar esta herramienta es instalarla.
Se puede instalar de forma relativamente sencilla mediante docker-compose, pero si nuestro objetivo no es usarla en producción, es cómodo usar la VM slingshot C2 de SANS que ya lleva todo instalado (además de muchas otras cosas que no son objeto de este artículo). El único problema es que la versión instalada no cuenta con las funcionalidades implementadas recientemente.
Uno de los puntos fuertes de esta plataforma es su amplia compatibilidad pudiendo importar entre otras cosas:
- TTPs creadas con MITRE ATTACK Navigator
- TTPs completas de Grupos APT desde MITRE https://github.com/mitre/cti
- Atomic Test Cases desde Atomic Red Team https://github.com/redcanaryco/atomic-red-team
- Colecciones desde un servidor de CTI TAXII (como una instancia de MISP). Si necesitas más info sobre esto puedes informarte aquí.
- Plantillas de campañas exportadas de otra instancia de Vectr.io
- y otras fuentes que se añaden con cada versión
Por supuesto, puedes configurar desde 0 todos los Test Cases o tomar como referencia estas campañas/TTPs para hacer modificaciones que se adapten mejor a tu circunstancia u organización, pero estos módulos de importación facilitan el primer paso hacia un ejercicio Purple Team exitoso para todos aquellos que no dispongan del conocimiento para hacerlo.
Gestión de campañas
Una vez que los casos de uso están diseñados o importados, el siguiente paso sería crear un assessment. Eso es simplemente una forma de agrupar una serie de campañas acotadas en el tiempo.
Dentro de estos assessment se crean las campañas. En cada campaña incluiremos todos los Test Cases orientados a un mismo objetivo que se ejecutarán dentro del mismo ejercicio. Por ejemplo, podemos hacer una campaña de TURLA, otra de FIN7, y una de phishing que serán testeadas dentro del mismo assessment. Más adelante veremos como estas divisiones pueden ser útiles a la hora del reporting.
A continuación se puede ver el aspecto que tiene una campaña en la interfaz. Se distribuyen en un gráfico dividido según las Tácticas MITRE ATT&CK. Debajo se encuentra un listado todos los Test Cases. En él se pueden asignar etiquetas a cada Test Case para ampliar las opciones y personalizar nuestro flujo de trabajo. En la columna Outcome, se marcan los resultados de detección de cada Test Case.
Test Cases
Las opciones de cada Test Case se encuentran divididas en dos zonas: azul y roja, donde se encuentran los campos a rellenar por los respectivos equipos. Estas opciones nos pueden ayudar a ir documentando las acciones que se van realizando y el resultado de ellas. Según lo minuciosos que seamos, podremos obtener un nivel más alto de granularidad y detalle en los reports.
En la parte del Red Team cabe destacar la posibilidad de tomar nota de los tiempos, asignar categorías MITRE a los Test Cases, de escribir instrucciones para el operador o de ir añadiendo los objetivos a los que se ha lanzado el ataque.
Por otro lado, en la parte del Blue Team, se pueden describir consejos de prevención y detección así como el resultado tras el test (tiempos, detecciones exitosas o artifacts forenses encontrados). Es aconsejable, por ejemplo, usar esta plataforma como base de conocimiento para reglas sigma/yara/suricata que hayan funcionado para cada caso.
En la imagen vemos como el ataque ha sido detectado y bloqueado por el EDR Aurora usando reglas sigma (pinchando en cada regla, se puede ver el contenido).
Y en la siguiente imagen se pueden ver las medidas de prevención para hacer frente a un ataque de dumpeo de LSASS.
Lecciones aprendidas y módulo de reporting
Tras haber ejecutado todos los casos de uso el número de iteraciones que se considere adecuado, es de vital importancia dejar constancia de todo con dos objetivos:
- Tener una base de conocimiento para futuros ejercicios y de esa forma, no perder tiempo y esfuerzo en replicar casuísticas ya contempladas anteriormente.
- Contar con una manera de informar de los resultados de los mismos al personal ejecutivo de la organización, que en muchas ocasiones no cuenta con el conocimiento o el tiempo como para leer largas listas de logs y eventos. La falta de capacidad del personal técnico para realizar informes ejecutivos puede redundar en la fatiga o desidia del personal ejecutivo, relegando la seguridad a un segundo lugar, mientras que una buena capacidad de reporting puede aportar información accionable que contribuya a que las áreas de seguridad se puedan ver más como una inversión que como un gasto.
Para todo esto juega un papel destacado el módulo de reporting de Vectr.io, mediante el cual se podrán generar diferentes diagramas con los resultados de los ejercicios, pudiendo aplicar filtros avanzados que permiten un buen grado de granularidad.
Vemos a continuación como se puede ver, por ejemplo el grado de cobertura (en términos de MITRE ATT&CK) en nuestros assesment de las TTP asociadas a FIN7 (primera imagen) o el porcentaje de detecciones para todos los Test Cases ensayados a lo largo del tiempo (segunda imagen).
Bonus Track
No quisiera terminar este artículo sin hacer mención a una de las funcionalidades más interesantes de esta aplicación, el Vectr Execution Framework.
Mediante este módulo, Vectr.io permite crear archivos ejecutables que pueden ser lanzados en los equipos víctima. Estos ejecutables pueden ser modificados ad-hoc para cada caso concreto mediante el uso de argumentos y además, permite agregar archivos que funcionen como artifacts para ser encontrados por el Blue Team.
Una vez lanzado el ejecutable, se genera un log que puede ser importado a la consola de Vectr de forma que se puede ir haciendo el seguimiento de equipos ya auditados y fecha/hora de las tareas.
Desgraciadamente, no se cuenta aún con la posibilidad de lanzar estos ejecutables desde el propio Vectr así que se tendrá que optar por otra alternativa como GPOs, SCCM, WinRM, etc para la ejecución del ejecutable y la recogida de logs.
Se muestra a continuación como en cada Test Case, hay un menú de Automation & Logging. Ahí es donde configuraremos los comandos a ejecutar y los argumentos. Una vez configurado se puede descargar el exe compilado.
Al ser una función en desarrollo, podría fallar en algunos casos. Hablando con los desarrolladores (que respondieron muy amablemente mis dudas en su canal de discord) me dijeron que si esto falla, los archivos están en /var/lib/docker/volumes/sandbox1-builder-runtimes/_data/out/build-*.
Ya solo quedaría ejecutar el exe en la máquina victima, y recoger el json generado para cargarlo en Vectr.io y así poblar nuestra bitácora.
Conclusión
Con esta entrada finalizamos esta serie de artículos que espero hayáis disfrutado y os haya aportado alguna cosa.
Evidentemente, esta herramienta cuenta con muchísimas otras utilidades (y las que estarán por venir) así que os animo a que la exploréis en profundidad para extraerle todo el jugo, y quizá os pueda aportar un valor diferencial en vuestra organización.
Si alguno detectáis algún error de bulto o incongruencia, no dudéis en avisar. Todos estamos permanentemente aprendiendo. ¡Hasta la próxima!
