Real-Time Hijacking: The Shift in Insurance Phishing Tactics
Just caught the CTM360 write-up regarding the shift in insurance sector phishing. We’ve moved past the days of simple credential harvesting. It looks like attackers are now automating the session hijacking process—effectively performing Man-in-the-Middle (MitM) attacks in real-time to bypass MFA.
Instead of stealing a username/password and trying to use it later (and getting blocked by MFA), they are using reverse proxy kits to intercept the session cookie immediately after the user authenticates. This allows them to maintain persistence without ever handling the 2FA code themselves.
From a detection standpoint, standard credential stuffing alerts won't catch this. We need to look for anomalies in the authentication flow itself. I've been tuning our Sentinel rules to flag impossible travel or device/browser inconsistencies during the same session ID.
Here is a basic KQL snippet I’m testing to catch rapid geographic changes on successful sign-ins that might indicate a proxy relay:
SigninLogs
| where ResultType == 0
| extend City = tostring(LocationDetails.city),
State = tostring(LocationDetails.state),
Country = tostring(LocationDetails.countryOrRegion)
| summarize TimeGenerated = max(TimeGenerated), Locations = make_set(City) by UserPrincipalName, AppDisplayName
| where array_length(Locations) > 1
| project UserPrincipalName, AppDisplayName, Locations
Are you seeing similar patterns in your telemetry, or are you relying more on device compliance policies to filter out these proxy connections?
We started seeing this pattern in our finance sector clients last quarter. The biggest differentiator for us was the User-Agent string mismatch—browsers reporting Chrome on iOS, or generic automation headers.
We pushed hard for FIDO2/WebAuthn hardware keys for our high-value targets. Phishing-resistant MFA is really the only way to kill the session cookie theft vector entirely. Conditional access based on network location is too porous when the attacker is relaying through the victim's actual IP.
It’s terrifying how easy these kits are to deploy now. You don't need to be a skilled dev to spin up a reverse proxy; they come with pre-configured templates for major insurers and banks.
I've found that analyzing TLS fingerprinting (JA3/JA4) helps spot the intermediate proxy, but attackers are getting better at spoofing that. The CTM360 report highlights how fast they automate the account takeover—sometimes within seconds of the user clicking 'login'.
Spot on. Beyond User-Agents, analyzing TLS fingerprinting (JA3) has been a game-changer for us. These reverse proxy kits often spoof the browser headers but fail to perfectly mimic the underlying TLS handshake, creating a mismatch.
We've been flagging sessions where the JA3 hash doesn't align with the expected browser signature. If you're extracting PCAPs, you can use this Python snippet to verify the hash:
import ja3
# Assuming 'raw_handshake' is your TLS client hello data
print(ja3.compute(ja3.get_hello(raw_handshake)))
Has anyone had success pushing FIDO2 keys to effectively neutralize this threat vector?
To complement the TLS and User-Agent analysis, we've started focusing on the hosting infrastructure. These reverse proxy kits rarely operate from residential IPs; they pop up on cheap VPS providers. Identifying traffic from datacenter ASNs where you expect residential traffic is a strong signal.
We use a KQL query similar to this to surface anomalies:
SigninLogs
| where Result == "Success"
| evaluate ipv4_lookup(NetworkDetails, IPAddress, NetworkIP, NetworkPrefix)
| where ISP contains "Hosting" or ISP contains "DataCenter"
| summarize count() by AppDisplayName, IPAddress
Agreed, Chris. Since these domains are often ephemeral, monitoring Certificate Transparency logs is a great proactive step. We run daily searches for newly issued certificates containing target brand keywords. Catching the domain during the setup phase allows for takedown before the campaign launches. Here is a query we use:
curl "https://crt.sh/?q=%.target-brand.com&output="
Pairing this with rapid reporting helps blunt their impact significantly.
Excellent breakdown on TLS and infrastructure. One distinct signal we monitor is browser automation inconsistencies. Even if headers are spoofed, the JavaScript environment often exposes the reverse proxy. Specifically, look for navigator.webdriver returning true or an empty navigator.plugins list, which indicates a headless browser rather than a legitimate user session.
You can automate a check for this property using a simple Selenium or Playwright script during analysis:
# Python/Selenium check for webdriver property
if driver.execute_script("return navigator.webdriver;"):
print("Headless browser detected - likely reverse proxy")
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access