martes, 23 de junio de 2020

Conexión de AD on-premise con Azure y bloqueo de palabras concretos en las claves de los usuarios

Estimados amigos de Inseguros!!!

En el artículo de hoy vamos a tratar algunos temas varios, relacionados entre sí, pero que creo que pueden ayudar a mucha audiencia de distintos tipos.

Vamos a comentar cómo implementar un servicio de Azure Active Directory para proporcionar single sing on de nuestros usuarios de Active Directory en Azure ( y sus servicios si queremos) ( y para los usuarios que queramos) y vamos a usar una función muy interesante para mejorar la seguridad de las contraseñas.


El servicio o función se denominada Password Protector y no es más que ampliar las funciones que vienen "de casa" en nuestros dominios con una protección para evitar que los usuarios usen ciertas palabras en sus contraseñas. Por ejemplo, que no usen el nombre de la empresa dentro del password...

Es muy interesante esta función ya que aparte de mejorar la seguridad de las contraseñas, tanto en la nube como en local, nos proporciona un registro puntual con eventos para seguir nuestras políticas de compliance de cualquiera de las mil que hay.

El proceso parte de un Active Directory sin ningún tipo de conexión con Azure, por lo que si ya tienes algún servicio tipo Microsoft  365 o similar, algunos pasos ya los tendrás.

En el portal de Azure tenemos que crear una nueva instancia de Active Directory para Azure, siguiendo varios sencillos pasos. Tienes que tener en cuenta los nombres y DNS, y entender que el dominio Active Directory en Azure puede o no ser el mismo que on-premise, es más puedes configurar todo tipo de granularidad. Por ejemplo, sincronizar en Azure solo cierto grupo de usuarios, por ejemplo, el departamento IT, para que acceda a los recursos de la nube con el Single Sign On.




Descargamos el AD Connect y procedemos a hacer la magia. Vamos a usar la opción por defecto para no entrar en esta materia que está ampliamente documentada.

Es importante crear un usuario en el AD local para la sincronización del directorio. No permite usar el usuario administrador ni se debe. El propio asistente te indica la posibilidad de ingresar uno o que crear uno, si previamente le introducimos un usuario administrador con capacidad para eso, para administrar el AD local.


Ahora es el turno del objetivo principal del post, configurar la seguridad para las contraseñas. Accedemos al portal de AD en Azure y entramos en la sección seguridad.


Accedemos a administrador, mecanismos de autenticación, protección con contraseña.***nota mental, necesitas E3 para esto o Azure Active Directory Premium 1***

Es muy forzar a que se use la lista y acometer la misma.


Ahora vamos a configurarlo para nuestro entorno local, on premise. Comenzamos descargando el agente e iniciando el proceso de instalación.



El proceso es automágico y después de un reinicio, podemos ejecutar el módulo Powershell que instala para saber si todo ha ido bien: Import-Module AzureADPasswordProtection

Ahora que tenemos el agente instalado y el proxy que se conectará a Azure, hacemos eso, conectarlo:

Register-AzureADPasswordProtectionProxy -AccountUpn 'hjkhjkh@9080.com'

El siguiente paso es registrar el bosque que queremos sincronizar: 

Register-AzureADPasswordProtectionForest -AccountUpn '0'09'90'@onmicrosoft.com'

Una vez seteado todo, vamos a hacer una prueba, vamos a realizar un cambio de contraseña a un usuario que contenga alguna de las palabras y ver qué ocurre.


Efectivamente aparece un preciado registro para nuestro SOC.

Espero que os sirva de ayuda para animaros a probar cosas de este tipo.

Gracias por leerme !!!

miércoles, 10 de junio de 2020

Detectar y esconder Sysmon


Estimados amigos de Inseguros !!!

De todos es sabido que Sysmon es una pieza fundamental para la monitorización de los sistemas Microsoft, pero es una pieza muy importante que debemos defender ya que los atacantes lo saben, y lo primero que harán será detectar el uso de la herramienta, para saber si pueden hacer más o menos ruido.


Una de las primeras cosas en un ataque o auditoria es evaluar las medidas defensivas del cliente/objetivo. Si tiene servicios defensivos complejos deberás ser más caúto y sobre todo lento en los reconocimientos y explotación de activos que si es un equipo que huele a siguiente, siguiente, siguiente. 

Lo primero que debemos saber es que por defecto si no renombramos el fichero de instalación de sysmon, se instalará en una rama tanto el binario como un driver con unos nombres predecibles, sysmon y sysmondrv. 

Si un atacante busca procesos corriendo, servicio o rama de registros relacionada con Sysmon detectaría el uso.

Tenemos la opción de cambiar el nombre del instalador e indicar el nombre del driver así:

carbonblack( o el nombre que quieras).exe -i -d carbonblack


Aparte de este pequeño hack, tenemos que ser consciente de que el driver se instala con un identificador o altitude único, un identificador que usa Microsoft para imponer un orden a la hora de ejecutar drivers en la pila de almacenamiento. Siempre es el mismo 385201. 

Podemos listarlo con el siguiente comando:

C:\Windows\system32>fltmc

Nombre de filtro                     Núm. instancias    Altitud    Trama
------------------------------  -------------  ------------  -----
DfsDriver                               0       405000         0
SysmonDrv                               5       385201         0
vsepflt                                 5       328200         0
WdFilter                                5       328010         0

Con este comando también podríamos deshabilitarlo...

Por lo tanto, si sabemos cambiarle el nombre en la instalación y sabemos cambiar el número de altitude...


Poco más que decir. Otras herramientas usan altitude conocido como procmon que siempre usa 385200...

En fin, espero que te guste la idea de usar sysmon, si ataques ya sabes como buscarlo, si defiendes como esconderlo... y así hasta el infinito.

Espero que os guste !!!

miércoles, 3 de junio de 2020

Reglas básicas de seguridad para Microsoft 365: lucha contra el timo del CEO

Estimados amigos de Inseguros !!!

Seguro que si hablamos del timo del Ceo conoces algún caso más o menos cercano de alguna organización que ha sucumbido a él.

Quizás no por ese nombre, pero el concepto está muy claro. Te envían un correo de una cuenta de algún proveedor o parecida... diciendo que cambies un número de cuenta para hacer un pago... algo similar.


Vamos a realizar un par de ajustes en nuestro Exchange Online para minimizar el impacto o posibilidades de que ocurra.

En primer lugar vamos a crear un flujo de correo sencillo, vamos a alertar a nuestros usuarios cuando llega un correo de otra organización. Esto parece una tontería, pero muchas veces los usuarios se relajan cuando ven un dominio "parecido"al nuestro.

Imagina las posibilidades que te da esto, pero poco a poco.

Ahora vamos a crear otra regla en la que identificamos una o varias palabras sospechosas en el correo, por ejemplo la palabra factura, y vamos a hacer dos cosas, anteponer un asunto que ponga PELIGRO y un mensaje antes del correo que indique que es sospechoso.



Si seguiste el último post sobre conectar por Powershell Microsoft 365, podrás conectarte al Exchange online con Connect-ExchangeOnline  para poder realizar cosas como listar las reglas:


Pero la gracia está en como decíamos en el artículo anterior, usar Powershell para administrar de manera masiva distintos Tenant. Para ellos vamos a exportar el conjunto de reglas, para luego poder importarlas, almacenarlas, etc.  $file = Export-TransportRuleCollection; Set-Content -Path "C:\reglas_empresa_x.xml" -Value $file.FileData -Encoding Byte

El resultado es sencillo:

<?xml version="1.0" encoding="UTF-16" standalone="true"?>

-<rules name="TransportVersioned">


-<rule name="TImo del ceo" format="cmdlet" id="a6963b64-ca84-4bbd-b96b-6dd995c748c8">


-<version requiredMinVersion="15.0.3.0">


-<commandBlock>

-<![CDATA[New-TransportRule -Name 'TImo del ceo' -Comments '
' -Mode Enforce -SubjectOrBodyContainsWords 'factura' -PrependSubject '[PELIGRO].      ' -SetAuditSeverity 'Medium' -ApplyHtmlDisclaimerLocation Prepend -ApplyHtmlDisclaimerFallbackAction Wrap -ApplyHtmlDisclaimerText 'CUIDADO CON ESTE CORREO, tiene elementos que lo hacen sospechoso, en concreto habla de una factura.']]>
</commandBlock>

</version>

</rule>


-<rule name="correo de fuera de la empresa" format="cmdlet" id="b7c84d9f-f74a-4b8d-9bd3-9168fa5e3b74">


-<version requiredMinVersion="15.0.3.0">


-<commandBlock>

-<![CDATA[New-TransportRule -Name 'correo de fuera de la empresa' -Comments '
' -Mode Enforce -FromScope NotInOrganization -SetAuditSeverity 'Medium' -ApplyHtmlDisclaimerLocation Append -ApplyHtmlDisclaimerFallbackAction Wrap -ApplyHtmlDisclaimerText '<<ATENCIÓN, este correo viene de una fuente externa, no olvide las directrices de seguridad de la compañía>>']]>
</commandBlock>

</version>

</rule>

</rules>

La manera de importarlas sería insultantemente sencilla como para documentarlo :-).

Ahora vamos con otro truco. Vamos a jugar con los arrays de valores en Powershell y vamos a crear una regla que por ejemplo, no deje enviar correos a gente de fuera de la organización, con ciertas palabras. Esto se podría usar de muchas maneras, por ejemplo, para detectar fugas de información con ciertas palabras... vamos a ello.


El uso que le des es infinito, por ejemplo, puedes crear una lista de remitentes seguros para el departamento de compras/pagos, en el que previamente se den de alta. Si alguno de los correos que te piden cambios o envían facturas o similar, sin que esté autorizado, puede dar un error... al final la tecnología está al uso de los procesos de la empresa y cada una es un mundo.

Espero que te sirva de ayuda este mini artículo con algunas ideas para fortificar tu Microsoft 365.

Gracias por leerme !!!

martes, 2 de junio de 2020

Intro a Powershell y administración de O365 Security Center and Compliance

Estimados amigos de Inseguros !!!

En el post de hoy me atrevo a contaros algunos pequeños trucos, consejos o breve guía para que os inicieis en el lenguaje Powershell, orientándolo un poco a la ciber, por no hacer el "hola mundo", y que de paso te sirva en tu día día.

Como sabes Powershell no es un lenguaje de programación como tal, es una interfaz de administración por consola, como viene siendo CMD o Bash, pero con funciones más avanzadas. Una respuesta de Microsoft a las exigencias de la comunidad de tener un lenguaje potente de administración para tareas complejas, pudiendo realizar operaciones para grandes cargas de trabajo, entornos complejos y sobre todo automatización.

Para intentar aportar algo de valor, vamos a hablar del Microsoft 365 ( Office 365) SCC Security Center & Compliance, como su nombre indica, el centro en donde administramos la configuración de seguridad de nuestro entorno o tenant ( inquilino).



Los motivos son muchos, pero cada uno tiene que valorar si necesita realmente utilizar la consola o los clicks. En mi caso, y dada la vertiente de administración de varias empresas, me es útil realizar los cambios mediante scripting, para poder repetirlos en mis distintas empresas o clientes.  Usar este código minimiza el impacto de un administrador que puede cometer un fallo y hacer un click donde o como no deba, por ejemplo borracho como una cuba :-)

Seguimos con lo básico. Los comandos Powershell, los CMDlet, se componen de 4 partes:

VERBO: Por ejemplo Get, List, Set, Add, etc
NOMBRE: Date, content, label, etc.
PARAMETROS: -Credential, - Path, -Force, etc
MODIFICADORES: –_Recurse,-Force. _

Otra de las cuestiones básicas de PowerShell es la canalización o Piping, lo que viene siendo "enviar" el resultado de un comando como dato de entrada del siguiente. Ejemplo: 
Get-Content -Path C:\listado_ordenadores.txt | Test-Connection 

Ahora que hemos visto lo más básico, vamos con la parte del Microsoft 365 SCC. Para poder conectarnos al entorno Powershell necesitamos el módulo de Azure Active Directory y el módulo de administración de Exchange Online.

En mi caso una vez instalado, en mi entorno con MFA:

Connect-IPPSSession -UserPrincipalName larala@comasd.com


Una vez "sesionados" podemos comprobar que todo ha ido bien con alguno de los comandos relativos a la sesión.



Vamos a listar las directivas de alertas de nuestro tenant con Get-ProtectionAlert.


Al final hay cientos de CMDlets y lo mejor es tirar de la referencia oficial para mostrar los que puedes necesitar, aunque hay algunos trucos para buscar en la consola...

PS C:\Users\Administrador > gcm -Name *alert*

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Alias           Get-ASRAlertSetting                                2.9.0      Az.RecoveryServices
Alias           Get-ASRAlertSetting                                0.2.4      AzureRM.RecoveryServices.SiteRecovery
Alias           Set-ASRAlertSetting                                2.9.0      Az.RecoveryServices

Gracias por leerme !!!