Starkiller PhaaS: Mitigating Adversary-in-the-Middle (AitM) Proxies in the Wild

We rolled out YubiKeys for our executive team and admin accounts last year after a simulated Evilginx attack. The user friction was a nightmare initially, but phishing protection is bulletproof now. With FIDO2, the private key never leaves the device, so a proxy can't relay the authentication response even if it intercepts the session. If you can't afford keys, looking into Number Matching in Microsoft Authenticator is a solid stopgap.

From a SOC perspective, this is a nightmare to detect because the traffic is encrypted and looks legitimate. We are focusing on detecting the initial delivery method (email links) and looking for 'impossible travel' scenarios post-login. If Starkiller is using a residential proxy network to hide their infrastructure, geo-blocking might fail. I'd recommend checking your conditional access policies for 'insider risk' contexts.

Another approach we've found effective is implementing TLS fingerprinting to detect reverse proxy tools. Starkiller and similar PhaaS platforms often have distinct TLS handshake characteristics that differ from normal browsers. You can monitor these using tools like JA3 or JA4:

# Example using JA3 fingerprinting with Scapy
from scapy.all import *
from ja3 import Ja3

def detect_proxy(pkt):
    if pkt.haslayer(TLSClientHello):
        ja3_fingerprint = Ja3(pkt[TLSClientHello])
        if ja3_fingerprint in known_proxy_fingerprints:
            alert_security_team(pkt[IP].src)

This won't catch everything, but it's another layer in your defense that can catch proxy tools even when they're using legitimate domains.

While YubiKeys are great, enforcing device compliance via Conditional Access is often a quicker win for broader coverage. Starkiller can relay the MFA token, but it struggles to spoof the device trust (Intune/Hybrid Join) required to access the resource. We block access unless the device is managed, effectively neutering the proxy's session access.

You can hunt for these bypasses by looking for successful MFA logins on non-compliant devices:

SigninLogs
| where ResultType == 0
| where DeviceDetail.isCompliant == false
| where AuthenticationRequirement == "multiFactorAuthentication"
| project Time, UserPrincipalName, IPAddress, AppDisplayName

Number matching is another strong layer that hasn't been mentioned yet. Even if Starkiller relays the session, the attacker can't see the two-digit code displayed on the victim's device to approve the authentication. It breaks the automated relay flow effectively. We've seen it stop automated AitM toolkits cold because it requires manual context awareness that the proxy can't bridge. Ensure your IdP configuration enforces this rather than simple push notifications.

It's vital to specify how hardware keys are deployed. As Eve noted, YubiKeys are effective, but only if enforced as FIDO2/WebAuthn keys. If your policy allows users to use the key as a TOTP generator, Starkiller can still relay the code. We strictly enforce FIDO2 to ensure the credential is bound to the domain, effectively closing that relay vector.

Building on TLS fingerprinting, we’ve had success hunting for specific JA3 signatures associated with reverse proxy kits in our proxy logs. While signatures change, they are often reused across different PhaaS campaigns for weeks. I recommend setting up a watchlist of known bad fingerprints and querying for matches daily. Here is a basic KQL query to get started hunting for these anomalies:

DeviceNetworkEvents
| where ActionType == "ConnectionSuccess"
| where TlsFingerprint has_any ("", "")
| summarize count() by TlsFingerprint, RemoteUrl

This helps catch the infrastructure even if the email bypasses filters.