Bloqueo de usuarios en Azure AD y plataformado de GPO en escenario Hybrid

En relación a la configuración de bloqueos tras XX intentos fallidos en la introducción de la contraseña, hay algunos aspectos interesantes que cabe destacar y analizar.

Por defecto, tenemos el umbral de bloqueo de usuario tras 10 intentos fallidos en sector privado y 3 intentos en los tenants de sector público. Este usuario se desbloqueará de forma automática, tras 60 segundos.

Como he dicho, la cuenta se bloquea tras 10 contraseñas no correctas y se bloquea de nuevo tras cada intento extra, o sea se bloqueará de nuevo en el intento 11 y de nuevo en el 12.

El tiempo de desbloqueo de la cuenta, aumenta. Siendo de 1 minuto tras 10 intentos y más de 1 minuto tiempo tras el intento 11. Por seguridad, Microsoft no ofrece información sobre el tiempo de aumento del bloqueo de usuario.

El bloqueo inteligente además realiza una comprobación de los tres últimos intentos y no considera intento fallido si se repite la contraseña. Por ejemplo, si un usuario escribe 10 veces mal la misma contraseña la cuenta no se bloquea.

El administrador no puede desbloquear el usuario. Hay que esperar el tiempo de rigor. De hecho, el único proceso que desbloquea al usuario, que puede lanzar un humano es el desbloqueo tras un proceso SSPR de reseteo de contraseña.

Hay dos contadores diferentes, si el usuario erra la contraseña desde un lugar que para ese usuario es habitual, y otro contador para cuando el usuario está intentando acceder desde un lugar no habitual para él/ella. Apareciendo en este segundo caso más sensible el MFA entre intento fallidos.

Hybrid Scenario con ADConnect

A tener en cuenta en Windows Active Directory GPOS

Es importante que las GPOS, bloqueen la cuenta de Windows Active Directory, tras un número de fallos mayor que lo que hay configurado en Azure AD, para evitar que antes de que llegue el contador de Azure AD a su umbral, la cuenta se haya bloqueado por Windows Active Directory y con ello la cuenta de Azure AD también.

El tiempo de desbloqueo en Windows Active Directory ha de ser alto en la GPO para conseguir que Azure AD sea el que desbloquea la cuenta antes. Según la configuración, la primera vez será de 60 segundos, pero tened en cuenta que luego si se vuelve a fallar la contraseña, los tiempos de bloqueo de la cuenta serán mayores de 60 segundos, ya que van aumentando.

Se aconseja que en Windows Active Directory local el umbral de bloqueo de cuenta  sea al menos dos o tres veces mayor que el umbral de bloqueo de Azure AD

La duración del bloqueo de Azure AD (en segundos) debe ser mayor que la duración de restablecer el contador de bloqueos en Windows Active Directory (que se establece en minutos)

Palabras prohibidas en contraseñas en entornos híbridos Azure AD y WSAD

 

Hola, 

A pesar de que está a la vista y es fácil de implementar, pocas o ninguna vez he encontrado la hibridación de la configuración avanzada de política de contraseñas entre Azure AD y Windows Server Active Directory.

En la ruta; Azure AD - Seguridad - Seguridad - Métodos de autenticación - Protección con contraseña, encontramos las opciones donde podemos bloquear al usuario tras 10 intentos, por defecto, fallidos durante en un principio 60 segundos. 

En este lugar, podemos también configurar una lista personalizada de palabras prohibidas en la contraseña, lo cual es realmente útil. Lo que nos permite además, si contamos con un entorno Windows Server Active Directory, descargar el software   que tras ser instalado en el DC o bien en un servidor que "vea" al DC y por otro lado, tenga acceso limitado a internet (Implementación de la protección con contraseña de Azure AD local - Microsoft Entra | Microsoft Learn) nos hace llegar la lista de palabras prohibidas personalizada a los cambios de contraseñas que se produzcan en el ámbito On premises.

AzureADPasswordProtectionProxySetup.exe

Realmente, el procedimiento de validación de contraseñas con palabras prohibidas, no funciona como todos creemos pensar, a continuación lo explicaré y realmente es algo más importante aún, conocer que previamente a la comprobación de nuestra lista predeterminada, Azure AD, comprueba la existencia de palabras prohibidas en una lista global que mantiene el fabricante.

De hecho, La comprobación de una contraseña para su aceptación en un entorno híbrido o solo cloud pasa por las siguientes comprobaciones: 

 

• Toda contraseña introducida se comprueba, antes de su aceptación, en una lista de contraseñas globales prohibidas, añadiré algo extraño y es que de contener una palabra de la lista. a la contraseña se le otorga un punto.
• Tras esto, se comprueba si la contraseña contiene una palabra prohibida de nuestra lista personalizada y de existir, se otorgará un punto.
• La contraseña pasa por un proceso de normalización, se convierten mayúsculas por minúsculas, se asociada cada letra a similares como a = @  o = 0 y se componen todas las variaciones posibles.
• Se crean variaciones para evitar contraseñas aproximadas
• Si la contraseña anterior era por ejemplo Alicante01 se comprueba si se trata Alicante10 o ej. abcdeg o abcdefg de existir esto se otorgaría un punto.
• Se comprueba si esa misma contraseña ha sido utilizada por el usuario anteriormente y de ser así se prohíbe.
• Se comprueba si la contraseña coincide con su nombre,  apellido o similitudes de información personal:  Miguel  o Miguel123 o aaaHern@ndez por ejemplo y de ser así, se otorga un punto.

Proceso de puntuación de contraseñas:

 

• Proceso de puntuación para aceptaciones o denegaciones.
• Por ejemplo una contraseña larga que contenga palabras prohibidas podría aceptarse
• Una contraseña que contenga su nombre tiene un punto
• Una contraseña que contenga una contraseña previamente utilizada un punto
• Cada palabra prohibida encontrada en una cadena  tiene un punto
• Cada carácter no prohibido encontrado tiene un punto
• La contraseña ha de tener 5 puntos o más.

Ejemplo:

 Prohibimos Alicante en la lista de palabras prohibidas y tratamos de utilizar  Al1c@nt3AN

                Al1c@nt3= 1 punto

                A = 1 punto

                N = 1 punto

                Total 3 puntos, la contraseña no se admite.

 

En cambio Al1c@nt3Aaaa

             Al1c@nt3 = 1 punto

Aaaa = 4 puntos (4 caracteres)

Total  5 puntos Al1c@nt3Aaaa se admite a pesar de estar Alicante prohibida.

Como apunte avanzado, revisa la documentación si dispone de varios bosques de WSAD on premises.

https://learn.microsoft.com/es-es/azure/active-directory/authentication/howto-password-ban-bad-on-premises-deploy#read-only-domain-controller-considerations

Evitar "MFA Fatigue attack" en Azure AD

 

Hola, 

Estamos asistiendo a un aumento de ataques MFA Fatigue, el cual como ya sabréis, se basa en ingeniería social, mandando al usuario una gran cantidad de validaciones MFA hasta que este, aceptar por error una de ellas. 

Evidentemente para poder realizar este ataque, hay que conseguir la contraseña del usuario y para evitar esto, lo mejor es activar Passwordless en todos los accesos que solicitan validación al usuario. Sobre esto hablaré en otro post.

Respecto a la parte más directa de este ataque, he recopilado una serie de opciones que existen en Azure AD y que evitarán el ataque a usuarios en nuestro tenant. Las opciones que indico a continuación, existen en practicamente todos los directors cloud, como puede ser Ping Identity, Okta, Gsuite, etc. y por tanto son igualmente aplicables.

Bastionado de tenant resistente a MFA Fatigue

Protección ante inicios de sesión en riesgo

La primera opción y para mí fundamental es configurar la proteeción ante riesgos en el login. Para esto es necesario Azure AD P1, pero creo que a día de hoy, vale la pena contar con esta licencia.

Protección del inicio de sesión de usuario basada en el riesgo en Azure Active Directory - Microsoft Entra | Microsoft Learn

Bloqueo de cuenta tras X intentos 

Por otra parte, lo esencial en cualquier tenant, sería configurar el bloqueo de cuenta tras un número de denegaciones por parte del usuario y situar este umbral bastante bajo. no más de 3-5 solicitudes denegadas del usuario. Cabe destacar que viene sin configurar, lo cual me parece un fallo por parte de Microsoft.

Esto lo tenéis en Azure Active Directory -> Seguridad -> Autenticación multifactor -> Bloqueo de cuenta.

Alertas de fraude

Otra opción efectiva es la de ofrecer en el aviso a los usuarios la posibilidad de denunciar un fraude y posterior bloqueo de la cuenta durante unos minutos.

MFA coincidencia de números

Una de las opciones más efectiva, es la coincidencia de números e información de localización que está actualmente en Preview para MFA, pero que en el caso de la primera, llevamos disfrutando desde hace mucho tiempo lo usuarios con paswordless.

Estas opciones de push avanzado de MFA están soportadas tanto en escenario cloud, como en escenario híbrido con complemento NPS y validación ADFS.

Para activar estas opciones, tenemos que ir a Azure Active Directory -> Seguridad -> Métodos de autenticación -> Microsoft authenticator -> Configurar -> Requerir coincidencia de números y Mostrar la ubicación geográfica en notificaciones Push.

Esto propiciará que en el MFA aparezca la siguiente información. Obligando al usuario a introducir un número aparecido en pantalla a quien propicie la llamada al MFA.

Evidentemente, como digo siempre, todo esto hay que combinarlo con control de acceso mediante equipos corporativos y delimitación de la posibilidad de realizar login en nuestras aplicaciones asociadas a Azure AD, desde localizaciones y/o países válidos para nuestra empresa.

También es importante no tener asignados roles y hacer uso de PIM.

Saludos.

Tratando de evitar ataques AITM (Adversary in the middle) a identidades cloud.

 

Dado que está resultando realmente exitoso para los atacantes. Empresas como Zscaler y el mismo Microsoft, han publicado diversos estudios y análisis sobre los ataques que se están llevando a cabo mediante AITM. Este formato consiste en situarse entre el usuario y el portal de validación para recoger una cookie de inicio de sesión que prevalece válida mientras dura la sesión del usuario validado.

Links de los estudios:

AITM Attack Targeting Microsoft Email Users | Zscaler

From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud - Microsoft Security Blog

Una vez he repasados estos estudios, destaco lo siguiente. 

Los ataques se están produciendo con aplicaciones tales como: Evilginx2 -utilizado en mi video- Muraena y Modlishka. Todos ellos funcionan siendo un proxy entre la víctima y el servicio de destino, pudiendo ser desde Spotify hasta O365, pasando por Paypal, Instagram, Twitter, etc.

Buscando soluciones a este ataque, primeramente veo que como casi todo phising, suele llegar vía correo electrónico indicando al usuario que ha de validarse en una url. Por lo que aconsejo la puesta en marcha de Safe Links en Advanced Threath Management que forma parte de la protección avanzada de Microsoft Defender.

La diferencia entre Defender y Defender en versión avanzada, es que el segundo, protege al hacer click en urls peligrosas a día del mismo click en correos pero que pasaron a la bandeja de entrada del usuario, siendo validadas por un Defender más básico y no declarar estas peligrosas, por no estar localizadas en ese momento.

También observé en el piloto que construí, que Google Chrome marcó bastante antes mi URL maliciosa -yo registré el dominio Outloook.tk- mientras que Edge tardó algo más de 24 horas en avisarme.

A día de hoy, se mantiene activa una list de dominios utilizados como urls proxy que se puede consultar aquí: https://github.com/threatlabz/iocs/blob/main/aitm_phishing/microsoft_iocs.

Dado que en los análisis hechos por Zscaler existen inicios de sesión tras 8 minutos después de robar al  usuario su información y no existen registro de acciones realizadas, como pueden ser enviar mails u otras y viendo también en mi piloto, que el software proxy me devolví la contraseña del usuario en texto plano. Me inclino a pensar que el atacante, registra un nuevo segundo factor en la configuración del usuario, para garantizarse futuros accesos con su usuario y contraseña + doble factor registrado.

Protección en Azure AD ante este ataque

Una vez el correo ha llegado al usuario y mientras nuestro sistema de detección de URLs no indique que la dirección es peligrosa, Estamos expuestos a que el usuario haga click y se valide en la ventana de login, por lo que cabe entender el funcionamiento de Azure AD en cuanto a la sesión del usuario, para protegernos ante la adquisición de la cookie.

PIM

Por supuesto, ya que nos podemos caer en la trampa y nos pueden secuestrar una credencial. Lo que es muy aconsejable es que ninguna de ellas, tenga roles privilegiados asociados. Esto lo conseguimos utilizando y activando PIM, tal y como expliqué en este Webinar.

De forma general podemos tener en cuenta lo siguiente:

Situación de riesgo	Herramienta para la remediación
El mail llegó al buzón del usuario y días después, habiendo sido marcado el dominio como peligroso, aun pudo hacer click visitando la web del atacante.	Activación de Advanced Threath Management para garantizar control de urls actualizado en el día del acceso.
La propia realización de inicio de sesión. Acceso por parte del atacante al existir una regla de permisividad del Login, excesivamente abierta. Permitiendo acceso desde su localización, lugar y dispositivo.	Este login se ha podido realizar al cumplir reglas, las cuales por defecto son, “cualquier parte del mundo”, “cualquier lugar”, cualquier dispositivo”. [1]   Se aconseja la creación reglas de acceso condicionar para delimitar países, lugares específicos como la oficina y dispositivos, distinguiendo entre logins desde equipos corporativos, sincronizados con AdConnect y considerados híbridos, y los no corporativos, considerados Register en Azure AD.
Posibilidad del inicio de sesión del atacante durante el periodo de validez de la cookie.   La cookie es válida mientras la sesión no se revoque.	Requerir re autenticación cada cierto tiempo si se realiza en equipos no corporativos.   https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime#user-sign-in-frequency-and-multifactor-authentication
Uso de sistema multifactor que genera cookie atacable	Usar sistemas multi factor que no generen cookie:  Fido2 Security Keys Windows Hello for Business Certificado  El resto, sms, llamada y mobile app, generan cookie utilizable.

[1]Reglas condicionales efectivas

Método	Protección
Requerir dispositivo como “compliant”	Protege
Requerir dispositivo híbrido o unido a Azure AD	Protege
Regla condicional de control de sesión	Protege solo durante una ventana de tiempo
Regla condicional en la que permitir login solo desde sitios de confianza	Protege

Saludos

Acceso a cuenta saltándonos la contraseña y mfa + APP Authenticator

APP Authenticator king is dead, long live the Fido 2 King.

Pues acabo de colgar un video mostrando el laboratorio que he montado hoy, donde entro fácilmente en una cuenta que cuenta con contraseña y MFA App authenticator.

Lo he hecho con Outlook pero es igualmente posible con Twitter, Instagram, Okta, O365, Gsuite y muchos más.

En breve un post sobre sistemas de seguridad MFA seguros a en la actualidad, mañana quién sabe...