Es una práctica habitual que cada vez usemos más y más la nube, definiendo como nube el uso de sistemas y aplicaciones de fuera de nuestra organización. Esta migración va acompañada muchas veces de una centralización de la autenticación, es decir, que todas las aplicaciones usen el mismo sistema de autenticación y así nos ahorramos el aprendernos 50 usuarios y contraseñas diferentes.
De forma práctica, la mayoría de las empresas que nos encontramos tienen un entorno de Office365 con Azure AD, en el que «replican» y sincronizan los datos de su Active Directory on-prem, y suelen usar ese Azure AD como SSO (Single Sign On) para autenticarse en aquellos sitios que lo implementen. Esto se puede hacer debido a que Azure AD implementa el estándar OAuth 2.0.
OAuth permite a un usuario del sitio A (proveedor de servicio) compartir su información con el sitio B (llamado consumidor) sin compartir toda su identidad. Para desarrolladores de consumidores, OAuth es un método de interactuar con datos protegidos y publicarlos. Para desarrolladores de proveedores de servicio, OAuth proporciona a los usuarios un acceso a sus datos al mismo tiempo que protege las credenciales de su cuenta.
Como se puede ver, dentro de este paradigma, la intención no es que el usuario esté venga a meter en todos lados su usuario y contraseña continuamente. Para ello, se usan los Tokens. Y estos trocitos de texto son precisamente el contenido de este artículo.
Recordemos que un proceso de autenticación no puede, ni debe, limitarse al típico usuario y contraseña. Hay que contemplar otras medidas como son el MFA, y cuando se puedan, políticas condicionales de acceso.
El problema es que los Threat Actors (TA) también conocen todo esto. Saben que muchas veces no será suficiente con robar el usuario y la contraseña. Necesitan los tokens para poder pasar por los controles adicionales que se hayan podido implementar. Veamos como funciona el proceso normal, las técnicas que usan los atacantes, y qué podemos hacer para protegernos, acotando la tecnología en uno de los sistemas que más nos encontramos: Azure AD y la suite de Microsoft Office 365.
Proceso de autenticación legítimo
En una situación normal, para acceder a un recurso (por ejemplo, una aplicación web protegida por Azure AD), un usuario debe presentar un token válido. Para obtener ese token, el usuario debe iniciar sesión en Azure AD con sus credenciales. En ese momento, según la política, es posible que deban completar la MFA. Luego, el usuario presenta ese token a la aplicación web, que valida el token y permite el acceso del usuario.
Cuando Azure AD emite un token, contiene información (claims) como el nombre de usuario, la dirección IP de origen, MFA y más. También incluye cualquier privilegio que tenga un usuario en Azure AD.
Con el phishing de credenciales tradicional, el atacante puede usar las credenciales que ha comprometido para intentar iniciar sesión en Azure AD. Si la política de seguridad requiere MFA, el atacante no puede iniciar sesión correctamente. Aunque las credenciales de los usuarios se vieron comprometidas en este ataque, el TA no puede acceder a los recursos de la organización. En la siguiente imagen se muestra cómo funcionaria el sistema «normal» de robo de credenciales (usuario y contraseña) cuando hay MFA.
Por eso es importante implementar MFA siempre que sea posible.
Entendiendo los registros
Todos los intentos de autenticación se reflejan en los logs de Azure AD, dentro de la sección de «Registros de inicio de sesión». Cualquier situación anómala la podremos ver alli, pero viene bien conocer algunos aspectos básicos para entenderlos.
Por un lado, se diferencia de «Inicios de sesión interactivos» de «Inicios de sesión NO interactivos». Para entendernos, una explicación «alto nivel» seria la siguiente:
- Inicios de sesión interactivos implica que un usuario ha introducido su usuario y su contraseña manualmente en una web, por ejemplo.
- Inicios de sesión NO interactivos quiere decir que se ha iniciado una autenticación a través de un token, por ejemplo. Que una aplicación web a autenticado al usuario a través de un Token.
Como aplicación podemos ver diferentes aplicaciones, siendo las más habituales:
- OfficeHome. Es la aplicación que utilizamos cuando accedemos a portal.office.com
- Office 365 Shell WCSS-Client. Es el código del navegador que se ejecuta cada vez que un usuario navega a (la mayoría de) las aplicaciones basadas en el navegador de Office365. La shell es un código compartido que se carga como parte de la mayoría de las cargas de trabajo de Office365, como SharePoint, OneDrive, Outlook, Yammer y muchas otras.
Dentro de estos datos de inicio de sesión, podemos ver algunos muy interesante, como pueden ser:
- La localización. Es una geolocalización de la IP, pero permite localizar de forma rápida conexiones sospechosas y plantearse hacer accesos condicionales en base a países o sitios no reconocidos.
- El dispositivo. Cada usuario tiene unos dispositivos enlazados. El acceso desde dispositivos no reconocidos puede ser motivo de sospecha y de realizar políticas.
- El recurso al que está accediendo el usuario.
Revisando estos eventos podemos conocer el cuándo, quién, cómo y qué está siendo accedido.
Escenarios de ataques posibles
Los TA, conocedores de esta situación, han evolucionado sus tácticas y técnicas para adaptarse y poder seguir realizando sus acciones. En este caso, el objetivo es conseguir el acceso, poder suplantar a un usuario (y si hay suerte y tiene permisos privilegiados, mucho mejor).
Se conocen dos escenarios diferentes de ataques:
Ataque de phishing de Adversary-in-the-middle (AitM)
Este es un ataque que cada vez vemos con más frecuencia. El usuario recibe un ataque de phishing que, mediante técnicas de ingeniería social, intentan enviar al usuario a una página que le fuerce a introducir sus credenciales:
Por ejemplo, se puede emular una pantalla de login de O365 (muy típica) haciéndote creer que necesitas autenticarte para acceder a un fichero compartido, por ejemplo.
El TA ha desarrollado una aplicación intermedia que luego contacta con tu Azure AD, y por un lado recoge las credenciales y, seguidamente, el token que le sirve Azure.
¿Qué pasaría tiene un rol de administración? Pues que tendría acceso a toda la infraestructura subyacente y llegar a realizar un compromiso total.
Ataque Pass-the-cookie
Cuando un usuario se autentica en una aplicación web, que por detrás consulta con Azure AD (por seguir con el mismo caso), se guarda el token en una cookie de la aplicación web. Con esto, un TA puede intentar robar estas cookies para usarlas emulando un navegador web y acceder a los recursos a los que accede el usuario
El robo de las cookies puede realizarse de diversas formas, pero la más común es usar un malware stealer que las envía a un servidor de command&control controlado por el atacante. En este sentido, los sistemas no controlados por las organizaciones tienen más riesgo de sufrir este ataque. Claro que todos tenemos software antimalware (perdón, ahora tenemos EDRs) en nuestro equipo corporativo, y políticas y controles de seguridad más restrictivos. Pero, ¿y en el portátil de casa que compartimos con nuestra familia? ¿En la tablet y el móvil con el que consultamos el correo?
¿Tan malo es todo esto?
Podemos intentar consolarnos pensando que tenemos MFA, que en algunos casos no nos controlan las credenciales, solo «una pequeña cadena de texto»… Pero debemos ver el riesgo en su dimensión real.
Por ejemplo, los ataques de AitM es muy típico que acaben en ataques BEC (Business Email Compromise), que suele seguir un esquema muy similar al siguiente:
En base a un acceso «robado», a pesar de no tener privilegios, llega a una monitorización del buzón del usuario y, posteriormente, realizar el fraude. Recordemos que, de acuerdo al estudio del FBI «Business Email Compromise and Real Estate Wire Fraud», en el año 2022 este ataque tuvo un impacto de 2.700 millones de dólares.
Estos ataques son solo el comienzo de una campaña más compleja sobre el objetivo. En el caso de un BEC, se analizaron todas las acciones que se llevaron a cabo y se identificaron diferentes actividades, tanto en el acceso inicial, como el reconocimiento o en el «pre-fraude». La siguiente imagen da una idea de como suelen trabajar este grupo de actores:
Pero podemos tener más casos. Imaginemos un acceso a una VPN corporativa protegida con un MFA. Estos ataques podrían permitir a un atacante acceder a toda la red corporativa para desplegar un ransomware (una técnica cada vez más usada). Quizás ahora veamos que el MFA, aunque necesario, no es lo único en lo que tenemos que pensar.
¿Y ahora qué podemos hacer?
Visto esto, y ya que estamos concienciados de que siempre se puede mejorar, veamos que podemos hacer en este caso en concreto. Como siempre, identificamos tres aspectos a tener en cuenta: debemos protegernos, debemos detectar un ataque y debemos responder.
La protección pasa por tener en cuenta algunas de estas medidas:
- Reducir la vida útil de las sesiones o reducir el tiempo de viabilidad de un token hace que la ventana de actuación de los atacantes sea más corta.
- Implementar políticas de acceso condicional, de forma que obligue a aplicar el MFA en caso de acceso desde un sitio o un dispositivo no reconocido.
- Implementar soluciones de MFA resistentes al phishing.
- Segregar y segmentar roles y permisos de usuarios, incluso en diferentes identidades para diferentes capacidades administrativas.
Estos elementos no son infalibles de forma individual, pero el objetivo es poner controles que dificulten el acceso a los atacantes. Esto es un negocio, si somos «difíciles» de acceder, es más probable que dejemos de ser rentables y pasen al siguiente objetivo.
La detección es también muy importante. Muchos casos de fraudes que nos hemos encontrado podrían haberse resuelto revisando los eventos de autenticación y las actividades sospechosas implicadas.
Para poder realizar esta detección se suelen monitorizar los eventos del sistema de autenticación y las aplicaciones relacionadas, y en base a diferentes reglas (correlación, comportamiento…) poder identificar situaciones de riesgo que un analista pueda revisar.
Algunas «red flags» que debemos tener en cuenta:
- Correos con ficheros o enlaces maliciosos que se hayan identificado tras su entrega al usuario.
- Manipulaciones sospechosas en los buzones de correo (permisos delegados, redirecciones…).
- Viajes imposibles: un usuario no puede hacer login desde Bilbao y en media hacerlo desde Albania.
- Actividad realizada desde un país que no suele tener actividad.
- Token con características anómalas.
- Propiedades de inicio de sesión anómalas.
Por ejemplo, la siguiente consulta nos puede dar aquellas sesiones que se han visto en la página de inicio de Office y posteriormente se han visto en otra aplicación, en otro país.
let OfficeHomeSessionIds = AADSignInEventsBeta | where Timestamp > ago(1d) | where ErrorCode == 0 | where ApplicationId == "4765445b-32c6-49b0-83e6-1d93765276ca" //OfficeHome application | where ClientAppUsed == "Browser" | where LogonType has "interactiveUser" | summarize arg_min(Timestamp, Country) by SessionId; AADSignInEventsBeta | where Timestamp > ago(1d) | where ApplicationId != "4765445b-32c6-49b0-83e6-1d93765276ca" | where ClientAppUsed == "Browser" | project OtherTimestamp = Timestamp, Application, ApplicationId, AccountObjectId, AccountDisplayName, OtherCountry = Country, SessionId | join OfficeHomeSessionIds on SessionId | where OtherTimestamp > Timestamp and OtherCountry != Country
No es posible siempre revisar todas las posibles alertas a mano, sobre todo en grandes infraestructuras grandes. Por eso, es importante usar soluciones de monitorización y complementar la acción con un Hunting realizado por un analista.
Si se detecta o se confirma una intrusión, es importante poder reaccionar. La reacción inicial es el bloqueo del usuario, pero debemos saber que también existe la capacidad de cerrar y revocar las sesiones y tokens asociados a un usuario. Como se puede ver en la siguiente tabla, no siempre es suficiente con el cambio de contraseña:
Además, es importante revisar las características del compromiso, identificar dónde puso estar el robo de la sesión, para mejores los sistemas de protección y tomar medidas adicionales.
Además., en caso de confirmar un compromiso, es importante revisar los siguientes aspectos que suelen realizar los atacantes para garantizar cierta prsistencia:
- Revisar las reglas del buzón de correo y los reenvíos de buzones.
- Identificar posibles modificaciones en la autenticación multifactor.
- Revisar si se han agregado dispositivos nuevos al perfil del usuario.
- Analizar posibles exfiltraciones de datos desde los sistemas de almacenamiento y compartición de ficheros.
Conclusiones
Llegados a este punto, consideramos que estamos concienciados de la importancia de proteger un punto tan importante como es Azure AD, el corazón de todos los mecanismos de autenticación de nuestra organización. Es imposible enumerar en un artículo todas las posibilidades, y cada organización es única. Pero nos queda claro que descuidar este aspecto puede ser muy perjudicial para las organizaciones.
Desde Perseus podemos ayudaros en las diferentes fases del ciclo de vida y adaptarnos a la madures de cada organización. Siendo la acción más básica la realización de una auditoría para conocer el estado exacto de seguridad, como la integración del AD en un sistema de monitorización corporativo y el análisis y respuesta ante incidente de seguridad, así como el apoyo de analistas forenses en caso de que se sufra un compromiso.
Referencias:
https://azure.microsoft.com/es-es/solutions/active-directory-sso
https://es.wikipedia.org/wiki/OAuth
https://blog.skymadesimple.io/examine-the-sign-in-logs/
https://aadinternals.com/post/prt/
Miguel Tubía
Responsable del CERT
miguel.tubia@pers.eus | Móv: 664 367 173
PGP KeyID: 0xF51D6746
Parque Tecnológico Edif. 205B | 48170 Zamudio – Bizkaia
www.pers.eus
