ShinyHunters vs Instructure: 3.65 TB, 275 Million Users, and the Five Questions Every School Should Be Asking

On 7 May 2026, during finals week at thousands of universities, the Canvas login page stopped looking like a login page. Instead, students and faculty were greeted with a message from a criminal extortion group: “ShinyHunters has breached Instructure (again). Instead of contacting us to resolve it they ignored us and did some ‘security patches’.”

The defacement was visible on roughly 330 institutional portals for about 30 minutes before Instructure took Canvas, Canvas Beta, and Canvas Test offline. By then the message had done its job — not against Instructure's engineers, but against Instructure's customers. Schools were going to start asking questions, and the questions were going to be loud.

This wasn't the start of the attack. It was an escalation. Four days earlier, ShinyHunters had quietly listed Instructure on their dark-web leak site under a “PAY OR LEAK” banner, claiming 3.65 TB of exfiltrated data covering approximately 275 million users across 9,000 schools and 15,000 institutions. When Instructure refused to negotiate and rolled out patches, the group switched tactics — from quiet extortion to loud public pressure, using Instructure's own customers as leverage.

What Happened, in Order

30 April: Instructure detected disruption in API-dependent tools across the Canvas ecosystem.

1 May: Instructure officially confirmed a cybersecurity incident and engaged forensic experts.

3 May: ShinyHunters added Instructure to their “Scattered LAPSUS$ Hunters” data leak site under a “PAY OR LEAK” headline, posting 3.65 TB of data as proof. They threatened to release billions of student-teacher messages if Instructure didn't pay by 6 May.

7 May: After Instructure refused to negotiate, ShinyHunters defaced approximately 330 institutional Canvas login portals via HTML injection, extending the deadline to end of day on 12 May. They also reached out directly to journalists at TechCrunch.

The exposed dataset, per the group's own claims and Instructure's disclosures, includes names, institutional .edu email addresses, student identification numbers, and private messages between students and faculty. Instructure has stated that passwords, dates of birth, government ID, and financial information were not in scope.

How They Got In (and Why It Keeps Working)

Instructure has not yet published a forensic report, so parts of what follows are inferred from ShinyHunters' documented operations against Cisco, Allianz Life, Odido, Wynn Resorts, and a long list of other SaaS-heavy victims through 2025 and 2026. The pattern is consistent enough that it's worth treating as the working theory.

Initial access. Attackers likely combined misconfigured “Free-For-Teacher” accounts, API key weaknesses, and vishing — voice phishing — against internal administrative staff. Once an admin was on a phishing site, the attackers captured SSO credentials and real-time MFA codes, then registered their own MFA devices for persistent access. This is the same playbook that worked at Cisco and Wynn.

Lateral movement. From there, the actors pivoted to Instructure's Salesforce instance. They used a tool called AuraInspector (which the group internally calls “RapeForce”) to identify misconfigured Salesforce Experience Cloud guest profiles and pulled data via SOQL queries. Salesforce was the access point, not the target — the target was customer records and metadata.

Extortion. When Instructure declined to negotiate, the group exploited a separate vulnerability to inject HTML into Canvas login pages, turning every customer's front door into a billboard for the ransom demand. The timing — spring finals week — was deliberate. It maximised institutional pressure on the vendor.

The reason this playbook keeps working is that none of the controls most organisations rely on (MFA, EDR, perimeter defences) actually break here. They get bypassed. The user authorises the attacker. The OAuth token gets issued legitimately. The API key works exactly as designed. The defence has to live further upstream — at the identity layer and the helpdesk — or it doesn't exist.

Why This Hits Schools Harder Than Most Breaches

The exposed dataset — names, emails, student IDs, and Canvas messages — reads as low-severity until you think about what Canvas messaging has actually been used for. Grade disputes. Accommodation requests. Mental health check-ins. Counselling-adjacent conversations. Safeguarding matters. For most institutions, none of this had a retention policy. Whatever has accumulated for years is now potentially in the leaked dataset.

The next wave of phishing won't be generic. Attackers now have real student names, real teacher names, real course titles, and real internal messages to build lures from. Expect emails that reference the assignment your student actually submitted, calls that mention the teacher they actually have, and texts that quote private messages that actually happened. Email security tuned for generic phishing won't catch this.

On the operational side, every Canvas integration — gradebooks, plagiarism detectors, library systems, video tools — needs to be re-authorised against Instructure's new timestamped API keys. That's days of cleanup at minimum, on top of compliance reporting under FERPA, GDPR, and any local student data protection regime that applies. Institutions that used Canvas messaging for safeguarding may have additional obligations under child protection laws.

The Five Questions Every School Should Put to Its Security Provider This Week

If your institution uses Canvas — or any SaaS platform that ShinyHunters might pivot through next — these are the five questions to ask, today, of whoever owns your security posture. The answers tell you whether they're actually equipped for this threat or just following a generic incident-response checklist.

1. Have you revoked and re-issued every API key, OAuth token, and connected app tied to our Canvas environment — including legacy “Free-For-Teacher” accounts and integrations we may have forgotten about?

Why it matters. ShinyHunters' playbook abuses long-lived API tokens and OAuth grants, not passwords. If your provider can't produce a current inventory of every key and what it's authorised to do, they can't tell you whether the attackers still have access. Instructure has issued new timestamped keys — every integration needs to be re-authorised against those.

2. What is our defence against vishing — specifically, a caller pretending to be from IT and asking a staff member to enter a code at microsoft.com/devicelogin or approve an MFA prompt?

Why it matters. This is the technique ShinyHunters used against Cisco, Allianz Life, and Wynn Resorts. Standard MFA doesn't stop it because the user authorises the attacker themselves. The defences are phishing-resistant MFA (FIDO2 keys or passkeys), Conditional Access policies that block OAuth Device Code Flow on user devices, and a helpdesk script that requires out-of-band verification before any password or MFA reset.

3. How will we detect, triage, and warn staff and students about phishing emails and calls that reference real course names, real teachers, and real Canvas message content?

Why it matters. Your existing email security is tuned to catch generic phishing. The next wave will be tailored using leaked data — sender names your staff recognise, subject lines about assignments that actually exist, references to private conversations that did happen. Your provider should be running a fresh awareness campaign this week and tightening detection rules for impersonation of internal contacts.

4. What sensitive content lives in Canvas messages, what is our retention policy, and can you help us purge or archive what we no longer need?

Why it matters. Canvas messaging has historically been used for grade disputes, accommodation requests, counseling-adjacent conversations, and safeguarding matters — often with no retention policy at all. Whatever has accumulated for years is now potentially in the leaked dataset. Going forward, the smallest message archive is the safest one. Your provider should help you set defensible retention windows and audit any free-text fields holding sensitive information.

5. If we discover staff or student credentials are being actively abused this week, who do we call, what's our containment playbook, and how fast can you isolate a compromised account?

Why it matters. The breach itself is contained at Instructure's end, but the follow-on credential abuse is just starting. You need a named contact, a documented response time, and confirmation that your provider can revoke sessions, force password resets, and pull a user off the network within minutes — not hours. If they need to “get back to you” on this, that's your answer.

Do Not Pay the Ransom

One last point that deserves to stand on its own. Paying does not guarantee the data is deleted, does not prevent it from being resold to other criminal groups, and directly funds the next attack. Law enforcement agencies in the US, UK, EU, and Australia consistently advise against payment, and in some jurisdictions payment may itself violate sanctions law. The decision Instructure has already made — to refuse and harden — is the right one. The decision your institution may face in the next twelve months is the same one. Make it before you're under deadline pressure, not during.

The Full Report

Stealth Cyber's threat intelligence team has published a full CTI report covering the timeline, attack methodology with mapped MITRE ATT&CK techniques, a profile of ShinyHunters as a threat actor, impact assessment for institutions and individuals, and a complete set of recommendations for both schools and parents/students. It's the document you can hand to your IT provider or board this week.