martes, 8 de noviembre de 2022

Azure Key Vault para tus scripts en Powershell: No more hardcored passwords...

 Estimados amigos de Inseguros !!!

En el post de hoy vamos a trabajar con algunas ideas para fortificar usuario/contraseña dentro de nuestros scripts.

Cuantos de vosotros tenéis claves a fuego en scripts?. La idea es guardarlos en un repositorio centralizado en Azure Key Vault, que nos permite más control sobre ellos.



Imagina que tu clave del usuario que hace algo en un script es mimamamemima.

La quieres cambiar cada 3 meses. En vez de cambiarla en el fichero del scrtip, yo hago una llamada el KeyVault, y me devuelve la clave.

Si la quiero cambiar, la cambio en KeyVault, pero en el script no hace falta, seguirá usando la llamada para recuperar la nueva clave. El concepto es ese más o menos.

Como siempre, voy a intentar explicaros mejor el concepto con el ejemplo. Lo primero, crear en Azure un almacen de claves e instalar el módulo de Azure en Powershell, si no lo tienes aún.


Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force

Connect-AzAccount

Ahora damos de alta un SPN, un service principal name, que en Azure es una aplicación que tiene una identidad concreta, y le vamos a dar una autenticación. Esta identidad será la que tenga permisos sobre el KeyVault para leer nuestra clave. 


Una vez tenemos creado el SPN, le asociamos un secreto. 


Nos vamos al almacen de claves, y le decimos que a ese SPN, le de X permisos. En este caso solo "get".
Es decir, cuando usemos nuestro script que hace "lo que sea" le pasaremos el ID y la key del paso anterior, y solo podrá recuperar secretos del KeyVault. No podrá cambiar, por ejemplo.




Ahora creamos nuestra clave, la que queremos usar en el script: mimamamemima




Como es normal, esto nos lo da porque estamos logueados en Azure. Si lo direccionamos a una variable $laclave= "chorizo" pues ya podemos usarlo.

Si no estuvieramos logueado, tendríamos que hacer algo así?


Una vez llegados a este punto, coincidireis conmigo que antes teníamos scripts con las claves, y ahora tenemos script con un secreto, que me da acceso a la clave xD xD xD. Cual es la diferencia?

Bueno, en primer lugar, hemos adquirido la buena costumbre de crearnos un usuario/clave para cada script, y un secreto en keyvault distinto. Esto ya es mucho, porque tenemos glanularidad en control de accesos, auditoria, etc, pero hablaremos en otro momento de ello. Tenemos la posibilidad de rotar estas claves, no todas, de poco en poco. También tenemos Defender for KeyVault...

Luego existe la posibilidad, de que hayamos accedido al contenido de este script, no porque tengamos una shell local con acceso al fichero, sino que hubieramos accedidor por una RFI/LFI en un server web, por lo que podríamos ver el fichero con el secreto, pero no podríamos ejecutarlo.

En el caso de máquinas en Azure, podemos establecer la IP del equipo que realiza la petición al keyvault, para no está disponible, o no se me ocurre este control, para IP on-premise.

Entonces, volvemos al asunto que nos requiere. Ahora lo que vamos a hacer es guardar el secreto que nos permite acceder al keyvault y recuperar la clave, pero lo vamos a cifrar con DPAPI. Como sabes, esto nos ayuda en el sentido de que para descifrar esa clave, debes ser el usuario que la cifro, y el sistema operativo.
Es decir, imagina el usuario kinomakino que cifra el secreto de acceso al keyvault. Para descifrarlo, tienes que ser kinomakino y estar en ese servidor. Si ejecutamos el script en ese contexto, podemos hacerlo. Si entras al servidor con otro usuario, por ejemplo administrador, no "podras" descifrar el secreto, por lo que tendrá sentido el fichero que indicamos. 

Por supuesto, este usuario que corre el script, no deberá tener permisos de login local, login interactivo, Rdp, acceso a disco ( solo a la carpeta indicada) etc... lo normal de cuando creamos un usuario para un servicio verdad? 

Con la base del script anterior, vamos a guardar en un fichero el contenido del secreto del acceso al keyvault, cifrado con dpapi:

 #$spnsecret = "Ame8Q~dAZB13s262sRzUo5k3Ipm1T5TjOJrIubFq"

#$spnsecret |  ConvertTo-Securestring -AsPlainText -Force | ConvertFrom-SecureString | Out-File "C:\sysmon_config\license.txt" 


Y ahora le decimos al script que lea de ese fichero.

 $tenant = "5790'¡0'¡90'¡90¡3d9d976e"

$spnid = "793e90'¡90'¡9bffaeadf7"

$secreto_des = Get-content "C:\sysmon_config\license.txt" | ConvertTo-SecureString

$credenciales = New-Object System.Management.Automation.PSCredential ($spnid,$secreto_des)

Connect-AzAccount -ServicePrincipal -Credential $credenciales -Tenant $tenant

$clave = Get-AzKeyVaultSecret -VaultName "formacion" -Name "miclavedescripts1" -AsPlainText

echo $clave 


Espero que haya quedada clara la idea. Usar Keyvault y sus ventajas, mediante DPAPI.

Podríamos haber usado solo DPAPI, es decir, en el script inicial, en el que "hace cosas" hacer una llamada al fichero donde tenemos cifrada , en este caso, en vez el secreto del keyvault, la propia clave, SI. Pero Keyvault aporta una capa más. Sin entrar en detalles, de esta manera, podríamos rotar la clave en Azure, y no estar volviendo a generar el fichero, por decir alguna más...

Espero que te haya ayudado, y sobre todo, aprendas de los conceptos que vamos manejando.

También podríamos hacer esto, en vez de con KeyVault, con Keep pass, como vimos aquí hace 5 años !!!

Como siempre, 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. 

lunes, 24 de octubre de 2022

Workbook para detectar recursos huérfanos en Azure

 Estimados amigos de Inseguros !!!

Los que trabajamos con Azure sabemos lo fácil que es adquirir servicios, que muchas veces no sabemos muy bien quien los paga :-) pero siempre los paga alguien :-)

No en serio, cuando creas una máquina virtual, muchas veces metes una ip pública, un storage adicional, o una logic app que hiciste para no se qué... y luego borras la máquina y se quedan recursos que pueden engrosar la factura mensual.



En este WorkBook, siguiendo las instrucciones, podemos controlar alguno de los recursos más habituales que suelen quedar huérfanos, sin uso, en nuestros grupos de rucursos.

Muy interesante para para la escoba de vez en cuando y mantener la casa limpia.

Espero que os guste, gran trabajo del autor 

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

martes, 18 de octubre de 2022

De TTP Mitre a GPO usable con unos clicks: Eventlist Tool

 Estimados amigos de Inseguros !!!

Al que pregunte por Mitre lo mandamos al pasillo 15 días !! :-) 

Conocer los TTP´s Mitre es muy interesante, como siempre decimos, para conocer las "virtudes" de los atacantes y conocer como debemos defendernos los buenos. Por el camino tenemos la detección.

Como sabéis, en los entornos Microsoft hay que lidar con una buena configuración de eventos. En Linux también... Si no activamos las opciones de auditoría avanzada en las GPO´s no registraremos eventos de valor que a posteriori, puedan ser consultados.


Lo que siempre digo, primero instala las cámaras de video para poder consultar las cintas... 

En esta ocasión os traigo un proyecto que puede serviros para vuestros inicios, o si estáis haciendo simulación de adversarios, o si estáis intentanto ahorrar costes en el SIEM con eventos de mucho valor.

La herramienta se llama Eventlist. Aplausos para Miriam Xyra 

Es un conjunto de scripts en Powershell, con una interface gráfica, que nos permite hacer cosas tan jugosas como seleccionar uno o varios TTP´s, generarnos una liasta de id de eventos que necesitamos para detectar el TTP´s. También nos genera un fichero donde usar la conversión de reglas Sigma a nuestro SIEM. También nos ayuda con el forwarder Splunk para delimitar que eventos quiero ingestar, y no meterle un "select * " de todos los logs que si, nos dará mucha visibilidad, pero aumentará la tarifa de EPS...

Pero lo que más me gusta así para comenzar, es que nos genera una GPO con las opciones necesarias para habiltar los eventos necesarios para la detección.


Súper simpático. Os aconsejo que le déis un vistazo, seguro que le encontráis utilidades interesantes.

Como siempre, espero que os guste y 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. 

jueves, 13 de octubre de 2022

Posters y gráficos para apoyar la comunicación de seguridad a tus usuarios...by Microsoft

 Estimados amigos de Inseguros !!!

Seguro que andas arreglando las contraseñas, o vas a poner el MFA a todos, o quizás un portal de restablecimiento de contraseña Cloud. Cualquier política o cambio que se hace en la organización suele llevar apareado la difícil tarea de comunicarlo a los empleados. 

Mucho más constoso si tiene implicaciones en procesos críticos, o legales, donde tenemos que certificar que la comunicación ha sido exitosa ( TCP vs UDP xD).

En este post os traemos un enlace de Microsoft con cartéles, posters, mensajes de correo, etc para ayudarnos con los cambios más habituales del momento en cuestiones de seguridad.

Espero que os guste y que los uséis a vuestra necesidad. 

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. 

lunes, 10 de octubre de 2022

Tengo una clave de Azure: y ahora qué? Situational Awareness

 Estimados amigos de Inseguros!!!

Como es normal, la experiencia es un grado,  y el continuo aprendizaje nos hace mejorar, y en esto de la ciber ni te cuento.

Cuando uno empieza con el hacking, quiere "romper" cosas... "acceder" a sistemas, pero cuando estás trabajando sabes que hay que conseguir unos objetivos, por ejemplo, en el de un pentester o hacking ético es ayudar al cliente a encontrar sus fallos y proponer mejoras.  Cuando accedes a una web y obtiene una SQLi no te limitas con eso, intentas seguir los distintos pasos dentro de una cadena de ataque, como podría ser persistencia, borrado de huellas, reconocimiento interno, etc.

Por el lado defensor, lamentablemente siempre se ha hecho esfuerzo en que esto no suceda, en el que el vector de entrada no exista... y nos encontramos con que las empresas no están preparadas a un ataque, ni por carencia de vulnerabilidades, ni por carencia de medios de detección y contención.

Bueno que me salgo... En esta ocasión vamos a dar algunos consejos para ese momento de compromiso inicial en el que te haces con unas credenciales de un Azure AD. Porque has hecho phishing, porque estás auditando, porque quieres simular un ataque, por lo que sea, pero te encuentras en esa situación.

Empezamos a hacer ruido y tirar herramientas? qué queremos conseguir? paso a paso.

Conciencia situacional sería en inglés sobre lo que vamos a hablar creo...

Yo empezaría a hacerme preguntas e intentar conocer las respuestas o a intuirlas. Qué usuario tengo? quien soy? Qué roles tengo? Está activado el MFA a nivel global? A qué servicios puedo acceder. Quienes son los usuarios con roles de admin. Qué seguridad, productos o servicios tiene el tenant?

Conocer un poco de esto te ayudará a saber quien eres y donde estás.

Nos vamos a conectar con nuestro az-connect y vamos a usar la suite PowerZure para realizar un análisis inicial


Como te decía antes, si la empresa tiene Defender y tiene sistemas de antivirus... se va a dar cuenta xD XD xD


En este caso es que he sido muy burro he instalado PowerZure en el propio DC de la empresa xD xD pero bueno, me gusta Defender con y sin acento.

Con esto Invoke-Powerzure -h tenemos una tabla con todos los cmdlets disponibles para nuestra enumeración, por si no te acuerdas siempre.


El propósito del post no es dar una lección de enumeración de Azure. Ya tienes estos comandos y lo que hacen, MUY descriptivos, y artículos de Powerzure creo que hay unos cuantos. Lo mismo algún día subo alguno,  pero el propósito del post es invitaros a que tengais una lógica de actuación, que paréis y penséis los pasos, e intentar hacer algo más que sacar herramientas :-)

Espero que os guste, gracias por leerme !!!