Phishing OAuth: cómo te roban el acceso sin pedirte contraseña

Phishing OAuth: cómo te roban el acceso sin pedirte contraseña

El phishing OAuth te roba el acceso a tu cuenta sin necesidad de conocer tu contraseña: en lugar de pedirte credenciales, te convence de pulsar "Permitir" en una pantalla de autorización legítima de Google o Microsoft. Ese robo de token concede a un atacante permisos permanentes sobre tu correo, tu Drive o tu calendario. Lo llaman consent phishing y funciona porque la víctima autoriza el fraude con sus propias manos. La autorización fraudulenta no dispara alarmas de contraseña filtrada, no salta el 2FA y sobrevive a un cambio de clave. Este tipo de ataque OAuth explota la confianza en el propio botón de "Iniciar sesión con Google". Vamos a diseccionar cómo montan la trampa y qué hacer cuando ya has picado.

Qué es el phishing OAuth y por qué se salta tu contraseña

OAuth 2.0 es el protocolo que permite que una app de terceros acceda a tus datos sin que le des la clave. Cuando pulsas "Conectar con Google", no compartes contraseña: entregas un token de acceso. Ese token es la llave real.

El atacante no necesita tu clave. Registra una aplicación maliciosa en la nube de Google o Microsoft, le pone un nombre creíble ("Adobe Cloud Sync", "Backup de Correo") y te manda el enlace de consentimiento oficial. La pantalla que ves es 100% legítima. Lo fraudulento son los permisos que solicita.

Cuando aceptas, la app obtiene un refresh token. Con él puede leer tu correo durante meses, aunque cambies la contraseña y aunque tengas verificación en dos pasos. El robo de token vive fuera de tu credencial. Por eso el consent phishing es tan difícil de detectar con las defensas clásicas.

Microsoft lleva años avisando de campañas de autorización fraudulenta contra cuentas corporativas de Microsoft 365. El caso más sonado fue la operación atribuida al grupo Nobelium (los mismos de SolarWinds), que usó apps OAuth maliciosas para mantener acceso persistente al correo de organizaciones objetivo.

Cómo funciona el ataque paso a paso

La mecánica del ataque OAuth es incómodamente elegante. Nada de webs falsas mal traducidas. Todo transcurre dentro de dominios reales de Google o Microsoft.

  1. Registro de la app maliciosa. El atacante crea una aplicación en Azure AD o en Google Cloud Console y define los scopes (permisos) que pedirá: leer Gmail, enviar en tu nombre, acceso total a Drive.
  2. Cebo por email. Te llega un correo tipo "Revisa este documento compartido" o "Renueva tu almacenamiento". El enlace apunta a la pantalla de consentimiento auténtica del proveedor.
  3. La pantalla legítima. Ves el logo de Google, la URL accounts.google.com real y el candado verde. Todo canta a seguro.
  4. El clic fatal. Pulsas "Permitir". Acabas de firmar la autorización fraudulenta.
  5. Persistencia. La app guarda su token y opera en silencio. Reenvía correos, exfiltra archivos, envía spam desde tu dirección.

El detalle diabólico: muchas de estas apps solicitan el permiso offline_access, que garantiza acceso incluso cuando no tienes sesión abierta. Aquí no hay página clonada que delate el fraude, así que las señales en la URL que suelen delatar una web de phishing no te sirven. La URL es la buena. El problema es lo que autorizas dentro.

Señales de alerta antes de pulsar "Permitir"

La pantalla de consentimiento es aburrida y por eso la gente la acepta sin leer. Ese es el agujero. Antes de dar acceso, lee lo que pide.

  • Permisos desproporcionados. Un supuesto visor de PDF no necesita "leer, enviar y borrar tu correo". Si los scopes no encajan con la función, huele a trampa.
  • Editor sin verificar. Google muestra un aviso amarillo cuando la app no está verificada. Microsoft indica "no publisher" o publisher desconocido. Bandera roja.
  • Nombre genérico o imitador. "Google Docs" con espacios raros, "Micr0soft Office" o marcas conocidas mal escritas.
  • Contexto forzado. Un email con prisa ("tu cuenta se suspenderá") que te empuja a autorizar. La urgencia es el sello del consent phishing.
  • Redirección extraña. Tras aceptar, acabas en un dominio que no reconoces.

Regla práctica: si una app pide acceso a tu correo o a tus archivos y no la instalaste tú a conciencia, cancela. El robo de token se previene en el segundo previo al clic, igual que en la seguridad informática para pymes la mitad de la batalla es formar a quien tiene el ratón.

Qué hacer si ya autorizaste una app maliciosa

Cambiar la contraseña no basta. El token sobrevive. Tienes que revocar el acceso de la aplicación directamente.

PlataformaDónde revocar
GoogleCuenta de Google → Seguridad → "Aplicaciones de terceros con acceso a la cuenta"
Microsoft 365myapps.microsoft.com → "Apps que puedes gestionar", o el admin revoca en Azure AD → Enterprise Applications
Meta/FacebookConfiguración → Apps y sitios web

Después de revocar, haz esta secuencia:

  1. Revoca la app en el panel de tu proveedor. Esto invalida el token.
  2. Cambia la contraseña y activa o revisa el 2FA, preferiblemente con app autenticadora o llave física, no SMS.
  3. Cierra todas las sesiones activas desde la configuración de seguridad.
  4. Revisa reglas de reenvío en tu correo. Los atacantes crean filtros que reenvían tu bandeja a una dirección externa. Bórralos.
  5. Comprueba exposición de tu email en Have I Been Pwned y escanea cualquier adjunto sospechoso en VirusTotal.
  6. Avisa a tus contactos si la app envió correos en tu nombre.

Si es una cuenta de empresa, escala al administrador de inmediato. Un solo token comprometido puede ser la puerta a toda la organización, sobre todo en entornos con dispositivos personales conectados al correo corporativo.

La defensa combina hábitos personales y controles técnicos. No hay bala de plata, pero sí capas.

  • Auditoría periódica. Cada pocos meses revisa qué apps tienen acceso a tu Google o Microsoft y elimina lo que no uses.
  • Consentimiento restringido en empresa. Los administradores de Microsoft 365 pueden desactivar el consentimiento de usuario y exigir aprobación del admin para cualquier app nueva. En Google Workspace existe el control de acceso de API por app.
  • Solo apps verificadas. Bloquea por política las aplicaciones sin editor verificado.
  • Formación. Enseña a tu equipo que la pantalla de permisos también es un vector de ataque OAuth, no solo las webs falsas.
  • Principio de mínimo privilegio. Encaja con el principio de minimización de datos del RGPD: ni una app ni un servicio deberían pedir más acceso del estrictamente necesario.

El marco regulatorio empuja en la misma dirección. El RGPD obliga a las empresas a proteger los datos personales, y una brecha vía OAuth que exponga correos de clientes es notificable a la autoridad de control en un plazo de 72 horas según el artículo 33. La Directiva NIS2 de la UE, en vigor y transponiéndose en los estados miembros, endurece las obligaciones de ciberseguridad para sectores esenciales. Si gestionas datos ajenos, la autorización fraudulenta deja de ser un problema técnico y pasa a ser un problema legal.

Si estás montando la infraestructura digital de tu negocio y quieres integrar logins sociales o APIs de terceros con criterio, conviene apoyarse en quien conozca el terreno. En Piqture trabajamos el desarrollo de páginas web profesionales y de soluciones de inteligencia artificial para empresas con la seguridad como cimiento, no como parche final.

Preguntas frecuentes

¿El phishing OAuth se salta la verificación en dos pasos?

Sí. El robo de token no necesita tu contraseña ni tu segundo factor, porque tú ya te autenticaste y luego autorizaste la app. El token concedido opera con permiso propio. Por eso activar el 2FA es necesario pero no suficiente frente al consent phishing.

¿Cambiar la contraseña elimina el acceso del atacante?

No siempre. Un token OAuth con refresh token sobrevive al cambio de clave. Debes revocar la aplicación específicamente en el panel de seguridad de Google o Microsoft. Solo entonces el acceso queda cortado.

¿Cómo sé qué aplicaciones tienen acceso a mi cuenta de Google?

Entra en tu Cuenta de Google, ve a Seguridad y abre "Aplicaciones de terceros con acceso a la cuenta". Verás cada app y sus permisos. Revoca cualquiera que no reconozcas o que ya no uses.

¿Es peligroso usar "Iniciar sesión con Google" en webs?

El mecanismo es seguro en sí mismo; el riesgo está en qué permisos concedes. Un login básico solo pide tu nombre y correo. Desconfía cuando una app solicita leer o enviar correo, acceder a Drive o gestionar contactos sin una razón evidente.

¿Las empresas pueden bloquear este tipo de ataques?

Sí. Los administradores de Microsoft 365 y Google Workspace pueden exigir aprobación del administrador para cualquier app OAuth nueva y bloquear editores no verificados. Es la defensa más eficaz contra la autorización fraudulenta a escala corporativa.

El siguiente paso

Abre ahora mismo el panel de seguridad de tu cuenta de Google o Microsoft, revisa la lista de aplicaciones con acceso y revoca todas las que no reconozcas o no uses. Cinco minutos hoy te ahorran una autorización fraudulenta mañana. Y si quieres seguir afilando el olfato, pásate por el resto de artículos del blog de MataSpam sobre phishing, estafas actuales y protección de datos.

phishing oauth robo token consent phishing autorización fraudulenta oauth ataque

Artículos relacionados

← Volver al blog