Activision’s December 2022 workforce breach began with company-confirmed SMS phishing of an employee that produced unauthorized access to internal systems. According to BleepingComputer, Activision said its information security team addressed the SMS phishing attack on December 4, 2022; secondary reporting described an employee Slack foothold used for further internal phishing. Closing that phishable login with phishing-proof, device-bound MFA stops the credential harvest. Once a workforce session already exists, revoke and containment remain separate. For the full attack-chain narrative, read the companion on legacymfa.sucks.
FAQ
Would phishing-proof MFA have stopped Activision’s SMS phishing login path?
Yes for the credential harvest that opens the door. The Activision incident started when SMS phishing of an employee yielded unauthorized access to workforce systems, with secondary reporting describing Slack account access afterward. Phishing-proof MFA 2.0 removes transferable secrets a text lure can collect: there is no password, OTP, SMS code, or push approval to type or approve for the attacker. Device-bound, origin-bound signatures never leave enrolled hardware, so a smished link cannot complete a reusable login into corporate apps. Public reporting does not establish which factors Activision had enrolled in 2022, so this is prevention design, not a claim that MFA failed on a named mechanism at the company. The prevention model is stop the harvest, not detect it later.
Does MFA 2.0 undo a hijacked Slack session after Activision-style SMS phishing?
No. Once attackers already hold an authenticated Activision employee Slack session, as screenshots cited via vx-underground in BleepingComputer’s coverage indicated, login MFA does not kill that session or reverse contested data access. Containment is explicit session revocation, monitoring, and least privilege. Closing the phishable login stops this path. Malware after a legitimate login is a harder, separate problem. Public reporting does not establish a named post-auth token-theft technique beyond account access after the SMS phishing attack, and impact scope remains contested between Activision’s statement and press accounts.
Are passkeys enough against workforce SMS phishing like Activision’s?
Passkeys are phishing-resistant at the login ceremony because signatures bind to the real origin. That hardens many SMS phishing pages that only collect typed secrets. MFA 2.0 is phishing-proof across the identity lifecycle: registration, device onboarding, authorisation, authentication, and decommissioning use no phishable factor. If enrollment or recovery still depends on SMS codes or email OTPs, an attacker who controls those channels can enroll their own device and then look legitimate at login. For Activision-style workforce SMS phishing, phishing-resistant login helps at the form; full-lifecycle phishing-proof coverage is what closes the remaining gaps.
What should CISOs change after the Activision SMS-to-Slack path?
Treat SMS phishing as a credential-phase workforce problem first. Replace phishable passwords and approval factors with device-bound, phishing-proof authentication so a text message cannot mint a reusable corporate login. Assume a compromised chat identity may coach peers next, the same credential-harvest class as the original lure, and plan fast revoke for any session already open. Public reporting does not establish MFA deployment details, a named threat actor, or a quantified record count at Activision. Prefer identity controls that make the coached hand-off impossible over hoping every employee ignores the next SMS.
Why does legacy MFA still lose to workforce SMS phishing?
Legacy MFA still loses when the second factor is transferable: OTP, SMS code, email code, or push approval can be typed, read out, or approved under live coaching from a phishing page or message. Activision’s confirmed path was SMS phishing into workforce access; public reporting does not name which second factor, if any, was in play. Device-bound MFA 2.0 has no secret to relay and no prompt to fatigue, and adding a device requires an already-enrolled device rather than a phishable enrollment code. That is why the fix is prevention of social engineering of identity, not a training slogan about careful users.
