Loading stock data...
Media eb19f299 ee3b 46ad a2c1 b8ec74847e9a 133807079768251950

Google uncovers a new phone-based social-engineering scam, and Google itself fell victim, exploiting Salesforce-linked apps to gain access.

In June, a calculated social-engineering operation targeted Salesforce customers by exploiting trust and access controls, culminat­ing in a broad campaign of account compromise. Two months later, Google disclosed that it too had fallen victim to the same or closely related tactics, underscoring the persistent risk of attacker impersonation and third‑party application integrations in enterprise environments. The attackers pursue financial gain by enabling access to sensitive business data, then attempting to monetize that data through extortion or sale on illicit channels. The scale of the campaign suggests a systematic, scriptable approach, not the result of isolated incidents, and the ripple effects reach across major brands and industries that rely on Salesforce to connect internal systems with external tools. This article provides a detailed, carefully parsed reconstruction of how the campaign operated, who was affected, the evolving threat landscape, and the concrete steps organizations can take to reduce exposure and bolster resilience in the face of social-engineering driven breaches.

Campaign Overview, Victims, and the Core Attack Vector

The central premise of the campaign was deceptively simple yet devastating in practice: a threat actor would impersonate a trusted member of a customer’s information technology ecosystem and present an urgent problem that demanded immediate access to the target’s Salesforce account. In this scenario, the attacker leverages the social trust embedded in routine IT communications to bypass typical security skepticism. Rather than focusing on exploiting software vulnerabilities or weaknesses in the Salesforce platform per se, the adversaries exploited human factors and the design of trusted workflows that underscore how modern enterprise environments connect various internal services to Salesforce through external applications.

The attackers targeted accounts used by Salesforce customers that had the capability to link external apps and data sources to their Salesforce instance. This linkage is a feature designed to enable seamless data exchange and integration with in-house systems—ranging from content management and analytics to mapping tools and other line-of-business resources. The attackers’ technique was to instruct employees to connect an external application to their Salesforce instance, exploiting the presumption that such integrations are part of standard operational procedures. Once the employee complied, the adversaries would request an eight-digit security code that the Salesforce interface requires as a second factor before establishing a connection between the external app and the Salesforce environment. With this code in hand, the attackers could complete the integration and gain access to the Salesforce instance and the data stored within it.

The scope of the incident is underscored by the breadth of organizations reported to be affected. Among the names cited in public recountings of the campaign are Adidas, Qantas, Allianz Life, Cisco, and the luxury brands under LVMH including Louis Vuitton, Dior, and Tiffany & Co. While the attackers’ intent was financial—securing access to data for monetization—the immediate consequence was the exposure of internal business information that, while sometimes publicly available in business directories and public records, represents a valuable foothold for attackers seeking to broaden access into the broader corporate network. The exposure was described as limited in scope, specifically to business names and contact details, which Google described as largely public information prior to the breach. This nuance matters because it indicates that the attackers were primarily interested in data that could be leveraged for follow-on social engineering campaigns, targeted phishing, or extortion, rather than attempting a sweeping exfiltration of highly sensitive records.

From a time perspective, Google indicated that the breach occurred in June, but the company did not publicly disclose the incident until two months later. This timing — a discovery lag between the initial compromise and public disclosure — is not unusual in complex, multi-site intrusions where early signals are subtle, dispersed across different asset owners, or require forensic confirmation before a formal statement can be issued. The company stated that analysis showed data was retrieved during a small window of time before access was severed. The data retrieved was characterized as business-related information that was largely already public in nature, suggesting the attackers’ objective may have leaned toward reconnaissance and commercial leverage rather than rapid exfiltration of highly sensitive competitive data.

In sum, the campaign represented a structured use of social engineering to induce legitimate users to connect an external app to Salesforce, followed by the misuse of a generated eight-digit code to complete unauthorized access. The fact that such access was obtained within a limited window reinforces the importance of rapid detection and robust access controls, as even brief periods of compromised credentials can yield material exposure in modern cloud-enabled environments. The overall victimology and the types of data accessed illuminate both the sophistication and the limitations of the attackers’ approach: they exploited a known workflow (external app integration) that is legitimate and widely used, but did so through a tactic that relies on deception and social manipulation rather than vulnerability exploitation.

How the Salesforce Abuse Mechanism Operated: Step-by-Step

The core abuse mechanism can be understood as a sequence of carefully choreographed steps that exploit trust relationships between internal personnel and the Salesforce platform. The attackers begin by identifying a target within a Salesforce customer organization that has the authority to approve or facilitate external app connections. This initial reconnaissance is foundational: it determines who within the organization has the authority to approve the addition of non-native tools or services into the Salesforce environment, and who might be susceptible to social-engineering prompts that present a pressing operational necessity.

The second step is impersonation. The attacker contacts the target employee—often by imitating someone in the customer’s IT department or a trusted vendor representative—and communicates a scenario that demands immediate action. The narrative typically centers on an urgent problem that would justify bypassing standard security checks or expedited access. In practice, this could involve claims of a data synchronization issue, a compliance directive requiring rapid integration of a reporting tool, or a supposed incident that insists on direct access to the Salesforce instance to prevent a business disruption. The goal of this pretext is to lower the recipient’s guard and create a sense of urgency that overrides normal verification procedures.

Once the employee is convinced of the authenticity of the request, the attacker guides them to initiate an external app connection within Salesforce. The employee is led to navigate to the configuration interface where third-party integrations are managed—and then to authorize the linkage of an external application to the Salesforce environment. This step is critical because it enables the external app to exchange data with Salesforce, often with broad or poorly bounded permissions that can enable downstream access to broader corporate data stores.

The operational twist comes at the moment when the attacker asks the employee for an eight-digit security code, a credential that Salesforce requires to complete the new connection. The employee, believing they are following legitimate procedures under instruction from a trusted IT contact, provides the code. With this code, the attacker completes the authentication handshake, effectively piggybacking on the legitimate session and securing ongoing access to the Salesforce instance and the data it contains. The attackers can then explore the data environment, extract basic business information, and maintain a foothold long enough to facilitate any subsequent monetization or extortion attempts.

The breach’s visible footprint was described as limited in the sense that the data retrieved consisted primarily of business identifiers and contact information, which were already publicly accessible to some extent. However, the mere existence of external app integrations—especially those that can access sensitive business data—creates a potential Achilles’ heel. The incident demonstrates how even routine, legitimate features designed to foster efficiency can be weaponized when misused through social engineering. It also underscores the importance of controlling which external apps are connected to critical platforms and ensuring that every integration undergoes rigorous identity verification, least-privilege access policies, and continuous monitoring.

From a defensive standpoint, the lesson is clear: organizations must not only enforce strong authentication but also implement strict controls around who can approve external connections, enforce appraisal processes for third-party apps, and require multifactor authentication (MFA) for any operation that could enable data access beyond the minimum necessary. In practice, this means tightening change control workflows, enabling MFA for administrators and key personnel, enforcing granular permissions for connected apps, and instituting ongoing audits to track which external integrations exist, who authorized them, and what data flows they enable. The risk is not merely theoretical; it manifests when trust is abused, and the only remedy is a combination of robust policy, rigorous enforcement, and continuous vigilance.

Google’s Breach: Discovery, Timing, and Implications

Georgia-Pacific-like timing notwithstanding, Google’s disclosure of its Salesforce-related breach two months after the fact highlights the challenges of rapid breach detection in highly interconnected enterprise ecosystems. The company stated that the breach occurred in June and that data access occurred during a narrow timeframe before the access was blocked. The precise data exposed was described as business information—names and contact details—that were largely public even before the incident. This characterization matters because it frames the breach not as a catastrophic loss of sensitive or proprietary information but as a breach of trust and a potential enabler of follow-on attacks, including targeted phishing or social-engineering campaigns that leverage seemingly innocuous data.

The designation of the attacker groups is another critical dimension. Initially, Google attributed the attacks to a group identified as UNC6040. A separate group, UNC6042, is associated with extortion activities that sometimes appear months after the UNC6040 intrusions. This latter group operates under the moniker ShinyHunters and is known for using data-leak-related strategies to pressure victims. Google’s assessment suggests that there is a linkage or at least a pattern of collaboration among these actor clusters, with the potential for cross-pollination of tactics, techniques, and procedures (TTPs) in different campaigns aimed at Salesforce customers. The analysis also warns of a broader threat landscape in which extortion-oriented actors may escalate their tactics by creating a data-leak site (DLS) to host and publicize stolen information, a tactic that digital extortionists have increasingly adopted in recent years.

The implications for the broader enterprise ecosystem are multifaceted. First, the incident demonstrates that even leaders in the tech space are not immune to targeted social-engineering intrusions that exploit legitimate collaboration features like external app integrations. Second, the breach underscores the importance of timely detection and transparent communication with stakeholders and customers. While the exact data exfiltration was limited, the strategic risk is real: even seemingly modest data exposures can seed further social-engineering campaigns, facilitate targeted credential stuffing, or enable the construction of more convincing phishing attempts that prey on business relationships. Finally, the emergence of extortion-centric actors using public-facing data as leverage signals a shift in attacker incentives toward a broader repertoire of coercive tactics. The evolving threat landscape requires a more robust, layered defense approach, where technical controls are complemented by proactive threat intelligence, rigorous security awareness training, and a culture of rapid incident response.

Threat Actor Landscape: UNC6040, UNC6042, and the ShinyHunters

Within the observed campaign, two major actor archetypes emerged: UNC6040 and UNC6042, the latter commonly associated with the ShinyHunters branding in extortion circles. The relationship between these groups appears to be one of parallel operation rather than strict containment of responsibilities, with UNC6042 engaging in extortion activities that may occur after intrusions attributed to UNC6040. This dual-actor dynamic has important implications for defenders: it signals that threat actors may leverage different personas or brandings to maximize impact, confuse attribution, and broaden the perceived scope of the threat across multiple campaigns and platforms.

The ShinyHunters’ involvement is particularly noteworthy given their publicized history of data-leak strategies that revolve around pressuring victims to disclose data or pay ransoms to prevent or mitigate public exposure. The potential for a “data leak site” (DLS) infrastructure signals a shift toward monetized disclosure ecosystems where stolen datasets are cataloged, advertised, and leveraged to create reputational damage or financial penalties for targeted organizations. The presence of such a site, as suggested in Google’s analysis, would be intended to amplify the coercive effect of the breach by providing public evidence of data loss and tangible consequences to victims.

From a defensive standpoint, this landscape calls for a two-pronged approach: (1) reduce the attack surface by restricting the use of external app connections and enforcing strict access controls, and (2) strengthen the offense side with proactive threat intelligence that maps actor TTPs to organizational assets, enabling faster detection and containment. It also underscores the need for robust incident response playbooks that can scale across multiple business units and third-party ecosystems, because the same actor clusters may appear across different organizations as they refine their techniques or pivot to new targets.

Industry Impact and Notable Victims: Implications Across Sectors

The breadth of organizations implicated in this campaign—ranging from consumer brands to telecommunications and luxury goods houses—highlights how pervasive the Salesforce-connected ecosystem has become in modern business. The involvement of Adidas, Qantas, Allianz Life, Cisco, and the Louis Vuitton, Dior, Tiffany & Co. triad underscores the cross-industry reach of the tactic and the heightened risk faced by enterprises that rely on integrated cloud platforms to drive operational efficiency. The common thread across these sectors is the reliance on CRM ecosystems to unify customer data, workflow automation, analytics, and partner integrations, all of which create expansive data surfaces for potential exposure.

The industry-wide implications extend beyond the immediate data exposure. A breach of Salesforce connections can erode trust among customers, disrupt business processes, and trigger heightened scrutiny from regulators and auditors. It prompts boards and executive leadership to reassess risk appetites associated with cloud-based integrations and third-party access. Notably, the exposure of business names and contact details—data that is often publicly accessible—does not necessarily indicate a catastrophic data loss; however, it can still be leveraged to craft highly convincing social-engineering campaigns, refined spear-phishing attacks, or targeted extortion attempts that leverage the reputational risks and operational disruptions associated with a breach.

Moreover, the incident exposes a potential supply-chain risk that arises when trusted partners or vendors connect external tools to customer environments. It underscores the importance of vendor risk management, continuous monitoring of third-party data-access privileges, and the enforcement of least-privilege principles across interconnected systems. For the organizations involved, the immediate priority is to complete a comprehensive audit of all Salesforce-linked integrations, identify any foreign connections that have been established, and harden configurations to reduce future exposure. For the broader market, it reinforces the need for standardized security practices around external app connections and more robust verification processes for changes to critical cloud environments.

Defensive Measures for Salesforce Customers: Reducing Exposure and Strengthening Resilience

The core defense against this class of social-engineering-driven breaches lies in a combination of policy discipline, technical controls, and human-centered training. Salesforce customers should treat any request to connect an external application to their Salesforce instance as a high-risk operation requiring formal approvals, documented change control, and verifiable identity verification steps. The attackers’ success hinges on convincing an employee to provide an eight-digit security code that is ordinarily designed to ensure secure integration, so mitigating this risk means ensuring that no one accepts such requests without multi-factor authentication and independent verification.

Key practical steps include:

  • Implement and enforce multifactor authentication for all accounts with administrative or integration-management privileges. MFA should be non-optional and combined with step-up authentication for any action that modifies integration settings or grants external access.

  • Establish rigid change-control processes for external app connections. Each request should be accompanied by a documented business justification, risk assessment, and a review by a security-initiated change advisory board (CAB) or equivalent governance structure.

  • Restrict external app permissions using the principle of least privilege. Only the minimum data and capabilities required for an external app to function should be granted, and permissions should be periodically reviewed and constrained.

  • Maintain an auditable ledger of all external integrations, including who approved, when the integration was established, the data flows involved, and any credentials or codes used in the provisioning process. Regularly reconcile this ledger with actual configurations to identify drift or unauthorized changes.

  • Conduct ongoing security awareness and phishing-resilience training for employees, with a focus on social engineering scenarios commonly used to initiate external integrations. Training should include real-world simulations, debriefs, and measurable improvements in detection rates.

  • Deploy continuous monitoring and anomaly detection for Salesforce integration activity. This includes alerting on unusual connection attempts, unexpected data access patterns, or the emergence of new external app connections outside of the approved baseline.

  • Establish clear incident response protocols for suspected breaches involving external integrations. The plan should outline containment steps, investigative workflows, communication templates, and escalation paths to executive leadership and regulatory bodies if required.

  • Perform periodic tabletop exercises that simulate social-engineering-based attempts to connect external apps. The exercises should involve IT, security, customer success, and legal teams to ensure a coordinated, comprehensive response.

  • Review vendor and partner ecosystems for risk. If a third-party application is indispensable, require vendor security attestations, data handling agreements, and joint-risk assessments that specify data handling, access controls, and breach notification obligations.

  • Consider additional layers of protection for highly sensitive domains within Salesforce. This might include segregating critical data, applying tighter access controls for sensitive data objects, and implementing additional authentication gates for high-privilege actions.

For organizations that rely on Salesforce, proactive posture change is essential. The combination of people, processes, and technology must be aligned to prevent social-engineering successes from translating into unauthorized access. This alignment requires a disciplined security culture that treats external app connections as first-class risk vectors, not as routine configurations to be approved with routine speed. The goal is to shift the balance away from convenience and toward verifiable trust, with clear accountability for every integration and a robust, repeatable process for validating and maintaining those integrations over time.

The Extortion Model: Data Leaks, Leverage, and Pressure Terversion

A notable dimension of this campaign and related activity is the increasing use of extortion and coercive tactics as a primary driver of impact. The attackers’ publicly acknowledged use of a data-leak site (DLS) by the “ShinyHunters” brand signals a shift toward monetization through public disclosure, reputational damage, and the application of pressure rather than purely financial gain through immediate ransom demands. This approach has grown in prominence in other data breach incidents and is now part of a broader toolkit used by threat groups to coerce victims into conceding to demands or making concessions that align with the attackers’ objectives.

The extortion narrative often hinges on the perceived consequences of data exposure for customers, partners, and employees. Even when the exposed data itself is not highly sensitive, the threat of public exposure, reputational harm, and regulatory scrutiny can be an effective lever to extract concessions. This tactic also complicates incident response because it requires defenders to consider not only technical remediation but also communications strategy, legal exposure, regulatory notifications, and stakeholder management. The possibility that extortion actors might escalate their tactics by combining data exposure with new ransomware-like pressure or targeted public campaigns heightens the need for rapid containment and clear, consistent messaging to affected parties.

For security teams, the evolving extortion playbook means that incident response plans should incorporate scenarios in which attackers leverage exposted data as leverage, even if the actual data exfiltration is relatively small. Planning should include pre-scripted communications for customers, investors, and partners, as well as legal and regulatory considerations around disclosure and notification obligations. Organizations must also invest in threat intelligence that helps distinguish between credible extortion threats and bluffs, as attackers frequently adapt their posture to maximize leverage and ambiguity.

Looking Ahead: Preparedness, Resilience, and Organizational Change

The convergence of social engineering, trusted integration mechanisms, and extortion-driven tactics creates a security landscape where the risk is not confined to a single incident but rather a recurring threat that requires ongoing vigilance and adaptation. The Google incident demonstrates that even the most technologically advanced organizations are not immune to the social dynamics of trust and the modern realities of cloud-based integrations. The broader market lesson is that security cannot be accomplished by technology alone; it requires a holistic, governance-backed approach that recognizes the human element as a primary attack surface.

Organizations should treat this as a call to action to reassess how external app integrations are managed, how employees are trained to recognize sophisticated social-engineering prompts, and how risk is mitigated through stronger authentication, tighter access controls, and proactive monitoring. The recommended posture includes an integration-centric risk assessment, routine audits of connected apps, and a cycle of continuous improvement informed by real-world threat intelligence about UNC6040, UNC6042, and related actors.

In practical terms, Salesforce customers should execute a comprehensive review of their external integrations, ensure MFA is enforced across administrative actions, implement least-privilege access for connected apps, and embed continuous monitoring for unusual or new integration activity. Training programs must emphasize the social-engineering vectors used to manipulate legitimate workflows, and incident response plans should be prepared to handle data-leak extortion scenarios with a clear communication and legal strategy.

The security community should continue to monitor the evolving tactics of groups like UNC6040 and UNC6042, with particular attention to the emergence of DLS-like leverage while maintaining vigilance against the broader trend of data exposure as a coercive tool. Through a combination of technical controls, policy discipline, and user education, organizations can strengthen their defenses against social-engineering breaches that leverage trusted workflow mechanisms and third-party integrations.

Conclusion

The June campaign against Salesforce customers demonstrates a persistent and adaptable threat landscape where social engineering and the manipulation of trusted integration pathways can yield access to business data with relative ease. The subsequent disclosure by Google that it too had been compromised reinforces the notion that even the most prominent organizations face similar risks when trusted processes are exploited. The dual threats—unauthorized access to Salesforce environments via manipulated eight-digit codes and extortion-driven data-leak pressure—present a clear imperative for organizations to adopt a layered, defense-in-depth posture that emphasizes not only technical safeguards but also governance, training, and incident readiness.

To withstand this evolving threat environment, enterprises must implement stringent controls over external app connections, enforce robust MFA, and maintain rigorous auditing and monitoring of all integration activity. Employees should receive ongoing training that incorporates realistic social-engineering simulations, enabling them to recognize and resist deceptive prompts before any sensitive actions are taken. The threat ecosystem has shown a willingness to blend traditional data breaches with coercive extortion, and organizations must respond with a holistic security program that pairs technical resilience with proactive risk management and proactive, transparent communication strategies. Only through comprehensive, sustained effort can organizations reduce the likelihood and impact of social-engineering breaches that exploit trusted tools and workflows, protect customer trust, and maintain operational continuity in an increasingly interconnected digital landscape.