Ivanti and SonicWall VPN Zero-Days Reveal Limits of Reusable Credentials
Zero-day flaws in Ivanti and SonicWall VPN appliances gave remote attackers unauthenticated shell access to edge devices. Once inside, operators extracted existing username-password pairs and session tokens directly from memory and configuration files, then replayed that material against VPN portals, jump hosts, and domain controllers. No additional user interaction or phishing was required because the stolen artifacts already satisfied every downstream authentication check.
The compromise spread quickly precisely because the initial vector bypassed the perimeter. Attackers did not need to intercept push notifications or one-time codes; they simply reused credentials and cookies already present on the network. Organizations that layered one-time codes or push notifications on top of passwords still lost access once the endpoint itself was under attacker control.
Why Credential Harvesting Produced Immediate Lateral Movement
After gaining a shell, the operators prioritized live credential extraction over new malware deployment. Passwords, tokens, and session cookies pulled from the compromised devices worked across multiple systems because authentication decisions continued to rely on reusable secrets that could be presented from any machine. This approach eliminated the need for persistence mechanisms or further social-engineering steps.
How One-Time Codes and Push Notifications Failed to Contain the Breach
Traditional MFA factors offered no additional protection once the endpoint was compromised. Session cookies bypassed subsequent challenges entirely, while push notifications could be approved by the legitimate user whose session had already been hijacked. The authentication flow never verified that the request originated from the specific enrolled device, allowing harvested material to satisfy every login attempt that followed.
Device-Bound Public-Key Credentials Alter the Outcome
Public-key cryptography generated and stored exclusively on the endpoint removes the reuse path. A private key is created on the device during onboarding and never leaves it; only the matching public key is registered with the identity provider. Each authentication request is signed locally, so the server can validate the signature against the enrolled key. An attacker who obtains passwords or session tokens still lacks the private key required to produce a valid assertion from a different machine.
This binding holds through enrollment, recovery, and decommissioning without introducing phishable fallback methods such as SMS or email. When VPN and remote-access systems enforce the model, a zero-day that grants shell access leaves attackers with material that cannot be used for further authentication.
MFA 2.0 implements exactly this approach: phish-proof, passwordless authentication built on public-key cryptography, the same technology underlying Apple Pay and Google Pay. Credentials remain bound to the device with no central database of secrets. Authentication occurs on the same device without requiring a second factor. The model is prevention-focused; the attack cannot succeed because no reusable credentials exist to compromise. It secures the full identity lifecycle rather than adding monitoring or anomaly detection after the fact.
Hardware tokens built on the same public-key principles can achieve similar protection only when they remain strictly device-bound and introduce no phishable recovery options. Many current deployments still allow TOTP or SMS fallbacks, recreating the exposure seen in this incident. In this scenario, attackers could still have exploited the zero-days to reach a shell. However, the harvested passwords and cookies would have been worthless for authentication because the required private key never existed on attacker-controlled systems.
