Passkey Lures, a Broken SSO Trust and One Stored Password: Why Every Credential Is an Attack Surface

Week of 14 September 2026 | Compiled by Team Paringa

Three incidents in one week, three different identity controls, one common failure: in each case the attacker did not break the authentication, they borrowed the artefact it produced.

What Happened This Week

🔴 Microsoft: passkey-themed vishing feeds AiTM and device-code phishing, then a slow drain of Microsoft 365

Microsoft published research on 11 September attributing a wave of Microsoft 365 data theft to actors it tracks as Storm-3121 (linked to ShinyHunters and the Falcon extortion brand) and Storm-3032 (former BlackFile members now operating as Helix), overlapping with Google's UNC6671 cluster. Active since May 2026, the playbook starts with open-source research on the target's org chart, then a phone call or SMS from "corporate IT" telling the employee they must urgently update a passkey, MFA or SSO setting or lose access. Registered lure domains include passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com and oktasession[.]com, usually with the victim company's name as a subdomain.

The passkey framing is a decoy. Microsoft is explicit that the attackers are not enrolling passkeys. The link goes to an adversary-in-the-middle proxy that relays the real Microsoft login, captures the credential and the resulting session token, or to a device-code flow where the victim types an attacker-supplied code into Microsoft's own legitimate authentication page. The device-code route issues a token to an attacker-controlled OAuth application with no further MFA challenge, and that token reaches every SSO-connected application: Salesforce, Google Workspace, Slack, Atlassian, SAP and the rest.

Inside the tenant the activity is methodical. In one case Microsoft watched a session from an unmanaged device stay live for about an hour while the attacker walked My Apps, My Sign-Ins, Approval Management, SharePoint and virtual desktop flows to map what the account could reach. Persistence comes from registering a new phone number, authenticator app or software OTP token so future MFA prompts are answered by the attacker. Microsoft Graph enumeration follows (users, groups, directory roles, registered auth methods, OAuth grants, SharePoint sites, mail folders), then automated collection using python-httpx against SharePoint, OneDrive and Exchange REST. Exfiltration is throttled to fewer than 1,000 files or emails per hour and stretched across hours or days to blend with normal usage. Microsoft's mitigation list is the familiar one: phishing-resistant MFA, managed-device restrictions, disable device-code flow where unused, and on compromise revoke all sessions and tokens and force re-registration of every authentication method.

Sources: BleepingComputer, SecurityWeek

Read Microsoft's own remediation advice carefully: revoke tokens, reset credentials, remove attacker-registered MFA methods, re-enrol the user. Every step is about cleaning up artefacts the identity platform created. The attackers never defeated the MFA; they stole the session token it issued, or they used Microsoft's legitimate device-code page to have a token issued to them directly. That is the structural weakness of any scheme, Entra or Okta, whose output is a bearer token that lives in a browser and can be relayed. Recommending "phishing-resistant MFA" as the fix for a campaign that uses phishing-resistant MFA as the lure should give IAM leads pause. Credential-free authentication, where no reusable password, OTP or long-lived token exists to be proxied, removes the artefact rather than the attacker's motivation. If your Entra tenant still has device-code flow enabled by default, that is the first thing to turn off this week.

🟡 Brevo SSO scoping flaw: one attacker-controlled identity provider, 138 accounts, 347,000 phishing emails

Marketing platform Brevo disclosed that an attacker created a Brevo account, enabled SAML single sign-on on it, invited legitimate Brevo users into that SSO configuration and then, using the attacker's own identity provider, signed in as those invited users. Brevo notes this is expected SSO behaviour. The flaw was in scoping: instead of limiting the attacker to the one organisation where SSO was enabled, Brevo granted access to every organisation those users could reach. That gave the attacker 138 accounts, contact exports from 43 of them, and the ability to send email as six customers.

One of those six was hardware wallet maker Trezor, which told customers on 10 September that 347,000 email addresses received a phishing message headed "Critical Security Alert: STM32 Entropy Vulnerability" linking to a site that asked for wallet backup phrases. Around 2,500 people clicked in the 20 minutes before the site was taken down. BitBox and CoinTracking appear to have been hit through the same route. It is Trezor's second third-party incident in a month after its shipping provider ShipMonk exposed data on roughly 81,000 customers.

Sources: SecurityWeek, The Register

This is federation working exactly as designed and still producing a breach, because the trust decision (which IdP is allowed to assert which users into which tenant) was made once at configuration time and never re-checked at login. Any SaaS platform your organisation federates into has a version of this scoping logic, and you do not control it. The 20-minute window between send and takedown, with 2,500 clicks inside it, is also a reminder that phishing awareness is not a control at scale. The defensible position is authentication that cannot be replayed even if the assertion path is abused: bind the login to the person and the device at the moment of the request, and issue nothing that a third party's misconfigured SSO can hand to someone else.

🟡 Florida DMV and Veradigm: one stored credential, one vendor API key, millions of records

The Florida Department of Highway Safety and Motor Vehicles confirmed on 11 September that its DAVID driver database, holding licence, address and vehicle records for the state's drivers, was breached on 4 September. The entry point was a single set of credentials belonging to a Plant City Police Department user, "improperly stored on the employee's personal electronic device". ShinyHunters, which claimed the attack and says it pulled more than 200,000 records including a screenshot of Jeffrey Epstein's file, tells a different story involving a password-reset flaw; FLHSMV has not confirmed the volume taken.

Two days earlier, healthcare software provider Veradigm (formerly Allscripts) told the SEC that an attacker used credentials obtained from a third-party vendor's environment to reach a customer-services API and copy patient data including Social Security numbers. The Gentlemen ransomware group claims 3.5 million patient records and set an 11 September leak deadline. Veradigm's filing stresses the credential only reached "that limited interface", which is true and also beside the point: the interface held the data.

Sources: BleepingComputer, BleepingComputer

Neither breach involved a sophisticated bypass. A password sat on a personal device; an API credential sat in a vendor's environment. Both were copied and replayed, and the systems on the other end could not tell the difference between the owner and the thief because a static credential carries no proof of who is presenting it. Your vendors, contractors and partner police forces will keep storing secrets badly; you cannot train that away. What you can change is whether a copied secret is worth anything, which means moving the accounts that touch regulated data onto authentication that has no static secret to copy. Start with third-party and API access, because that is where your controls are weakest and this week's attackers went first.

What CISOs and IAM Leads Are Dealing With

The three stories describe three different identity architectures failing in the same way. Modern MFA in Microsoft 365 produced a session token that was relayed. Federated SSO at Brevo produced an assertion that was scoped too widely. Legacy passwords and API keys at Florida DMV and Veradigm were simply copied. In every case the authentication event succeeded; what failed was the assumption that the artefact it produced would only ever be presented by its rightful owner. Attackers have stopped attacking the login and started collecting its outputs, whether by proxy, by federation abuse or by finding them on a personal phone.

That reframes the IAM roadmap. Adding a stronger factor to a scheme that still issues a stealable credential moves the theft one step later in the flow; Microsoft's own advice to disable device-code flow is an admission that the platform's convenience paths are now attack paths. The organisations best placed for the next quarter are the ones asking a different question: not "how strong is our MFA" but "what does our authentication leave behind that an attacker could use". Credential-free authentication answers that with "nothing", and this week is a good argument for making it the design goal rather than the aspiration.

Three Things Worth Watching Next Week

1. Device-code flow defaults - Microsoft's advice to disable device-code authentication where not needed will trigger tenant reviews. Expect follow-on reports of how many enterprises still have it on by default and how many OAuth apps have been granted access this way.

2. Brevo's downstream customers - BitBox and CoinTracking have not yet named Brevo or quantified impact. More of the 43 accounts whose contact lists were exported are likely to disclose, and the SAML scoping pattern deserves a check against every SaaS platform you federate into.

3. ShinyHunters' identity playbook - The same crew is behind the Microsoft 365 vishing, the Florida DMV breach and the ReliaQuest attempt. Their next disclosure will show which identity control they targeted, and it is unlikely to be the login page.

Questions? hello@paringa.ai

Paringa's Track A AUTHENTICATE layer replaces stealable credentials with credential-free, phishing-resistant authentication that issues nothing an adversary-in-the-middle can relay. We work with CISOs and IAM leads who have concluded that a stronger factor is not the same as a safer one. | 14 September 2026 | © Paringa Ltd