Defeating Starkiller: When MFA isn't enough against reverse proxy phishing
Just caught the Krebs article on the 'Starkiller' PhaaS offering. It's essentially a streamlined version of reverse proxy attacks (like Evilginx2) that allows attackers to proxy legitimate login pages in real-time. The user interacts with the real site via the attacker's infrastructure, meaning all the HTML/JS is legitimate, making static analysis almost useless.
The core issue here is that this effectively neutralizes TOTP and SMS-based MFA. The attacker acts as a middleman, relaying credentials and the MFA code instantly to the legitimate service. Even worse, they can intercept session cookies or tokens (like PRT in Entra ID), allowing session persistence that bypasses subsequent MFA checks.
We've been pushing hard on FIDO2/WebAuthn hardware keys as the only true mitigation, but adoption is slow. In the meantime, we're relying heavily on Conditional Access policies.
Here is a snippet of a KQL query we use to hunt for suspicious sign-in patterns often associated with AiTM (like device ID changes with the same user):
SigninLogs
| where ResultType == 0
| project Timestamp, UserPrincipalName, AppDisplayName, DeviceDetail, Location, MFARequired
| summarize count() by bin(Timestamp, 1h), UserPrincipalName, DeviceDetail.deviceId
| where count_ > 10 // Threshold for rapid logins
| order by Timestamp desc
How is everyone else handling this? Are you enforcing phishing-resistant MFA for admins, or do you rely on "Impossible Travel" and device compliance alerts?
We made the jump to FIDO2 for all privileged accounts last quarter. During our red team exercises, AiTM kits were bypassing our TOTP 100% of the time. The hardware keys stop it cold because the browser cryptographically validates the origin. If you can't do keys yet, enforce number matching in your Authenticator app—it adds friction that makes manual relay attacks harder.
From a SOC perspective, we're seeing a lot of these kits utilize residential IP proxies to bypass geo-fencing, so 'Impossible Travel' alerts are becoming less reliable. We've started looking more closely at user-agent strings and TLS fingerprinting (JA3). Often these kits use a default Python or Curl-based UA that stands out against normal browser traffic.
Good catch on the KQL. We also added a Conditional Access policy that requires 'Compliant Device' status for our most sensitive apps. Since most reverse proxies can't inject the necessary device compliance claims (Hybrid AAD Join cert), it blocks the session even if they get the password and MFA code.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access