Attackers Are Getting Stealthier
The phishing toolkit ecosystem is maturing, and toolkit builders live and die by one metric: can their tooling evade detection long enough to let attackers conduct fraud?
Lately, that's produced a clear trend: residential proxies.
Instead of logging in from a VPN or a datacenter IP, the attacker routes through a real household connection. And increasingly, they pick one that matches the city and ISP of the real user.
In this case, there's no "new country" flag and no anomalous ISP. Just a login from the user's own town, on the same provider they use every day.
We've seen a lot of these in the past few months. And as the cases below show, the login alone isn't going to catch them. Let's dive in.
Case 1: Same City, Same ISP, Same Subnet
The real user on this tenant logs in from Killeen, TX on Brightspeed.
The attacker's login?
Killeen, TX. Same ISP. IP in the same subnet range as the real user's home connection.
This is a near-perfect match. The attacker routed through a residential proxy that geolocates to the same city as the user, shares the user's ISP, and even lands in the same IP range as the user's actual home connection. If you looked at this login in isolation, nothing about it would look out of place.
Why is this hard to catch?
- No location anomaly. Attacker and user geolocate to the same city.
- No ISP anomaly. "First time seeing this ISP for this user" heuristics don't fire. It's the same ISP.
- No subnet anomaly. The attacker's IP sits in the same range as the user's real home IP.
- No timing anomaly. The attacker logs in during business hours, alongside the user's normal activity.
- No loud follow-on. No inbox rules. No outbound phishing. Nothing a traditional BEC detection would pick up on.
Case 2: Same City, Same ISP
The real user on this tenant logs in from Chattanooga, TN and Hixson, TN (a Chattanooga suburb). Their ISP is EPB Fiber Optics, a regional provider based in Chattanooga.
The attacker's login?
Chattanooga, TN. EPB Fiber Optics.
Here's the enrichment on the attacker IP:
The IP is flagged as a node in six separate residential proxy networks. The attacker went shopping for a residential proxy, filtered to Chattanooga on EPB Fiber Optics, and logged in.
What's notable here is how regional the ISP is. EPB Fiber Optics isn't a national carrier. It's a Chattanooga-based fiber provider. The attacker specifically picked a proxy node on that provider to match the user.
Case 3: Clear Programmatic City Matching
This one is our favorite example of what programmatic city matching looks like when it doesn't quite work.
The real user logs in from Oxford, CT.
The attacker tries Oxford, AL. Then Oxford, PA.
It's almost funny. The attacker (or the attacker's toolkit) clearly had "match the user's city" in its targeting logic, but the residential proxy pool didn't have an exit node in Oxford, Connecticut. So it fell back to the next best thing: any town named Oxford with an available residential IP.
A human attacker picking a city wouldn't try three different Oxfords in sequence. This is a script iterating through candidate exit nodes, and it tells you just how programmatic this targeting has become.
Takeaway: Logins Aren't Enough Anymore
Residential proxy attacks expose the ceiling of login-based detection.
- Location is no longer a reliable signal. Whether the attacker nails the user's exact city, ISP, and subnet or fumbles the state while trying to match the city name, there's rarely anything in the login metadata alone that cleanly distinguishes them from the real user.
- They won't tip their hand the way BEC actors used to. These attackers are happy to sit quietly for months, exfiltrating sensitive data. No inbox rules, no outbound phishing, nothing loud.
Login anomaly detection assumed the attacker would look different on the way in. Residential proxies break that assumption.
The only reliable way to catch these attackers is to watch what they do once they're in and discern their intent:
- Every email opened.
- Every SharePoint file accessed.
- Every mailbox search.
That's where the attacker's behavior diverges from the real user's, even when their login doesn't.
If you're defending Microsoft environments against stealthy account compromise, schedule a demo today.