Esta es la parte incómoda: una cuenta de Google Workspace comprometida no es un problema de correo electrónico. Es una puerta de entrada.

La mayoría de las personas todavía piensa en Google Workspace (GWS) como piensa en una suite de productividad: Gmail, Docs, Drive, Calendar, las herramientas que mantienen un negocio funcionando día a día. Los actores de amenazas no lo ven así. Ellos ven infraestructura de identidad. Con un conjunto de credenciales robadas, no solo leen correos. Se mueven hacia aplicaciones de SaaS conectadas, aprueban concesiones de OAuth y redirigen silenciosamente flujos financieros. Gmail, en muchos entornos, es la raíz de confianza de facto para todo lo demás.

Y, sin embargo, cuando las empresas construyen su detección y respuesta ante amenazas de identidad (ITDR), Google Workspace suele ser una idea de último momento. La mayoría de la cobertura de ITDR en el mercado fue diseñada primero para Microsoft 365, y GWS se agrega después, o peor, los equipos simplemente suponen que las mismas detecciones se trasladan.

No es así.

El modelo de identidad de Google, la consola de administración y los registros de auditoría están construidos de manera diferente a Entra ID y Azure AD desde cero. Los eventos de inicio de sesión se ven distintos. Los roles de administrador funcionan distinto. El modelo de token de autenticación no es el mismo. Las detecciones ajustadas para las señales de identidad de Microsoft no se trasladan limpiamente a las de Google, lo que significa que una herramienta centrada primero en Microsoft 365 que "es compatible" con Google Workspace suele implicar solo ingesta de registros, no detección real.

Lo que está en juego es real: una proporción creciente de los incidentes críticos y de alta gravedad que investigamos ahora involucra identidad, no malware ni alertas tradicionales de endpoint. La identidad es donde aterrizan los ataques y donde se mueven.

Esta guía explica cómo se ve realmente ese panorama de amenazas dentro de Google Workspace, por qué las herramientas creadas para Microsoft 365 dejan brechas reales cuando se aplican a GWS, cómo Huntress Managed ITDR las cierra, y exactamente cómo incorporar un inquilino de GWS, además de las preguntas que más hacen los profesionales.

Las amenazas que se describen a continuación no son amenazas de endpoint, ni amenazas de contenido de correo como un adjunto malicioso. Son amenazas de identidad que viven dentro de sesiones autenticadas, consolas de administración y permisos de OAuth. Eso es lo que las hace difíciles de detectar.

Aquí está la parte que confunde a muchos equipos de seguridad: la mayoría de estas técnicas no involucran malware. Ningún adjunto sospechoso. Ningún payload. Ninguna alerta de endpoint que se encienda en un panel. Solo un atacante haciendo cosas que un usuario legítimo y con sesión iniciada podría hacer. La detección tiene que basarse en el comportamiento, porque no hay ningún archivo que analizar.

Robo de credenciales y toma de control de una cuenta

Las credenciales robadas de Google aparecen constantemente en kits de phishing y registros de infostealers, muchas veces reutilizadas de filtraciones que no tenían nada que ver con Google. Una vez que un atacante tiene una cookie de sesión o un token de autenticación válidos, puede secuestrar esa sesión directamente y pasar de largo la autenticación multifactor, sin necesidad de adivinar ninguna contraseña.

La primera pista visible suele ser un inicio de sesión desde un lugar que no corresponde: un país inesperado, una IP de centro de datos, un proxy que no coincide con el patrón habitual del usuario.

Abuso de tokens de autenticación y consentimiento de OAuth

Muchos atacantes evitan por completo la pelea por la contraseña y van directo por OAuth. Registran o comprometen una app que solicita permisos amplios de Gmail, Drive o Admin SDK, y luego engañan al usuario para que otorgue su consentimiento, sin que haga falta ninguna contraseña ni superar el MFA. Una vez otorgado ese permiso, el token de actualización del atacante puede sobrevivir a un cambio de contraseña, dándole una persistencia silenciosa y duradera.

Escalamiento de roles de administrador

Las cuentas de superadministrador y de administrador delegado son pocas en número, pero enormes en valor. Si un atacante compromete una, puede cambiar la configuración de seguridad, debilitar la configuración de SSO o desactivar la verificación en dos pasos para toda la organización. Puede crear cuentas de puerta trasera o reescribir las políticas de las unidades organizativas. Como las cuentas de administrador se usan poco, también son las que más probablemente pasen desapercibidas ante alertas genéricas.

Compromiso de cuentas de servicio e identidades no humanas, a diferencia de la identidad humana

Las cuentas de servicio no inician sesión a través de un navegador, y por eso son tan peligrosas cuando se ven comprometidas. Las claves se filtran en repositorios de código y canalizaciones de CI/CD más a menudo de lo que cualquiera quisiera admitir. La delegación en todo el dominio, cuando se usa mal, permite que un atacante se haga pasar por cualquier usuario del inquilino. Y la mayoría de las cuentas de servicio no tienen MFA, un punto ciego estructural integrado en su propio funcionamiento.

Movimiento lateral entre aplicaciones SaaS

Google Workspace suele funcionar como la identidad raíz no oficial de todo el stack de SaaS de una empresa. Un atacante con una sola identidad de Google comprometida puede moverse hacia otras aplicaciones conectadas mediante restablecimientos de contraseña o flujos de OAuth, sin necesidad de ningún exploit adicional.

En el camino, suelen configurar reglas de filtrado o reenvío en Gmail que eliminan silenciosamente las alertas de seguridad y ocultan su rastro. Encadenado todo: entran, leen la bandeja de entrada para mapear el negocio, plantan persistencia mediante reglas y tokens de autenticación, y luego se mueven lateralmente hacia todo lo demás que confía en esa identidad.

La mayoría de los ataques de identidad en GWS generan cero firmas de malware; la detección depende del comportamiento, no de los payloads.

Aquí está la pregunta que vale la pena hacerle a cualquier proveedor: ¿realmente estás detectando ataques de identidad dentro de Google Workspace, o solo estás observando cómo pasan los registros?

La mayoría de las herramientas de ITDR se construyeron primero contra Microsoft Graph y los registros de inicio de sesión de Entra ID. No es una crítica: Microsoft 365 tiene una base instalada más grande, y los proveedores construyen donde está el mercado. Pero eso significa que la lógica de detección, el análisis y todo el enfoque se ajustaron al esquema de eventos de Microsoft.

El Admin SDK, la API de Reports y el Alert Center de Google usan estructuras de eventos diferentes, límites de tasa diferentes y ventanas de retención diferentes. Apuntar un motor ajustado para Microsoft 365 a los registros de GWS no te da una detección con la calidad de Microsoft 365. Solo te da registros.

El modelo de tokens tampoco se traslada. El comportamiento del token OAuth 2.0 de Google y del token de actualización, junto con el funcionamiento de las cookies de sesión de Google, no es igual al modelo de tokens y sesiones de Microsoft. Una detección diseñada para detectar la repetición de tokens de Azure AD no va a detectar automáticamente el secuestro de sesión en GWS. Son mecánicas de ataque distintas con nombres similares.

Y los propios registros de auditoría muestran información diferente. Los eventos de auditoría de inicio de sesión y de administración de Google incluyen campos como el tipo de desafío de inicio de sesión y las concesiones de permisos de OAuth, que no tienen un equivalente limpio en Microsoft. Muchos proveedores centrados primero en Microsoft 365 ingieren los registros de GWS solo para tener visibilidad o alimentar un SIEM, sin ejecutar ninguna lógica de detección nativa sobre ellos.

Esa es la verdadera brecha: "compatible con Google Workspace" en una ficha técnica a menudo significa ingestión de registros o escaneo de postura, no la misma detección y respuesta basada en comportamiento y liderada por un Centro de operaciones de seguridad (SOC) que el proveedor ejecuta para Microsoft 365. Puede parecer cobertura, pero a menudo no lo es.

Una comparación simple se ve así:

Google Workspace necesita detecciones y manuales de respuesta diseñados para cómo funciona realmente el modelo de identidad de Google, no una integración de mero trámite tomada de Microsoft 365.

Hay una pregunta que resuelve la mayoría de las comparaciones entre proveedores: ¿el proveedor ejecuta detección nativa basada en comportamiento y respuesta liderada por un SOC para Google Workspace, o simplemente ingiere registros de GWS junto con un producto creado para otra cosa (endpoints, Microsoft 365, Active Directory)?

Huntress frente a CrowdStrike

La propuesta de CrowdStrike para Google Workspace se basa en las capacidades de postura SaaS de Falcon y en conectores de registros que envían eventos de GWS a Falcon. Eso resulta útil para la postura y la visibilidad, pero no equivale a una detección y respuesta de identidad nativa para GWS. Huntress aplica el mismo modelo de detección y respuesta basado en comportamiento y liderado por el SOC a Google Workspace que aplica a Microsoft 365, desde una sola plataforma, con un solo equipo vigilando ambos.

Huntress frente a SentinelOne

Singularity Identity se creó para entornos de Active Directory y Entra ID, y la relación de SentinelOne con Google se centra en integraciones de Google Cloud y de operaciones de seguridad de Chronicle, más que en una capacidad de ITDR dedicada a GWS. Huntress trata a Google Workspace como una superficie de identidad de primer nivel por derecho propio, no como otra fuente de registros secundaria que alimenta un producto pensado primero para Microsoft.

Huntress frente a Sophos

Sophos lanzó su producto de ITDR con verificaciones de postura de identidad cloud y monitoreo de credenciales en la dark web. Hoy, su cobertura de Google Workspace proviene en gran parte de la ingesta de telemetría de MDR y XDR, no de un módulo de ITDR nativo para GWS construido alrededor del modelo de identidad de Google. Huntress combina la detección nativa con remediación directa del SOC dentro del propio inquilino de GWS, como revocar sesiones riesgosas y eliminar reglas maliciosas de Gmail, en lugar de dejarte a ti los pasos de respuesta por configurar.

Huntress frente a Kaseya

SaaS Alerts de Kaseya vigila Google Workspace, junto con otras aplicaciones SaaS, en busca de inicios de sesión riesgosos y señales de cuentas comprometidas. Se posiciona como un complemento dentro de una pila de RMM más amplia para MSP, no como un servicio dedicado de respuesta a amenazas de identidad. Huntress suma investigación y respuesta humana del SOC sobre la detección, cerrando el ciclo que herramientas de monitoreo de registros como esta suelen dejar abierto.

Google Workspace es infraestructura de identidad, lo trate así una empresa o no. Merece detección y respuesta creadas para cómo funciona realmente el modelo de identidad de Google, no cobertura prestada de Microsoft 365, ni una integración de ingesta de registros disfrazada de protección.

Esa es la brecha que cierra Huntress Managed ITDR: una sola plataforma, un solo SOC, con detección y respuesta de amenazas a la identidad nativa que funciona tanto para Microsoft 365 como para Google Workspace.

Si todavía estás evaluando proveedores, mira cómo se compara realmente la cobertura. Y si ya estás listo para ver cómo se ve la protección nativa de GWS en la práctica, échale un vistazo más de cerca a Huntress Managed ITDR.

Tus identidades de Google Workspace ya son un blanco. Es hora de empezar a vigilarlas como tal.