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.
Editorial analysis by NHI Mgmt Group, based on content published by Swarmnetics: “Have ShinyHunters and Scattered Spider Teamed Up? New Cyber Attack Attributions Paint a Complex Picture”.
Key questions
Q: What breaks when a CRM trust chain is abused through social engineering?
A: The main failure is that a legitimate enrolment or approval flow becomes an access path for an attacker.
Q: Why do delegated SaaS permissions increase identity risk?
A: Because they move access decisions away from direct human login and into durable grants that can be reused across sessions and services.
Q: What are the signs that CRM-connected app governance is failing?
A: Warning signs include support-driven app enrolments, unexplained eight-digit verification codes, new OAuth grants that were not requested through formal change, and CRM access that suddenly reaches identity platforms.
Practitioner guidance
- Audit CRM connected-app trust paths Map every CRM integration, third-party app, and downstream identity or productivity system that inherits access from the CRM session.
- Require step-up verification for app enrolment Treat any new trusted connection to CRM data as a privileged change request, with out-of-band verification for the requester and the approver.
- Review downstream identity reach Identify whether CRM-connected apps can reach Okta, Microsoft 365, or other control-plane systems, and remove any unnecessary propagation of trust.
Bottom line: The attack pattern is not a generic SaaS compromise but a trust-chain abuse problem that starts with social engineering and ends with downstream access.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
CRM trust chains are becoming the real attack surface. The vendor-style perimeter view of SaaS security misses the actual control problem, which is delegated access that can be extended through connected apps and support workflows. When a CRM can bridge into identity, email, or collaboration systems, governance has to follow the trust chain, not the application label. Practitioners should treat downstream trust links as first-class access assets.
A question worth separating out:
Q: How should teams respond when a third-party CRM is compromised?
A: Containment should start by revoking vendor credentials, isolating the affected integration, and preserving logs before the attacker can move through legitimate export or admin paths. After that, teams should review what data the third party could reach, not just what was visibly exfiltrated. Response is about shrinking the blast radius and proving which identities had access.
👉 Read our full editorial: ShinyHunters and Scattered Spider expose CRM trust gaps