Defending Against LeakyLooker: Critical Steps to Secure Google Cloud Data

Data visualization and business intelligence tools are essential for modern operations, but they often serve as bridgeheads between sensitive data stores and the public internet. Recently, Tenable Research unveiled "LeakyLooker," a collection of nine critical vulnerabilities in Google Looker Studio that underscore the risks inherent in cloud-connected workflows.

For security defenders, the discovery of LeakyLooker is a stark reminder that the security of SaaS platforms is not just about the platform itself, but how it connects to other critical infrastructure like BigQuery and Google Sheets. These vulnerabilities allowed for cross-tenant attacks—meaning a malicious actor could potentially access or manipulate data they do not own without ever compromising the victim's internal credentials directly.

With Google having remediated these issues, the focus for IT and security teams now shifts to validation, configuration hardening, and ensuring that these bridging tools do not become the weak link in your security posture.

Technical Analysis: The Mechanics of LeakyLooker

The "LeakyLooker" research identifies nine novel vulnerabilities (tracked by Tenable as TRA-2025-27 through TRA-2025-29) primarily revolving around improper access controls within Google Looker Studio. The severity of these flaws lies in their ability to facilitate cross-tenant unauthorized access.

Affected Products & Systems:

• Google Looker Studio: The primary entry point.
• Google BigQuery: Targeted for data exfiltration via SQL injection.
• Google Sheets: Impacted through data source leaks.
• Database Connectors: Compromised via stored credential abuse.

Vulnerability Breakdown: The flaws can be categorized into two main attack vectors:

1. Zero-Click and 1-Click SQL Injection: The most critical vulnerabilities allowed attackers to execute arbitrary SQL queries on victims’ databases. Specifically, TRA-2025-28 detailed a Zero-Click SQL Injection on Database Connectors, while TRA-2025-29 highlighted SQL Injection through Stored Credentials. In these scenarios, simply viewing a malicious report or interacting with a crafted data source could trigger the attack.

2. Cross-Tenant Data Leaks: Tenable demonstrated that the "Hyper" connector and native BigQuery functions could be abused to leak data from other tenants. This bypassed standard isolation boundaries, allowing data exfiltration from adjacent databases or cloud storage buckets.

Fix Status: Google has successfully patched all nine identified vulnerabilities. While no customer action is strictly required to apply the patch (as it is a server-side fix), the window of exposure prior to remediation necessitates a thorough audit of access logs and connected data sources.

Defensive Monitoring

Detecting exploitation of vulnerabilities like LeakyLooker requires visibility into the specific actions performed by identity providers and SaaS connectors. If you are ingesting Google Cloud logs into Microsoft Sentinel, you can use the following KQL query to hunt for suspicious Looker Studio activity, specifically focusing on unusual BigQuery query patterns or access attempts.

The query below filters for Looker Studio service usage and identifies instances where BigQuery queries are executed, helping you verify that only authorized reports are running data extraction queries.

GoogleCloudActivity
| where ServiceName == "lookerstudio.googleapis.com"
| extend MethodName = tostring(MethodName)
// Look for methods that imply data access or query execution
| where MethodName contains "Query" or MethodName contains "GetData" or MethodName contains "Run"
| extend AuthorizationInfo = todynamic(AuthorizationInfo)
| extend GrantedPermissions = tostring(AuthorizationInfo[0].granted_permissions)
| project TimeGenerated, 
          AuthenticationInfoPrincipalEmail, 
          ResourceName, 
          MethodName, 
          ProtoPayload, 
          GrantedPermissions
// Join with BigQuery activity to see the impact of the Looker request
| join kind=inner (GoogleCloudActivity 
    | where ServiceName == "bigquery.googleapis.com" 
    | project TimeGenerated, bq_Resource=ResourceName, bq_Method=MethodName, bq_User=AuthenticationInfoPrincipalEmail) 
    on TimeGenerated
| where TimeGenerated > ago(7d)
| summarize count() by bin(TimeGenerated, 1h), AuthenticationInfoPrincipalEmail, bq_Resource
| order by count_ desc

Remediation & Mitigation

While the patches are live, defenders must take proactive steps to secure their Google Cloud environment against similar classes of vulnerabilities and verify their current security stance.

1. Verify Connector and Plugin Integrity Review all third-party connectors and community plugins currently active in your Google Looker Studio environment. Disable any that are no longer in use or are not from verified publishers. Attackers often target unmaintained connectors to pivot into data stores.

2. Audit Stored Credentials (TRA-2025-29) The LeakyLooker research highlighted the abuse of stored credentials. Audit your Looker Studio data sources to ensure that stored OAuth tokens or service account keys adhere to the principle of least privilege.

• Action: Navigate to the Looker Studio Data Source settings and revoke access for any stale service accounts or users who no longer require data visualization access.

3. Enforce BigQuery Access Controls Ensure that the service accounts used by Looker Studio to connect to BigQuery have restricted permissions.

• Action: Do not use project-level editor roles. Assign specific bigquery.jobUser or bigquery.dataViewer roles scoped only to the specific datasets required for the visualization.

4. Enable VPC Service Controls To prevent cross-tenant data exfiltration and unauthorized access, consider implementing Google Cloud VPC Service Controls for your BigQuery and Storage resources. This creates a security perimeter that prevents data from being accessed from outside the trusted network, effectively mitigating the impact of platform-level vulnerabilities.

5. Review Audit Logs for Anomalies Historical analysis is crucial. Review your Google Cloud Audit Logs for the past 90 days looking for:

• Looker Studio identities accessing BigQuery tables they shouldn't.
• Unusual volumes of data export (e.g., massive hyper-connector downloads).

Related Resources

Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub