Google Salesforce Data Breach | SalesforceTutorial

The google salesforce data breach refers to a 2025 incident where one of Google’s corporate Salesforce instances was affected by activity that Google Threat Intelligence Group tracks as UNC6040. The core lesson for Salesforce teams is clear: the reported entry path was not a Salesforce platform vulnerability; it was social engineering, OAuth abuse, and weak connected app governance.

For admins, developers, and security architects, the response is not to panic or disable every integration. The response is to review connected apps, reduce API-enabled access, validate Data Loader usage, inspect Event Monitoring logs, and run a scoped salesforce pentest that tests people, permissions, OAuth flows, and data export paths.

Google Salesforce Data Breach: What actually happened?

Google’s public threat research describes UNC6040 as a financially motivated cluster that used vishing calls to impersonate IT support and persuade users to authorize malicious connected apps in Salesforce. Google later added an August 5 update stating that one of its corporate Salesforce instances was impacted by similar UNC6040 activity in June 2025. The affected instance stored contact information and related notes for small and medium businesses, and Google said the retrieved data was confined to basic and largely publicly available business information.

This distinction matters. The google salesforce data breach was a Salesforce-related customer environment incident, not evidence that Salesforce’s core platform was exploited. Salesforce’s own security guidance also describes attacks where threat actors guide users to a connected app approval page, sometimes using a modified Data Loader app name or branding, and then use the connected app to exfiltrate data.

Use the official references while briefing executives and incident teams: Google Threat Intelligence Group’s UNC6040 analysis, Salesforce guidance on social engineering threats, and the Salesforce security best practices hub.

How did the google salesforce data breach attack chain work?

The attack pattern works because a connected app can receive OAuth tokens after a user authorizes access. If the user has enough object permissions, field permissions, and API access, the token can be used to query or export Salesforce data within that user’s effective access. MFA helps protect logins, but it does not replace connected app governance when a user is persuaded to approve a malicious app.

Mandiant UNC6040 Salesforce findings to model

The phrase mandiant unc6040 salesforce is often used by searchers looking for the Google Threat Intelligence and Mandiant analysis of this campaign. The useful takeaway for a Salesforce team is not the group name alone; it is the technique: voice phishing, malicious or custom connected apps, Data Loader-style data extraction, VPN or TOR infrastructure, and delayed extortion after the first intrusion.

In enterprise orgs, model this as an identity and SaaS control failure. A secure Salesforce org can still lose data if a real user authorizes an attacker-controlled app and that user has broad API access. That is why your response to mandiant unc6040 salesforce activity should include identity logs, Salesforce event logs, connected app usage, permission review, and endpoint evidence from the workstation used during the call.

Mandiant unc6040 salesforce investigation checklist

Use the mandiant unc6040 salesforce pattern as a practical checklist during triage. Confirm whether the google salesforce data breach scenario applies to your org by checking for a vishing event, a new or unfamiliar connected app, a Data Loader-like client, and abnormal API extraction. If any item is present, treat the case as a potential google salesforce data breach until logs prove otherwise.

The mandiant unc6040 salesforce label should not distract the team from evidence. Ask which user approved the app, which OAuth scopes were granted, which objects were queried, and which IP addresses touched the org. A good mandiant unc6040 salesforce investigation ends with a list of revoked tokens, restricted users, reviewed objects, and monitoring rules that would catch the same pattern again.

How should admins respond to a suspected google salesforce data breach?

A google salesforce data breach response should be handled like a SaaS identity incident. The attacker may not need a password after OAuth authorization, so the investigation must cover user identity, app authorization, tokens, API activity, and data access.

Start with containment, not cleanup. If you suspect connected app abuse, preserve evidence before removing every trace. Revoking tokens and blocking apps can stop active access, but your security team still needs log exports, timestamps, users, IP addresses, app names, and object access patterns to scope the incident.

1. Freeze the timeline. Record when the user received the call, when the app was authorized, when exports started, and when access was revoked.
2. Identify the app. In Setup, review Connected Apps OAuth Usage and Manage Connected Apps. Note the app name, user count, first use, last use, and whether the app was installed or user-authorized.
3. Revoke active access. Revoke tokens for unknown or suspicious apps. Then block or uninstall apps that have no approved owner.
4. Review user access. Check API Enabled, View All Data, Modify All Data, Export Reports, object CRUD, field-level security, permission set groups, and delegated admin assignments.
5. Export logs. Pull EventLogFile records for login, API, Bulk API, report export, URI, and other relevant events. Send raw logs to the security team or SIEM before retention windows expire.
6. Notify the right teams. Bring in legal, privacy, security operations, Salesforce platform owners, and the business data owner. Do not make customer notification decisions from Salesforce logs alone.

For the administrator path, use Salesforce’s connected app documentation: Connected Apps overview, Manage access to a connected app, and Manage OAuth access policies.

What Salesforce connected app controls reduce breach risk?

Connected app control is the center of google salesforce data breach prevention because OAuth approval can turn a trusted user into an export channel. Review policies before an incident, not only after suspicious activity appears.

A connected app review should answer three questions: who owns the app, who can use it, and what token permissions it receives. If the answer is “any user can approve it,” the org has a weak control point. This is where many google salesforce data breach discussions become practical for admins.

Salesforce also published guidance for connected app usage restrictions after the 2025 social engineering wave. Review Prepare for Connected App Usage Restrictions Change before assigning permissions that let users approve or use uninstalled connected apps.

Salesforce pentest scope for OAuth and connected apps

A salesforce pentest after this type of incident should not focus only on Apex or Experience Cloud. Include OAuth authorization, connected app approvals, API clients, identity provider reset flows, support desk scripts, and data export permissions. Salesforce states that customers no longer need prior approval for many Salesforce product security assessments, but you still need legal approval, rules of engagement, non-disruptive methods, and a test plan that avoids data corruption.

For a practical salesforce pentest, build a test matrix that includes:

• Can a standard sales user authorize an unapproved OAuth app?
• Can a user with API Enabled export Accounts, Contacts, Leads, Cases, or custom objects outside normal business need?
• Can a help desk process be used to reset MFA or guide a user into app approval without a second verification channel?
• Do Event Monitoring alerts fire when one user exports unusual record volume or when a new connected app starts high-volume API activity?
• Can a security analyst map an OAuth token to a user, IP address, app, and exported object within the required response time?

Link the test results to remediation work. A salesforce pentest report that only lists findings is less useful than one that maps each finding to a permission set, connected app policy, identity control, and monitoring rule.

Repeat the salesforce pentest after high-risk permission changes, major integration deployments, or identity provider changes. In larger orgs, schedule a smaller salesforce pentest for connected apps every quarter and a deeper salesforce pentest before large data migration projects.

How do you query Salesforce logs after connected app abuse?

Log review is the evidence layer for a google salesforce data breach investigation. Without Event Monitoring or exported identity logs, teams often know that something happened but cannot prove which records, objects, or apps were involved.

Salesforce Event Monitoring exposes operational event data through the EventLogFile object. Trailhead also shows admins how to use the Event Log File Browser and Developer Console to query event log files. Some orgs see a delay before event files are available, and retention depends on licensing and configuration, so export logs early during a suspected google salesforce data breach investigation.

Use this SOQL to list recent event files. Run it in Developer Console Query Editor, Workbench, Salesforce CLI, or another approved tool with the right permission.

SELECT Id, EventType, LogDate, Interval, LogFileLength
FROM EventLogFile
WHERE LogDate = LAST_N_DAYS:14
ORDER BY LogDate DESC

After you identify the EventLogFile record, download the CSV log file through the REST API. Replace the API version and record Id with values from your org. The example uses a versioned REST path; use an API version supported in your org.

curl "https://yourInstance.my.salesforce.com/services/data/v61.0/sobjects/EventLogFile/0ATXXXXXXXXXXXX/LogFile" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -o salesforce-event-log.csv

When reviewing the CSV, look for high-volume API calls, unusual source IPs, unfamiliar application names, exports from users who do not normally export data, and repeated access to objects that hold personal or customer data. Cross-check Salesforce logs with identity provider logs, endpoint telemetry, email security data, and help desk tickets from the same time window.

You can also search setup changes. The following SOQL can help locate recent setup audit entries that mention connected apps or OAuth. Validate the result manually because Setup Audit Trail text can vary by action and release.

SELECT CreatedDate, CreatedBy.Name, Section, Action, Display
FROM SetupAuditTrail
WHERE CreatedDate = LAST_N_DAYS:30
AND (Display LIKE '%Connected App%' OR Display LIKE '%OAuth%')
ORDER BY CreatedDate DESC

What should developers change after the google salesforce data breach?

Developers should treat the google salesforce data breach as an integration design warning. Any custom service, Apex endpoint, or external client that can read many records needs clear authorization checks and monitoring.

Developers should review integration design, not only custom code. Any integration that uses OAuth should have a named owner, documented scopes, token rotation expectations, least-privilege user assignments, and a break-glass revocation process. Do not use a human admin account as a long-running integration user.

For custom Apex and LWC, this incident is a reminder to keep server-side authorization strong. Use with sharing where record-level sharing must apply, check CRUD and field-level security before returning data, and avoid exposing bulk export endpoints that bypass normal review. The breach pattern is OAuth-centered, but excessive custom APIs can create the same result: a valid session pulls too much data too fast.

public with sharing class AccountContactExportGuard {
    @AuraEnabled(cacheable=true)
    public static List<Account> getAccountsForReview() {
        if (!Schema.sObjectType.Account.isAccessible()) {
            throw new AuraHandledException('You do not have access to Account records.');
        }

        // Keep the query selective and avoid exporting unnecessary fields.
        return [
            SELECT Id, Name, Industry, OwnerId
            FROM Account
            WHERE LastModifiedDate = LAST_N_DAYS:30
            ORDER BY LastModifiedDate DESC
            LIMIT 200
        ];
    }
}

This Apex example is intentionally small. It checks object access, returns only the fields the UI needs, and limits rows. In production code, also enforce field-level security for fields returned to the user, add tests, and avoid building “export everything” methods for convenience. Salesforce requires at least 75% Apex test coverage for deployment, but security tests should go beyond the coverage number and validate unauthorized paths.

How do you explain risk to business owners?

For business owners, the google salesforce data breach is easier to understand as a consent problem: someone was tricked into granting access, and the access matched that user’s permissions.

Explain the google salesforce data breach in business terms: a trusted user can be tricked into granting a token, and that token can read the same Salesforce data the user can read. If the user has broad object access, the incident scope grows. If logs are missing, the team cannot prove what was accessed. If connected apps have no owner, nobody knows which app should be revoked.

Use this decision table during remediation planning.

Best practices for preventing the next google salesforce data breach

• Require app ownership. Every connected app should have a business owner, technical owner, approved scopes, and a review date.
• Reduce API Enabled access. Assign it through permission sets only where the user or integration needs API access.
• Use admin-approved access. Configure connected app policies so only approved users can use sensitive apps.
• Train on app authorization, not just passwords. Users must know that entering a device code or approving an app can grant data access.
• Monitor exports. Alert on unusual API volume, report exports, new connected app activity, and access from unexpected networks.
• Run a focused salesforce pentest. Test OAuth approval paths, help desk validation, high-risk permissions, and log visibility.
• Keep Data Loader current. Salesforce’s Data Loader page states that the latest version should be maintained and older versions are not supported.

Frequently Asked Questions

Related SalesforceTutorial resources

• Salesforce Data Loader setup and safe usage
• Connected App vs External Client App in Salesforce
• Salesforce security model for admins and architects
• Salesforce API guide for integrations
• SOQL query examples for investigations