What Happened
Ransomware group ShinyHunters added Amtrak (National Railroad Passenger Corporation) to its data leak site on April 12, 2026, claiming theft of 9.4 million Salesforce records containing personal and corporate data. The group set an April 14 ransom deadline and threatened to publicly release the data without payment. As of April 16, no verified data samples have been released and no payment has been publicly confirmed.
According to security researchers, ShinyHunters gained access to Amtrak’s Salesforce data through social engineering attacks targeting Salesforce employees — not through a technical vulnerability in the Salesforce platform itself. Salesforce denied any compromise of its core infrastructure. The attack vector mirrors the method used in a series of ShinyHunters breaches this year involving Cisco, Rockstar Games, Hallmark, Beacon Pointe Advisors, and McGraw-Hill — all of which involved data accessed through Salesforce customer environments rather than a direct Salesforce platform breach.
McGraw-Hill separately confirmed on April 15 that a Salesforce misconfiguration — not social engineering — allowed attackers to access 13.5 million accounts from their internal Salesforce environment. The parallel incidents highlight two distinct but related risks: social engineering of Salesforce personnel and misconfigured Salesforce environments that expose data without an attacker needing to breach Salesforce itself.
Why This Matters for Canadian Organizations
Salesforce is one of the most widely deployed enterprise platforms in Canada, used across financial services, telecommunications, retail, healthcare, professional services, and government. Canadian organizations that store customer data, operational records, or regulated information in Salesforce are directly exposed to both attack patterns seen in the Amtrak and McGraw-Hill incidents.
Social engineering of cloud platform employees — targeting Salesforce, Okta, or Microsoft support staff to obtain access to customer tenants — is a documented and effective technique used by groups like ShinyHunters and Lapsus$. Canadian organizations cannot assume their Salesforce tenant is protected by Salesforce’s own security posture alone. Customer data held in a platform can be exfiltrated if the platform vendor’s personnel are compromised.
Under PIPEDA, any organization that suffers a breach resulting in a real risk of significant harm to individuals must notify both the Office of the Privacy Commissioner of Canada and affected individuals without unreasonable delay. Salesforce breaches involving personal data — names, contact information, account records — meet this threshold. Canadian security and legal teams should treat every Salesforce breach disclosure as a prompt to audit their own tenant security posture, access controls, and breach notification readiness.
What to Do
Review your Salesforce tenant access controls immediately. Audit which internal and external accounts have access to sensitive data objects, and remove permissions that are no longer operationally required. Enable Salesforce Event Monitoring to detect unusual data access or export activity. Enforce multi-factor authentication on all Salesforce user accounts without exception, including administrators. Restrict Salesforce API access to known IP ranges and disable legacy authentication protocols.
Beyond configuration, brief your vendor management and procurement teams on the social engineering risk posed by attackers targeting SaaS platform support personnel. Implement a verification protocol with your Salesforce account team for any unusual access requests or permission changes. If your organization stores sensitive personal data in Salesforce, conduct a data classification review to confirm what data is present and whether it should be there.
Source: SecurityWeek | BleepingComputer
