Ransomware

The BYOD extortion group added Michigan State University (MSU) to its leak site on Sunday, November 1, claiming personal data on current and former students. News reports give the figure as 1.3 million; the copy of the post captured by the tracker ransomware.live reads "1.03 million". The group also claims staff records, passwords and a full compromise of university systems. None of this has been verified, and MSU says it "has not determined that any personal information was compromised."

The listing came a month after MSU forced every NetID holder to reset their password. On October 1 at 5 p.m., the university emailed all students, faculty and staff about "suspicious cybersecurity activity" and asked them to reset. MSU has not said the two events are linked. It is the same group that claimed the October 26 attack on the University of New Mexico's hospital, which we covered in our UNM Health post. For universities and health systems on single sign-on (SSO), MSU raises a narrower question than UNM did: what still has to happen after a forced password reset.

What MSU has said, and what BYOD claims

MSU's own service status page records the incident as "Required Password Reset for All MSU Accounts", filed under Identity and Access Management. Its text says the university "became aware of suspicious cybersecurity activity" and that, so far, "there is no evidence that other MSU data has been accessed, changed, or stolen." The page shows the incident marked resolved on October 30, two days before the listing. MSU described the October activity to The Record as a potential credential compromise, and The Record reports that the new passwords had to be at least 15 characters, which matches MSU's published password guidance.

After the listing, a campus-wide MSU IT email reported on November 3 said it was investigating a potential threat with law enforcement, partners and the State of Michigan. Spokesperson Emily Guerrant told The State News the university was not aware of the group being involved in the October incident, and did not confirm or deny the student figure.

BYOD's post opens with "Full Personal Identifiable Information for 1.03 million current and ex students" and tells MSU to open contact. The Record says the post appeared on Sunday; The State News says Monday. Ransomware.live logged it at 03:50 UTC on November 2, which is late Sunday evening in Michigan.

Why a password reset may not end a credential compromise

At MSU, as at most large campuses, one identity reaches almost everything. MSU's own help article shows the NetID password is managed in Okta (the identity provider behind auth.msu.edu), and that after changing it, remote users must connect to the MSU VPN and on-campus users must lock or reboot domain-joined Windows machines so cached credentials update. One credential covers web SSO, VPN and Windows logon.

A forced reset stops anyone from starting a new sign-in with the old password. It does not, by itself, end sessions that already exist. Microsoft's guidance for Entra ID is explicit that access tokens stay valid until they expire (one hour by default), and that the identity provider "can't directly revoke a session token issued by an application": each application controls its own session cookie. Okta treats ending sessions as a separate admin action, "Clear User Sessions", which can be done during or apart from a password reset.

That gap matters when the stolen credential came from an infostealer, malware that copies what the browser holds. Microsoft's analysis of Lumma Stealer says it "extracts saved passwords, session cookies, and autofill data" from Chromium browsers. A stolen session cookie can let an attacker keep using an application after the password changes, without passing multi-factor authentication (MFA) again.

What BYOD says it does

The group appeared in September. In its Trump Mobile case it posted data on 3,615 customers and told International Cyber Digest that it first infected an employee at the partner carrier Liberty Mobile with an infostealer, and that neither company used any form of MFA. Neither company has confirmed that account, so treat it as the group describing itself. Since the MSU post, ransomware.live shows BYOD has also listed IHG Hotels & Resorts, on November 4.

The pattern the group claims is worth testing in your own environment: steal a working login, find where MFA is missing, then use the directory and SSO to reach everything else.

What to check

1. Hunt in the identity provider log, starting weeks before the first sign of trouble. In the Okta System Log, filter on these event types with queries such as eventType eq "user.mfa.factor.activate":

• user.mfa.factor.activate, user.mfa.factor.deactivate and user.mfa.factor.reset_all: a factor enrolled or removed on a user, the classic sign of an attacker adding their own phone.
• system.mfa.factor.deactivate: an admin turning off an MFA factor for the whole org.
• security.threat.detected: requests from IPs Okta ThreatInsight flags for password spraying or brute force.
• user.session.start with a failure outcome, grouped by source IP, to spot spraying against many NetIDs.
• user.account.reset_password outside your planned reset, to see who reset accounts and from where.

2. Clear existing sessions after the reset. In Okta, go to Directory, People, select the user, then More Actions and Clear User Sessions. In Entra ID, Revoke-MgUserSignInSession -UserId <id> revokes refresh tokens. For accounts you believe are compromised, Microsoft recommends resetting the on-premises Active Directory password twice to cut off pass-the-hash use. Then sign users out of applications that keep their own sessions, such as the learning management system or student records portal.

3. Look at the VPN and Windows logons separately. A credential that reached the VPN may have reached the internal network. Compare successful VPN logins after the reset date with the devices and source addresses each account normally uses. Accounts with no MFA factor enrolled are the first to review, since that is the gap BYOD says it looks for.

4. Watch the leak sites yourself. Ransomware.live recorded the MSU post within hours. Set an alert on trackers like it for your institution's name, your hospital and your main suppliers, so you hear about a listing before reporters call.

5. Know your notification clocks before a claim lands. Michigan's Identity Theft Protection Act (MCL 445.72) requires notice to residents "without unreasonable delay", with an exception where the breach is not likely to cause substantial loss, injury or identity theft. Schools in federal student aid programs have been told by the Department of Education that their Student Aid Internet Gateway (SAIG) agreement requires reporting actual and suspected breaches on the day they are detected or suspected; check the current Federal Student Aid guidance. University health units also fall under the HIPAA 60-day rule set out in our UNM post.

The wider lesson for identity teams

MSU forced a reset of every account on October 1, and it is facing an extortion claim a month later. Whether or not the two are connected, a mass reset starts the response. The record of who logged in, from where and with which factor in the weeks before it is what shows whether data left. Check your Okta or Entra log retention today: if it is shorter than the window you would need to investigate, export it to a store you control.

Our security operations team hunts for factor changes and session abuse like the events above, and our on-demand risk reduction work finds the accounts and VPN paths that still lack MFA. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: The Record, MSU service status notice, The State News, WWMT via Mid-Michigan NOW, ransomware.live: Michigan State University, ransomware.live: BYOD, MSU IT: resetting a NetID password, MSU SecureIT passwords, The Register on Trump Mobile, IBTimes on Trump Mobile, Microsoft: revoke user access in Entra ID, Okta: revoke all user sessions, Okta event types, Microsoft on Lumma Stealer, Michigan MCL 445.72, Davis Wright Tremaine on Michigan's breach law, NASFAA: ED cybersecurity FAQ, Campus Technology on ED breach reporting.