How a Phone Call Beats MFA: Anatomy of the Wall Street Vishing Wave

The threat actor picture

The attackers behind the Apollo breach and the broader campaign operate under multiple monikers tracked by Google Threat Intelligence Group and cross-referenced by independent researchers. Public naming includes Falcon, Helix, Pink, Redact, and Silent Ransom. These are subgroups adjacent to, or overlapping with, the ShinyHunters extortion ecosystem responsible for the 2026 Canvas / Instructure breach, the Klue / Salesforce OAuth "Icarus crew" campaign, the RingCentral 1.6M record leak, and the Aura consumer identity-protection breach.

The organizational structure is loose — cells operate independently but share tradecraft, tooling, and access to compromised infrastructure. Attribution to a specific cell within a given intrusion is difficult and rarely matters operationally. What matters is that the tradecraft is consistent enough that defenses developed against one intrusion apply meaningfully to the others.

The attack chain, step by step

Step 1: Reconnaissance. Attackers identify high-value targets at the victim firm. LinkedIn is the primary source. Public press releases, portfolio company disclosures, and SEC filings supplement. The attacker learns organizational structure, reporting relationships, department names, and the names of IT helpdesk staff. A target profile takes hours.

Step 2: Timing and pretext development. The attacker develops a pretext that fits the target's likely reality — a recent internal reorganization, a known travel period, a scheduled system maintenance window. The pretext is time-sensitive enough to discourage the target from stopping to verify.

Step 3: The call. The attacker calls the target's business phone number. Caller ID may or may not be spoofed. The attacker introduces themselves by name — a real name from the target's IT department — and references a plausible ticket, account issue, or verification requirement. The tone is competent and helpful. Within two minutes, the target has been walked to a URL that appears to be an internal identity portal.

Step 4: The lookalike portal. The URL points to attacker-controlled infrastructure hosting a pixel-accurate clone of the target's Microsoft, Okta, or other identity provider sign-in flow. The domain is typosquatted (microsoftonline-verify[.]com, apollo-idp[.]net), often with a valid TLS certificate. The target enters credentials.

Step 5: The proxy attack. The lookalike portal is a proxy. It forwards the credentials to the real identity provider in real time and receives the MFA challenge in response. The proxy presents that challenge to the target, who completes it — often via push notification approval or one-time code entry. The identity provider issues an authenticated session token in response to the successfully completed MFA challenge. The proxy captures that token.

Step 6: Session use. The attacker loads the captured session token into their own browser and accesses the identity provider's protected resources — Microsoft 365, Azure, Salesforce, whatever the target firm uses. From the identity provider's perspective, this is the same authenticated user completing normal actions. There is no re-authentication prompt because the session is already valid.

Step 7: Persistence. Depending on target value, the attacker may register a fraudulent device into the identity fabric (Entra ID join, Intune enrollment, or the equivalent) so subsequent access appears to originate from a compliant managed endpoint. This bypasses device-based Conditional Access policies. Mailbox rules may be planted to filter security notifications into hidden folders. OAuth grants may be added to establish out-of-band access that survives password resets.

Step 8: Exfiltration. Data is pulled through the identity provider's standard APIs. At the network edge, the traffic looks like normal Microsoft Graph or Salesforce API activity — because it is. The compromise persists for days to months. Discovery typically arrives externally: an extortion demand, a public leak site posting, or a threat intelligence tip.

Detection signals and identity-fabric indicators

Every step in this chain leaves telemetry. The problem is not that the signals do not exist. The problem is that they are not being reviewed with the specificity required to distinguish attacker behavior from normal user behavior. Key indicators, in the order they typically become visible:

• Sign-in anomalies: Impossible-travel scenarios, especially where a successful sign-in from a new geography follows a helpdesk-adjacent event by minutes to hours. Sign-ins from ASNs associated with commercial VPN providers or with residential proxy infrastructure.
• Device registrations: New Entra ID device registrations for privileged users that do not correspond to a known hardware refresh. Devices with join dates that predate the user's provisioning of hardware.
• OAuth grants: New OAuth application grants against high-privilege scopes (Mail.ReadWrite, Directory.Read.All, Files.ReadWrite.All) for accounts that do not normally consent to third-party applications.
• Mailbox rules: Inbox rules created by the user account that redirect security-related messages, invoice-related messages, or messages from specific external senders into hidden folders. Rules that mark messages as read and stop processing.
• Administrative activity: Privileged role activations or role assignment changes made by accounts that do not typically perform administrative tasks. Guest invitations from privileged accounts.
• Data access patterns: Bulk downloads via Microsoft Graph API, especially for mailboxes, SharePoint sites, or OneDrive contents unrelated to the user's normal work.

The organizations that catch these attacks quickly are the ones running compromise-assessment workflows against their identity fabric on a defined cadence — not the ones relying on SIEM alerting for it.

The hardening playbook

The controls that meaningfully reduce vishing-wave exposure are not exotic. They are, however, unevenly implemented in mid-market and PE firms:

1. Phishing-resistant MFA everywhere it can be enforced. FIDO2 hardware keys or platform authenticators (Windows Hello for Business, Touch ID / Face ID with WebAuthn) do not release credentials to lookalike portals because the authenticator binds to the legitimate origin. Push notifications and one-time codes remain vulnerable to real-time proxy attacks.
2. Helpdesk verification hardening. Any procedure that verifies caller identity based only on knowable information (name, department, start date, manager's name) is defeated. Effective verification uses out-of-band callback to a number of record, video verification with government ID, or challenge-response through a channel the caller does not control.
3. Device-based Conditional Access with device attestation. Restrict access to managed, compliant devices. The rogue-device-registration step in the attack chain is designed to defeat this control; hardware-attested compliance policies close that gap.
4. Continuous session risk evaluation. Continuous Access Evaluation and equivalent Okta/Ping controls terminate sessions when risk signals change — geography shift mid-session, admin activity from a new device, sign-in from an anomalous ASN. Static session lifetimes measured in days are the enabling condition for token replay.
5. Compromise assessment cadence. Quarterly at minimum — monthly for firms with active portfolio company transaction volume or heightened threat profile — dedicated review of the identity-fabric indicators listed above by an assessor whose independence is documented.
6. Least-privilege enforcement at the OAuth layer. Restrict which third-party applications employees may grant consent to. Require admin approval for any application requesting high-privilege scopes.
7. External password reset processes that do not depend on the helpdesk being uncompromised. The moment the helpdesk is the injection point, any password reset it processes is suspect. Emergency reset paths through separate channels — with different authenticators — matter.

The combined effect of one through seven is that the attack chain has to defeat multiple layers, not one. Vishing works today because at most target organizations it only has to defeat one.

What Cloudskope does about this

Cloudskope built SARTUS™ specifically to run this playbook in a bounded window. The Part 1 assessment reviews M365 and Azure AD identity posture, credential exposure, cloud configuration drift, and active-compromise indicators over three days. Part 2 remediates what can be closed within the assessment window. Findings that cannot be closed inside six days — hardware-dependent items, structural projects, third-party dependencies — land in the consolidated risk register with a documented path and, where requested, a separate quote. Fixed fee, defined scope, executive readout on the following week.

If you are reading this and thinking about a PE firm you sit on the board of, or a portfolio company that has not looked at its identity fabric with fresh eyes in twelve months, the honest answer to whether the vishing wave could work there is: probably yes, because the controls that stop it are not evenly deployed. The honest answer to when you would rather find out is: before the extortion email, not after.

Related reading:

• Apollo. Blackstone. Bridgewater. Bain. The Same Crew Is Vishing Them All — And Bain Is Already a Defendant. — the executive synthesis
• Apollo Global Management: Breach Library entry — the factual record