Nunca es solo una termita: seis meses investigando ataques a aplicaciones de OAuth

Resumen: si administras al menos un inquilino de Microsoft 365, audita tus aplicaciones de OAuth ahora mismo. Estadísticamente hablando, hay una buena probabilidad de que tu inquilino esté infectado con una aplicación maliciosa.

Escribí un script de código abierto que puede ayudarte a hacer esto:

https://github.com/HuskyHacks/cazadora 

Específicamente, busca en tus Aplicaciones Empresariales y Registros de Aplicaciones:

  • Aplicaciones nombradas como una cuenta de usuario
  • Aplicaciones llamadas “Test” o “Test App” o algo similar
  • Aplicaciones nombradas según el nombre de dominio del inquilino donde están instaladas
  • Aplicaciones que usan cadenas arbitrarias como nombres designados, como aplicaciones con nombres no alfanuméricos (es decir, “........”)
  • URLs de respuesta anómalas, incluyendo específicamente una URL de loopback local con el puerto 7823 [“http://localhost:7823/access/”]

En serio, ¡ve a auditar tus aplicaciones! El artículo seguirá aquí cuando vuelvas.

Si te interesan los detalles técnicos sobre inteligencia de amenazas, sigue leyendo.

Imagina esto: es un hermoso domingo por la mañana y esperas con ganas un día de descanso bien merecido después de una semana difícil. Entras tambaleándote a tu cocina y preparas tu bebida con cafeína favorita. El sol brilla. Los pájaros cantan. Te asomas por la ventana y sientes la brisa del verano en tu frente. Por un momento estás en paz. Te alegra estar vivo.

Y entonces miras hacia abajo y ves que en el alféizar de tu ventana hay una sola, solitaria termita.

Y al principio piensas: “Bueno, es solo una termita, no es gran cosa.”

Y luego lo piensas un segundo más. Y se te hiela la sangre porque te das cuenta de la terrible verdad: esta es la única termita que has visto.

Pero nunca hay una sola termita.

Tus esperanzas de relajación se desvanecen mientras formulas un plan para arrancar las tablas del piso de tu cocina.

Esta es, más o menos, la posición en la que nos encontramos yo y otros miembros del personal de Huntress cuando empezamos a analizar los datos sobre las aplicaciones de Azure y cómo se usan de forma maliciosa en los inquilinos de nuestros socios. Así que acompáñanos en este alocado recorrido mientras arrancamos las tablas del piso de la cocina y descubrimos qué tan grande es realmente el nido de termitas.

Ataques a aplicaciones de OAuth

Desde que lanzamos la capacidad de Acceso no deseado en agosto de 2024, el Centro de Operaciones de Seguridad de Huntress (SOC) ha estado ocupado acumulando conteos de ataques de identidad disuadidos. Construimos esta capacidad para enfocarnos en áreas clave de acceso inicial en el ámbito de la identidad, incluyendo el robo de credenciales, el robo de tokens de autenticación, ataques de adversario en el medio (AiTM) e inicios de sesión anómalos por ubicación o VPN. Según los datos, esta capacidad ha reducido significativamente la actividad de los actores de amenazas, y ahora estamos neutralizando entre 3 y 6.000 casos de acceso inicial cada mes.

Pero fiel al arte de la ciberdefensa, de nada nos sirve dormirnos en los laureles. Los hackers son como los zombis de I Am Legend. ¿Por qué? Bueno, ambos se queman al exponerse a la luz solar directa. Pero, más importante aún, ambos evolucionarán hasta el punto en que tus defensas actuales se vuelvan irrelevantes después de suficiente tiempo. Así que seguimos adelante para encontrar nuevas formas de identificar y romper sus cadenas de ataque.

Una de las áreas de investigación más urgentes es el concepto de las aplicaciones fraudulentas. Las aplicaciones en la nube son una parte fundamental de la experiencia del usuario y les dan a los desarrolladores un conjunto de herramientas poderoso para construir y escalar. Pero como hemos aprendido recientemente, los mismos beneficios que hacen tan atractivas a las aplicaciones en la nube para administradores y desarrolladores también las convierten en una opción atractiva para los ciberdelincuentes. Este parecía el siguiente lugar lógico para buscar ataques que lograron pasar desapercibidos por nuestros sistemas de combate al acceso inicial.

Así que, en agosto de 2024, me propuse responder algunas preguntas de investigación. ¿Cómo funcionan las aplicaciones de OAuth en Azure? ¿Cómo pueden aprovecharse durante los ataques? ¿Qué las hace tan poderosas y útiles para los ciberdelincuentes? ¿Cuál es la mejor manera de cazar estas aplicaciones fraudulentas? Y la pregunta final, que me generó una sensación de temor: ¿cuántas hay por ahí?

List of testbed Application Registrations
Figura 1: La lista actual de los Registros de Aplicaciones de mi entorno de pruebas. Con algo de suerte, la tuya no tendrá varias aplicaciones llamadas “not a backdoor.”

Al buscar respuestas a estas preguntas, terminamos encontrando mucho más de lo que esperábamos.

Los sistemas en juego: cómo funcionan las aplicaciones de OAuth

Agárrate, porque aquí viene un curso intensivo sobre las aplicaciones de Azure y cómo funcionan. Empezaré diciendo que este sistema es complicado y extraño. Un recurso que me ayudó a entenderlo fue la charla de John Savill’s Technical Training, "Azure App Registrations, Enterprise Apps, and Service Principals." Y vale la pena mencionar que John es un maestro certificado de la administración de Azure, y la miniatura de ese video lo muestra con cara de preocupación por tener que explicar el concepto. Así que no te preocupes por entender el sistema hasta el más mínimo detalle. Para los fines de este blog, explicaré los conceptos directamente relevantes para cómo las aplicaciones pueden usarse de forma maliciosa.

Las aplicaciones en la nube son muy parecidas a las aplicaciones de tu celular o tu computadora. Son programas modulares diseñados para hacer algo útil. Las aplicaciones en Azure se conectan con Entra ID, de modo que tu cuenta de Microsoft 365 podría, por ejemplo, usar un cliente de escritorio que organiza los correos electrónicos de tu cuenta en la nube.

Azure divide las aplicaciones en dos categorías: Aplicaciones Empresariales y Registros de Aplicaciones. Esta convención de nombres me parece extremadamente confusa, y me tomó un tiempo distinguir cuál era cuál. Pero la principal diferencia se puede resumir así: “¿Construiste la aplicación o estás usando una que alguien más construyó?”

Las aplicaciones empresariales son aplicaciones construidas, mantenidas y publicadas por alguien más en otro inquilino, que ahora estás usando en tu propio inquilino. Los Registros de Aplicaciones son aplicaciones que tú estás construyendo, manteniendo y publicando en tu propio inquilino para que otras personas las usen. En otras palabras, un Registro de Aplicación es algo así como una plantilla para una aplicación, mientras que una Aplicación Empresarial es una instancia de una aplicación que alguien está usando. Un desarrollador presuntamente escribirá el código de la aplicación y luego creará un Registro de Aplicación en su propio inquilino antes de publicarla para uso público o interno.

Ahora, supongamos que un administrador emprendedor quiere instalar tu app en su inquilino. Tal vez encontró tu sitio web y piensa que tu app se ve útil. Las apps no pueden simplemente instalarse donde quieran. ¿Te imaginas? Sería un caos. Por eso debe existir un sistema de autenticación (authN) y autorización (authZ) antes de que alguien pueda instalar una app en su inquilino. Por lo general, esto funciona así:

  • El usuario solicitará instalar la app. Al hacerlo, el usuario se autentica con su nombre de usuario, contraseña y MFA para asegurar que la app la esté instalando una parte confiable.
  • La app tiene un conjunto de permisos que le permiten hacer aquello para lo que fue diseñada. Por ejemplo, los permisos podrían permitirle a la app acceder a la Graph API para obtener los correos del usuario. La app muestra un aviso para que el usuario dé su consentimiento a los permisos.
App requiring consent to install a service principal into the user’s tenant.
Figura 2: El proceso de autenticación y autorización de la aplicación. La app requiere consentimiento para instalar un service principal en el inquilino del usuario.
Application authentication and authorization processes.
Figura 3: Los procesos de autenticación y autorización de la aplicación. El usuario, feliz, da su consentimiento a los permisos requeridos.
  • El usuario da su consentimiento a los permisos y autoriza a la app a acceder a recursos según esos permisos. Con la autenticación y la autorización ya resueltas, la app puede hacer aquello para lo que fue diseñada.
  • Ahora se instala un service principal en el inquilino del usuario, que funciona como una cuenta para esta app. Lleva el registro de los permisos consentidos y de las identidades que dieron su consentimiento a la app. La cuenta de servicio actúa en nombre de la app mientras esta permanece instalada en el inquilino.
 App installs a service principal in the user’s tenant.
Figura 4: Los procesos de autenticación y autorización. Con ambos resueltos, la app instala un service principal en el inquilino del usuario.

Si te saltaste la sección anterior porque era aburrida, no te culpo. Pero las conclusiones clave son las siguientes:

  • Las apps se pueden crear internamente (Registros de aplicaciones) o instalar desde otro inquilino (Aplicaciones Empresariales).
  • Las apps pueden tener acceso delegado en nombre de uno o más usuarios de un inquilino para acceder a recursos.
  • Las apps de Azure usan el sistema integrado de autenticación y autorización para funcionar.
  • Cada vez que se instala una app en algún lugar, se instala una entidad de servicio en ese inquilino, que funciona como la cuenta de trabajo de esa aplicación.
  • Y, por último, la configuración predeterminada de Azure permite que cualquier usuario instale cualquier aplicación y otorgue su consentimiento a permisos específicos para el acceso a sus propios recursos, ¡sin que la app pase por una revisión!

Lo que tenemos aquí es un conjunto fantástico de primitivas para la explotación.

¿Por qué? Cualquiera que haya pasado tiempo administrando un sistema grande y complicado de autenticación y autorización te dirá que a los atacantes les encanta encontrar las grietas imposibles de parchar del sistema para explotarlas. Cualquier red teamer que haya ejecutado un ataque de Kerberoasting te dirá que las mejores primitivas de explotación son funciones, no errores, y por lo tanto no se pueden parchar. Las apps en Azure siguen este mismo axioma: son parte del ecosistema, para bien o para mal. Su capacidad de personalización les da a los atacantes muchas opciones para adaptar la app al tipo de ataque que quieren ejecutar. Y, en su mayoría, pasan desapercibidas dado lo complejo que puede ser todo este sistema.

Cuando usas apps en Azure, sean maliciosas o no, permaneces por completo dentro del andamiaje legítimo que permite que las apps funcionen. Para los actores de amenazas, eso es un sistema increíblemente poderoso con el cual jugar. Averigüemos exactamente qué tan útil puede ser.

Traitorware: buenas apps que se vuelven maliciosas

Una barreta es una herramienta increíblemente útil. Puedes usarla para abrir cajas, forzar puertas atascadas y, si tienes suerte, hasta escapar de una enorme instalación de investigación subterránea en los desiertos de Nuevo México. Si captaste esa última referencia, pasas la prueba.

Una barreta en sí misma no es ni buena ni mala. Es útil en muchos contextos distintos. Y esos contextos definen cómo vemos la barreta como herramienta. Así que, ya sea que estés abriendo una caja de suministros o entrando por la fuerza a la casa de alguien, la barreta sigue siendo la misma. Claro que no puedes decir que todas las barretas son malas todo el tiempo. ¡Pero casi siempre que ves a alguien entrando por la fuerza a una casa, tiene una barreta!

En el mundo de las apps de Azure, la primera categoría de apps que estamos rastreando se parece mucho a una barreta. Llamamos a esta categoría traitorware. El término se refiere a apps que no están diseñadas explícitamente con fines maliciosos, pero que resultan extremadamente útiles para hackers, ciberdelincuentes y personajes turbios. Rastreamos apps que se usan abrumadoramente en ataques, aunque esas apps en sí no sean maliciosas.

El equivalente más cercano en seguridad de endpoints estaría en algún punto entre Living Off the Land y Bring Your Own tools. Este tipo de ataque se parece más a la instalación de una herramienta de Remote Monitoring and Management (RMM) durante una intrusión en un endpoint: el actor de amenazas trae una herramienta legítima a la pelea, que resulta ser útil para sus propósitos turbios.

Traitorware, aka Good Apps Gone Rogue.
Figura 5: Traitorware, también conocido como Good Apps Gone Rogue. Cada app tiene su escenario Jekyll y Hyde.

Al momento de escribir esta publicación, hay cinco apps de este tipo que consideramos pruebas contundentes. Estadísticamente hablando, los atacantes prefieren estas cinco apps. Con un tamaño de muestra de alrededor de 1,5 mil casos reportados y una tasa promedio de falsos positivos del 1,8%, los datos respaldan que detectar estas apps revelará mucha más actividad de hackers que actividad legítima.

La lista completa de apps Traitorware que hemos recopilado hasta ahora, junto con más detalles sobre cómo suelen usarse de forma indebida, está disponible en nuestro repositorio de código abierto de aplicaciones fraudulentas. Si has visto apps usadas de forma indebida de maneras similares, ¡nos encantaría saberlo! Considera abrir un PR y contribuir a la base de conocimiento para que podamos definir y rastrear mejor esta interesante superficie de ataque emergente.

Stealthware: apps malignas de la granja a la mesa

Por otro lado, el ecosistema de apps de Azure también les da a los hackers las herramientas para crear apps desde cero diseñadas para sembrar el caos. Hablo de APPS MALIGNAS de la granja a la mesa, de lote pequeño, hechas en casa, de origen ético, de campo libre, sin daño a los delfines, artesanales y hechas a mano. Creadas por manos de hackers y entregadas directamente a tu inquilino.

El nombre extenso para estos ataques es “OAuth Illicit Consent Grant Attacks," pero eso es como llamarle a un perro Canis Lupus. Solo los nerds usan nomenclatura científica, así que puedes ser un nerd genial como yo y llamarlas stealthware.

Lo complicado de cazar apps stealthware es que no hay dos iguales. No puedes encontrarlas buscando un nombre de app específico. Cada app está hecha a medida, adaptada al tipo de explotación que el hacker quiere llevar a cabo.

Enseño cómo hacer una con fines educativos en un episodio de Tradecraft Tuesday, si te interesa ese tipo de cosas.

Stealthware, an imposter among Azure applications.
Figura 6: Stealthware, el impostor entre las aplicaciones de Azure. Creado para sembrar el caos, creado para pasar desapercibido.

La caza en acción

Con nuestro modelo de amenazas afinado, es hora de meternos de lleno en los datos y responder la pregunta: “Aparte de esa termita, ¿cuántas más hay por ahí?”. Para esto, junto con la desarrolladora sénior de Operaciones de amenazas Christina Parry, emprendimos un viaje de recopilación de datos. Enumeramos más de 8.000 inquilinos en múltiples sectores e industrias, recopilamos todas sus aplicaciones Empresarial y registros de apps, realizamos un montón de análisis sobre los datos y presentamos nuestros hallazgos en BSidesNYC en octubre de 2024. En resumen, esto es lo que encontramos:

  • Encontramos evidencia tanto de Traitorware como de Stealthware en los inquilinos encuestados.
  • Alrededor del 10% de los inquilinos encuestados tenían al menos una de las apps Traitorware instalada.
  • Usar una combinación de la rareza global, la cantidad de usuarios asignados por app y los permisos otorgados a la app es una forma efectiva de detectar Stealthware.
  • Las apps con menos del 1% de prevalencia global entre los inquilinos encuestados que tenían acceso delegado a un solo usuario tenían más probabilidades de ser Stealthware. Agregar la clasificación de los permisos de OAuth en grupos según lo que le permitían hacer a los hackers durante las intrusiones, y detectar apps poco comunes que también tenían permisos poderosos, aumentó la tasa de aciertos significativamente.

Después de nuestra presentación, nos pusimos a trabajar en construir los sistemas para ampliar los datos y capturar la información de todos los inquilinos socios de Huntress. Después de volver a analizar y ajustar nuestros análisis, descubrimos que el hallazgo sobre las aplicaciones Traitorware se mantuvo constante en alrededor del 10%.

Después de publicar nuestros hallazgos, el SOC de Huntress también se puso a trabajar. Usando la nueva telemetría, formularon una hipótesis de caza e identificaron más de 500 instancias de aplicaciones Stealthware en todos los inquilinos socios. Mencioné antes que no puedes cazar Stealthware buscando por el nombre de una aplicación, y los resultados confirmaron ese punto. Esta es solo una muestra de algunos de los nombres de las apps confirmadas como positivas que encontramos:

Malicious app names the Huntress SOC found.
Figura 7: Solo una muestra de la variedad extravagante de nombres de apps maliciosas confirmadas que encontró nuestro SOC.

Con algunas hipótesis ya comprobadas, finalmente estábamos en posición de sacar una conclusión. Los ataques de apps OAuth no solo están presentes en los inquilinos socios de Huntress, sino que son mucho más comunes de lo que anticipábamos. Algunas de estas apps llevaban años instaladas para cuando las descubrimos. Y si te llevas algo de este artículo, que sea esto: estadísticamente hablando, hay una buena probabilidad de que tu propio inquilino esté infectado con una de estas apps.

Presentamos: Cazadora

Si llegaste hasta aquí y ahora estás pensando: “Vaya, tal vez debería ir a auditar mis apps”, ¡genial! Eso significa que logré demostrar suficientemente cuánto potencial de ataque existe en el ecosistema de apps de Azure.

Para acelerar el proceso de educar a la comunidad y darles a los administradores de Azure una oportunidad real de limpiar los nidos de termitas, construí y publiqué una herramienta de código abierto que enumera las apps de tu inquilino y las revisa para encontrar cualquier indicio evidente.

Cazadora
Figure 8: The output of Cazadora, identifying a few apps that have suspicious characteristics.

Te presentamos Cazadora, un script simple para buscar apps en Azure. Sea socio de Huntress o no, cualquiera puede ejecutar este script para enumerar y auditar las apps de tu inquilino según un conjunto de características de técnicas de ataque comúnmente observadas. Usa tu propia autenticación de usuario, llama a la API de Graph, organiza los datos que obtiene de la API sobre las Aplicaciones Empresariales (Enterprise Applications) y los Registros de Aplicaciones de tu inquilino, y ejecuta cierta lógica de búsqueda sobre los resultados. Es rápido y algo rudimentario, pero la idea es darles a los administradores de Azure en todas partes una forma de obtener de inmediato una idea sobre cualquier app sospechosa en su inquilino.

El script no puede encontrar el 100 % de las apps maliciosas en todos los casos. E incluso si el script no encuentra nada, eso no significa que tu inquilino esté a salvo de apps maliciosas. Pero, al menos, es un excelente punto de partida para que los administradores de Azure auditen sus apps e identifiquen cualquier cosa evidente. Consulta el README en el repositorio para ver las instrucciones.

Hasta la próxima, cuídate. Cuídense entre todos. Mantente alerta. ¡Feliz hacking!

También te podría interesar