jymcheong/autottpTácticas, Técnicas y Procedimientos Automatizadas
Tácticas, Técnicas y Procedimientos Automatizados. Volver a ejecutar secuencias complejas manualmente para pruebas de regresión, evaluaciones de productos, generar datos para investigadores, etc., puede ser tedioso. Jugué con la idea de facilitar la escritura de scripts para Empire (o cualquier framework/producto/kit de herramientas que proporcione APIs como Metasploit (RPC), Cobalt-Strike, etc.) usando un IDE como Visual Studio Code (o equivalente). Así que empecé a diseñar AutoTTP. Esto sigue siendo un trabajo en progreso. Probado con Empire 2.2.
YouTube - Resumen y Análisis Profundo de Técnicas Seleccionadas
En mi caso, las tácticas están organizadas según mi modelo de Ciclo de Vida del Ataque. Existen otros modelos como Kill-Chain(R) de Lockheed Martin, Ciclo de Vida del Ataque de Mandiant y ATT&CK de Mitre. Sea cual sea el modelo, una "Táctica" esencialmente agrupa técnicas, por ejemplo, la ejecución de código/ejecución de payload puede lograrse de muchas maneras:
Uso "Stage" para agrupar "Tácticas" relevantes. Si observas el árbol fuente, la estructura de carpetas refleja la columna de Tácticas de la matriz. La matriz también menciona los controles respectivos para cada táctica ofensiva. ¿Cómo surgieron estas etapas?
El diagrama de Venn en el medio del ciclo rojo es del artículo "Three Tenets for Secure Cyber-Physical System Design and Assessment" de Dartmouth College. Define las condiciones necesarias y suficientes, o simplemente los requisitos de cualquier ataque físico/lógico exitoso. Agregué el anillo rojo (etapas) alrededor del diagrama de Venn para ilustrar flujos ofensivos típicos que finalmente conducen al impacto en la Confidencialidad de la Información, la Integridad y la Disponibilidad o Seguridad del Sistema si está relacionado con Ciber-Físico (piensa en Infraestructura Crítica de Información).
Un atacante puede comenzar desde la Etapa 1 y llegar directamente a la Etapa 4, por ejemplo, credenciales de administrador predeterminadas en una página de administración expuesta públicamente. No necesita ser lineal (etapa 1->2->3->4). Después de la infiltración inicial, podría haber realizado alguna recolección de información interna (reconocimiento) primero antes de escalar privilegios en la primera máquina y luego lanzar un comando remoto a otra máquina objetivo dentro de la misma red. Para la siguiente máquina víctima, es una Etapa 2; entrega y ejecución exitosa de payload que permite al atacante obtener comando y control sobre otra máquina más.
El archivo de la izquierda es un script de procedimiento, el de la derecha es un script de técnica. Observa que la escritura de scripts de procedimiento no está llena de demasiados detalles específicos de Empire; gran parte de los detalles están encapsulados en el script de técnica. La escritura de scripts de procedimiento debe centrarse en la secuencia de técnicas utilizando información de activos, por ejemplo, nombre de host/ip, a qué correo electrónico enviar el payload, qué técnica de payload, etc.
El ejemplo de "¿es administrador de usuario?" en realidad consta de algunos pasos ya que hay al menos 3 posibilidades como se detalla en los comentarios del script. Por supuesto, podemos crear "macros" personalizadas en Empire, Metasploit y demás, pero se vuelve estrechamente integrado dentro de un framework/producto particular. Queremos aprovechar las herramientas existentes y organizar técnicas reutilizables en módulos para poder mezclar y combinar a nivel de Procedimiento (es decir, la automatización).
Aproveché los módulos bien estructurados de Empire para crear una clase de autocompletado en Python. En lugar de escribir el nombre completo del módulo (por ejemplo, powershell/situational_awareness....), solo usa las capacidades de autocompletado del IDE.
Para cada módulo, hay opciones (para la mayoría, si no todos los frameworks). El problema con Empire es que una vez que lo ejecutas como rest/headless (hablaré de esto más adelante), NO hay consola para ver las opciones del módulo. En la clase auxiliar de autocompletado, cada módulo tiene una subclase options. Las opciones requeridas tienen el prefijo como se muestra arriba, por lo que podemos completar esas opciones con valores antes de llamar a un módulo.
La descripción de cada módulo también se incluye como parte de la documentación de la clase de Python y se mostrará al pasar el cursor sobre la clase. ¡Dado que hay 276 módulos (a partir de Empire 2.1), esta clase auxiliar necesitará algo de scripting para crearla! Fuente: https://gist.github.com/jymcheong/22c2eede978c8eb694945e3347c20c6b
Con IDEs como Visual Studio Code (o equivalente), se puede aprovechar la inspección de variables de depuración, ejecutar paso a paso el script o incluso modificar el script mientras se depura/se ejecuta paso a paso después de conocer la estructura de los valores de retorno. Los documentos de las API REST están disponibles para Empire, pero a veces no conocemos exactamente los valores de retorno hasta que ejecutamos el módulo. Por esa razón, se pasa al siguiente tema.
Por mucho que queramos hacer todo en el IDE, necesitarás una consola. El autor de DeathStar, ya lo sabía mientras desarrollaba ese script que automatiza la toma de control de un Administrador de Dominio usando Empire. Tomé prestada su idea pero adapté su enfoque de hilos para Empire 2.1 ya que su enfoque no funciona con la función refactorizada de inicio de API RESTful. Fuente: https://gist.github.com/jymcheong/6a7668ecf73c29dd1d234d1c76ef438c
NO es necesario modificar el script de Empire ya que Empire 2.2 tiene el manejador de bucle de comandos mientras se ejecuta en modo REST. Sin embargo, NO interactúes con el agente mientras usas la API para obtener el resultado del agente.
Agradecimientos a @radioboyQ por su EmpireAPIWrapper, a @allfro y @Mikaayenson por pymetasploit, y a @byt3bl33d3r, MTFBWU.
