Microsoft lanzó recientemente un noticias de seguridad actualización que aborda informes escalofriantes de que los atacantes han podido pasar de un inquilino de prueba a la suite C para obtener acceso a los correos electrónicos que se envían y reciben. Además, salió a la luz que Buzones corporativos de HPE Se había accedido utilizando un exploit similar.
Ambos parecen estar relacionados con un ataque de pulverización de contraseñas contra cuentas de correo electrónico heredadas que no tenían habilitada la autenticación multifactor. Analicemos la publicación de Microsoft y cómo podemos prevenir proactivamente este tipo de ataques en nuestra propia organización.
Microsoft indicó que: “Midnight Blizzard [a Russian state-sponsored actor also known as NOBELIUM] utilizó ataques de pulverización de contraseñas que comprometieron con éxito una cuenta de inquilino de prueba heredada que no era de producción y 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”.
Asegúrese de que la autenticación multifactor esté habilitada
Una lección que se puede aprender de esto es garantizar 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 inquilino de producción principal de Microsoft 365. Hoy en día, MFA debería ser obligatoria para cualquier servicio en la nube; no confíe solo en una contraseña para proteger cualquier activo en la nube.
Si su base de usuarios se opone a las implementaciones de MFA, hay formas de hacerlas más aceptables. Con el uso del acceso condicional, puede configurarlo de modo que MFA no sea obligatorio desde una ubicación confiable. Pero no seas demasiado complaciente; Si los atacantes obtienen acceso a una ubicación confiable, el acceso condicional o incluir una dirección IP en la lista blanca para garantizar que sus ejecutivos no se molesten con un mensaje de MFA puede no ser el camino a seguir. Dependiendo de la tolerancia al riesgo de su base de usuarios, puede decidir que esta política no es prudente.
Microsoft indicó que los ataques provinieron de direcciones IP que no parecían dañinas. «El actor de amenazas redujo aún más la probabilidad de descubrimiento al lanzar estos ataques desde una infraestructura de proxy residencial distribuida», según la actualización. «Estas técnicas de evasión ayudaron a garantizar que el actor ocultara su actividad y pudiera persistir el ataque en el tiempo hasta tener éxito».
Por lo tanto, las defensas normales no los habrían señalado como provenientes de lugares riesgosos. Es posible que desee considerar la instalación de direcciones IP estáticas en la configuración del hogar para aquellas personas de su organización que tienen más probabilidades de ser atacadas por atacantes. El uso de una dirección IP estática significa que puede identificar y proteger estos accesos mejor que las simples direcciones IP residenciales que pueden cambiar con el tiempo.
Preste atención a la ubicación desde la que los usuarios inician sesión
A menudo, con un ISP es difícil determinar la ubicación exacta desde la que un usuario inicia sesión. Si acceden desde un teléfono celular, a menudo esa dirección IP geográfica se encuentra en una ciudad importante a muchas millas de distancia de su ubicación. En ese caso, es posible que desee configurar una infraestructura adicional para transmitir su acceso a través de un túnel que esté mejor protegido y pueda ser examinado. No asuma que los malos usarán una dirección IP maliciosa para anunciar que han llegado a su puerta.
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”.
Luego, los atacantes crearon una nueva cuenta de usuario para otorgar consentimiento en el entorno corporativo de Microsoft a las aplicaciones OAuth maliciosas controladas por el actor. “El actor de amenazas luego utilizó la aplicación OAuth de prueba heredada para otorgarles Office 365 Exchange Online. acceso_completo_como_aplicación rol, que permite el acceso a los buzones de correo”.
Aquí es donde mi preocupación pasa de la incapacidad de Microsoft para proteger proactivamente sus procesos al problema más amplio de nuestra vulnerabilidad colectiva en las implementaciones en la nube. La autenticación se ha alejado del nombre de usuario y la contraseña tradicionales hacia una autenticación basada en aplicaciones que es más persistente. 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 a los atacantes hacerse un hueco.
Configurar permisos para mantener el control de los parámetros de acceso
Cualquier usuario puede crear un registro en la aplicación y luego dar su consentimiento para graficar los permisos y compartir cualquier dato corporativo. Debe configurar su inquilino para que requiera que un administrador de aplicaciones o un administrador de aplicaciones en la nube otorgue a un usuario el derecho de agregar una aplicación de terceros basada en OAuth al inquilino en lugar de permitir que los usuarios realicen autoservicio.
Este es especialmente el caso en una organización que administra información confidencial de cualquier tipo: todas las aplicaciones que se agregan al inquilino de Microsoft 365 deben aprobarse manualmente mediante un proceso de autorización. En el Centro de administración de Microsoft 365, seleccione Configuración, luego Configuración de organización, desplácese hacia abajo hasta Consentimiento del usuario para aplicaciones.
Desmarca la casilla que permite a los usuarios dar su consentimiento cuando las aplicaciones solicitan acceso a los datos de tu organización en su nombre. Desea examinar las aplicaciones antes de implementarlas para sus usuarios. El enfoque para la nube no es diferente.
Susan Bradley
Luego ve a Entra.microsoft.com en Configuración de la aplicación y busque Registros de aplicaciones. Asegúrese de haber identificado y reconocido las aplicaciones enumeradas. No entre en pánico si ve un P2PServidor listado, es un marcador de posición de la primera máquina unida a AD. Pero examine e investigue cualquier otra aplicación.
Susan Bradley
A continuación, vaya a Configuración de usuario y desactive aquellas que permiten a los usuarios registrar sus propias aplicaciones:
“Los usuarios designados pueden registrar aplicaciones” debe ser: No.
«Restringir la creación de inquilinos a usuarios que no sean administradores» debe ser: Sí.
«Los usuarios pueden crear grupos de seguridad» debería ser: No.
«Restringir el acceso al centro de administración de Microsoft Entra» debería ser: Sí.
Desea que los usuarios envíen solicitudes de consentimiento de administrador al configurar dicha aplicación. Pruebe el proceso de aprobación para asegurarse de que el administrador deseado reciba el aviso y examine la aprobación en consecuencia.
Asegúrese de que ningún usuario administrativo inicie sesión desde un dispositivo personal. Asegúrese de utilizar siempre un dispositivo seguro dedicado para el trabajo administrativo y ningún otro dispositivo.
Las aplicaciones en la nube pueden otorgar derechos potencialmente peligrosos a los usuarios
Hemos fomentado y utilizado aplicaciones en la nube para hacernos la vida más fácil, pero también han introducido derechos potencialmente peligrosos. Otro papel del que se puede abusar en el AppRoleAssignment.ReadWrite.All Función de la aplicación MS Graph que omite el proceso de consentimiento. Esto fue por diseño y estaba destinado a su implementación. Como resultado, esta función de la aplicación es peligrosa si no se comprenden las implicaciones.
Con demasiada frecuencia, nuestros desarrolladores e implementadores leyeron una publicación de blog o utilizaron una recomendación sin comprender realmente los riesgos. A menudo, no regresamos 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 características de seguridad.
A la luz de esta situación, querrás regresar y revisar si has asignado específicamente el AppRoleAssigment.ReadWrite.All que sin darse cuenta le otorgó mayores privilegios de los que pretendía. Una mejor manera de implementar permisos de aplicaciones es evitar el uso de este rol y en su lugar usar Política de consentimiento.
La conclusión es: no se limite a implementar nuevas tecnologías en la nube sin buscar también orientación para fortalecer la nube. Revisa las recomendaciones según los puntos de referencia de la CEIy otros proveedores que brindan asesoramiento sobre el fortalecimiento de Azure. No se limite a tomar los valores predeterminados proporcionados por el proveedor, las nubes también necesitan ser reforzadas: no son seguras de forma predeterminada.
Seguridad del correo electrónico, Gestión de amenazas y vulnerabilidades, Vulnerabilidades, Seguridad de Windows
Enlace fuente