SBN

How SquareX Could Have Prevented the Coinbase Customer Support Attack

By John Carse, Field CISO, SquareX

Coinbase recently disclosed a security breach involving overseas customer support agents who were bribed to provide personally identifiable information (PII) to attackers. This data was then used in a coordinated phishing and social engineering campaign targeting Coinbase users. The incident highlights the critical need for robust browser security in customer support environments, where agents rely heavily on cloud-based SaaS applications.

Understanding the SaaS-Based Customer Support Architecture

Quick research of Coinbase’s open roles shows a high-reliance on SaaS systems from SFDC, Workday, Netsuite, Gsuite, Slack, Atlassian, Amazon. The architecture for modern customer support teams often includes a mix of SaaS platforms like:

  • Salesforce Service Cloud for customer relationship management (CRM)
  • JIRA for issue tracking and internal workflows
  • Google Workspace for email, collaboration, and document sharing
  • Amazon Connect for voice and chat support
  • IDP/SSO Systems (i.e., Okta, Entra) for centralized authentication and user management

Sample Architecture Diagram:

Diagram showing an example IT architecture of enterprise tools used for customer support operations, including: issue tracking, CRM, collaboration tools, etc., all of which are accessed by employees via the browser.

This setup allows customer support agents to seamlessly access customer data across multiple systems, but it also introduces significant security risks if not properly monitored. Often, companies do not have the necessary visibility into the use of browser-based SaaS products as they would have on their endpoints. They are limited to authentication events through their IDP, or events in their applications (which are likely not logging through to Insider Risk or the SOC). As Coinbase stated in their 8K, they were able to detect “instances of such personnel accessing data without business need” using their monitoring solutions “in the previous months.” Given the statement, it would seem that they did not have enough information to see the data that was being accessed and how the data was being exfiltrated (~1% of 9.7M monthly transacting users) to take a definitive action.

Attack Vector Analysis

The architecture presents several key risk points:

  1. Browser-Based Access to Sensitive Systems:
  • Agents use web browsers to access a wide range of sensitive customer data, creating a single point of potential compromise.
  • Without robust browser-level monitoring, data exfiltration can go undetected, especially if agents are coerced or tricked into sharing information.

2. Unmonitored Channels and Data Exfiltration:

  • Many SaaS applications allow file sharing, data export, and clipboard access, which can be exploited to silently extract sensitive data.
  • For example, an agent accessing Salesforce or JIRA through a browser can copy customer records, screenshots, or transcripts without triggering endpoint-level alerts.
  • This data can then be exfiltrated through encrypted email, file-sharing platforms, or even direct browser-based messaging without proper inspection.

3. Blind Spots in Standard DLP, EDR, and SWG:

  • Traditional systems often miss browser-based data leaks because they focus on endpoint or network traffic, not browser-specific activity.
  • Data copied to the clipboard, saved as browser downloads, or shared via online forms can evade these controls.
  • Agents using Google Workspace or Amazon Connect can export data directly to personal drives, bypassing corporate oversight.

How SquareX Could Have Prevented the Attack

SquareX’s Browser Detection & Response (BDR) and DLP technologies are specifically designed to secure this type of high-risk SaaS environment:

  1. Real-Time Browser Monitoring and Isolation:
  • SquareX BDR continuously monitors browser sessions for abnormal data flows, detecting when agents attempt to access or export sensitive data.
  • It can isolate browser sessions (personal versus enterprise) and prevent unauthorized data transfers, significantly reducing the risk of exfiltration.

2. DLP at the Browser Level:

  • Unlike traditional DLP, SquareX’s approach directly controls browser interactions, preventing sensitive data from being copied, pasted, or exported without proper authorization.
  • This includes blocking data transfer through personal and unsanctioned SaaS applications which are common vectors for insider threats (personal Google Drive, or hacker-provided websites).

3. Blocking Unmonitored Channels:

  • SquareX can detect and block risky browser behaviors, such as accessing personal email, cloud storage, or unauthorized messaging platforms that are often used for covert data exfiltration. You can whitelist SaaS apps and identities needed for your call centers.
  • This level of control is critical in preventing sensitive data from leaking through unmonitored channels, while still allowing your call center agents to interact through web mail, web chat, and other sanctioned channels.

4. Enforce browser protection at your IDP:

  • Your IDP can be configured to require SquareX BDR to be working in the browser before allowing the authentication to be successful — whether they are employees or contractors
  • This allows you to know that your crown jewels and customer-facing infrastructure is being monitored and protected

5. Integration with SIEM for Continuous Oversight:

  • SquareX integrates with SIEM systems to provide real-time alerting and continuous monitoring, ensuring that suspicious data access attempts are flagged immediately.
  • This capability helps catch early signs of compromise, even if an agent’s credentials have not been directly stolen.

At a minimum, if your organization operates with heavy SaaS usage, we recommend these next steps to protect the enterprise from DLP:

  • Enforce strict browser protection for sensitive workflows
  • Implement granular DLP policies for customer support applications
  • Enhance monitoring to catch data exfiltration in real-time
  • Integrate browser security with centralized SIEM for continuous oversight

Find the Gaps in Your SaaS

The Coinbase incident highlights the need for robust, browser-focused security in SaaS-heavy support environments. By deploying SquareX BDR and advanced DLP, companies can significantly reduce the risk of data leaks, unauthorized data transfers, and insider threats, providing a critical layer of defense against modern attacks. Having the right security in the browser in place would have changed the outcome from learning about an attack when you’re being extorted, to not having an issue at all.

Learn more

Have more questions? Join us on Thursday, May 22 for an Ask the Expert: Browser Security Edition interactive webinar with the SquareX technical team.


How SquareX Could Have Prevented the Coinbase Customer Support Attack was originally published in SquareX Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from SquareX Labs - Medium authored by Mary Yang. Read the original post at: https://labs.sqrx.com/how-squarex-could-have-prevented-the-coinbase-customer-support-attack-bddc618f75a1?source=rss----f5a55541436d---4