Stolen logins opened at least 165 organizations' cloud data (2024) and what it shows about passwords people know

A US software-as-a-service (SaaS) provider let organizations store data in its cloud. In 2024, attackers targeted the provider and its customers, at least 165 organizations in all, with stolen login credentials. They signed in to the customers’ data, viewed and downloaded terabytes of records, then demanded ransoms. A federal indictment filed October 10, 2024, and a plea agreement filed August 5, 2026, describe the scheme. Signing in with someone else’s stolen password is the kind of act the federal anti-hacking law covers; see Password sharing and the federal anti-hacking law (CFAA).

What happened

The provider’s software let organizations upload and store data in cloud storage areas the plea agreement calls instances. Only users the customer organization authorized were meant to reach them. Each user had their own account and their own permissions within the instance.

According to the plea agreement, the scheme began no later than February 2024 and ran until at least October 10, 2024. The attackers “stole or otherwise obtained stolen access credentials” for the customers’ instances. They used them to sign in, then viewed and downloaded terabytes of private data. At least some of the credentials belonged to real people. One count of the indictment lists the item used as a “Username and password of a real person.”

The attackers also wrote a program that read organization names, user roles and network addresses from inside the instances. They used it to pick which instances held data worth stealing. The data included call and text history records, banking and payroll records, driver’s license and passport numbers, and Social Security numbers. Victims included large telecommunications, retail and healthcare companies.

The plea agreement says the attackers extorted at least 36 bitcoin, worth about $2.5 million at the time, from at least three victims. The victim companies lost more than $9.5 million, counting ransoms and the cost of responding.

The cause the record states

The court records say the logins were stolen or otherwise obtained. They don’t say where the passwords were taken from, how, or which sign-in checks the accounts had.

The record does show the path. The attackers signed in as users, with logins that worked. Each user had their own permissions, so a stolen login gave the attackers whatever that user could reach.

Corrective steps

The court records describe the criminal case. They don’t describe changes made afterward by the provider or by its customers.

Controls usually expected after incidents like this

A password works for whoever has it. The controls for this type aim to make a stolen password useless, or to make it obvious when someone uses one.

NIST’s authentication guideline, SP 800-63B-4, covers the password itself. Section 3.1.1.2 says new passwords must be checked against a blocklist of “commonly used, expected, or compromised” ones. It says a system must force a change when there is evidence a password has been compromised. A password used on its own must be at least 15 characters.

The FTC Safeguards Rule, for covered financial institutions, covers what stands behind the password. It requires multi-factor authentication (MFA) “for any individual accessing any information system” (16 CFR 314.4(c)(5)). MFA means a second proof beyond the password, such as a code from an authenticator app. The rule also requires monitoring and logging of what authorized users do, so that unauthorized access or use can be detected (314.4(c)(8)). The rule doesn’t list what to watch for. With a stolen password there are no failed logins to see, so the useful signals are large downloads and sign-ins from new places.

How a second sign-in step works on accounts several people use is covered in What is two-step verification?. How FTC complaints describe login failures is in Which password and shared-login failures has the FTC called unreasonable?.

Questions to ask about your own setup