Starkiller - A Reminder That a Residential Proxy Strategy is Needed
Starkiller markets itself as an "Advanced Phishing Framework" with bold claims: 99.7% success rate, 0% detection rate. Having comprehensively mapped their infrastructure and fed it into our AiTM Feed for months, we can confidently refute the "zero detection" claim!
That said, based on the capabilities we've observed - MFA bypass, cookie capture, keylogging, and crucially, built-in proxy rotation - Starkiller likely evades many conventional security controls. This matters because proxy rotation isn't unique to Starkiller. We've observed a marked increase in AiTM campaigns leveraging residential proxy networks over the past 18 months, representing a systematic shift in adversary infrastructure that demands a defensive response.
In this blog post we'll examine why proxy networks matter and what organisations can sensibly implement.
Proxy Network Primer (in an AiTM context)
A proxy network is a system that routes internet traffic through intermediate servers, masking the true origin of the connection. Residential proxy networks specifically use IP addresses assigned to real homes by ISPs. When an adversary authenticates to your systems through a residential proxy, the traffic appears to come from a legitimate residential internet connection - complete with residential ISP, geolocation, and device characteristics - rather than from the attacker's actual location. This makes it extremely difficult for traditional security controls to distinguish malicious authentication attempts from genuine users connecting from home.
In addition to residential proxy networks, mobile proxy networks (mobile/cellular device networks) and datacenter proxies (e.g. those in the address space of hosting providers such as DigitalOcean or M247) are also commonplace. Whilst proxy providers do try to separate mobile, residential and datacenter proxies there is usually a lot of bleed and overlap.
We're drawing a distinction in this post between proxy networks and ORB (Operational Relay Box) networks. Unlike residential proxies which route through legitimate ISP connections, ORB networks typically consist of compromised IoT devices and home routers. The distinction matters because ORB infrastructure is inherently criminal (compromised devices) while residential proxies occupy a legal grey area (users sometimes unknowingly participate via VPN services or apps). We might address ORB networks separately in future posts.
Proxy Network Challenges
If you've mapped proxy networks, it might sound logical to simply block access from those networks. But there are several challenges to this approach:
Dynamic Infrastructure: Proxy networks are not static. IP addresses change regularly, just as residential users' IPs do. Devices providing residential proxy capability may not be permanently online in the way datacenter proxies are. The IP that was part of a proxy network yesterday may no longer be today, or vice versa.
Carrier-Grade NAT (CGNAT): CGNAT is a mechanism widely used by ISPs to share limited IPv4 address space amongst many users. Many residential ISPs assign multiple users to a single IP address - this is even more prolific with mobile data services, meaning blocking a single "malicious" IP could impact dozens of legitimate users.
Consider this example from our proxy mapping activities:
{
"country": "United Kingdom",
"country_code": "GB",
"isp": "YouFibre Limited",
"address": "88.97.251.247"
}
YouFibre explicitly documents their CGNAT usage in the whois record itself (which is handy):
inetnum: 88.97.192.0 - 88.97.255.255
netname: UK-YOUFIBRE-10042024
org: ORG-YL80-RIPE
country: GB
descr: CGNAT
Customers status: SUB-ALLOCATED PA
While it's possible we've seen this IP more frequently than others by chance, it's more likely that multiple YouFibre customers are providing residential proxy services, causing this single IP to appear repeatedly in our data. We've not seen it specifically used in AiTM campaigns, but it is one of the many thousands of IPs that the Starkiller framework had access to at the time of writing.
CGNAT usage on residential internet connections varies, but for anyone using mobile internet, CGNAT is almost always in use.
CGNAT usage on residential internet connections varies, but for anyone using mobile internet, CGNAT is almost always in use.
Scale Limitations: The sheer size of proxy networks makes them extremely difficult to handle via blocklist. When you're dealing with proxy networks containing millions of IPs, you quickly find that your security tooling can't handle the volume. Most security tooling limits active blocklists (blocking that happens before the event) to around 5,000 entries, forcing you into reactive, post-event scenarios (wait for the incident to occur and then detect and clean up).
Proxy Networks Strategy
If we're seeing steady evolution toward proxy network abuse in AiTM attacks, what can organisations sensibly implement? The answer depends entirely on your environment and risk tolerance, but here are some key considerations:
1. Understand your legitimate proxy IP usage patterns
Analyse your authentication logs to identify where proxy IPs appear legitimately. Common scenarios include:
Mobile devices on CGNAT: Mobile carriers extensively use carrier-grade NAT, causing legitimate mobile authentications to appear from shared residential IP space.
BYOD with consumer VPNs: Personal devices running Surfshark, NordVPN, or similar services will authenticate from residential proxy networks.
International travel: Users abroad may rely on VPN services that leverage proxy infrastructure.
If you're on Entra ID then review sign-in logs for "Incoming token type: none" events from proxy IPs - these events represent actual credential submissions rather than token refreshes, helping you identify the scope of genuine user impact. Understanding this distinction prevents both false positives (blocking legitimate mobile users) and false negatives (overlooking attacks because they appear to come from familiar local networks like Vodafone, AT&T, T-Mobile etc.).
2. Curated feeds over comprehensive datasets
Rather than blocking every known proxy IP past and present, focus on intelligence that directly correlates with active attacks. At Lab539, we curate our AiTM feed to include only IPs and domains we've associated with actual adversary activity (planned, active or past activity). Even with curated feeds, you might still face scale challenges with Microsoft's Named Locations constraints and similar tooling, but the signal-to-noise ratio makes the operational overhead worthwhile.
3. Leverage existing controls to differentiate legitimate traffic
Before blocking proxy IPs broadly, consider what compensating controls can separate legitimate users from attackers:
Corporate VPN infrastructure: If users have VPN access, restrict authentication from proxy IPs for cloud applications while ensuring VPN authentication itself remains accessible. Consider certificate-based authentication for the VPN to avoid a circular dependency where users blocked from proxy IPs cannot authenticate to the VPN that would unblock them. Users can then authenticate to cloud services via VPN from trusted exit IPs.
Device registration and compliance: Use Conditional Access to require registered or compliant devices when authenticating from proxy IPs. Block new device registration from proxy networks entirely - legitimate users register devices from corporate or home networks, while attackers operating from proxy infrastructure cannot establish device trust.
Authentication strength policies: For environments without device management, require phishing-resistant authentication methods (FIDO2, Windows Hello for Business, certificate-based auth) when users authenticate from proxy IPs. This adds friction but maintains security without outright blocking.
Differentiate initial authentication from token operations: Token refresh using Primary Refresh Tokens indicates a device already established trust. Consider blocking only "Incoming token type: none" events from proxy IPs while permitting PRT-based sign-ins, reducing false positives from mobile devices roaming across CGNAT networks.
4. Understand the limitations of vendor-provided protections
A common refrain during incident response is surprise that existing security tooling didn't prevent the attack. If you're relying solely on Microsoft's built-in threat intelligence or a major vendor's feeds, consider this: adversaries targeting Microsoft 365 environments test their infrastructure against those same protections before launching campaigns.
Attack infrastructure that successfully bypasses Microsoft Defender, Microsoft Entra ID Protection, or other widely-deployed controls isn't accidental - it's the result of deliberate testing and iteration by threat actors. If an AiTM proxy network is actively being used in the wild, it has likely already been validated as undetected by baseline Microsoft protections.
This isn't a criticism of these platforms - detecting novel attack infrastructure at scale is genuinely difficult. But it does mean that vendor-provided threat intelligence often lags behind active adversary operations. Our AiTM feed exists precisely because of this gap. Baseline vendor protections should be your foundation, not your ceiling. Threat intelligence feeds, behaviour analytics, and detective controls that look beyond what your primary vendor sees are essential for catching attacks that have already been optimised to evade those baseline defences.
5. Build detection alongside prevention
Recognition matters as much as blocking. Understanding that proxy networks exist as attack infrastructure means you can design strategies to address them - even if that strategy is "not doing anything yet, but we're aware."
When incidents occur, the proxy angle becomes a crucial triage consideration. A suspicious login from a Vodafone IP isn't automatically benign just because the user typically connects via Vodafone - that familiarity can mask CGNAT-obscured attacks. Conversely, if you've implemented proxy IP blocking, having an awareness at your help-desk and mechanisms to quickly unblock legitimate users caught in CGNAT scenarios is essential.
Use your authentication logs proactively. Sign-in analytics, impossible travel detection, and correlation between authentication patterns and known proxy infrastructure can catch what preventive controls miss. The goal isn't perfect coverage - that's unachievable. It's finding the balance between blocking adversary infrastructure and maintaining usability for your legitimate user base.
Conclusion
Residential proxy networks represent a persistent challenge in defending against AiTM attacks. Adversaries will continue to leverage this infrastructure precisely because it's difficult to block comprehensively without impacting legitimate users. The path forward isn't about achieving perfect prevention - it's about layered defences that combine curated threat intelligence, device trust models, and behavioural analytics to separate attackers from genuine users operating in the same IP space.
A critical consideration: threat intelligence timing matters. The most effective threat intelligence is proactive - identifying and blocking attack infrastructure before it's used against you, not after incidents have occurred. Intelligence feeds derived from "what affected other customers" are inherently reactive; by the time that infrastructure appears in the feed, attacks have already succeeded elsewhere. Worse, sophisticated adversaries often burn infrastructure after successful campaigns, rendering post-incident intelligence obsolete. Look for providers actively hunting and mapping attack infrastructure before it's operationally deployed, not cataloguing it after the fact.
For organisations evaluating their defensive posture, the question isn't whether to address proxy networks, but how to do so proportionate to your environment's risk tolerance and operational constraints.
A critical consideration: threat intelligence timing matters. The most effective threat intelligence is proactive - identifying and blocking attack infrastructure before it's used against you, not after incidents have occurred. Intelligence feeds derived from "what affected other customers" are inherently reactive; by the time that infrastructure appears in the feed, attacks have already succeeded elsewhere. Worse, sophisticated adversaries often burn infrastructure after successful campaigns, rendering post-incident intelligence obsolete. Look for providers actively hunting and mapping attack infrastructure before it's operationally deployed, not cataloguing it after the fact.
For organisations evaluating their defensive posture, the question isn't whether to address proxy networks, but how to do so proportionate to your environment's risk tolerance and operational constraints.