Skip to content

Esta herramienta no está afiliada a Google LLC, ni respaldada ni patrocinada por Google LLC. Google Workspace, Gmail y Google Drive son marcas comerciales de Google LLC. Los demás nombres son marcas comerciales de sus respectivos propietarios.

Aplicación OAuth sospechosa en Google Workspace: investigar

Investigar una aplicación OAuth sospechosa en Google Workspace: eventos authorize y activity, scopes de Gmail y Drive, revocar el token y bloquear la app.

Publicado el 6 min de lectura

En resumen. Una concesión de consentimiento ilícita es un phishing que pide permiso en lugar de una contraseña. El usuario pulsa «Permitir» y una aplicación controlada por el atacante obtiene un token para su buzón o su Drive que sobrevive al restablecimiento de la contraseña. En el registro de tokens OAuth, busque eventos authorize con scopes de Gmail, Drive o administración, nombres de aplicaciones desconocidos, autorizaciones desde una IP de riesgo y eventos activity que muestren a la aplicación leyendo correo en volumen. Revoque el token, bloquee el ID de cliente para toda la organización y después acote qué leyó la aplicación.

La vía OAuth resulta atractiva porque esquiva casi todo lo que vigilan los defensores. No se roba ninguna contraseña, la 2SV no se aplica a las llamadas a la API y el acceso perdura. MITRE recoge el robo de estos tokens como T1528 Steal Application Access Token, y la recopilación de correo a través de ellos como T1114.002 Remote Email Collection.

Qué guarda el registro de tokens OAuth

La página OAuth log events de Google y el apéndice de eventos de token describen los eventos:

EventoQué le dice
authorizeUn usuario dio acceso a una aplicación: nombre, ID de cliente, tipo de cliente, scopes
activityLa aplicación llamó a una API de Google en nombre del usuario: nombre de la API, método, bytes devueltos
request, denyAcceso solicitado o denegado (por ejemplo, por los controles de acceso de aplicaciones)
revokeAcceso revocado para el usuario

Google indica un retraso de un par de horas para este registro (tabla de retrasos). Si exporta una hora después del clic, puede que la autorización todavía no esté.

Evaluar un evento authorize

Cinco preguntas, en orden:

  1. ¿Qué scopes? La lista de scopes lo cuenta todo.

    ScopeAlcanceGravedad en el analizador
    https://mail.google.com/, gmail.readonly, gmail.modify, gmail.send, gmail.settings.*…Leer, enviar o reconfigurar el buzónAlta
    drive, drive.readonlyTodos los archivos a los que accede el usuarioMedia
    admin.directory.*, cloud-platformAcciones a nivel de organizaciónAlta
    openid, userinfo.email, drive.fileIdentidad de inicio de sesión, archivos creados por la propia aplicaciónNo se marca
  2. ¿Cuándo y desde dónde? Una autorización minutos después de un inicio de sesión de riesgo, desde la misma IP de hosting, es el atacante autorizando su propia aplicación con la sesión robada. Una autorización desde la red habitual del usuario tras un correo de phishing es un phishing de consentimiento.

  3. ¿Qué nombre tiene? Los nombres señuelo imitan utilidades: «PDF Viewer», «Document Signer», «Secure Mail». El nombre lo elige el desarrollador de la aplicación y no prueba nada.

  4. ¿Quién más la autorizó? Pivote sobre el ID de cliente. Una herramienta SaaS legítima tiene muchos usuarios a lo largo del tiempo. Una aplicación señuelo aparece en ráfaga, o en una sola cuenta.

  5. ¿Está verificada y aprobada? Revise Security → Access and data control → API controls → Manage third-party app access (etiquetas de la consola en inglés) para ver el estado y la verificación de la aplicación.

Leer los eventos activity

activity muestra el token en uso. Para Gmail verá api_name = gmail y métodos como gmail.users.messages.list, gmail.users.messages.get, gmail.users.settings.filters.create. Este último significa que la aplicación creó un filtro de Gmail, a menudo el filtro de ocultación de un BEC.

El analizador marca una aplicación que hace 20 o más llamadas a la API de Gmail en 60 minutos para el mismo usuario con el hallazgo Aplicación que lee Gmail en volumen mediante la API. Eso es recopilación, no un cliente de correo que sincroniza de vez en cuando. Las IP de estos eventos son la infraestructura de API del atacante. Añádalas a su pivote de IP.

Respuesta

  1. Revocar para el usuario: consola → el usuario → Security → Connected applications → eliminar la aplicación. También forma parte del procedimiento de Google para cuentas comprometidas.
  2. Bloquear para todos: marque la aplicación como Blocked en los controles de API, por ID de cliente. Si no, el siguiente usuario víctima de phishing volverá a autorizarla.
  3. Restringir las aplicaciones no configuradas: el control de acceso de aplicaciones de Google permite impedir que los usuarios den acceso a aplicaciones que usted no ha revisado, o limitarlas a scopes de solo inicio de sesión. Los usuarios pueden entonces solicitar una revisión.
  4. Acotar el daño: a partir de los eventos activity, liste métodos y periodos. En el registro de Gmail, compruebe qué se reenvió o envió en la misma ventana. num_response_bytes da una idea aproximada del volumen.
  5. Vigilar el lado de la administración: el analizador también marca a los administradores que relajan los controles de aplicaciones (ADD_TO_TRUSTED_OAUTH2_APPS, UNBLOCK_ALL_THIRD_PARTY_API_ACCESS y similares) con el hallazgo Controles de acceso de aplicaciones relajados.

Autorización por usuario frente a delegación de todo el dominio

Todo lo anterior se refiere al consentimiento por usuario: un usuario, un token, limitado a lo que ese usuario alcanza. La delegación de todo el dominio es distinta. Un superadministrador permite que un cliente de API suplante a cualquier usuario para los scopes indicados, sin consentimiento alguno. Queda en el registro de Admin, no en el de tokens. Tiene su propio artículo.

Falsos positivos habituales

  • Las herramientas de copia de seguridad, archivado, firma electrónica y CRM piden legítimamente acceso completo a Gmail o Drive. Documéntelas y bloquee el resto.
  • Los clientes de correo que usan OAuth también tienen https://mail.google.com/.
  • Las aplicaciones internas creadas por sus propios desarrolladores. Compruebe el propietario del proyecto de Google Cloud del ID de cliente.

El analizador todavía no tiene lista de permitidos, así que las aplicaciones conocidas se activarán. Trate esos hallazgos como una revisión de inventario.

Siguiente: riesgos de la delegación de todo el dominio. Vuelva a la guía de investigación o pase su registro de tokens por el analizador.

FAQ

¿Restablecer la contraseña revoca el acceso de una aplicación de terceros?

No cuente con ello. Una aplicación que el usuario autorizó sigue funcionando hasta que se revoca su token. Revóquela para el usuario (consola de administración → usuario → Security → Connected applications) y bloquee la aplicación para la organización en los controles de API.

¿Qué scopes OAuth son los más peligrosos en Google Workspace?

El acceso completo a Gmail (https://mail.google.com/), gmail.readonly / gmail.modify / gmail.send y los scopes de configuración de Gmail, Drive completo (drive, drive.readonly) y los scopes de directorio de administración o cloud-platform. Dan a una aplicación el mismo alcance que el usuario, o más.

Artículos relacionados

Superadministrador de Google Workspace comprometido: eventos del registro de Admin sobre nuevos admins, roles, SSO, delegación, enrutamiento y cumplimiento.
Riesgos de la delegación de todo el dominio: un cliente de API que suplanta a cada usuario, los eventos del registro de Admin, DeleFriend y qué hay que revisar.
Investigar un inicio de sesión sospechoso en Google Workspace: is_suspicious, ASN de hosting, países nuevos, viaje imposible, fallos en ráfaga y 2SV.

Esta herramienta no está afiliada a Google LLC, ni respaldada ni patrocinada por Google LLC. Google Workspace, Gmail y Google Drive son marcas comerciales de Google LLC. Los demás nombres son marcas comerciales de sus respectivos propietarios.