En Huntress, nos despertamos cada mañana, nos servimos nuestra bebida con o sin cafeína favorita, nos sentamos en nuestros escritorios y nos hacemos la misma pregunta: “¿Cómo podemos convertir a los cibercriminales en un ejemplo hoy?”
Me llamo Matt. Soy uno de los investigadores de seguridad en Huntress. Trabajo en el equipo de Gestión de Producto y ayudo a desarrollar nuestros productos para que golpeen a los hackers donde más les duele. Últimamente, eso significa que he estado trabajando en nuestro producto Managed ITDR. Ayudo a asesorar al equipo sobre cómo convertir nuestro producto de Microsoft 365 en un motor turboalimentado de perdición y consternación para hackers. Trabajo con un equipo de clase mundial de ingenieros de detección, investigadores de seguridad, analistas del SOC e ingenieros de software para lograr este objetivo.
Hoy quiero hablar de parte de la nueva tecnología que hemos implementado en nuestra lucha contra uno de los pasos más críticos en la cadena de ataque de Microsoft 365: el acceso inicial. El nombre del juego es cortar la actividad de los hackers lo más cerca posible del inicio del ataque. Me emociona compartir algunos de los desafíos y avances que hemos logrado recientemente para ayudarnos a detectar y disuadir a hackers sospechosos desde el comienzo de sus campañas. También quiero compartir el camino a seguir y el trabajo que queda por hacer.
El resumen es:
- Hemos logrado avances significativos para combatir el acceso inicial en las últimas semanas, enriqueciendo nuestros datos de eventos y creando detectores en torno a estos enriquecimientos.
- Los nuevos avances ya están dando frutos, y ya hemos atrapado hackers en plena acción. Los nuevos detectores para ubicaciones de usuario anómalas, evasión defensiva mediante VPN y credential stuffing representan una gran parte de los incidentes de Microsoft 365 reportados en el último mes.
- Todavía nos queda trabajo por hacer, ¡y vienen muchas mejoras en camino!
¡Vamos a eso!
Planteando el problema
Cuando la estrella de tu película de acción favorita se cuela en la base enemiga durante el gran éxito de taquilla, suele tener que bailar entre un pasillo de geniales láseres verdes para evitar ser detectada. En este escenario, imagina que la estrella de acción es un actor de amenazas y está en camino a tomar el control de tu cuenta.
Si logran acceder a tu correo electrónico, pueden interceptar y redirigir facturas, robar dinero, y en general causar estragos y caos a dueños de negocios desprevenidos.
En Huntress, nuestro trabajo es poner tantos de esos láseres verdes en su camino, en distintos ángulos y alturas, para que cuando se equivoquen (y créeme, sí se van a equivocar), sus errores sean detectados y sancionados en consecuencia.
Con ese fin, nuestro objetivo aquí es afinar la detección de la actividad de actores de amenazas que indica que ha ocurrido una toma de control de una cuenta. Esto significa que es fundamental poder distinguir cuándo un inicio de sesión es legítimo y cuándo indica actividad maliciosa. Es un problema complicado y lleno de matices. ¿Por dónde podemos empezar?
Para empezar a desenredar el molesto problema de la toma de control de cuentas, podemos dividir el tema en dos partes: VPN y proxies y viajes imposibles. Empecemos con las VPN y los proxies.
Herramientas del oficio: VPN, proxies y anonimizadores
Según informes de nuestro SOC, alrededor del 75% de las tomas de control de cuentas observadas y de la actividad sospechosa de hackers provienen de VPN y proxies. Las VPN y los proxies son tecnologías distintas, pero afectan a nuestros socios de manera similar.
Las VPN permiten a los cibercriminales operar de forma confidencial al cifrar su tráfico y enrutarlo a través de un servidor separado. Los proxies acceden a recursos en nombre de un usuario y ocultan la dirección IP real del usuario ante el servidor solicitado, pero por lo general no cifran el tráfico del usuario. Una parte menor de ese 75% de actividad sospechosa proviene de anonimizadores, como Tor, diseñados para proteger la identidad del usuario además de cifrar sus comunicaciones.
Si bien estas tres tecnologías difieren en cuanto a confidencialidad, funcionalidad y seguridad operativa, todas son utilizadas por cibercriminales para ocultar direcciones IP y mantener el anonimato durante sus operaciones. Desde la perspectiva del defensor, todas están estrechamente relacionadas en cuanto al impacto en nuestros socios y merecen nuestra atención.
Aquí tienes una pequeña muestra de actividad anónima de VPN y proxy de nuestros registros:
Nuestra suposición aquí es que, si bien no se puede afirmar con certeza que el uso de una VPN, proxy o anonimizador sea una señal segura de actividad sospechosa de hackers, la gran mayoría de la maldad confirmada proviene de estas fuentes. Cada uno de los eventos en esa captura de pantalla podría representar actividad de hackers. O todos podrían ser inofensivos. No puedo saberlo a simple vista. Y ese es el punto.
Ahora tenemos un dilema que resolver: ¿cómo distinguir lo bueno de lo malo cuando se trata de Microsoft 365?
De los 3,6 millones de eventos de Microsoft 365 que Huntress recibió en las últimas 24 horas al momento de escribir este blog, alrededor de 1,8 millones de esos eventos son eventos de inicio de sesión de usuario. De esos 1,8 millones de eventos de inicio de sesión, alrededor de 15.000 provienen de VPN. Si bien el uso de VPN representa menos del 1% del total de eventos de inicio de sesión, sigue siendo una cantidad asombrosa de inicios de sesión individuales para revisar.
Algunos de nuestros socios, en particular quienes realizan trabajo político y periodístico en todo el mundo, dependen de VPN y anonimizadores para proteger sus identidades. Cuando atrapamos a hackers abusando de proxies, VPN y anonimizadores como parte de sus ataques, en retrospectiva nos parece obvio. Pero a la escala en la que trabajamos, simplemente decir “VPN = malo” y “anonimizador = malo” está fuera de cuestión.
¿Podemos comprobar actividad sospechosa con solo ver de dónde proviene un evento de inicio de sesión de usuario determinado? ¡Es posible! Los datos de dirección IP de un evento dado son un excelente punto de partida. El desafío es que los datos de dirección IP son una auténtica bestia de domar. Nuestro primer obstáculo a superar al intentar avanzar contra el acceso inicial es convertir esta enorme cantidad de ruido relacionado con direcciones IP en datos procesables. ¡Aquí entra Spur!
Entra: Spur
Spur es una herramienta de terceros que enriquece nuestros datos al agregar contexto a lo que de otra manera sería una dirección IP estática. Usamos los datos que proporciona Spur para ver si las direcciones IP vinculadas a la actividad de los usuarios tienen algún atributo de interés. Por ejemplo, ahora podemos ver si esa IP proviene de un proveedor de VPN, un nodo Tor, un botnet conocido o un proveedor de servicios en la nube. También podemos saber si la dirección IP está anonimizada. Incluso obtenemos datos de geolocalización para las IP en nuestros eventos (más sobre esto después).
Cuando agregamos el contexto de Spur a nuestros registros de Microsoft 365, ahora podemos decir algo como: “muéstrame todos los eventos de inicio de sesión de Microsoft 365 de los últimos 15 minutos donde la dirección IP esté asociada con Surfshark VPN” y examinar los resultados:
¡Genial! Ahora sí estamos avanzando.
Pero seguimos con el mismo problema: si usar VPN es algo normal para un usuario dado, no podemos usar eso para probar actividad maliciosa. Entonces, ¿cómo podríamos establecer qué es normal para un usuario en comparación con otro? Para eso, necesitamos convertir una instantánea individual de la actividad del usuario en una película completa. Esto nos lleva a nuestra siguiente pieza de tecnología nueva: enriquecimientos de patrón de vida.
Patrón de vida
Para construir el contexto de desde dónde un usuario dado normalmente accede a Microsoft 365, examinamos su actividad y calculamos estadísticas basadas en los eventos vinculados a su cuenta. Luego, procesamos estos números y derivamos porcentajes para cualquier ubicación dada para saber desde dónde suele trabajar.
Por ejemplo, los usuarios en mi entorno de pruebas normalmente inician sesión desde Syracuse, Nueva York. Esto tiene mucho sentido porque vivo en Syracuse, así que los porcentajes para esa ciudad son altos:
Entonces, para este usuario en particular, cuando vemos eventos con direcciones IP en Syracuse, podemos decir: “sí, eso se ve bien. Ese usuario accede a Microsoft 365 desde Syracuse el 86% de las veces que lo hemos observado”.
Luego puedo consultar si hay inicios de sesión para esta identidad que también tengan ubicaciones de bajo percentil. Y, efectivamente, cuando busco inicios de sesión para esta identidad bajo un umbral de percentil de ubicación del 10%, encuentro esto:
¡Parece que esta cuenta inició sesión desde Japón! Más importante aún, Japón no es una ubicación común para [email protected]. Pero podemos seguir y ver si hay otros atributos interesantes para este evento:
Ahora consideremos la historia que podemos contar:
- La mayoría de las veces, lowpriv inicia sesión desde Syracuse, Nueva York…
- …pero esta vez, tenemos un evento de ubicación de bajo percentil en Japón…
- …y, tras una inspección más detallada, vemos que este inicio de sesión en realidad proviene de un nodo Tor!
¿Ha ocurrido una toma de control de una cuenta? En este caso, solo era yo probando nuestros detectores. Pero ya ves el punto. Podemos reducir el embudo para buscar y erradicar tomas de control de cuentas con estos enriquecimientos.
Un enriquecimiento individual sirve como una buena señal, pero combinar y correlacionar enriquecimientos empieza a contar una historia más interesante para nuestros analistas del SOC. Cada punto de datos es otro píxel en la imagen. Cuando combinamos estos enriquecimientos, podemos empezar a construir casos increíbles para cazar al mal.
Toma el increíble trabajo de mi colega Dave Kleinatland para identificar qué ISP tienen niveles inusualmente altos de inicios de sesión exitosos desde ubicaciones de bajo percentil:
El gráfico muestra que el ISP Ipxo Limited tiene un número inusualmente alto de inicios de sesión exitosos desde ubicaciones donde el percentil de ubicación para ese usuario dado es del 1% o menos. En pocas palabras, muchos inicios de sesión exitosos desde ubicaciones sospechosas provienen de direcciones IP alojadas por este ISP. El número de inicios de sesión de bajo percentil más que duplica el número de inicios de sesión donde la ubicación es del 100% para el usuario dado. Ese dato cuenta una historia que nuestro SOC puede usar durante las investigaciones.
Cazando al mal: credential stuffing en curso
Veamos otro ejemplo de lo que podemos hacer cuando combinamos contextos de enriquecimiento. En este caso, estamos tratando de identificar credential stuffing. Para demostrar esto, primero hablemos de las políticas de acceso condicional.
Piensa en las políticas de acceso condicional como reglas de firewall para las identidades de Microsoft 365. Permiten que un administrador de Microsoft 365 especifique reglas que permitan y denieguen el acceso a los recursos de su inquilino. Por ejemplo, una empresa puede establecer políticas de acceso condicional para permitir que los usuarios en su sede accedan a Microsoft 365 sin autenticación multifactor, pero exigir autenticación multifactor para cualquier intento de inicio de sesión que provenga de fuera de la sede. Los bloques de construcción de estas reglas son simples enunciados si-entonces: “si un usuario quiere acceso, entonces esto debe ocurrir primero”.
Hay montones de reglas que puedes implementar como políticas de acceso condicional. Todo, desde el geocercado de inicios de sesión por dirección IP hasta exigir autenticación multifactor, está sobre la mesa. Incluso puedes bloquear a los empleados para que no accedan a los recursos hasta que su dispositivo cumpla con las normas y esté administrado:
En Huntress, no controlamos las políticas de acceso condicional que nuestros socios establecen. Pero cuando nuestros socios deciden implementarlas (¡y te recomendamos que lo hagas!), sucede algo interesante.
Según la documentación de Microsoft, las políticas de acceso condicional se aplican justo después de que el primer factor de autenticación de un inicio de sesión tiene éxito:
Si suponemos que existe una política de acceso condicional y que un usuario es bloqueado por esa política, sabemos que el inicio de sesión tuvo éxito hasta el punto en que fue bloqueado. Cuando esto ocurre, se genera un evento correspondiente con “BlockedByConditionalAccess” en el campo LogonError.
Pensemos en esto por un momento: un usuario intentó iniciar sesión, ingresó correctamente su primer factor de autenticación, pero luego fue detenido por una política de acceso condicional. En la mayoría de los casos, la autenticación sigue el flujo estándar de “nombre de usuario y contraseña -> MFA (si está habilitado) -> inicio de sesión exitoso”. Hay excepciones donde un usuario puede tener la autenticación de dispositivo como su primer factor, pero hemos encontrado que esto es poco frecuente en los entornos de nuestros socios.
Entonces, si el acceso condicional impide que un usuario avance hacia la solicitud de MFA, sabemos que en la mayoría de los casos el inicio de sesión se autenticó correctamente con un nombre de usuario y una contraseña. Si suponemos que el inicio de sesión fue completado por un actor de amenazas, podemos inferir que el actor de amenazas adivinó o robó la contraseña de un usuario. Luego podemos buscar ese LogonError e identificar un posible credential stuffing en curso.
¡Eureka!... ¿Verdad? No exactamente.
No puedes saber que un inicio de sesión fue malicioso simplemente observando que fue bloqueado por una política de acceso condicional. Este tipo de cosas suceden todo el tiempo, y alertar sobre cada falla de política de acceso condicional sería demasiado ruidoso para ser útil. De hecho, mientras escribo este blog, tenemos más de 23.000 bloqueos de acceso condicional en los últimos 14 días dentro de las organizaciones de nuestros socios. Eso es alrededor de 1.640 eventos por día.
Si le dijera a nuestro SOC que tendría que investigar 1.640 bloqueos de inicio de sesión por acceso condicional al día para encontrar cuáles son realmente maliciosos, nuestro Director del Centro de Operaciones de Seguridad, Max Rogers, me mandaría a dar un paseo muy largo por un muelle muy corto. Y con razón.
Aun así, sabemos que podría haber algo malicioso en estos eventos de inicio de sesión bloqueados. Si un actor de amenazas tiene éxito con un nombre de usuario y contraseña robados y es bloqueado por una política de acceso condicional, sabemos que en la mayoría de los casos al menos comprometió o robó las credenciales de la cuenta del usuario. Y si yo fuera administrador de uno de nuestros socios, querría saberlo para poder rotar las credenciales del usuario y avisarle que cambie su contraseña si la usa en varias cuentas (¡qué vergüenza!).
¡Hay una señal en algún lugar aquí! Solo tenemos que ordenar los datos para separar la señal del ruido. Podemos aprovechar nuestros enriquecimientos para mejorar la tasa de aciertos al detectar eventos donde es probable que un actor de amenazas esté intentando iniciar sesión en tu cuenta con credenciales robadas.
Veamos más de cerca un ejemplo de un bloqueo por política de acceso condicional. Pero esta vez, veamos de cerca los enriquecimientos de datos:
En el ejemplo, examinamos poco menos de 100 eventos y determinamos que este usuario probablemente inicia sesión desde los Estados Unidos. Entonces, cuando un inicio de sesión aleatorio desde una VPN anónima en Yakarta es bloqueado por una política de acceso condicional, podemos avisarles que algo anda mal y que tal vez quieran rotar sus credenciales.
Usando enriquecimientos, hemos extraído algo potencialmente malicioso del ruido. Podemos construir una lógica de detección a partir de escenarios como este que básicamente dice:
“Muéstrame todos los bloqueos de política de acceso condicional de Microsoft 365 donde:
- El evento proviene de una fuente anónima…
- …y se ha observado la identidad del usuario lo suficiente como para identificar un patrón de comportamiento…
- …y el inicio de sesión bloqueado proviene de un lugar distinto a su ubicación habitual!”
Aunque no es infalible, esta es una evolución importante en la forma en que combatimos el acceso inicial. Esta es una señal derivada del ruido que podemos pasar a nuestro SOC para su investigación. Tal vez esto fue algo malicioso. Tal vez fue un usuario legítimo. El punto es que esta es una señal de mucha mayor calidad para entregar al SOC para su investigación.
¡Enriquece todas las cosas!
Estos enriquecimientos nos dan los bloques de construcción para una gran cantidad de nuevas detecciones. ¿Detectar actividad anómala de usuario desde una VPN? Listo. ¿Posible ataque de credential stuffing desde una ubicación de bajo percentil cuando el inicio de sesión falló MFA? Listo. ¿Inicio de sesión exitoso desde un nodo Tor en Brasil? ¡Listo, listo, listo! Lanzamos la mayor actualización de reglas de detección que hemos hecho, la misma semana en que integramos estos nuevos enriquecimientos.
De hecho, al momento de escribir y publicar este blog, las detecciones de ubicación anómala de usuario representan el 37% de los incidentes de seguridad de Microsoft 365 reportados en las últimas dos semanas. Los detectores de evasión de defensa mediante VPN representan el 15% de los incidentes de seguridad de Microsoft 365 reportados en ese mismo período. Los detectores de credential stuffing representan el 11% de los incidentes reportados.
Como dijo una vez el gran filósofo del siglo XXI T-Pain: “Puedo hacer esto todo el día como si no fuera nada”.
Estos detectores no son infalibles. Estamos constantemente refinando nuestro enfoque para reducir el número de falsos positivos y positivos verdaderos benignos. Pero cada uno que implementamos es otro láser verde en el pasillo. Ya hemos identificado y erradicado amenazas reales en las redes de nuestros socios al implementarlos. ¡La cacería está en marcha!
Mirando hacia adelante: la posible solución a los viajes imposibles
Le hemos dado un gran protagonismo a la actividad sospechosa de VPN con nuestra primera ronda de enriquecimientos. Pero la otra mitad de la ecuación, el viaje imposible, sigue sin resolverse. O al menos, parcialmente sin resolverse. Déjame explicarte.
"Viaje imposible" es básicamente una forma abreviada del siguiente axioma:
"Un usuario inició sesión desde la ubicación X y también inició sesión desde la ubicación Y, que está al otro lado del mundo, dentro de una ventana de tiempo que ni siquiera los métodos de viaje más rápidos permitirían. Ambos inicios de sesión no pueden ser legítimos."
Hay un argumento válido sobre por qué esa afirmación no es necesariamente cierta en todos los casos. Kyle y Chris hablaron sobre este tema en un episodio de the Product Lab (alrededor del minuto 31) si te interesa saber más sobre por qué no siempre es cierta. Pero para simplificar, voy a asumir que sí lo es.
Incluso cuando asumimos que ese axioma es cierto en todos los casos, esto significa que en realidad no estamos buscando el viaje imposible en sí. Estamos buscando indicadores de que ha ocurrido una toma de control de una cuenta de nuestros partners. El viaje imposible puede ser uno de esos indicadores.
La buena noticia es que nuestros detectores de inicios de sesión de VPN desde ubicaciones de bajo percentil hacen un muy buen trabajo al detectar cuándo ocurre una toma de control de una cuenta, y muchas de estas detecciones caen dentro de la categoría de viaje imposible. Recuerda que la mayoría de la actividad sospechosa de hackers observada ya proviene de VPN y proxies. En muchos casos, las detecciones anómalas de inicio de sesión de VPN coinciden con eventos de inicio de sesión legítimos de un usuario dado. Estos dos eventos de inicio de sesión pueden presentar una situación de viaje imposible.
Por ejemplo, este par de eventos de inicio de sesión muestra al mismo usuario iniciando sesión desde Virginia, EE. UU. y Delhi, India dentro de una ventana de 4 horas.
No existe ningún método en la Tierra que pudiera facilitar un viaje tan rápido. La última vez que lo revisé, el SR-71 Blackbird todavía no está disponible en el mercado comercial.
Encontré este par de inicios de sesión buscando eventos de inicio de sesión desde ubicaciones de bajo percentil que también tuvieran un evento de inicio de sesión de VPN o proxy dentro de un rango de tiempo cercano. El inicio de sesión desde Delhi proviene de un proxy de Zscaler, mientras que el inicio de sesión desde Virginia no tiene un proxy asociado. Además, este usuario tiene percentiles de ubicación saludables para Virginia (por encima del 95 % en este caso) y un percentil extremadamente bajo para India (menos del 2 % en este caso). El uso de un proxy explica cómo el usuario pudo iniciar sesión desde ambas ubicaciones dentro de una ventana de tiempo imposible.
Si bien este escenario presenta un caso de viaje imposible, el hecho más importante que hay que observar aquí es que un usuario inició sesión desde una ubicación de bajo percentil a través de un proxy. Este tipo de actividad activa uno de nuestros detectores. Luego podemos entregarle el caso al SOC para que lo investigue más a fondo.
El problema sin resolver, entonces, es cómo erradicar la toma de control de cuentas desde fuentes que no son VPN. No podemos depender de nuestros enriquecimientos para crear estas detecciones, así que debemos abordarlo desde una perspectiva más estadística y examinar escenarios de viaje imposible para lograrlo. La tasa de falsos positivos al detectar tomas de control de cuentas desde fuentes que no son VPN mediante el análisis de viajes imposibles sigue siendo, lamentablemente, muy alta. La misma identidad de usuario puede aparecer en eventos en múltiples ubicaciones, en múltiples dispositivos, representada por diferentes aplicaciones SaaS, todo dentro del margen de un segundo.
Observa que no estamos tratando de resolver el problema de la toma de control de una cuenta de forma unilateral. Podemos dividir el problema en partes más pequeñas y resolver cada una a su vez. El viaje imposible en realidad solo representa una parte menor del problema general si consideras que lo que en verdad estás resolviendo es el acceso inicial malicioso. Pero el viaje imposible, con todos sus matices y complejidad, aún puede ser una señal de que algo malo está ocurriendo. Así que es nuestra próxima montaña por escalar. Nuestra solución está en desarrollo. ¡Pronto más novedades sobre este tema!
Conclusión
Al inicio de esta publicación, planteé la pregunta que nos hacemos constantemente en Huntress: “¿Cómo podemos convertir a los cibercriminales en ejemplos hoy mismo?”. Cuando se trata de Microsoft 365, la respuesta es más o menos así:
- Análisis ofensivo: siempre comenzamos examinando cómo se desarrollan los ataques reales y desglosando sus piezas.
- Contexto: enriquecemos nuestros datos para crear señales significativas y separarlas del ruido habitual de Microsoft 365.
- Patrones: creamos patrones de comportamiento para las identidades, para saber si se autentican desde donde esperamos.
- Correlacionar: combinamos enriquecimientos de datos para contar una historia técnica más completa sobre los eventos de los usuarios.
- Erradicar: usamos el panorama que hemos construido para ubicar, armar nuestros casos y erradicar a los cibercriminales.
Todavía tenemos trabajo por hacer, y nuestro enfoque evolucionará con el tiempo. Y a medida que evolucionen las tácticas, también lo harán nuestras detecciones. Aun así, el trabajo que el equipo ha realizado recientemente para cambiar el rumbo contra los cibercriminales en el ámbito de Microsoft 365 ya ha dado frutos. Soy optimista de que seguiremos convirtiendo a los cibercriminales en ejemplos.
Gracias por leer y mantente atento a más novedades. Si tienes alguna pregunta específica, no dudes en escribirme a matt.kiely[at symbol]huntresslabs.com.
Y a los cibercriminales que andan por ahí, les digo esto: pónganse las zapatillas de ballet y cuiden sus pasos. Vienen más láseres verdes en camino.
