Starkiller PhaaS: The End of Static Phishing Filters?
Just caught the KrebsOnSecurity write-up on the new 'Starkiller' phishing-as-a-service offering. While reverse-proxy attacks (AitM) aren't new—Evilginx has been around for years—Starkiller seems to be lowering the barrier to entry for script kiddies significantly.
The scary part is how it renders traditional email filters useless. Since the site is a live relay to the actual login page (e.g., O365 or AWS), static HTML analysis sees a perfect copy because it is the real site. The attacker essentially sits in the middle, passing credentials and MFA codes in real-time to steal the session cookie.
I've been digging into detection methods for these relay services. Since content analysis fails, we have to rely on behavior. One heuristic I'm testing is analyzing the latency between the client and the relay vs. the relay and the destination, or looking for specific JavaScript injection patterns often used to handle the relay logic.
Here is a rough Python script I'm using to identify potential proxy indicators based on header anomalies and timing during internal assessments:
import requests
import time
def analyze_relay_risk(target_url):
headers = {'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36'}
start_time = time.time()
try:
response = requests.get(target_url, headers=headers, timeout=10)
latency = time.time() - start_time
# Check for suspicious headers often found in reverse proxies
proxy_headers = ['X-Forwarded-Host', 'X-Proxy-Id', 'Via']
detected = [h for h in proxy_headers if h in response.headers]
if detected or latency > 2.0:
return f"[!] Suspicious: Headers {detected}, Latency: {latency:.2f}s"
return "[+] Clean"
except Exception as e:
return f"Error: {e}"
However, code checks are reactive. The only true mitigation I see is moving toward FIDO2/WebAuthn phishing-resistant MFA, but that's a huge lift for legacy environments.
How is your org handling the legacy app gap? Are you forcing device compliance or just accepting the risk on TOTP?
We’ve seen similar traffic recently associated with AitM kits. The biggest issue we found was that blocking by IP reputation was a losing battle due to the fast-flux infrastructure these services use. We’ve aggressively pushed FIDO2 keys for all critical admin access. It was a rough couple of months for the helpdesk, but it completely nullifies the session cookie theft aspect of these attacks.
From a Red Team perspective, the Python snippet is a good start, but you might want to look at TLS fingerprinting (JA3) as well. These proxy kits often use standard libraries (like Golang or Python's requests) that have distinct TLS fingerprints compared to a standard Chrome browser. If you can correlate a 'browser' User-Agent with a 'script' TLS handshake, you've caught the relay.
Anyone tried implementing conditional access policies that trigger on 'impossible travel' anomalies at the login attempt? Since the attacker is proxying the request, the geolocation might jump significantly between the initial connection and the MFA approval. It’s noisy, but it might catch low-effort Starkiller users who don't route through residential proxies properly.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access