The Wall Street Vishing Wave Shows Why MFA Is Not Enough
Attempted attacks on major US investment firms put the helpdesk and identity provider at the centre of the threat model. Public reporting does not establish that every named target was breached.
Update, 22 August 2026: Apollo Global Management has confirmed that a social-engineering incident led to unauthorised access to cloud platforms and exposure of personal data. A full update appears below.
Reuters reported on 5 August that hackers had attempted sophisticated cyberattacks against major Wall Street money managers and financial-services firms. The reported targets included Point72 Asset Management, Two Sigma Investments and Citadel, alongside private-equity businesses.
The attempts reportedly used phone calls in which criminals tried to persuade employees to grant access or disclose sensitive information. Point72 told investors it had faced an attack and, according to Reuters’ sources, said that no customer information was stolen. Public information did not establish a successful breach at every organisation named in the reporting.
That caution is important. A list of targets is not a list of victims. Even so, the campaign deserves attention because it concentrates on a control many organisations still treat as secondary: the process by which a person proves who they are to IT support.
Vishing attacks the recovery path
Voice phishing works because the caller can create urgency and borrow the authority of an internal support team. The attacker may claim that an account is under attack, that a security update is required or that the employee must visit a login page immediately.
In related campaigns documented by Google Threat Intelligence Group, criminals combined convincing calls with lookalike sign-in pages and adversary-in-the-middle infrastructure. That can capture not only a password but also an authenticated session or token, allowing an attacker to get past some forms of multi-factor authentication.
Once inside a cloud identity or SaaS account, the attacker can search email, SharePoint, Teams or other repositories, automate bulk data collection and use stolen internal accounts to make later messages appear more credible. Data theft then becomes leverage for extortion.
Google tracks one such operation as UNC6671 and associates it with the BlackFile name. However, public reporting about the August Wall Street attempts does not conclusively attribute every attempted intrusion to that actor. The activity should therefore be treated as a pattern rather than a single confirmed campaign.
The helpdesk is a privileged interface
An organisation can deploy strong authentication and still leave a weaker reset or enrolment route beside it. If support staff can add a new MFA device, reset a password or approve remote access after a persuasive call, the helpdesk effectively holds administrative power over the identity system.
The solution is not to tell staff to “be more careful”. Verification must be designed so that a convincing voice, a familiar name and knowledge of internal details are insufficient.
Controls to review now
- Require a callback through a trusted directory number for sensitive support requests; never use contact details supplied by the caller.
- Introduce a second-person approval for MFA resets, new device enrolment and changes to privileged accounts.
- Move administrators and high-value users to phishing-resistant authentication such as passkeys or hardware security keys.
- Prevent a password reset from automatically preserving existing sessions; revoke tokens and review newly registered devices as part of containment.
- Alert on unusual identity-provider enrolments, impossible travel, new forwarding rules and bulk downloads from Microsoft 365 or other SaaS platforms.
- Separate everyday accounts from privileged administration and restrict where administrative sessions can originate.
- Give support teams a short, rehearsed way to stop an urgent call without being penalised for delaying a genuine request.
- Run vishing exercises that test the support and recovery process, not only the employee receiving the first call.
Financial institutions are attractive targets, but the lesson applies to any organisation with valuable cloud data. Identity security is only as strong as its least verified recovery path.
Sources and further reading
- Reuters: major Wall Street firms targeted in attempted cyberattacks
- TechRadar Pro: major US funds targeted by a vishing campaign
- Google Threat Intelligence Group: inside the BlackFile vishing and extortion operation
- New York Department of Financial Services: advisory on targeted vishing attacks
Named organisations’ exposure and attribution may change as investigations continue. Treat unconfirmed targeting and confirmed data loss as separate claims.
Update: the campaign is broadening and becoming more industrialised
Reporting through 19 August indicates that the vishing and SaaS-extortion activity has continued rather than ending with the first financial-sector disclosures. The victim stream has expanded into medical-technology organisations, and researchers tracking the infrastructure estimate that the operation has been adding roughly 1.5 victims per day during the latest period.
The rate should be treated as a researcher estimate, not a complete global count. It is still useful because it changes the incident from a short wave against Wall Street into a repeatable access-and-extortion business model.
The operating pattern increasingly looks industrialised. Callers obtain or reset access, adversary-in-the-middle pages capture credentials and authenticated sessions, and other operators enumerate cloud applications, automate data collection and apply extortion pressure. Multiple public brands can appear during that chain. Separating social engineering, infrastructure, data theft and negotiation lets the operation continue even when one domain, persona or leak site is disrupted.
The clustering assessment has also strengthened, but it remains important not to collapse every vishing incident into one actor. Shared infrastructure, registration patterns, phishing templates and timing support a relationship between activity branded as BlackFile and Redact and the cluster Google tracks as UNC6671. That is stronger than a superficial similarity in tactics. It is not proof that every incident using those names, or every attempt against a named company, was conducted by the same operators.
For defenders, the expansion into medical technology matters more than the brand. The same helpdesk, identity-provider and SaaS recovery weaknesses exist across sectors, while medical-technology companies may hold regulated data, product information and access to healthcare customers. Controls designed only around banks and investment firms will miss the broader campaign.
The original conclusion therefore becomes more urgent: MFA can work exactly as designed while a recovery process, helpdesk or stolen session transfers its authority to an attacker. Organisations should hunt for the campaign as an identity and data-movement sequence, not wait for a ransomware payload or one definitive group name.
Additional sources
- Google Threat Intelligence Group: Welcome to BlackFile
- BleepingComputer: activity linked to UNC6671 and BlackFile-branded operations
Update, 22 August: Apollo confirms the campaign produced a breach
Apollo Global Management has now confirmed a successful intrusion within the financial-sector social-engineering wave. In a notification filed with the California Attorney General, the company said unauthorised users accessed certain cloud platforms between 6 and 10 July 2026 following a social-engineering incident.
Apollo determined on 12 August that the affected information may include names, dates of birth, contact details, home addresses and Social Security numbers. The company has not disclosed how many people were affected. It said its investigation had not found evidence that the data had been publicly posted or used for identity theft or fraud at the time of notification.
This changes an important part of the original evidence. The first reports established a campaign and named organisations that had been targeted, but targeting did not prove compromise. Apollo is now a confirmed breach with identified personal-data exposure. That does not establish that every other financial firm named in earlier reporting was breached.
CyberScoop described Apollo as the first named victim to formally disclose sensitive personal-data loss from this financial-sector wave. The publication placed the incident in the context of BlackFile, which Google tracks as UNC6671, and its related extortion brands. Apollo did not publicly name the attacker, so the campaign relationship remains a reporting-based assessment rather than a direct attribution by the victim.
The confirmed access path reinforces the article’s central point. An attacker does not need to defeat MFA cryptography or deploy ransomware when social engineering can transfer control of an authenticated cloud identity or recovery process. Once that authority is obtained, ordinary cloud functions can become the collection channel.
Organisations in the campaign’s target set should review helpdesk calls, password resets, MFA-device enrolments, session creation, forwarding rules, OAuth grants and bulk downloads around suspicious contact. Containment should revoke active sessions and newly registered factors, not only change a password. The investigation should also preserve call records and support tickets because the initial compromise may have occurred outside conventional endpoint telemetry.
Apollo update sources
- California Attorney General: Apollo Management Holdings breach notification, reported 20 August 2026; publication time not displayed
- Bloomberg Law: Apollo reports data breach from social-engineering incident, published 21 August 2026 at 16:14 UTC
- CyberScoop: Apollo discloses data breach from ongoing financial-sector attack wave, published 21 August 2026; publication time not displayed
Continue the series: AMER Cyber & Digital Law Series index


