Cisco MFA fatigue vishing opened VPN access

According to [Cisco Talos](https://blog.talosintelligence.com/recent-cyber-attack/) on 10 August 2022, Cisco’s 2022 corporate-network incident began when an attacker took Cisco credentials synced from an employee’s browser into a compromised personal Google account, then ran MFA fatigue and multi-day voice phishing until a push was accepted. That acceptance granted VPN access as the targeted user. The attacker enrolled new MFA devices, moved laterally, and exfiltrated one employee Box folder plus Active Directory authentication data.

According to Cisco Talos on 10 August 2022, Cisco became aware of the compromise on 24 May 2022 after an attacker used browser-synced Cisco credentials from a personal Google account, then MFA push bombing and multi-day vishing impersonating trusted support, until the employee accepted a push. VPN access followed in that user’s context. The attacker enrolled a series of new MFA devices, escalated and moved laterally (including Citrix), reached domain controllers, dumped NTDS, and used tooling such as Cobalt Strike, Mimikatz, and Impacket. Confirmed exfiltration was limited to one employee’s Box folder contents and Active Directory authentication data. Cisco reported no evidence of access to critical product-development or code-signing systems. Talos assessed ties to an initial access broker linked to UNC2447, Lapsus$, and Yanluowang.

If you want the prevention angle, read the related article on mfa2point0.com.

FAQ

How did attackers get into Cisco’s VPN in 2022?

Attackers got into Cisco’s VPN in 2022 by first stealing the employee’s Cisco password from a compromised personal Google account where Chrome had synchronized saved browser credentials, then flooding MFA push requests and coaching the employee over multi-day vishing calls until one push was accepted. According to Cisco Talos, that acceptance granted VPN access in the context of the targeted user. Public reporting does not name a TAP, helpdesk reset, AiTM proxy, or device-code flow for this path.

Was this an MFA bypass or MFA fatigue?

The Cisco 2022 VPN path was MFA fatigue plus social pressure on push MFA, not a cryptographic break of the second factor. The attacker already held the password from browser sync, initiated a high volume of push notifications, and used sophisticated voice phishing under the guise of trusted support organizations to convince the victim to accept. Legacy approve/deny push is a transferable decision an attacker can spam and coach. Public reporting does not establish SIM swap, OTP seed theft, or a spoofed login page as the mechanism here.

What role did vishing play after the password was stolen?

Vishing in the Cisco 2022 incident was multi-day coaching to obtain MFA push acceptance after the password was already in attacker hands. Cisco Talos stated the attacker conducted sophisticated voice phishing attacks purporting to be from various trusted organizations, with callers speaking English in various international accents, attempting to convince the victim to accept attacker-initiated MFA push notifications. The password alone was not enough. The live social engineering closed the gap that push MFA left open.

What happened after the first VPN login succeeded?

After the first Cisco VPN login succeeded, the attacker enrolled a series of new MFA devices so later VPN authentications no longer needed fatigue or vishing. From that foothold they escalated privileges, moved laterally including via Citrix, reached domain controllers, dumped NTDS, and used Cobalt Strike, Mimikatz, Impacket, LogMeIn, and TeamViewer. Cisco Talos confirmed exfiltration of one compromised employee’s Box folder contents and Active Directory authentication data, and stated there was no evidence of access to critical internal systems such as product development or code signing. Weeks after eviction, failed re-entry attempts abused weak post-reset password hygiene, including single-character password changes, from Tor and later residential IPs. Public reporting does not establish a quantitative ransom figure or specific extortion demands in the post-eviction emails to executives.

Did MFA protect Cisco once the attacker was on the VPN?

MFA did not protect Cisco’s directory or Box data once the attacker already held a VPN session as the employee and had enrolled their own MFA factors. Push MFA was the gate at initial VPN login. After that gate opened, lateral movement, NTDS dumping, machine-account authentication, and limited exfiltration were post-authentication problems. Closing the phishable push-acceptance path stops this class of initial access. Malware-grade or in-network abuse after a legitimate session is a harder, separate problem. A fix for the fatigue and coached-acceptance class exists; the companion post covers prevention without replaying this chain.