Why MFA Doesn't Stop This Vishing Attack

Vishing is voice phishing: a social engineering attack carried out over a phone call instead of an email. It runs on the same mechanics as phishing: impersonation, urgency, a request that sounds routine, but the phone is a harder channel for corporate filters to inspect, and a caller can build pressure before an employee has time to verify the request.

In August 2026, Google's Threat Intelligence Group published details of a vishing campaign built around exactly that pressure, aimed squarely at financial services, private equity, and professional services firms. The campaign matters because it doesn't target a missing control. It targets the gap between a technical control and the human decision that activates it.

How the campaign worked

Google tracks the group behind it as UNC6671, an extortion operation that started the year under the name BlackFile and has since operated under several brands, including Redact, Pink, Helix, and Falcon. The method stayed consistent across the rebrands: call an employee's personal mobile number, not their work line, and pose as a coworker or an IT helpdesk technician handling an urgent security migration. The caller walks the employee to a spoofed login page. The employee enters their credentials, then their MFA code, and the attacker's infrastructure captures and reuses both while the session is still live.

The pretext works because it borrows authority, not because it's technically clever. A caller who sounds like IT support already has implicit permission to ask for cooperation, the request carries urgency that discourages a pause to verify, and most employees are inclined to help resolve what sounds like a shared problem rather than to question it.

That last step is what separates this from ordinary credential theft. Google identified 72 malicious websites built specifically for this campaign, using adversary-in-the-middle infrastructure that sits between the employee and the real login page, intercepting the password and the authentication code as they're entered. In several cases, the group also used compromised email accounts to trigger password resets on applications outside single sign-on, then deleted the confirmation emails and security alerts that would normally flag the change.

Between January and May 2026 alone, Google's Threat Intelligence Group traced roughly $10.69 million in bitcoin, about 141.65 BTC, across 18 wallets linked to the operation. SecurityWeek later reported initial ransom demands ranging from $1 million to more than $3 million, negotiated down by 50 to 75 percent in most cases, with final payments averaging around $750,000 in more than half of the tracked incidents. Several of the firms targeted rank among the largest private equity firms in the world by assets under management.

Reporting on the campaign has drawn a careful distinction between firms whose employees were targeted and firms confirmed to have been compromised, and that distinction hasn't been resolved for every organization involved. Available reporting does confirm that the operation used phone-based targeting broadly across private equity, asset management, and professional services.

Why MFA didn't stop it

Multi-factor authentication was built on an assumption: that stealing a credential and using it happen at different times and in different places. A password gets phished today; an attacker tries to use it later, from somewhere else, and the second factor catches the mismatch.

Vishing paired with adversary-in-the-middle infrastructure collapses that gap. The theft and the use happen in the same call, in the same minute, with the attacker's fake page relaying everything to the real one in real time. If the second factor is something an employee can read aloud, tap to approve, or type into a page that looks legitimate, it can be captured exactly as it's meant to be used. The control still functions. It no longer distinguishes the real login attempt from the one happening on the phone at the same time.

That's the question worth asking about any MFA deployment: not whether it exists, but whether a code or approval on it can be relayed by a person, under pressure, during a live conversation. If it can, the technology is working as designed and still not doing its job.

Why private equity is an attractive target

Private equity firms combine a few conditions that make this kind of call unusually effective. Large amounts of money move on tight, deal-driven timelines. Employees routinely coordinate with portfolio companies, fund administrators, auditors, and limited partners they've never met in person, so a caller who sounds informed about a live deal doesn't automatically sound suspicious. Urgency is already the normal operating tempo: closings, capital calls, and wire instructions frequently do need to move fast.

That combination is what a vishing script is built to exploit. A call framed as "we need to fix your access before the close" doesn't read as an incident. It reads as one more operational request in a day full of them, which is precisely the moment an employee is least likely to pause and verify.

Key insight

This campaign didn't defeat MFA as a technology. It defeated an assumption baked into how most organizations deploy it: that authentication happens at arm's length from the attacker, not in a live conversation with them. Once a caller is on the phone at the moment a code is entered, MFA becomes a formality the attacker walks through alongside the employee.

That reframes the problem as an authentication design question, not only an awareness gap: which of the credentials an organization relies on can be handed over, read aloud, or approved by a person mid-call, and which ones physically cannot be.

Vishing and MFA: three questions security leaders are asking

Can MFA stop a vishing attack? MFA stops an attacker who only has a stolen password. It's far less effective once the attacker is on the phone at the moment the second factor is entered, because a real-time relay can capture and reuse it before the session closes. Phishing-resistant methods, hardware keys or passkeys bound to a specific site and session, close that gap because they can't be read aloud or relayed over a call.

How does adversary-in-the-middle vishing work? The attacker calls an employee, usually on a personal number, with a credible pretext and guides them to a fake login page that sits between the employee and the real service. Everything the employee enters, password and MFA code, gets relayed to the real service in real time, giving the attacker a valid session.

What should financial services and private equity firms do differently? Verify any request to reset access, change banking details, or approve a transfer through a channel the employee starts independently, not one the caller provides. Prioritize phishing-resistant authentication for high-risk roles, and include realistic phone-based scenarios in security awareness training, not only email simulations.

What this means in practice

Any request to reset access, change banking details, or approve a transfer should be verified through a channel the employee initiates independently, not the one the caller is already on. Hanging up and calling back a known number closes the exact gap this campaign was built to exploit.

For high-value approvals, codes that a person can read aloud, enter into a page, or approve without transaction context can become the weakest link in the chain. Phishing-resistant methods, hardware security keys or passkeys bound to the specific site and session, can't be relayed over a phone call even if an employee wants to help. Approval should also be tied to the transaction itself, not only to a successful login: systems that record who approved what amount, to which destination, close a step that credential theft alone can still get around.

None of this works as a single control. The pattern behind this campaign, helpdesk impersonation, a personal-device call, an urgent request, a lookalike portal, is easier to catch when identity, email, and helpdesk activity are reviewed together rather than as separate signals. And most security awareness programs still simulate email phishing almost exclusively. Training that includes a realistic vishing scenario, a plausible pretext, real urgency, a request to skip the normal ticketing process, tests the exact behavior this campaign relied on, rather than one attackers have largely moved past.

The organizations targeted in this campaign weren't necessarily careless. Many had MFA in place, which is more than a lot of firms can say. The gap wasn't the absence of a control. It was a control built for a threat model that didn't include an attacker present, live, on the phone, at the exact moment it mattered. As authentication improves, the phone call remains one of the few places where a well-designed system still depends entirely on a person's judgment in the moment.

When an employee gets an unexpected call asking for urgent verification, is the safe response also the easiest one to make?