Starkiller Detection: Hunting for the Reverse Proxy Relay
Just read the KrebsOnSecurity piece about the new 'Starkiller' PhaaS. It’s essentially a polished, reverse-proxy attack similar to open-source tools like Modlishka or EvilGinx2, but packaged as a service.
The scary part is that because the attacker is relaying traffic in real-time, the victim actually logs into the legitimate site. Traditional static phishing kits fail because the HTML content doesn't match the hash of the real site. With Starkiller, the HTML is identical because it is the real site, just loaded through a proxy.
For detection, we need to look beyond the content and analyze the transport layer. Since the connection to the destination service originates from the Starkiller infrastructure (likely a VPS or cloud instance) rather than the victim's ISP, we should be flagging login events where the IP address belongs to a hosting provider but the User-Agent claims to be a standard consumer browser.
Here is a basic KQL query to identify potential AitM (Adversary-in-the-Middle) activity by checking for ASN mismatches—specifically logins from hosting ASNs:
SigninLogs
| where Result == "Success"
| extend ASN = tostring(DeviceDetail.trustType) // Note: Actual ASN lookup usually requires an enrichment table
| where isnotempty(UserAgent)
// Enrichment logic needed here to tag 'Hosting' vs 'ISP'
// Assuming we have a parsed Category field from a GeoIP/ASN lookup
| where Category == "Hosting/VPN"
| project TimeGenerated, UserPrincipalName, IPAddress, UserAgent, ASN, Category
| order by TimeGenerated desc
Does anyone have success with JA3 fingerprinting to detect these relays, or are we strictly relying on IP reputation and ASN analysis now?
We've been blocking known hosting provider CIDR blocks at the perimeter for critical apps, which catches a lot of these low-effort PhaaS relay servers. However, it inevitably leads to false positives for remote employees using corporate VPNs that exit through cloud VPSs. You have to carefully whitelist your own infrastructure IPs before enforcing this.
JA3 is useful if the kit uses a standard TLS library like OpenSSL, but newer kits are getting better at mimicking browser fingerprints. The real silver bullet here is FIDO2/WebAuthn. A true reverse proxy can't bypass the cryptographic attestation of a hardware key unless they are using a sophisticated man-in-the-middle browser extension on the victim's machine—which is a much higher bar than a phishing link.
Another indicator we've found useful is timing. In a real session, there's human-like latency between the request and the response. Some of these relays introduce a few milliseconds of extra lag, or conversely, they are too fast if they automate the credential stuffing immediately after capture. correlating TimeGenerated with subsequent password change events can help spot the 'stolen session' usage phase.
Since the attacker acts as a middleman, the Referer header is a strong tell. Legitimate users usually navigate through internal pages before hitting auth endpoints, whereas phishing victims often land directly on the login page from an external domain. We should also check for TLS anomalies, as the relay often terminates the connection differently than a browser would.
Here is a basic KQL query to hunt for these external referrer jumps:
SigninLogs
| where Result == "Success"
| extend ReferrerDomain = parse_url(Referrer).Host
| where ReferrerDomain !contains "yourdomain.com"
| summarize count() by UserPrincipalName, ReferrerDomain
Another subtle signal is HTTP header ordering. Browsers are strict about the sequence of headers, but reverse proxies often rely on libraries that shuffle them or append headers in unnatural ways (e.g., X-Forwarded-For appearing before Host). We’ve had success flagging connections where the header fingerprint diverges from standard browser orders.
expected = ['host', 'connection', 'accept', 'user-agent']
received = [k.lower() for k in request.headers.keys()]
if received[:4] != expected:
alert('Anomalous header ordering')
It won't catch everything, but it filters out many poorly implemented kits.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access