Real-Time Insurance Account Hijacking: Defending Against AiTM Social Engineering

The traditional model of credential harvesting—tricking a user into divulging credentials and storing them for future use—is effectively obsolete in high-value verticals like insurance. Recent investigations by CTM360 reveal a sophisticated evolution: attackers are now executing real-time account hijacking.

Instead of simply stealing username and password combinations, these campaigns employ Adversary-in-the-Middle (AiTM) techniques. By proxying the victim's authentication session through a rogue server in real-time, attackers intercept not just credentials, but the session cookies or multi-factor authentication (MFA) tokens issued immediately after login. This allows them to bypass MFA controls and gain unrestricted access to insurance portals, claims data, and financial systems instantly. Defenders can no longer rely on password strength or standard MFA to stop these intrusions; we must detect the behavioral anomalies of a proxied login session.

Technical Analysis

Threat Vector: Social Engineering -> Reverse Proxy Phishing (AiTM) -> Session Hijacking.

Affected Platforms: Cloud-based SaaS platforms heavily utilized by the insurance sector (e.g., Microsoft 365, Salesforce, custom insurance portals).

Mechanism of Action:

Lure: Targets receive highly personalized spear-phishing messages mimicking policy renewals or claims updates.
Proxy: The link directs the user to a malicious site that acts as a reverse proxy (e.g., using tools like Evilginx2 or modlishka).
Real-Time Relay: The victim enters credentials and interacts with the 2FA prompt. The proxy relays these credentials to the legitimate service in real-time.
Session Theft: The legitimate service issues a session cookie (e.g., SAMLAssertion, FedAuth). The proxy captures this token and passes it to the attacker.
Hijacking: The attacker injects the stolen session cookie into their own browser, bypassing the need for credentials or MFA entirely.

Exploitation Status: Confirmed active exploitation in the insurance sector. This is a logic abuse of authentication flows, not a software vulnerability, meaning no CVE exists to patch. The vulnerability lies in the reliance on shared secrets and cookie-based session management.

Detection & Response

Detecting AiTM attacks requires a shift from looking for "bad credentials" to looking for "impossible contexts." Since the credentials and MFA are technically valid, standard authentication logs will show a "Success." However, the context of that login is anomalous.

SIGMA Rules

These rules target the behavioral indicators of an AiTM session, specifically focusing on Entra ID (Azure AD) sign-ins where risk is present but the challenge was passed, and impossible travel scenarios.

YAML

---
title: Azure AD Successful Sign-in with High Risk Detected
id: a1b2c3d4-5678-90ab-cdef-1234567890ab
status: experimental
description: Detects successful sign-ins to Entra ID where risk events were detected but the sign-in was allowed, indicative of AiTM or MFA bypass.
references:
  - https://attack.mitre.org/techniques/T1557/
author: Security Arsenal
date: 2026/07/15
tags:
  - attack.credential_access
  - attack.t1557.002
logsource:
  product: azure
  service: signinlogs
detection:
  selection:
    ResultType|startswith: '0'
    RiskEventTypes_V2: '*'
    RiskLevelDuringSignIn: 'high'
  condition: selection
falsepositives:
  - Users traveling from new locations without device compliance
level: high
---
title: Azure AD Impossible Travel / Velocity Anomaly
id: b2c3d4e5-6789-01bc-def2-345678901234
status: experimental
description: Detects sign-ins from two geographically distant locations within a time window that makes physical travel impossible, suggesting a concurrent hijacked session.
references:
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/07/15
tags:
  - attack.initial_access
  - attack.t1078.004
logsource:
  product: azure
  service: signinlogs
detection:
  selection:
    RiskEventTypes_V2: 'impossibleTravel'
    ResultType|startswith: '0'
  condition: selection
falsepositives:
  - Users using VPNs that exit in different countries
  - Satellite connections with inconsistent IP geo-location
level: high
---
title: Windows Browser Spawning Shell via Social Engineering Hook
id: c3d4e5f6-7890-12cd-ef34-567890123456
status: experimental
description: Detects a browser process (Chrome/Edge) spawning cmd.exe or powershell.exe, often seen following a user clicking a malicious link attempting to launch a secondary payload or script.
references:
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/07/15
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
    Image|endswith:
      - '\powershell.exe'
      - '\cmd.exe'
      - '\wscript.exe'
  condition: selection
falsepositives:
  - Legitimate web application downloads launching installers
level: medium

KQL (Microsoft Sentinel)

This query hunts for successful MFA sign-ins that exhibit risk characteristics typical of AiTM attacks (e.g., anonymous IP addresses combined with device failures).

KQL — Microsoft Sentinel / Defender

SigninLogs
| where ResultType == 0
| where RiskDetail == "mcasImpossibleTravel" or RiskLevelDuringSignIn == "high"
| extend DeviceDetail = parse_(DeviceDetail)
| extend Browser = DeviceDetail.browser, OS = DeviceDetail.operatingSystem
| project TimeGenerated, UserPrincipalName, AppDisplayName, Browser, OS, IPAddress, Location, RiskEventTypes_V2, AuthenticationRequirement
| order by TimeGenerated desc

Velociraptor VQL

This artifact hunts for recent browser history modifications or suspicious cache files on the endpoint, which may help identify if a user interacted with a known phishing infrastructure or if processes spawned from the browser.

VQL — Velociraptor

-- Hunt for browser processes spawning shells or recent history access
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ 'chrome.exe' OR Name =~ 'msedge.exe'

-- Join with network connections to see active connections from browsers
SELECT Process.Pid, Process.Name, Process.CommandLine, Net.RemoteAddress, Net.RemotePort
FROM pslist() AS Process
JOIN netstat() AS Net ON Process.Pid = Net.Pid
WHERE Process.Name =~ 'chrome.exe' OR Process.Name =~ 'msedge.exe'

Remediation Script (PowerShell)

This script assists in the immediate response phase by forcibly clearing cached credentials and web session tokens from a potentially compromised workstation, severing the attacker's active session if they are using pass-the-cookie techniques.

PowerShell

<#
.SYNOPSIS
    Incident Response: Clears browser cache, cookies, and credential manager entries for a specific user.
.DESCRIPTION
    Use this script on an endpoint identified as part of an AiTM campaign to invalidate
    locally stored session tokens and credentials.
#>

$ErrorActionPreference = "SilentlyContinue"

Write-Host "[+] Starting Session Sanitization..."

# Stop Common Browsers
Write-Host "[+] Stopping browser processes to release file locks..."
Get-Process -Name "chrome", "msedge", "firefox" -ErrorAction SilentlyContinue | Stop-Process -Force

# Clear Windows Credential Manager (Web Credentials)
Write-Host "[+] Clearing Windows Credential Manager Web Credentials..."
cmdkey /list | ForEach-Object{
    if($_ -like "*Target:*"){
        $target = $_.Substring($_.IndexOf(":")+2).Trim()
        if ($target -like "*http*" -or $target -like "*microsoft*"){
            cmdkey /delete:$target
        }
    }
}

# Clear Internet Explorer/Edge Cache (Legacy support)
Write-Host "[+] Clearing IE/Edge Cache..."
RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 8
RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 2

Write-Host "[+] Sanitization Complete. User will be forced to re-authenticate on next launch."

Remediation

Since this attack vector bypasses standard MFA, remediation requires moving to phishing-resistant authentication methods:

Implement FIDO2/WebAuthn: This is the only definitive control against AiTM attacks. FIDO2 keys (hardware or platform-bound biometrics like Windows Hello) use cryptographic signatures that cannot be phished via a reverse proxy. Enforce this for all administrative and high-privilege insurance portal access immediately.
Enable Number Matching in MFA: If FIDO2 is not immediately feasible, ensure your MFA solution (Microsoft Authenticator, etc.) enforces "Number Matching." This prevents attackers from proxying the push notification approval to the victim without the victim seeing the specific challenge number.
Conditional Access Policies (CAP):
- Device Compliance: Require devices to be managed (Intune/MDM) and compliant.
- Network Location: Block access from anonymous IP addresses and known Tor exit nodes.
- Session Risk: Configure policies to force re-authentication or block access when "Impossible Travel" or "Anonymous IP" risk is detected, even if MFA was passed.
Email Hardening: Enforce DMARC, SPF, and DKIM strictly to prevent the delivery of the initial spear-phishing lure. Deploy link-time analysis for URLs targeting insurance-specific domains.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub