Acceso persistente por permisos OAuth y sesiones abiertas tras compromiso no basta cambiar la

La amenaza no siempre se parece a un exploit espectacular; muchas veces entra por la puerta principal porque alguien la abre. En las últimas semanas se ha observado un patrón reiterado en el que atacantes combinan ingeniería social con mecanismos legítimos de autenticación y administración para obtener acceso persistente a cuentas y entornos corporativos. Los vectores más comunes no son vulnerabilidades zero‑day, sino permisos concedidos por usuarios o sesiones remotas que permanecen abiertas tras un compromiso. Esto cambia la forma en que debe responderse: no basta con cambiar la contraseña.

Técnicamente, los abusos más frecuentes aprovechan el flujo de consentimiento de OAuth/SSO y las sesiones persistentes de herramientas de soporte remoto o acceso remoto. En el caso de OAuth, una aplicación maliciosa o una página de consentimiento falsificada solicita al usuario permisos para actuar en su nombre; si el usuario acepta, la aplicación recibe tokens (access token y, a menudo, refresh token) que permiten mantener acceso sin necesidad de la contraseña. Estos tokens persisten hasta que se revocan explícitamente o caducan, por lo que un cambio de contraseña no elimina necesariamente ese acceso. De modo parecido, los atacantes usan sesiones activas de escritorio remoto o software de soporte (TeamViewer, AnyDesk, etc.) para mantener un canal directo: cerrar la sesión del sistema local no siempre revoca la autorización del software de control remoto.

También se están explotando técnicas más «clásicas» que facilitan el engaño: páginas con dominios muy parecidos (typosquatting), instrucciones de instalación que redirigen a instaladores maliciosos, y archivos compartidos con enlaces que piden aprobación de aplicaciones o acceso a datos. En paralelo continúan campañas de ransomware y de robo de identidad que usan los accesos obtenidos mediante estas rutas para cifrar datos, extraer información o desplegar servidores de mando y control (C2) escondidos detrás de servicios legítimos.

Quién resulta afectado es amplio: usuarios individuales cuya cuenta de correo o servicios en la nube son la llave de múltiples plataformas; pequeñas y medianas empresas que delegan en aplicaciones SaaS y en consents delegados por empleados; y organizaciones grandes cuando las configuraciones de SSO, consentimiento de aplicaciones y políticas de acceso no están endurecidas. Confirmado: las concesiones de permisos por parte de usuarios y las sesiones remotas abiertas son vectores prácticos y recurrentes. Estimación: el impacto real se multiplica en entornos donde hay cuentas con roles administrativos o acceso a activos críticos; en esos casos la cadena de ataque puede escalar a ransomware o robo masivo de datos. Incierto: la magnitud global de campañas simultáneas y la autoría exacta de cada operación suelen tardar en confirmarse por los equipos de respuesta y por los proveedores de cloud.

Las consecuencias prácticas son claras: acceso persistente sin necesidad de contraseñas, robo de correos y contactos, exfiltración de archivos, establecimiento de puertas traseras (aplicaciones con permisos, service principals, claves API) y ejecución de ransomware o fraude. Un punto crucial reportado por analistas es que revocar la contraseña no borra automáticamente tokens emitidos ni cierres de sesión remota, por lo que las puertas abiertas siguen existiendo si no se revocan las autorizaciones y sesiones activas.

Qué hacer ahora: acciones concretas para usuarios individuales y para responsables de seguridad.

Para cualquier usuario: revise las aplicaciones con acceso a su cuenta y retire las desconocidas o innecesarias; compruebe sesiones activas y cierre las que no reconozca; active la verificación en dos pasos robusta (preferiblemente sin SMS: llaves FIDO2 o aplicaciones de autenticación); y no acepte permisos de aplicaciones que pidan acceso amplio a correo, archivos o contactos salvo que confíe en el desarrollador. Google mantiene una página para gestionar aplicaciones conectadas y sesiones que es útil como primer paso: Administrar el acceso a tu cuenta Google. Además, si usa herramientas de soporte remoto, cierre y verifique la lista de dispositivos autorizados y notifique al proveedor si sospecha uso indebido.

Para equipos y empresas: implemente políticas de consentimiento administrativas que limiten la capacidad de los usuarios para aceptar aplicaciones de terceros sin revisión; habilite listas blancas de aplicaciones aprobadas; haga auditorías de consents delegados y ofrezca formación específica sobre consent phishing (cómo reconocer solicitudes legítimas de OAuth frente a imitaciones). En entornos Microsoft/Azure, revise y gestione los permisos de aplicaciones empresariales a través del portal de Azure AD y considere revocar grant approvals a aplicaciones sospechosas; Microsoft ofrece documentación para administrar el consentimiento y los permisos de aplicaciones en Azure AD: Administrar el consentimiento de aplicaciones.

Otras medidas técnicas imprescindibles incluyen forzar cierre de sesiones y revocación de tokens tras incidentes (en algunos proveedores existe la opción de revocar refresh tokens o «revocar sesiones»), desactivar protocolos de autenticación heredados que no soportan MFA, habilitar políticas de acceso condicional (por ubicación, dispositivo y riesgo), rotación de claves y secretos de aplicaciones, y monitorización de logs para detectar concesiones de consent imprevistas o la creación de service principals. También es buena práctica restringir los permisos de las aplicaciones al menor privilegio necesario y usar herramientas EDR para detectar y bloquear transferencias inusuales de datos o ejecución de herramientas administrativas por procesos no autorizados.

En resumen: la normalidad de estas intrusiones —una llamada, un archivo compartido o un botón «Permitir»— obliga a tratar el permiso concedido como un riesgo de seguridad en sí mismo. La respuesta efectiva combina revocación explícita de permisos y sesiones, endurecimiento de políticas de consentimiento, y controles preventivos como MFA fuerte y listas blancas de aplicaciones. Revisar lo que ya tiene acceso antes de añadir algo nuevo es, por ahora, la regla más práctica y eficiente para reducir la superficie de ataque.