ForumsGeneralNew 'Starkiller' PhaaS proxies real sites — traditional phishing defenses useless?

New 'Starkiller' PhaaS proxies real sites — traditional phishing defenses useless?

MSP_Owner_Rachel 2/22/2026 USER

Just saw the Krebs writeup on 'Starkiller,' and it looks like the PhaaS (Phishing-as-a-Service) ecosystem is evolving faster than our static filters can keep up. Unlike traditional kits that host a copy of a login page—which we can easily hash and block—Starkiller uses a reverse proxy to serve the actual target website to the victim.

This means the HTML, CSS, and even the JavaScript loading behavior are identical to the legitimate site. The attacker acts as a 'man-in-the-middle,' relaying credentials and, crucially, the MFA tokens in real-time. Since the content is technically from the legitimate domain (just proxied), standard reputation-based web filters often miss it.

I've been looking into ways to detect this behavior on the client side, primarily by analyzing the DOM for injection hooks that these proxy tools often rely on to hijack session cookies. Here is a quick Python snippet using selenium to check for common network interception patterns often seen in these kits:

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

def_check_proxy_hijack(url):
    options = Options()
    options.add_argument("--headless")
    driver = webdriver.Chrome(options=options)
    
    try:
        driver.get(url)
        # Check for window.performance hooks often used by proxy kits
        script = "return Object.keys(window.performance).length"
        key_count = driver.execute_script(script)
        
        # Heuristic: Unusually high key count suggests hook injection
        if key_count > 50: 
            return "Suspicious hooking detected"
        return "Likely clean"
    finally:
        driver.quit()

While this isn't foolproof, it gives us a heuristic to investigate. However, with real-time MFA bypassing becoming standard in these services, are we finally reaching the point where SMS/App-based TOTP is dead and FIDO2/WebAuthn is mandatory for everyone?

FI
Firewall_Admin_Joe2/22/2026

We've seen similar activity from 'Evilginx2' in our pentests, and the success rate is terrifying compared to static templates. The fact that Starkiller automates the subdomain generation makes it even harder for blocklists to keep up. We've started pushing Conditional Access policies that force device compliance (Hybrid Azure AD join) for sensitive apps. Even if they phish the creds and the MFA code, the attacker still lacks the compliant device token.

SY
SysAdmin_Dave2/22/2026

From a SOC perspective, the real tell is often in the network telemetry rather than the page content. We are using Zeek (formerly Bro) to look for TLS handshakes where the client indicates support for modern cipher suites (indicating a up-to-date browser) but the JA3 fingerprint of the server doesn't match the known fingerprint of the legitimate service (due to the intermediate proxy). It generates some false positives with corporate proxies, but it's catching stuff pure URL filters miss.

VP
VPN_Expert_Nico2/22/2026

That Python snippet is a good starting point, but I'd add a check for hidden iframes or injected scripts that aren't present in the known-good version of the site. We use a diffing tool during assessments to compare the live DOM against a cached clean version. If you see scripts loading from domains that look like the target but have slight typos (e.g., '0x' vs 'ox'), that's usually the relay mechanism.

Verified Access Required

To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.

Request Access

Thread Stats

Created2/22/2026
Last Active2/22/2026
Replies3
Views231