According to GuidePoint Security around 27 August 2024, GRIT documented a US workforce campaign that targeted more than 130 organizations. Callers posing as IT or helpdesk texted SMS links to fake Cisco, Fortinet, or Palo Alto VPN login pages, harvested usernames and passwords with MFA one-time codes, and coached push approvals live on the phone. Phishing-proof MFA 2.0 stops that harvest because a fake portal is the wrong origin and there is no password, OTP, or push prompt left to coach. For the full attack-chain narrative, read the companion on legacymfa.sucks.

FAQ

Would phishing-proof MFA 2.0 have stopped the GuidePoint GRIT VPN harvest?

Yes. The GuidePoint GRIT campaign stole workforce credentials at attacker-controlled fake VPN login pages under a live helpdesk pretext: usernames, passwords, MFA one-time codes, and coached push approvals. MFA 2.0 is phishing-proof, device-bound authentication. There is no transferable secret to type into a spoofed portal and no approve-prompt a caller can pressure the employee to complete. Closing that phishable VPN login stops this path.

Why do OTP and push MFA still lose to a helpdesk-styled vishing call?

OTP and push lost in the GuidePoint GRIT wave because both remain transferable under live coaching. The employee typed a one-time code on a fake Cisco, Fortinet, or Palo Alto-looking page, or approved a push while still on the phone. Password plus phishable MFA is satisfied for the attacker the moment the victim complies. Phishing-proof MFA 2.0 removes those surfaces. The case against legacy MFA is exactly this class of coached factor transfer.

Are passkeys enough for this VPN path, or do you need phishing-proof MFA 2.0?

Passkeys are phishing-resistant at the login ceremony when origin binding holds, which already beats OTP and push on a fake VPN page. MFA 2.0 is phishing-proof across the identity lifecycle, so enrollment and device onboarding also avoid phishable factors. Public reporting on the GuidePoint GRIT campaign does not show TAP issuance or helpdesk re-enrollment. The documented failure was transferable VPN login factors. Full-lifecycle coverage still matters so a later recovery path cannot reopen the same social-engineering class. The device-bound architecture keeps private keys off the network for that login path.

If a password and OTP were already harvested, does MFA 2.0 undo VPN access?

No login MFA undoes access that already completed on a real VPN after stolen credentials were replayed. For the GuidePoint GRIT campaign, public reporting does not establish reverse-proxy AiTM kits, stolen session cookies, or confirmed real-VPN session completion. The prevention claim is upstream: phishing-proof MFA 2.0 stops the fake-portal harvest so the attacker never holds usable credentials or coached second-factor material. Revoke stays hygiene if malware later lands on a machine that already holds a legitimate session. Fooling a user into a fake VPN login is easy. Planting malware is not.

What should CISOs change on workforce VPN authentication after this campaign?

CISOs should drop passwords, SMS or app OTPs, and push approvals from workforce VPN paths and require device-bound, origin-bound signatures instead. Helpdesk-styled callers in the GuidePoint GRIT campaign succeeded because employees could still type secrets and approve prompts under social pressure. With MFA 2.0 there is nothing useful to type on a spoofed portal and no prompt to approve on the phone. Keep staff guidance that IT never texts VPN login links, and keep revoke ready for true endpoint compromise after a legitimate login.