Vishing Attacks on Financial Firms: How to Detect Account Takeover Attempts​

Attackers are using commercial VPNs and residential proxies to make stolen credentials look like legitimate authentication. Here’s how financial security teams can add the network context needed to detect suspicious access.

Recent cyberattacks targeting major Wall Street financial institutions have put identity security back in the spotlight.

A recent campaign has targeted hedge funds, private equity firms, and other financial organizations using voice phishing, or “vishing,” to impersonate trusted IT and help desk personnel. The goal is to direct employees to convincing phishing pages where they surrender credentials, authentication tokens, or MFA codes that attackers can then use to access identity platforms and SaaS environments such as Microsoft 365 and Okta.

The Role of Anonymization in the Wall Street Cyberattack: An Identity Security Blind Spot

Once attackers have successfully social-engineered an employee, they still need to connect to the victim’s environment. That activity can be hidden behind commercial VPNs, proxies, residential proxy networks, and other anonymization infrastructure designed to obscure the attacker’s true origin.

In this campaign, that infrastructure was part of the observed attack chain. Google Threat Intelligence Group (GTIG) reported that the majority of identified campaign IPs were commercial VPN nodes and identified multiple IP addresses used as “M365 / Okta Residential Proxy” infrastructure. GTIG also noted that the actors continuously rotate source IPs, limiting the effectiveness of static blocklists.

For identity and security teams, that creates a problem: What happens when the credentials look legitimate, the MFA challenge succeeds, and the source IP looks like an ordinary consumer internet connection?

Why Residential Proxy Traffic Is Hard to Evaluate

Residential proxies are particularly effective at undermining traditional IAM controls because they route traffic through real consumer ISP addresses, the same types of addresses used by legitimate customers and employees. Unlike obvious datacenter proxies or known malicious hosting infrastructure, a residential proxy can make attacker traffic appear to come from a normal household or mobile connection. That can weaken controls built around IP reputation, geographic anomalies, and velocity.

Even a residential proxy detection requires context. A proxy-enabled device may share a public IP with other legitimate devices in a home, business, carrier, or CGNAT environment. Signals such as client count or device density can help security teams assess whether proxy activity is likely associated with the authenticating device itself or simply another device sharing the same public IP.

Authentication systems often combine device, location, behavioral, and network signals to decide whether a user should be allowed through. If the network signal incorrectly appears benign, the system is making that decision with incomplete context.

Recent conversations with financial-services security teams reinforce how relevant this problem has become. Teams are actively working through how residential proxy and anonymization signals can feed existing risk-based authentication, detection, and investigation workflows. The challenge is often not recognizing that the signal matters, but determining where in the existing security stack they can act on it effectively.

Adding Network Context to Identity Security Decisions

IP intelligence and session enrichment provide security teams with insight into the infrastructure behind internet connections, helping them evaluate whether IPs are associated with residential proxies, commercial VPNs, or other anonymization services. For identity and security teams, that intelligence can be applied at several points in the identity and access lifecycle.

In practice, there is no single implementation model. Some organizations can act on network context during a web session they control. Others need to apply it downstream through an identity platform, risk engine, SIEM, SOAR, or investigation workflow. Platform limits and where authentication is hosted often determine what is possible.

Enrich and prioritize risky authentication attempts

Organizations can enrich authentication telemetry from Microsoft 365, Okta, VPN, SSO, and other sensitive systems with context indicating whether an apparently benign IP is associated with residential proxy or anonymization infrastructure. Security teams can combine that signal with identity, device, geographic, and behavioral information to improve authentication risk assessment and policy decisions.

Network context can also be applied before unusual activity becomes a SOC case. Instead of creating an alert for every atypical login, teams can use infrastructure intelligence to help prioritize events where anomalous identity behavior and suspicious network characteristics occur together.

Apply friction where the architecture allows

Not every residential or anonymized connection is malicious, and broadly blocking this traffic is not realistic for most organizations. Where organizations control the application or authentication flow, session enrichment can contribute network and browser context to real-time decisions. In environments where the identity provider hosts the login experience, IP intelligence can instead feed existing IAM, SIEM, SOAR, and risk-based authentication workflows.

Depending on the surrounding signals and the controls available, an authentication attempt originating from known anonymization infrastructure could contribute to a decision to require step-up authentication or additional verification, restrict access to sensitive resources, send the activity for review, or deny access. The goal is targeted friction based on combined risk, not treating every VPN or residential connection as malicious.

Investigate whether compromised credentials were used

For organizations that believe they may already have been targeted by a phishing or vishing campaign, network context can also support retrospective investigation. Security teams can enrich authentication and security logs with IP intelligence to look for suspicious VPN or proxy infrastructure, correlate related sessions, and investigate whether stolen credentials were subsequently exercised.

Historical baselining can make that signal more useful. Has this user routinely authenticated through this type of connection, or did the behavior begin after the suspected compromise? Did the connection type, service, geography, or network suddenly change? These patterns can help analysts prioritize activity even when attackers rotate source IP addresses.

How Spur Helps

Spur provides network and session context that can be incorporated into authentication decisions, threat hunting, incident investigations, and existing security workflows through real-time session enrichment and continuously refreshed IP intelligence.

Session enrichment for real-time decisions in web sessions you control

For web sessions organizations control, Spur Monocle surfaces indicators such as proxy or VPN use, anonymization tooling, and non-human behavior during the session itself. Identity and security teams can combine infrastructure context with browser-level indicators of proxy usage or automation to support more precise access policies in real time.

For more, read Spur’s latest white paper, How to Strengthen Authentication Against Modern Account Abuse with Session Enrichment.

IP intelligence for authentication telemetry, threat hunting, and incident investigations

For environments such as Microsoft 365 and Okta, Spur data feeds, API, and integrations can enrich authentication telemetry and downstream security workflows with current and historical intelligence about residential proxy, VPN, hosting, and other anonymization infrastructure.

Spur’s IP intelligence provides structured context including anonymization type, hosting information, behavioral tags, and confidence data for consumption by IAM risk engines, SIEM platforms, fraud decisioning systems, and investigation workflows.

Used together, Monocle and Spur’s IP intelligence create a layered detection approach.

• At the session layer, Monocle can help identify proxy indicators, automation, and other signs of risky access in web sessions organizations control, even when the IP itself appears clean.
• At the network layer, Spur can identify known residential proxy, VPN, hosting, and other anonymization infrastructure across authentication telemetry and historical logs.

Combined, those signals can support higher-confidence risk assessment and more precise authentication, detection, and investigation decisions.

After a successful phish, the question is no longer just whether the credentials are valid. It is whether the resulting session can be trusted.

Can your current identity and security stack reliably distinguish a legitimate residential user from an attacker hiding behind residential proxy or anonymization infrastructure?

Strengthen Authentication with Network Context

Valid credentials do not always mean a trusted session. Spur helps security teams identify the VPNs, residential proxies, and other anonymization infrastructure attackers use to make malicious access look legitimate.

Use Spur IP intelligence and Session Enrichment to add context to authentication decisions, prioritize suspicious activity, and investigate whether compromised credentials were actually used.

Get started with Spur Community to explore Spur’s IP intelligence for free, or request a demo to see how Spur can support your account takeover and authentication security workflows.