Incident Analysis

PowerSchool Breach: 62M Students, $2.85M Ransom, Cascading Extortion

PowerSchool's December 2024 breach exposed data on roughly 62M students and 9.5M teachers through a compromised support-portal credential and triggered downstream extortion of school districts months later.

Alex
Security Analyst
6 min read

On January 7, 2025, PowerSchool — the dominant U.S. student-information-system vendor, serving roughly 18,000 schools and 60 million-plus students across North America — publicly disclosed a December 28, 2024 cyberattack against PowerSource, its customer support portal. The attacker used a single compromised support-engineer credential to authenticate to PowerSource, pivot into the production Student Information System (SIS), and exfiltrate years of student and teacher records. PowerSchool paid a ransom widely reported at approximately $2.85 million in Bitcoin to prevent public release. The data did not stay buried. In May 2025, individual school districts in Canada and the United States began receiving direct extortion demands from threat actors who claimed (with verifiable samples) to still hold the data. The federal indictment of Matthew D. Lane on May 6, 2025, named a 19-year-old Assumption University student as the attacker; Lane pleaded guilty on November 18, 2025 and was sentenced on April 22, 2026 to four years in federal prison with $14.1 million restitution.

Who got hit and when?

PowerSource is PowerSchool's customer service portal — staff at the company use it to access customer SIS tenants for troubleshooting. Between December 22 and December 28, 2024, the actor used a stolen credential (likely harvested via infostealer malware on a PowerSchool support engineer's personal device) to log into PowerSource and pivot into customer SIS tenants. The actor systematically queried Students, Contacts, Staff, Custom_Fields, and Demographics tables and exfiltrated CSV bulk exports. PowerSchool detected the incident on December 28 and engaged CrowdStrike on December 29. PowerSchool initially estimated impact at "less than half" of customers; by the May 2025 final analysis, the breach was confirmed to affect roughly 62 million current and former students and 9.5 million teachers, making it the largest known breach of U.S. children's data.

What data was stolen?

The exfiltrated dataset included names, dates of birth, addresses, parent contact information, medical alerts (e.g. severe allergies, asthma indicators), special-education status, free-and-reduced-lunch eligibility, behavioural-incident records, and in some districts Social Security numbers. The latter is the most damaging: although PowerSchool's SIS does not require SSNs, many districts historically used SSNs as student IDs and stored them in Student_Number or custom fields. PowerSchool's January 17, 2025 customer FAQ confirmed SSN exposure in "limited" cases. The data is uniquely sensitive because most affected individuals are minors — Social Security numbers issued to children carry far longer financial-lifetime risk than adult numbers, and credit-bureau placeholders for minors are routinely abused for synthetic-identity fraud.

How did the support-portal compromise happen?

PowerSchool's January 17 customer letter and the subsequent CrowdStrike-led forensic summary identified the entry as a "compromised credential to PowerSource" — a single legacy account without MFA. The credential is believed to have been harvested by Lummac or RedLine infostealer running on a contractor's personal computer that the engineer also used to access the corporate PowerSource portal. PowerSchool had MFA available for PowerSource but not strictly enforced for every account type; the compromised account was a long-tenured maintenance ID that had been grandfathered out of the MFA rollout. This is the same exact failure mode that produced the Snowflake customer breaches in 2024 (UNC5537 exploited customer Snowflake accounts that lacked MFA despite Snowflake offering it).

Why is the follow-on extortion so notable?

PowerSchool paid the original ransom and received "assurances" that the data had been deleted. As K-12 Dive and TechCrunch reported on May 8, 2025, that promise was not kept. Beginning the first week of May 2025, individual school districts in North Carolina (Wake County), Texas (Crowley ISD), Ontario (Toronto District School Board), and at least 50 others received emails from a self-styled "ShinyHunters Co" identity demanding payment to prevent district-specific data leaks. The emails included verifiable student samples from each district. PowerSchool subsequently published a public statement acknowledging the cascading extortion and offering districts an extended incident-response support package and two additional years of credit monitoring beyond the initial offer. The episode is now a textbook case in why paying a ransomware operator never guarantees data destruction.

What's the indictment story?

On May 6, 2025, Federal prosecutors in Massachusetts unsealed an indictment against Matthew D. Lane, a 19-year-old at Assumption University in Worcester. The indictment ties Lane to extortion conspiracies against PowerSchool and "Victim 2" (a separate telecommunications company widely reported as Cellcom). Lane allegedly initiated negotiations with PowerSchool on December 28, 2024 demanding $2.85 million in Bitcoin. Lane pleaded guilty on November 18, 2025 to four counts: conspiracy to commit cyberextortion, aggravated identity theft, conspiracy to commit wire fraud, and unauthorised computer access. The April 22, 2026 sentencing of four years in federal prison plus $14.1 million in restitution reflects the scale of victim impact, though prosecutors did not name the secondary extortion campaign's perpetrators (Lane's involvement in the May 2025 follow-up was not alleged).

# Hardening: enforce MFA on every service account in a customer support portal
# OAuth conditional access policy (Microsoft Entra ID example)
$mfaPolicy = New-MgIdentityConditionalAccessPolicy `
  -DisplayName "Support Portal - Require MFA All Users" `
  -State "enabled" `
  -Conditions @{
    Users = @{ IncludeUsers = @("All") }
    Applications = @{ IncludeApplications = @("PowerSource-SIS") }
    ClientAppTypes = @("browser","mobileAppsAndDesktopClients")
  } `
  -GrantControls @{
    Operator = "AND"
    BuiltInControls = @("mfa","compliantDevice")
  }

What should EdTech vendors and school districts do?

Six steps. First, EdTech vendors must enforce phishing-resistant MFA (WebAuthn or FIDO2) on every internal account that can access customer data — no grandfathered legacy accounts, no exceptions. Second, vendors must isolate customer-support engineering environments so that a single compromised credential cannot pull data across multiple tenants; tenant-isolated short-lived credentials are the goal. Third, school districts must contractually require their EdTech vendors to publish SOC 2 Type II reports annually, disclose incidents within four business days, and attest to MFA enforcement and SSN minimisation. Fourth, districts must build incident-response runbooks specifically for "vendor was breached, our data is out" scenarios. Fifth, districts must press their state legislatures for student-data-protection laws that include vendor-side breach-notification triggers (New York's Education Law 2-d and Illinois SOPPA are templates). Sixth, never trust a ransomware actor's promise to delete data — assume the data is permanently public and counsel families accordingly.

How Safeguard Helps

Safeguard maps every EdTech and SIS vendor in a district's portfolio against the CIS K-12 Cybersecurity Benchmarks, NIST SP 800-171, and the FTC Education Privacy enforcement record, scoring suppliers on MFA enforcement posture, time-to-disclose, and SOC 2 attestation currency. Griffin AI cross-references vendor incidents against active extortion-group infrastructure (ShinyHunters, Hellcat, RansomHub) and raises a critical finding the moment a supplier appears on a leak site or in an indictment. TPRM scoring downgrades vendors that allow legacy credentials without MFA or that store SSNs unnecessarily. Policy gates block any new EdTech rollout whose vendor cannot attest in writing to phishing-resistant MFA across all support-engineer accounts, ensuring the next PowerSource-class entry vector is closed before contract signature.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.