Redacción Digital Inside España
Proofpoint documenta que las aplicaciones OAuth pueden mantener acceso a correo y archivos aunque se restablezca la contraseña o se aplique MFA. La compañía describe que, una vez obtenido el control de una cuenta en la nube, el atacante puede registrar y autorizar aplicaciones internas con permisos a medida sobre recursos corporativos. Ese acceso autorizado se conserva aunque cambien las credenciales del usuario, lo que convierte a la aplicación en un punto de persistencia dentro del entorno comprometido. Los autores publican además una herramienta de demostración que automatiza la creación de estas apps maliciosas y el mantenimiento del acceso en entornos comprometidos.
El vector clave no es solo el consentimiento a apps externas, sino la creación de aplicaciones internas en el tenant que heredan confianza y pasan más desapercibidas. En el análisis se distingue entre aplicaciones de terceros (registradas en un tenant externo) y de “segunda parte” o internas (registradas dentro de la propia organización, en Microsoft Entra ID). La segunda tipología de aplicaciones, puede eludir controles diseñados sobre todo para monitorizar aplicaciones externas. Pudiendo resultar menos visibles para equipos de seguridad si no se auditan de forma específica.
En el flujo de ataque típico, la intrusión inicial se apoya en técnicas de interceptación de sesión (por ejemplo, proxys inversos) combinadas con señuelos de phishing personalizados para robar credenciales y cookies. Con ese primer acceso, el actor amenaza registrar una app interna, le asigna permisos según sus objetivos y la autoriza frente a los recursos que desea (correo, ficheros o colaboración). A partir de ahí, la persistencia ya no depende del usuario: la aplicación opera con su propio secreto de cliente y con los tokens emitidos por la plataforma cloud.
En su prueba de concepto, los investigadores automatizan el registro de apps con permisos como Mail.Read y offline_access, generan secretos de cliente y capturan tokens para persistir tras un cambio de contraseña. El ejercicio muestra que, aun cuando un equipo de respuesta a incidentes fuerza el reseteo de la contraseña, la aplicación mantiene el acceso autorizado y puede seguir leyendo el buzón del usuario y otros recursos definidos por los ámbitos concedidos (SharePoint, OneDrive, Teams, calendario o contactos). La visibilidad de esa app en el portal de Entra ID existe (aparece como un registro interno con sus permisos y secretos), pero requiere auditoría activa para identificarla y revocar su acceso.
La telemetría de Proofpoint recoge un caso real con cuatro días de actividad, reglas de buzón maliciosas y una app interna denominada ‘test’ que siguió accediendo al correo tras el reseteo de credenciales. En ese incidente, el acceso inicial se asoció a un agente de usuario característico de ataques adversario-en-medio y a proxies VPN en EE. UU. Después de crear reglas de correo y registrar la aplicación con permisos Mail.Read y offline_access, el actor continuó con su actividad aunque se cambiara la contraseña del usuario; posteriormente se observaron intentos fallidos desde una IP residencial en Nigeria, mientras la aplicación seguía activa.
Los investigadores de Proofpoint señalan que: “Los ataques de toma de control de cuentas en la nube se han convertido en una preocupación significativa en los últimos años, puesto que los ciberdelincuentes están adoptando cada vez más aplicaciones OAuth maliciosas como medio para obtener acceso persistente en entornos comprometidos. Una vez que entran en una cuenta cloud, pueden crear y autorizar aplicaciones internas con permisos y alcances definidos para maximizar el impacto de este acceso a recursos críticos, como buzones de correo o archivos”.
Para los responsables de TI y de compras tecnológicas, la conclusión operativa es directa: la respuesta no puede limitarse a rotar contraseñas o reforzar MFA; hay que gestionar el ciclo de vida de las aplicaciones registradas en el tenant. La remediación efectiva, según el análisis; pasa por la revocación inmediata de todos los secretos de cliente y certificados vinculados a la app, la invalidación de los tokens de usuario, la eliminación del registro de la aplicación y de sus service principals, y el establecimiento de monitorización continua de las aplicaciones de línea de negocio. Junto a ello, resulta necesario reforzar la concienciación de los usuarios para que traten como sospechosas las solicitudes de consentimiento inesperadas y reporten cualquier autorización anómala.
En términos prácticos, esta técnica obliga a revisar políticas y capacidades de inventario y auditoría en Microsoft 365/Entra ID: localizar registros de aplicaciones internas, verificar ámbitos concedidos y vigilar la creación de secretos con vigencias largas. La ventana de persistencia que otorga un secreto de cliente válido puede prolongar la exposición durante meses si no se detecta. En paralelo, deben integrarse en el plan de respuesta a incidentes las tareas específicas de revocación y limpieza de aplicaciones, junto con el barrido de reglas de buzón y otros artefactos post-explotación, para cerrar todas las vías de acceso no dependientes de credenciales de usuario.
