Estimados amigos de Inseguros !!!
Vamos a empezar con el concepto de simulación de adversarios para adentrarnos un poquito más en este mundo con una herramienta concreta, en esta caso, Mitre Caldera.
El concepto es muy sencillo y lo que estamos en los equipos "defensivos" o delante de un SIEM o similar estamos acostumbrados. Los famosos Use case, el ruido !!!
Si tu tienes una alerta en el SIEM que detecta un ataque de fuerza bruta horizontal... tendrás que probarlo? nosotros lo llamamos "hacer ruido", generar los eventos, reproducir el ataque de una manera controlada para comprobar si realmente estamos detectando o no. Mejorar la detección, el ataque, al final es parte del ciclo de mejora de la defensa.
![]()
Con los ejercicios de simulación conseguimos esto, preparar y entrenar no solo los sistemas sino al personal ante eventos conocidos.
Al final, estás haciendo ese Purple Team o escenarios mixtos ataques/defensas.
Como ya he comentado en alguna charla, muchas veces la información que nos deja un Red Team o servicio ofensivo es de alto valor, pero puestos a trabaja la información, necesitamos correlar mucha información, sobre cómo ha funcionado el sistema defensivo, que rastros ha dejado, que medidas se han tenido que evadir con el Red Team, como se van a implementar medidas que corrijan los hallazgos, pero no solo los encontrados, sino en el tiempo, los futuros fallos de similar índole...
El uso de esta herramienta, Mitre Caldera nos gusta mucho porque es muy sencilla de desarrollar y se ciñe a nuestros propósitos.
Básicamente es una interface web para controlar un RAT, una herramienta de administración remota, un backdoor !!! con el que pasarle comandos al sistema.
Mediante comandos del sistema, bien sean bash, shell de Windows/Mac, powershell podemos replicar ataques conocidos, y ejecutarlos de manera controlada, añadiendo fases, recogiendo información útil para ser usada a posteriori...
El framework viene con una serie de TTP definidos, con el standard del MITRE, lo que nos "anima" a seguir con esta nomenclatura, o no...
Vamos a crear un pequeño ejemplo práctico y así puedes ver como va
A mi personalmente me gusta realizar la instalación de la máquina a "mano", sin docker, cosas de mi inexperiencia, pero si ya tengo una máquina virtual en dos clicks gracias a Azure, me de lo mismo liarme 5 minutos a instalar cositas, y así aprendo de paso.
Siguiendo los rigurosos pasos del documento de instalación me hago con el componente servidor.
![]()
La instalación me ha costado unas pocas gestiones, porque es un proyecto que está en cambio constante, que usa versiones 3 de python, y que no soy muy experto en estos menesteres.
La pantalla inicial me produce tal satisfacción que me remito a ella:
![]()
Siguiendo los preceptos de la aplicación, tenemos dos vías de "infectar" nuestras máquinas o sistemas a testear. Mediante un comando "del sistema" tipo ssh o powershell, o accediendo simplemente a la url con el binario. Muestro la opción del powershell.
![]()
![]()
Realizo alguna infección más y procedo con el panel de control a ver las distintas opciones.
Al final, esta parte es muy importante porque es el componente RAT el que va a ejecutar los trabajos.
Vamos a simular una técnica de persistencia basada en la técnica Mitre T1031 de modificar un servicio existente.
![]()
El sistema nos muestra el comando que subyace con esta técnica:
- id: 52771610-2322-44cf-816b-a7df42b4c086
name: Replace a service binary with alternate binary
description: |
This is an example technique. snmptrap.exe should be changed in the command
below with the new desired service binary. Depending on the value of
host.service.modifiable this ability can damage the target system.
tactic: persistence
technique:
attack_id: T1031
name: Modify Existing Service
platforms:
windows:
psh:
command: |
$s = Get-Service -Name #{host.service.modifiable};
if ($s.status -ne 'Stopped') { Stop-Service $s };
$exe = (Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\#{host.service.modifiable}").ImagePath.split()[0];
$path = (Resolve-Path $exe).Path;
Copy-Item -Path $path -Destination ($path + ".saved");
Copy-Item -Path "C:\Windows\System32\snmptrap.exe" -Destination $path
cleanup: |
$exe = (Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\#{host.service.modifiable}").ImagePath.split()[0];
$path = (Resolve-Path $exe).Path;
If (Test-Path ($path + ".saved")) {
Remove-Item $path;
Move-Item -Path ($path + ".saved") -Destination $path
}
Ahora creo un Adversary para ir añadiendo distintas TTP al ataque. Siguiendo el ejemplo, vamos a configurar la técnica 1031 que habíamos visto anteriormente.
![]()
Ahora realizamos la operación a simular, es decir, con la definición o uso de nuestra técnica y las fases, vamos a establecer el grupo de objetivos y a lanzar la operación.
![]()
Con el resultado de la operación tenemos un informe en formato gráfico y json, donde podemos ver que no se ha podido realizar la técnica, debido a que los dos equipos no tenían ningún servicio vulnerable para modificar con los permisos que se estaba ejecutando el RAT.
![]()
Ahora vamos a lanzar una operación con un conjunto de TTP´s más "cantosos".
![]()
Como puedes ver, en esta operación vamos a parar la recolección de logs, conseguir información del sistema, buscar entornos wifi, apaga el adaptador... y un conjunto de técnicas a las que engloba como "noisy neighbor" :-)
Después de un rato, me doy cuenta que efectivamente en mi mac me había desactivado el wifi xDDDDD
platforms:
darwin:
sh:
command: |
./wifi.sh off
cleanup: |
./wifi.sh on
payload: wifi.sh
linux:
sh:
command: |
./wifi.sh off
cleanup: |
./wifi.sh on
payload: wifi.sh
windows:
psh:
command: |
.\wifi.ps1 -Off
cleanup: |
.\wifi.ps1 -On
payload: wifi.ps1
Fíjate en esta descripción de técnica como implementa un comando que requiere de un fichero, se denomina payload y debemos de especificarlo. Es muy sencillo subirlo al server y que el agente lo descargue en la ubicación por defecto que decidamos.
El resultado de la operación, aparte de tirarme el wifi :-) es el siguiente:
![]()
Aunque tengamos el report gráfico, la recolección de lo que llama facts o hechos la tenemos en detalle en el fichero de reporte json.
![]()
Siguiendo el propósito de nuestro test, vemos si nuestras herramientas de recolección de información están obteniendo la información que deseamos, y si vemos en nuestro SIEM las esperadas alertas a la detección de los ataques realizados.
Si todo ha ido bien, nuestro equipo blue team habrá podido ver/analizar que pasa, y si no, no nos habremos enterado de nada :-)
![]()
Al final, una herramienta muy versátil y que dota a los equipos de test muchas facilidades a la hora de realizar las pruebas.
Espero que os guste, que la trabajéis. Haremos más cositas seguramente en otras entradas.
Gracias por leerme.
Vamos a empezar con el concepto de simulación de adversarios para adentrarnos un poquito más en este mundo con una herramienta concreta, en esta caso, Mitre Caldera.
El concepto es muy sencillo y lo que estamos en los equipos "defensivos" o delante de un SIEM o similar estamos acostumbrados. Los famosos Use case, el ruido !!!
Si tu tienes una alerta en el SIEM que detecta un ataque de fuerza bruta horizontal... tendrás que probarlo? nosotros lo llamamos "hacer ruido", generar los eventos, reproducir el ataque de una manera controlada para comprobar si realmente estamos detectando o no. Mejorar la detección, el ataque, al final es parte del ciclo de mejora de la defensa.
Con los ejercicios de simulación conseguimos esto, preparar y entrenar no solo los sistemas sino al personal ante eventos conocidos.
Al final, estás haciendo ese Purple Team o escenarios mixtos ataques/defensas.
Como ya he comentado en alguna charla, muchas veces la información que nos deja un Red Team o servicio ofensivo es de alto valor, pero puestos a trabaja la información, necesitamos correlar mucha información, sobre cómo ha funcionado el sistema defensivo, que rastros ha dejado, que medidas se han tenido que evadir con el Red Team, como se van a implementar medidas que corrijan los hallazgos, pero no solo los encontrados, sino en el tiempo, los futuros fallos de similar índole...
El uso de esta herramienta, Mitre Caldera nos gusta mucho porque es muy sencilla de desarrollar y se ciñe a nuestros propósitos.
Básicamente es una interface web para controlar un RAT, una herramienta de administración remota, un backdoor !!! con el que pasarle comandos al sistema.
Mediante comandos del sistema, bien sean bash, shell de Windows/Mac, powershell podemos replicar ataques conocidos, y ejecutarlos de manera controlada, añadiendo fases, recogiendo información útil para ser usada a posteriori...
El framework viene con una serie de TTP definidos, con el standard del MITRE, lo que nos "anima" a seguir con esta nomenclatura, o no...
Vamos a crear un pequeño ejemplo práctico y así puedes ver como va
A mi personalmente me gusta realizar la instalación de la máquina a "mano", sin docker, cosas de mi inexperiencia, pero si ya tengo una máquina virtual en dos clicks gracias a Azure, me de lo mismo liarme 5 minutos a instalar cositas, y así aprendo de paso.
Siguiendo los rigurosos pasos del documento de instalación me hago con el componente servidor.
La instalación me ha costado unas pocas gestiones, porque es un proyecto que está en cambio constante, que usa versiones 3 de python, y que no soy muy experto en estos menesteres.
La pantalla inicial me produce tal satisfacción que me remito a ella:
Siguiendo los preceptos de la aplicación, tenemos dos vías de "infectar" nuestras máquinas o sistemas a testear. Mediante un comando "del sistema" tipo ssh o powershell, o accediendo simplemente a la url con el binario. Muestro la opción del powershell.
Realizo alguna infección más y procedo con el panel de control a ver las distintas opciones.
Al final, esta parte es muy importante porque es el componente RAT el que va a ejecutar los trabajos.
Vamos a simular una técnica de persistencia basada en la técnica Mitre T1031 de modificar un servicio existente.
El sistema nos muestra el comando que subyace con esta técnica:
- id: 52771610-2322-44cf-816b-a7df42b4c086
name: Replace a service binary with alternate binary
description: |
This is an example technique. snmptrap.exe should be changed in the command
below with the new desired service binary. Depending on the value of
host.service.modifiable this ability can damage the target system.
tactic: persistence
technique:
attack_id: T1031
name: Modify Existing Service
platforms:
windows:
psh:
command: |
$s = Get-Service -Name #{host.service.modifiable};
if ($s.status -ne 'Stopped') { Stop-Service $s };
$exe = (Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\#{host.service.modifiable}").ImagePath.split()[0];
$path = (Resolve-Path $exe).Path;
Copy-Item -Path $path -Destination ($path + ".saved");
Copy-Item -Path "C:\Windows\System32\snmptrap.exe" -Destination $path
cleanup: |
$exe = (Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\#{host.service.modifiable}").ImagePath.split()[0];
$path = (Resolve-Path $exe).Path;
If (Test-Path ($path + ".saved")) {
Remove-Item $path;
Move-Item -Path ($path + ".saved") -Destination $path
}
Ahora creo un Adversary para ir añadiendo distintas TTP al ataque. Siguiendo el ejemplo, vamos a configurar la técnica 1031 que habíamos visto anteriormente.
Ahora realizamos la operación a simular, es decir, con la definición o uso de nuestra técnica y las fases, vamos a establecer el grupo de objetivos y a lanzar la operación.
Con el resultado de la operación tenemos un informe en formato gráfico y json, donde podemos ver que no se ha podido realizar la técnica, debido a que los dos equipos no tenían ningún servicio vulnerable para modificar con los permisos que se estaba ejecutando el RAT.
Ahora vamos a lanzar una operación con un conjunto de TTP´s más "cantosos".
Como puedes ver, en esta operación vamos a parar la recolección de logs, conseguir información del sistema, buscar entornos wifi, apaga el adaptador... y un conjunto de técnicas a las que engloba como "noisy neighbor" :-)
Después de un rato, me doy cuenta que efectivamente en mi mac me había desactivado el wifi xDDDDD
platforms:
darwin:
sh:
command: |
./wifi.sh off
cleanup: |
./wifi.sh on
payload: wifi.sh
linux:
sh:
command: |
./wifi.sh off
cleanup: |
./wifi.sh on
payload: wifi.sh
windows:
psh:
command: |
.\wifi.ps1 -Off
cleanup: |
.\wifi.ps1 -On
payload: wifi.ps1
Fíjate en esta descripción de técnica como implementa un comando que requiere de un fichero, se denomina payload y debemos de especificarlo. Es muy sencillo subirlo al server y que el agente lo descargue en la ubicación por defecto que decidamos.
El resultado de la operación, aparte de tirarme el wifi :-) es el siguiente:
Aunque tengamos el report gráfico, la recolección de lo que llama facts o hechos la tenemos en detalle en el fichero de reporte json.
Siguiendo el propósito de nuestro test, vemos si nuestras herramientas de recolección de información están obteniendo la información que deseamos, y si vemos en nuestro SIEM las esperadas alertas a la detección de los ataques realizados.
Si todo ha ido bien, nuestro equipo blue team habrá podido ver/analizar que pasa, y si no, no nos habremos enterado de nada :-)
Al final, una herramienta muy versátil y que dota a los equipos de test muchas facilidades a la hora de realizar las pruebas.
Espero que os guste, que la trabajéis. Haremos más cositas seguramente en otras entradas.
Gracias por leerme.
