Attackers Registered Their Own MFA Device After Phishing an SSO Code

A second documented variant of the campaign used a victim-branded phishing site: operators called employees, directed them to the site, captured single sign-on credentials and a multi-factor code, and then enrolled an attacker-controlled MFA device on the account.

A captured one-time code is worth one authentication and expires in seconds. Real-time relay phishing has been understood for years, and the mitigation — treat the session as compromised, force reauthentication — is well established.

Registering a new factor converts that momentary access into standing access. The attacker no longer needs the employee, no longer needs to intercept anything, and can authenticate independently whenever they choose.

A password reset does not remove it. Ending the session does not remove it. The account is now legitimately configured to trust a device the organisation does not know about.

Adding a device is the operation users perform when they get a new phone. It is designed to be easy, is usually available to any authenticated session, and rarely generates an alert anyone reads.

It is also, functionally, the granting of permanent authentication capability. The corpus records the same asymmetry elsewhere: the operation that establishes durable access is administratively trivial while the operation that removes it requires someone to notice.

Requiring a second, independent verification before enrolling a factor — or restricting enrolment to managed devices or trusted networks — would close this. It also strands users who genuinely lose a phone while travelling, which produces help-desk calls, which is where the campaign at 25-0806 started.

Every hardening measure here pushes load onto the recovery path, and the recovery path is the softest surface in this database.