A username and a password were enough to start the Colonial Pipeline ransomware event, the Change Healthcare outage, and Midnight Blizzard's theft of Microsoft corporate email. Nobody relayed a code or fatigued a push prompt. The login path never asked for a second factor.
Password-only workforce portal breaches happen when a VPN profile, remote-access portal, support account, or test tenant still accepts a password alone on the path the attacker uses. Public sources document exactly that at Colonial Pipeline, Change Healthcare, PowerSchool, Microsoft, and Healthplex. Phishing-proof MFA 2.0 closes the gap by requiring a device-bound, origin-bound proof on every interactive workforce path, so a stolen or sprayed password cannot finish sign-in.
This rolling hub covers that coverage failure. It is not an AiTM story and not a helpdesk-reset story, because in these cases the second factor was missing, not stolen. The full incident analyses stay on their own pages: Colonial's legacy VPN profile, Change Healthcare's Citrix portal, PowerSchool's support portal, Midnight Blizzard's test tenant, and Healthplex's Outlook Web Access. If you want more detailed information about how these attacks unfolded, read the related post on legacymfa.sucks: how password-only workforce portals still fall.
Where a password alone still finished sign-in
According to Mandiant's Charles Carmakal, testifying to the House Homeland Security Committee on 9 June 2021, the earliest evidence of compromise at Colonial Pipeline was a VPN login on 29 April 2021 using a legacy VPN profile and an employee's username and password. The legacy profile did not require a one-time passcode.
UnitedHealth Group CEO Andrew Witty's written testimony, reported by BleepingComputer, says criminals used compromised credentials on 12 February 2024 to reach a Change Healthcare Citrix portal used for remote desktop access. "The portal did not have multi-factor authentication," Witty wrote. Ransomware followed nine days later.
A PowerSchool spokesperson confirmed to TechCrunch that the subcontractor account used to breach its customer support portal was not protected with MFA. Microsoft Threat Intelligence wrote that Midnight Blizzard's password spray compromised a legacy, non-production test tenant account that did not have MFA enabled. New York's financial regulator found in its Healthplex consent order that MFA was not enabled for Outlook Web Access when a phished employee's credentials were used in November 2021.
| Login path | What sources document | What the login opened |
|---|---|---|
| Colonial legacy VPN profile | Username and password, no one-time passcode | Network access before ransomware |
| Change Healthcare Citrix portal | Compromised credentials, no MFA | Lateral movement, data theft, ransomware |
| PowerSchool support portal | Subcontractor account without MFA | Student and teacher personal data |
| Microsoft test tenant | Password spray, MFA not enabled | OAuth apps, then corporate mailboxes |
| Healthplex Outlook Web Access | MFA not enabled after Office 365 move | Mailbox holding residents' personal data |
Everything after those logins is blast radius: encryption, exfiltration, OAuth abuse, mailbox reading. Authentication had already finished for the attacker when the password worked. Closing the phishable login stops this path. Malware after a legitimate login is a harder, separate problem.
Why coverage counts missed the breached account
Each of these organizations had MFA somewhere. PowerSchool told TechCrunch it uses single sign-on and MFA for employees and contractors, yet the subcontractor's support-portal account lacked it. Microsoft wrote that if the same team deployed that legacy tenant today, mandatory policy would ensure MFA was enabled. Healthplex had MFA on its previous email environment and, according to NYDFS, failed to make it fully operational for browser access after migrating to Office 365.
The pattern is exceptions: a legacy VPN profile nobody retired, a non-production tenant outside current policy, a subcontractor maintenance account, a migration that dropped a control. Coverage metrics that count enrolled users miss the one account an attacker actually tries. Midnight Blizzard's spray, Microsoft says, was tailored to a limited number of accounts with a low number of attempts to evade detection. That is how exceptions get found quietly.
How phishing-proof MFA 2.0 closes the single-factor door
Prevention here is a requirement, not a percentage: every interactive VPN, Citrix, webmail, support, test-tenant, and break-glass path must demand a proof the attacker cannot replay. The approach uses device-bound credentials built on public-key cryptography. The private key stays on enrolled hardware, and each sign-in produces a fresh signature bound to the real portal's origin. There is no password to spray or reuse from an infostealer log, and no one-time code a later kit can relay.
Factor quality matters as much as coverage. Adding SMS codes to a forgotten support account stops a password spray and still leaves a transferable secret for the next AiTM campaign. Passkeys and FIDO2 are phishing-resistant at login when required with no password fallback, which would have closed these single-factor doors. Phishing-proof MFA 2.0 extends that across the identity lifecycle, including how subcontractor and support accounts are registered, onboarded, and decommissioned.
| Control | Against stolen or sprayed password | Against later code relay |
|---|---|---|
| Password only | Fails immediately | Not applicable |
| Password plus OTP or push | Stops spray | Code or approval relayed |
| Passkeys required at login | Stops spray | Origin-bound, resists relay |
| Phishing-proof MFA 2.0 | No password on that path | No transferable factor |
The fix starts with an inventory and ends with a rule: no workforce path survives on a password alone. Start at prevention, not detection.
Key takeaways for defenders
- Treat VPN profiles, Citrix and remote-desktop portals, webmail, IdP test tenants, and vendor support portals as production identity with no password-only survivors.
- Retire legacy VPN profiles and non-production tenants, or bring them under the same authentication policy as production.
- Re-verify authentication on every path after a migration, as Healthplex's Office 365 move shows.
- Require subcontractor and maintenance accounts to use the same phishing-proof sign-in as employees.
- Measure MFA coverage per login path, not per enrolled user.
FAQ
Would phishing-proof MFA have stopped the Colonial Pipeline and Change Healthcare initial logins?
Phishing-proof MFA 2.0 would have stopped the initial logins at Colonial Pipeline and Change Healthcare, because both paths accepted a password alone according to public testimony. A device-bound, origin-bound signature requirement means a stolen password cannot finish VPN or Citrix sign-in, so the later ransomware never gets that first session.
Is a password-only breach the same failure as AiTM phishing against MFA?
A password-only breach is not the same failure as AiTM phishing. In the Colonial, Change Healthcare, PowerSchool, Microsoft test tenant, and Healthplex cases, the breached path never required a second factor. AiTM phishing relays a second factor that did exist. Both are credential-phase failures, and the honest description of each is different.
What do Microsoft's test tenant and PowerSchool's support portal have in common?
Microsoft's Midnight Blizzard test tenant and PowerSchool's customer support portal were both exceptions to the organization's own MFA posture. Microsoft said current policy would have enforced MFA on a newly deployed tenant, and PowerSchool said it uses MFA for employees and contractors. The breached accounts sat outside those rules.
Are passkeys enough on VPN and Citrix portals like Change Healthcare's?
Passkeys required with no password fallback would have closed the single-factor door on a Citrix portal like Change Healthcare's, because they are phishing-resistant at login. They do not cover how accounts are enrolled, recovered, or handed to subcontractors. Phishing-proof sign-in across the full identity lifecycle covers that, which matters because support and maintenance accounts usually escape policy.
Which workforce paths should CISOs check first after the Change Healthcare breach?
After the Change Healthcare breach, CISOs should first check every internet-facing remote access path: VPN profiles, Citrix and remote-desktop gateways, and webmail. Next come IdP test and break-glass accounts and any vendor support portal that can reach customer data. Confirm a phishing-proof proof is enforced on each account, not just on the average employee.
Updates
2025-01-17: Named victim reporting
A PowerSchool spokesperson confirmed to TechCrunch that the subcontractor account used to breach PowerSchool's customer support portal was not protected with multi-factor authentication.
Source: TechCrunch, Malware stole internal PowerSchool passwords
2024-02-12: Named victim testimony
UnitedHealth Group's CEO said in written congressional testimony that criminals used compromised credentials on 12 February 2024 to access a Change Healthcare Citrix portal that did not have multi-factor authentication.
Source: BleepingComputer, Change Healthcare hacked using stolen Citrix account with no MFA
2024-01-25: Vendor disclosure
Microsoft Threat Intelligence documented that Midnight Blizzard's password spray compromised a legacy non-production test tenant account without MFA, then abused OAuth applications to reach corporate mailboxes.
Source: Microsoft Security Blog, Midnight Blizzard guidance for responders
2021-11-24: Regulator finding
NYDFS found that MFA was not enabled for Healthplex's Outlook Web Access after an Office 365 migration, so an attacker with a phished employee password reached the mailbox through a browser.
Source: NYDFS, Healthplex consent order
2021-05-07: Named victim testimony
Mandiant's Charles Carmakal testified that the earliest Colonial Pipeline compromise evidence was a 29 April 2021 VPN login with a legacy profile and an employee's username and password, with no one-time passcode required.
Source: House Homeland Security Committee, Carmakal prepared statement
