Exploiting Google Workspace: The Silent Breach via OAuth and API Misconfigurations

TLDR: This research exposes how attackers can bypass standard security controls in Google Workspace by leveraging OAuth misconfigurations and gaps in audit logging. By abusing domain-wide delegation and malicious Chrome extensions, adversaries can maintain persistent access and manipulate email rules without triggering traditional alerts. Pentesters should prioritize auditing third-party app permissions and monitoring for anomalous API calls to detect these stealthy, high-impact techniques.

Security researchers often focus on the perimeter, but the most dangerous vulnerabilities in modern cloud environments exist in the trust relationships between services. Google Workspace is a prime example. It is a massive, interconnected ecosystem where a single compromised service account or a poorly scoped OAuth token can grant an attacker the keys to the kingdom. The recent research presented at Security BSides 2025 highlights how these trust relationships are being weaponized to conduct silent, persistent breaches that bypass standard detection mechanisms.

The Chrome Extension Backdoor

Browser extensions are a massive, often overlooked attack surface. In the CyberHaven incident from late 2024, attackers demonstrated how a supply chain compromise can turn a trusted tool into a malicious implant. The technique is straightforward but devastating: an attacker gains access to a developer's credentials through phishing, then pushes a malicious update to a legitimate Chrome extension.

Because the extension is already installed and trusted by users, it inherits the permissions granted during its initial installation. In the case of the CyberHaven attack, the malicious update was designed to exfiltrate cookies and session tokens from targeted websites. The critical failure here is the lack of visibility. Google Workspace administrators have no native way to monitor the specific version history of extensions or detect when an extension’s behavior deviates from its baseline. For a pentester, this means that if you can compromise a developer account with access to the Chrome Web Store, you can effectively deploy a persistent, silent backdoor to thousands of endpoints without ever touching the underlying operating system.

Weaponizing Domain-Wide Delegation

Domain-wide delegation is a powerful feature that allows a service account to impersonate any user in a Google Workspace domain. While intended for administrative automation, it is a goldmine for attackers. The vulnerability here is not a bug in the code, but a failure in the OWASP A01:2021-Broken Access Control model.

When a service account is configured with domain-wide delegation, it can be granted specific OAuth scopes, such as https://www.googleapis.com/auth/gmail.readonly. If an attacker compromises the service account key, they can generate a JWT, sign it, and exchange it for an access token that grants them full access to the target user's data. The most alarming part of this technique is the lack of logging. Google’s audit logs will show that an "authorized" event occurred, but they do not distinguish between legitimate administrative activity and malicious impersonation.

To reproduce this, an attacker needs the service account key and the unique ID of the service account. Once obtained, the following Python snippet demonstrates how to impersonate a user and access their Gmail:

from google.oauth2 import service_account
from googleapiclient.discovery import build

SCOPES = ['https://www.googleapis.com/auth/gmail.readonly']
creds = service_account.Credentials.from_service_account_file(
    'service_account.json', scopes=SCOPES, subject='target_user@example.com'
)
service = build('gmail', 'v1', credentials=creds)
messages = service.users().messages().list(userId='me').execute()

This code bypasses MFA because the service account is acting as the user, and the authentication flow is handled entirely through the API.

Business Email Compromise via API

Business Email Compromise (BEC) has evolved. Attackers no longer just send fake invoices; they now automate the manipulation of the victim's mailbox. By using the Gmail API, an attacker can create inbox rules that automatically delete incoming emails containing specific keywords like "security alert" or "password reset." This effectively blinds the victim to any automated warnings from their security team.

The beauty of this attack is its stealth. The user never sees the rule being created, and because the rule is managed via the API, it often does not appear in the standard user-facing settings page. During a red team engagement, this is the ultimate persistence mechanism. You can maintain access to a mailbox for months, exfiltrating sensitive data and rerouting financial transactions, all while the victim remains completely unaware.

Defensive Strategies

Defending against these attacks requires moving beyond simple log monitoring. You must implement strict access control for all GCP service accounts. If a service account does not need domain-wide delegation, disable it. If it does, apply the principle of least privilege to the OAuth scopes granted.

Furthermore, you need to build custom monitoring. Since Google’s native logs are insufficient, you should use the Google Workspace Admin SDK to periodically pull and audit user settings, including inbox filters and third-party app authorizations. If you see a filter being created that deletes emails, that is a high-fidelity signal of a compromise.

The complexity and volume of cloud audit data make manual investigation impossible. You must invest in automated intelligence that can correlate events across different APIs. If you are a researcher or a pentester, start by mapping out the trust relationships in your target environment. Look for service accounts with broad scopes and investigate the third-party applications that have been granted access to the domain. The "silent breach" is only silent if you aren't looking in the right places.