Starkiller PhaaS: Why MFA fatigue is now your biggest risk
Just read the Krebs breakdown on 'Starkiller'—this is a scary evolution of PhaaS. Unlike static kits that host a fake HTML page, Starkiller uses a reverse proxy to relay traffic between the victim and the legitimate site.
Because it proxies the real site:
- Static analysis fails: The HTML, CSS, and JS are 100% authentic, bypassing most email filters scanning for cloned content.
- MFA is defeated: It captures the session cookie (or TOTP code) in real-time, relaying it to the legitimate service before the session expires.
We're seeing this bypass standard MFA like Duo and Microsoft TOTP. The only reliable defense I've found is moving to FIDO2/WebAuthn hardware keys (phishing-resistant MFA).
I've been rolling out a detection rule to spot potential proxy sessions by looking for anomalies in TLS fingerprinting or device context. Here is a basic KQL snippet I'm using to look for rapid login failures from a single source IP, which often indicates a phishing site is 'testing' credentials:
SigninLogs
| where AppDisplayName contains "Exchange" or AppDisplayName contains "Microsoft 365"
| where ResultType == 50126 or ResultType == 50053 // Invalid password or Account locked
| summarize Count = count() by IPAddress, bin(TimeGenerated, 5m)
| where Count > 10
| order by Count desc
Has anyone else started blocking specific hosting providers known for these proxies, or is it purely a user-awareness + FIDO2 play for you?
We moved entirely to FIDO2 keys for our admin accounts last year after a close call with a similar AiTM attack (likely Evilginx). For standard users, we're pushing passwordless (Windows Hello) aggressively. If you are still relying on TOTP or SMS, Starkiller is going to walk right in. Number matching helps slightly with awareness, but it's not a technical block against the relay.
From a pentester perspective, this isn't new tech—Evilginx2 has been around for years—but the 'service' aspect lowers the barrier to entry significantly. Your KQL is a good start, but we recommend focusing on Conditional Access policies. Require compliant or hybrid-joined devices for sensitive apps. If the proxy endpoint can't bind the device object, the auth fails.
We've implemented TLS Fingerprinting (JA3) on our edge. These phishing proxies often run on cheap VPS providers or cloud instances that use standard OpenSSL stacks that differ from a typical user browser. It generates some false positives, but it's caught a few of these 'perfect clone' sites that URL reputation missed.
Beyond MFA, enforcing Conditional Access based on device compliance is critical for these AiTM attacks. If an attacker relays the session cookie, they still need a compliant device to access the apps. We block access unless the device is marked 'Compliant' or 'Hybrid Azure AD joined'.
To monitor potential session theft, track sign-ins from devices that are not compliant but have valid MFA claims:
SigninLogs
| where ResultType == 0
| where DeviceDetail.isCompliant == false
| where AuthenticationRequirement == "multiFactorAuthentication"
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access