For years, phishing campaigns targeting financial institutions followed a predictable playbook: trick victims into entering their username and password on a fake site, collect the credentials, and attempt account access later when an opportunity arose. Multi-factor authentication largely neutralized this approach — stolen credentials alone were no longer sufficient.
That model is changing. Research published by CTM360 on July 25, 2026 documents how insurance and financial portal phishing has evolved into a real-time operation that defeats MFA entirely.
The Old Model vs. The New Model
The traditional phishing-for-credentials approach had a fatal weakness from the attacker's perspective: time. Between when credentials were stolen and when the attacker attempted to use them, the victim might change their password, the organization might detect the breach, or MFA would block the login attempt outright.
Modern AiTM (Adversary-in-the-Middle) phishing eliminates the delay:
Old model: Victim submits credentials → attacker collects them → attacker attempts login later → MFA challenge blocks access
New model: Victim connects to attacker's proxy → proxy forwards everything to the real portal in real time → victim completes MFA → proxy captures the live session token → attacker instantly replays the session token to access the account
The session token — the cookie or bearer token that proves authentication has already been completed — is what makes MFA work. By sitting between the victim and the legitimate service, the AiTM proxy captures this token at the moment it is issued, when MFA has just been successfully verified.
How Insurance Portals Are Targeted
CTM360's research focuses specifically on the insurance sector, which has become a high-value target for this class of attack. Insurance portals offer access to:
- Policyholder account details including beneficiary information
- Payment and banking information for premium collection or claims disbursement
- Claim submission capabilities that can be fraudulently used
- Policy modification tools that can be abused to change coverage, beneficiaries, or contact information
Attackers create highly convincing clones of specific insurance carrier portals, complete with carrier-specific branding, logos, and even custom lure emails that reference the victim's actual insurer. The lures reference common trigger events: policy renewal notices, premium payment reminders, claim status updates, or account verification requests.
The Proxy Infrastructure
The technical backbone of these campaigns relies on purpose-built adversary-in-the-middle frameworks. CTM360 identified the use of:
- EvilProxy: A commercial phishing-as-a-service platform that provides reverse proxy infrastructure and session token harvesting
- Evilginx2: An open-source AiTM framework originally developed for penetration testing, now widely adopted by threat actors
- Custom frameworks: Attacker-developed proxies tailored to specific insurance carrier portals
These tools operate by acting as a transparent reverse proxy. The victim connects to the phishing domain, and every request and response is forwarded to and from the real insurance portal. From the victim's perspective, the site looks and functions exactly like the real thing — because it essentially is, just with every bit of traffic passing through the attacker's infrastructure first.
Why Common MFA Fails
This approach defeats the most widely deployed MFA methods:
| MFA Type | Why It Fails Against AiTM |
|---|---|
| SMS OTP | Victim enters the code through the proxy — proxy forwards it |
| TOTP (authenticator apps) | Same as SMS — time-valid codes are relayed in real time |
| Email OTP | Intercepted and forwarded by the proxy |
| Push notification approval | Victim approves the real push — proxy gets the session |
The common thread: any MFA factor that can be presented through a browser session can be relayed through an AiTM proxy, because the proxy is acting as the victim's browser from the server's perspective.
What Actually Works
The only MFA methods that remain effective against AiTM attacks are those that cryptographically bind the authentication to the exact domain and device:
FIDO2 / Passkeys
FIDO2 hardware security keys and passkeys (device-bound passkeys using platform authenticators) are cryptographically tied to the legitimate origin domain. When a FIDO2 authenticator generates a response, it signs a challenge that includes the relying party identifier — the exact domain of the site being authenticated to.
An AiTM proxy operating from fake-insurer-portal.com cannot produce a valid FIDO2 assertion for portal.realinsurer.com. The authentication will fail at the server, not at the victim — making the entire AiTM interception useless.
Session Binding
Some organizations implement additional mitigations at the session level: binding session tokens to the originating IP address or device fingerprint so that a token captured from one location cannot be replayed from another. This adds friction to AiTM attacks even when session tokens are captured.
Recommendations
For individuals:
- Treat any unsolicited insurance-related email link with high suspicion. Navigate directly to your insurer's portal by typing the URL.
- Verify the domain and certificate issuer carefully before entering credentials.
- Request FIDO2 or passkey authentication from your insurance providers where available.
For insurance and financial organizations:
- Accelerate migration from TOTP/SMS MFA to FIDO2/passkeys for portal authentication.
- Implement anomalous session detection: flag sessions where the IP address, geolocation, or device fingerprint changes abruptly after login.
- Deploy token binding or short-lived session tokens with re-authentication requirements for high-risk actions (policy changes, payment updates).
- Monitor for phishing infrastructure mimicking your brand — dark web and certificate transparency log monitoring can provide early warning.
The Broader Trend
CTM360's findings reflect a broader maturation in the phishing-as-a-service ecosystem. AiTM toolkits that once required significant technical expertise are now available as commercial services, lowering the barrier for less sophisticated threat actors to run real-time session hijacking campaigns. The insurance sector's combination of high-value accounts, relatively slow MFA modernization, and large volumes of policyholder data makes it an increasingly attractive target.
Organizations still relying on SMS or TOTP as their primary MFA factor should treat this research as a signal to accelerate their FIDO2 adoption roadmaps.