Starkiller PaaS: The Real-Time Proxy Threat to MFA
Just caught the KrebsOnSecurity piece on the new 'Starkiller' Phishing-as-a-Service (PaaS) offering, and it’s a textbook example of the evolutionary arms race in social engineering.
Unlike static kits that clone HTML—which are easy for automated crawlers to fingerprint and take down—Starkiller uses a reverse proxy architecture. It essentially acts as a Man-in-the-Middle (MITM), relaying traffic between the victim and the legitimate target site in real-time. This means the victim sees the actual, pixel-perfect site, but the actor captures credentials and, critically, the MFA token/session cookie.
The Technical Shift
This is similar to open-source tools like Evilginx2 or Modlishka but commercialized for lower-skill actors. The danger here is that it renders standard TOTP (Google Authenticator, etc.) and SMS-based MFA ineffective because the phishing kit relays the code to the legitimate site instantly.
Detection & Hunting
Since there are no specific CVEs for this type of infrastructure (it's an abuse of protocol rather than a software bug), we have to rely on heuristics. One angle is monitoring for suspicious TLS certificates or domains recently registered that contain keywords related to your brand.
If you are using Microsoft Defender or similar EDR, you might try hunting for processes establishing connections to known-bad IP ranges or newly registered domains with high entropy:
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has_any ("login", "signin", "oauth")
| where InitiatingProcessFileName in ("chrome.exe", "msedge.exe", "firefox.exe")
| extend Entropy = entropy(RemoteUrl)
| where Entropy > 3.5 // High entropy often indicates randomized domains
| project DeviceName, RemoteUrl, RemoteIP, InitiatingProcessFileName
**Mitigation**
The only real defense against these relay attacks is FIDO2/WebAuthn (hardware keys or Passkeys), which cryptographically verify the origin domain. If the origin doesn't match, the key won't sign the challenge.
Are you guys seeing a shift toward these proxy attacks in your threat intel feeds? Have you managed to get approval to move away from TOTP to hardware keys yet?
We’ve been tracking similar infrastructure in our honeypots. The real kicker is that SSL inspection doesn't always catch this because the phishing site terminates the SSL, then establishes a new SSL connection to the legitimate site. The traffic looks normal on the wire unless you're doing deep packet inspection on the HTML content for hidden proxy scripts. We're pushing hard for FIDO2, but the user friction argument is still a blocker for leadership. It's frustrating because TOTP is effectively dead against these kits.
From a pentester's perspective, this is nothing new technically—it's just Evilginx with a subscription model. However, the accessibility is scary. The KQL query for high entropy is a good start, but I'd add a filter for age of the domain. Starkiller sites are usually 'living-off-the-land' for very short periods.
// Added domain age check logic conceptual
| whois RemoteUrl // hypothetical lookup
| where DomainAge < 2d
If you can block newly registered domains (NRDs) at your perimeter, you stop 90% of these attacks instantly.
We actually dealt with a breach caused by a similar kit last month. The attacker got the session cookie and bypassed the MFA prompt entirely by injecting the cookie into their own browser context. The user never even saw the '2FA code entered' log. We are now enforcing conditional access policies based on device compliance and location. It's not a silver bullet, but it raises the bar significantly compared to just username + password + MFA.
Building on the SSL inspection issues, we should focus on TLS fingerprinting mismatches. Since the reverse proxy terminates the connection, the JA3 signature often deviates from the legitimate site's baseline. You can catch this by correlating User-Agents with unexpected TLS parameters. For example, a modern browser shouldn't negotiate legacy cipher suites. Here is a simple logic check:
def check_tls_ja3(user_agent, ja3_hash, db):
expected = db.get_baseline(user_agent)
return ja3_hash != expected
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access