Cómo prevenir proactivamente los ataques ‘password spray’ en cuentas de correo electrónico heredadas

Microsoft ha publicado recientemente información sobre unos inquietantes informes en los que explica que algunos atacantes han sido capaces de pasar de un tenant (cliente de sus servicios cloud) de prueba a la suite C para obtener acceso a los correos electrónicos que se envían y reciben. Además, ha salido a la luz que, usando un exploit similar, también habían accedido también a los buzones corporativos de HPE.

Ambas situaciones parecen estar relacionadas con un ataque de ‘password spray’ o pulverización de contraseñas contra cuentas de correo electrónico heredadas que no tenían activada la autenticación multifactor. Vamos a analizar la publicación de Microsoft y explicar cómo podemos prevenir proactivamente este tipo de ataques en nuestra propia organización.

Lo que indica Microsoft en la publicación es que "Midnight Blizzard [un actor ruso patrocinado por el Estado también conocido como Nobelium] utilizó ataques de pulverización de contraseñas que comprometieron con éxito una cuenta tenant de prueba heredada, no de producción, que no tenía habilitada la autenticación multifactor (MFA). En un ataque de pulverización de contraseñas, el adversario intenta iniciar sesión en un gran volumen de cuentas utilizando un pequeño subconjunto de las contraseñas más populares o más probables".

Hay que asegurarse de que la autenticación multifactor está activada

Una lección que se puede aprender de esto es la necesidad de asegurarse de que la autenticación multifactor (MFA) está habilitada en todo y revisar los procesos utilizados para las cuentas de prueba que tienen acceso a su tenant principal de producción de Microsoft 365. Hoy en día, la autenticación multifactor debería ser obligatoria para cualquier servicio en la nube: no hay que confiar en una simple contraseña para proteger cualquier activo en cloud.

Si la base de usuarios de una empresa se opone a las implementaciones de la autenticación multifactor, hay formas de hacerlas más llevaderas. Con el uso del acceso condicional, se puede configurar de forma que la autenticación multifactor no sea obligatoria desde un lugar de confianza. Pero no hay que confiar demasiado; si los atacantes consiguen acceder a una ubicación de confianza, el acceso condicional/la lista blanca de una dirección IP para asegurarse de que los ejecutivos no son molestados con un aviso de autenticación multifactor puede no ser el camino a seguir. Dependiendo de la tolerancia al riesgo de la base de usuarios que tenga una organización, se puede decidir si esta política es o no prudente.

Según Microsoft, los ataques procedían de direcciones IP que no parecían dañinas. "El actor de la amenaza redujo aún más la probabilidad de ser descubierto lanzando estos ataques desde una infraestructura proxy residencial distribuida", según exponen en la publicación realizada. "Estas técnicas de evasión ayudaron a asegurar que el actor ocultara su actividad y pudiera persistir el ataque en el tiempo hasta tener éxito".

De este modo, las defensas normales no los habrían identificado como procedentes de ubicaciones de riesgo. Es posible considerar la instalación de direcciones IP estáticas en entornos locales para aquellas personas de la organización con más probabilidades de ser objetivo de los atacantes. El uso de una dirección IP estática significa que se puede identificar y proteger estos accesos mejor que las meras direcciones IP locales que pueden cambiar con el tiempo.

Es preciso prestar atención a la ubicación desde la que se conectan los usuarios

A menudo, con un ISP es difícil determinar la ubicación exacta desde la que se conecta un usuario. Si accede desde un teléfono móvil, a menudo esa dirección IP geográfica se encuentra en una gran ciudad a muchos kilómetros de distancia de la ubicación de la empresa. En ese caso, es posible configurar una infraestructura adicional para retransmitir el propio acceso a través de un túnel que esté mejor protegido y pueda ser examinado. No hay que dar por sentado que los malos utilizarán una dirección IP maliciosa para anunciar que han llegado a la puerta de una organización.

Según Microsoft, "Midnight Blizzard aprovechó su acceso inicial para identificar y comprometer una aplicación OAuth de prueba heredada que tenía acceso elevado al entorno corporativo de Microsoft. El actor creó aplicaciones OAuth maliciosas adicionales".

Por tanto, los atacantes crearon una nueva cuenta de usuario para otorgar consentimiento en el entorno corporativo de Microsoft a las aplicaciones OAuth maliciosas controladas por ellos. "El actor de la amenaza luego usó la aplicación OAuth de prueba heredada para otorgarles el rol de Office 365 Exchange Online full_access_as_app, que permite el acceso a los buzones de correo".

En este punto, preocupa no sólo la incapacidad de Microsoft para proteger proactivamente sus procesos sino la potencial vulnerabilidad colectiva en las implementaciones en la nube. La autenticación ha pasado del tradicional nombre de usuario y contraseña a una autenticación basada en aplicaciones que es más resistente. Además, a menudo no entendemos lo que estamos configurando en un entorno de nube y accidentalmente dejamos los permisos en un estado que facilita que los atacantes entren.

Configuración de permisos para mantener el control de los parámetros de acceso

Cualquier usuario puede crear un registro de app y luego consentir permisos gráficos así como compartir cualquier dato corporativo. Es necesario configurar el tenant para que requiera que un administrador de aplicaciones (o de aplicaciones en la nube) conceda a un usuario el derecho a añadir dicha app de terceros basada en OAuth al tenant, en lugar de permitir que los usuarios se autogestionen.

Este es especialmente el caso de una organización que gestione información sensible de cualquier tipo; todas las apps que se añaden al tenant de Microsoft 365 deben ser aprobadas manualmente por un proceso de autorización. En el Centro de Administración de Microsoft 365 hay que seleccionar Configuración, luego Configuración de Org y desplazarse hacia abajo hasta Consentimiento del usuario para Apps.

Hay que desmarcar la casilla que permite a los usuarios dar su consentimiento cuando las aplicaciones solicitan acceso a los datos de su organización en su nombre. Lo que se busca es examinar las aplicaciones antes de que sean desplegadas a sus usuarios. El enfoque para la nube no es diferente.

A continuación, hay que ir a Entra.microsoft.com en Configuración de aplicaciones y buscar Registros de aplicaciones. Es preciso asegurarse de que se han identificado y reconocido las aplicaciones que aparecen en la lista. No hay que asustarse si se ve un P2PServer en la lista, es un marcador de posición de la primera máquina unida a AD. Pero hay que investigar cualquier otra aplicación.

A continuación, hay que ir a Configuración de usuario y desactivar las opciones que permiten a los usuarios registrar sus propias aplicaciones:

"Named Users can register applications" debería ser: No.

"Restringir a usuarios no administradores la creación de tenants" debería ser: Sí: Sí.

"Los usuarios pueden crear grupos de seguridad" debe ser: No.

"Restringir el acceso al centro de administración de Microsoft Entra" debería ser: Sí.

El cliente desea que los usuarios envíen solicitudes de autorización de administrador al configurar dicha aplicación. Hay que probar el proceso de aprobación para asegurarse de que el administrador reciba la solicitud y revisar la aprobación en consecuencia. Es preciso asegurarse de que ningún usuario administrativo inicia sesión desde un dispositivo personal y de que siempre utiliza un dispositivo seguro dedicado para el trabajo administrativo y ningún otro dispositivo.

Las aplicaciones en la nube pueden conceder derechos potencialmente peligrosos a los usuarios

En las organizaciones hemos fomentado y utilizado las aplicaciones en la nube para hacernos la vida más fácil, pero también hemos incorporado derechos potencialmente peligrosos. Otra de estas funciones que puede ser objeto de abuso es la función AppRoleAssignment.ReadWrite.All de la aplicación MS Graph, que se salta el proceso de consentimiento. Esto fue por diseño y estaba previsto para su implementación. Como resultado, este rol de aplicación es peligroso si no se entienden las implicaciones.

Con demasiada frecuencia, nuestros desarrolladores e implementadores han leído una entrada de blog o han utilizado una recomendación sin comprender realmente los riesgos. A menudo, no volvemos atrás y auditamos cómo están funcionando nuestras implementaciones en la nube, ni mantenemos una revisión constante de los cambios en los valores predeterminados y la introducción de nuevos valores predeterminados y funciones de seguridad.

A la luz de esta situación, el cliente querrá volver atrás y revisar si ha asignado específicamente el AppRoleAssigment.ReadWrite.All que inadvertidamente dio privilegios más altos de lo que pretendía. Una manera mejor de implementar los permisos de aplicación es evitar el uso de este rol y utilizar en su lugar la Política de Consentimiento.

En resumidas cuentas: no hay que limitarse a implantar nuevas tecnologías en la nube sin contemplar también una estrategia que dote a esta de mayor seguridad. Hay que revisar las recomendaciones de los puntos de referencia del CIS y de otros proveedores que ofrecen asesoramiento sobre el endurecimiento de Azure. No hay que limitarse a aceptar los valores predeterminados proporcionados por el proveedor, las nubes también necesitan ser reforzadas, no son seguras por defecto.