CNA Financial: Phishing Malware Harvested Sessions After Login

A single phishing email tricked a CNA Financial employee into running what looked like a browser update. The payload installed malware that harvested credentials and sessions from an already-authenticated workstation. Attackers then moved laterally, located valuable data, and deployed ransomware that ultimately led to a $40 million payment.

How the Initial Phishing Vector Bypassed Any Login Check

The attack opened with social engineering that placed code directly on the endpoint. No password, OTP, or push notification was involved at the moment the employee executed the fake update. Even a time-based OTP or push would not have stopped this attack.

Once the malware ran, it captured whatever sessions and tokens already existed on the machine. Those materials required no new authentication step, so any factor tied to the original login offered no protection. The ransomware operators used the stolen access to reach high-value targets and encrypt systems before demanding payment.

Device-Bound Credentials Close the Remote Theft Path

Device-bound credentials or keys remove the ability to harvest a usable factor through phishing or proxying. Because the private key never leaves the enrolled hardware, malware on the endpoint can only obtain whatever the operating system already exposes — cookies, tokens, or memory-resident material. It cannot extract a key that was never present in software-readable storage.

This property narrows the attack surface to a pure endpoint problem rather than an identity problem solvable through remote social engineering. The CNA Financial incident began with exactly that remote vector. A fresh signature demand on every interactive request would have rendered harvested sessions useless for later stages that still required authentication. This is where device-bound sessions and keys would have completely stopped the attackers in their tracks.

Passkeys Alone Leave Enrollment Exposed

FIDO2 and WebAuthn place the private key inside a hardware boundary such as a TPM or secure enclave and return only the public key to the server. Each signature is bound to the origin of the relying party, preventing replay on another domain. These mechanics protect the login ceremony itself.

They do not, however, govern how the key pair was first registered or how additional devices are added later. If an organisation still relies on email OTP, SMS codes, or push notifications to onboard a new device, an attacker who controls that channel can enroll their own hardware. The newly enrolled device then produces signatures the server accepts as legitimate. MFA 2.0 requires that no phishable factor appear at registration, device onboarding, authorisation, authentication, or decommissioning.

The same playbook hit other organizations in prior incidents. Device-bound keys close this replay path when the next login attempt actually occurs.

FAQ

Would device-bound credentials have prevented the CNA Financial initial compromise?

Device-bound credentials would have prevented the CNA Financial initial compromise from becoming reusable authentication material. The phishing email succeeded by delivering malware that harvested existing sessions; no new authentication occurred at the point of infection. A device-bound private key never present in memory or on disk would have left the attackers without a usable factor for subsequent interactive access.

Did the CNA Financial attackers abuse any federation protocol?

Public reporting on the CNA Financial ransomware attack does not indicate use of Golden SAML or other federation token forgery. The operators relied on stolen credentials and live sessions harvested from the compromised workstation.

How does full lifecycle protection differ from passkeys for enrollment?

Passkeys protect only the authentication step. Full lifecycle protection eliminates phishable factors at every stage of the identity lifecycle, including registration and device onboarding. An attacker who can intercept an email OTP used to add a new device can still register their own hardware even if login itself uses passkeys.

What made the CNA Financial breach different from typical ransomware incidents?

The CNA Financial breach began with a single phishing message that installed malware through a fake browser update. Once the payload executed, attackers operated with already-authenticated sessions rather than submitting fresh credentials that a second factor could have challenged.