Notifications
Clear all
Topic starter
12/07/2026 12:19 pm
TL;DR: ShinyHunters-style vishing campaigns used help desk impersonation to push victims into approving malicious Salesforce connector changes, enabling CRM data theft across firms including Qantas, LVMH, and Google, according to Cybertrust Japan's analysis of GTIG reporting. The real failure is not MFA alone, but assuming users can safely validate connector trust under live social engineering pressure.
NHIMG editorial — based on content published by Cybertrust Japan: Salesforce CRM targeted by vishing attacks and the 2025 threat trends behind them
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams handle vishing attacks that target SaaS support workflows?
A: Treat support workflows as part of the identity perimeter.
Q: Why do MFA and SSO not stop Salesforce data theft in social-engineering attacks?
A: Because the attacker is often not trying to beat the login flow.
Q: What do security teams get wrong about OAuth and connected apps?
A: Teams often assume a delegated app is safe because it was approved once, but approval is not the same as ongoing trust.
Practitioner guidance
- Lock down support-mediated account recovery Require higher assurance before any help desk action that can reset access, approve device changes, or alter connected application trust.
- Review all Salesforce-connected applications and consent scopes Inventory every connector, confirm business ownership, and remove unused grants.
- Treat connector approvals as privileged events Send alerts for new consent grants, changes to connected apps, and data-loader authorisations.
What's in the full article
Cybertrust Japan's full blog covers the operational detail this post intentionally leaves for the source:
- The step-by-step vishing sequence used against Salesforce-connected environments and how the malicious connector was introduced.
- The incident timeline and named organisations affected, including the way customer data was pulled through the trust chain.
- The Google Threat Intelligence Group references and supporting incident sources that underpin the attack narrative.
- The mitigation actions the vendor highlights for Salesforce environments, including specific platform settings and administrative checks.
👉 Read Cybertrust Japan's analysis of Salesforce CRM vishing and data theft →
Salesforce CRM vishing and the governance gap teams are missing?
Explore further
12/07/2026 12:32 pm
Support-assisted access is a governance surface, not a back-office convenience. Vishing campaigns succeed when identity programmes treat help desk actions as administrative routine rather than access decisions. The support channel can create or widen trust in ways that MFA never sees. Practitioners need to govern support-mediated changes with the same seriousness as privileged access changes.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 38% have no or low visibility, and a further 47% have only partial visibility, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to the same study.
A question worth separating out:
Q: Who is accountable when a support-assisted connector change leads to data exfiltration?
A: Accountability sits across identity, service desk, and application ownership. IAM teams should define who approves connector scopes, who can alter them, and who must revoke them after incidents or role changes. Without that ownership, delegated access outlives the business reason for it.
👉 Read our full editorial: Salesforce CRM vishing shows how social engineering beats MFA
