TL;DR: Recent attacks on LVMH companies, Adidas, Qantas and Allianz Life suggest a repeatable path into local environments through a third-party CRM platform, with social engineering used to enroll malicious tooling and reach connected systems such as Okta and Microsoft 365, according to Swarmnetics and Google Threat Intelligence Group. The pattern shows that delegated trust, not the CRM platform itself, is the weak point in many identity and access controls.
NHIMG editorial — based on content published by Swarmnetics covering the attribution debate between ShinyHunters and Scattered Spider: Have ShinyHunters and Scattered Spider Teamed Up? New Cyber Attack Attributions Paint a Complex Picture
Questions worth separating out
Q: How should security teams handle trust decisions in SaaS connected-app workflows?
A: Security teams should treat connected-app approval as a privileged control point, not a user convenience feature.
Q: Why do CRM and SaaS integrations increase lateral movement risk?
A: Because one approved connection can extend identity trust across multiple systems, including SSO, collaboration, and data platforms.
Q: What do organisations get wrong about social engineering defence?
A: They often treat it as an awareness problem instead of a workflow problem.
Practitioner guidance
- Harden connected-app approval workflows Require step-up verification for any new Data Loader, OAuth, or connected-app approval in CRM and adjacent SaaS platforms.
- Map downstream SaaS trust chains Inventory which identity platforms and collaboration tools inherit access from CRM systems, including Okta and Microsoft 365.
- Train staff on support impersonation patterns Educate employees with CRM or admin access about fake IT support calls, malicious connector prompts, and urgent code-sharing requests.
What's in the full analysis
Swarmnetics' full analysis covers the operational detail this post intentionally leaves for the source:
- The article’s line-by-line attribution clues for why the attacks were initially misread as Scattered Spider activity
- The attack sequence around Salesforce CRM access, malicious Data Loader trust establishment, and the eight-digit code workflow
- The reasoning behind the hypothesis that ShinyHunters focused on exfiltration and private ransom negotiation rather than ransomware
- The context on how contractor posture and English-language support impersonation factor into the intrusion chain
👉 Read Swarmnetics' analysis of the ShinyHunters and Scattered Spider attribution pattern →
ShinyHunters and Scattered Spider: what CRM trust gaps mean now?
Explore further
Delegated SaaS trust is now a primary identity governance risk. The article shows that a CRM workflow can become an approval channel for malicious tooling when users are tricked into authorising a connection. That is not a vendor-specific failure, it is a governance failure around who can create trust, how that trust is verified, and what downstream systems inherit the result. Practitioners should treat connected-app approval as a privileged action, not a routine user gesture.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the same research.
A question worth separating out:
Q: Who is accountable when a contractor or support path opens a SaaS breach?
A: Accountability should sit with the system owner, the identity team, and the third-party access owner together. Contractor access, support impersonation risk, and connected-app permissions are not separate problems when they combine into one access path. Frameworks such as NIST CSF and NIST SP 800-53 both expect clear access governance and review.
👉 Read our full editorial: ShinyHunters and Scattered Spider expose CRM trust gaps