Voice Phishing, AiTM, and the False Perimeter of Wall Street's Cloud Identity

We do not build for today. We build for the failure case. This is the principle that separates an infrastructure audit from a marketing slide. So when Google's Threat Intelligence Group (GTIG) released a report on UNC6671, a persistent voice-phishing operation, the most important artifact was not the narrative about IT helpdesk impersonation. It was the raw telemetry: 72 web addresses, published for the public, left to dangle in the ecosystem. Reuters, doing what a competent incident responder would do, fed those URLs into DomainTools and urlscan, and mapped the subdomains to a list of Wall Street institutions. The target list reads like an acquisition index: Blackstone, Bridgewater Associates, Apollo Global Management, Bain Capital, KKR, TPG, CME Group, Clearlake Capital, and Moody's. Nobody asked whether a zero-day in Okta was exploited. The answer is obvious. The attack uses a telephone. The report confirms what I have found in too many security posture assessments: the weakest link is not code, but the human who answers the phone. And in this campaign, the human is not even sitting behind the corporate VPN. Before we get to the forensic details, let's position UNC6671 properly. Google's GTIG has been tracking this group for some time. The latest report notes that these operations "uniformly leverage tailored IT helpdesk voice phishing (vishing), AiTM credential harvesting panels, and data theft from SaaS applications." Those three components form a predictable attack chain. First, the actor identifies a target employee, often using corporate directories accessible via sales tools, LinkedIn, SEC filings, or brokerages. Then, the actor calls the employee's personal mobile phone. Why personal? Because corporate mobile devices are often protected by mobile device management, call recording, and possibly Zero Trust network access. A personal phone is a clean perimeter. It is outside the enterprise security boundary, and thus outside the firewall's jurisdiction. During the call, the impersonator plays the helpdesk operator—urgent security update, suspicious login from a foreign IP, immediate action required to avoid account suspension. The urgent tone is designed to overwhelm analytical thought. The employee is directed to a spoofed login portal. That portal is not a static phishing page. It's an adversary-in-the-middle (AiTM) proxy that sits between the victim and Microsoft 365 or Okta. When the employee types the password, the proxy forwards it to the real service in real time. When the employee enters the MFA code, the proxy forwards that too. The real service validates the code and issues a session cookie. The proxy returns the session to the user—but also captures a copy for the attacker. This is not credential theft and later use. It's credential and session hijacking in one synchronous operation. The attacker is standing next to you, metaphorically, inside the TLS stream. When I dissect the AiTM architecture, I see a familiar pattern. These proxies are built from open-source frameworks like evilginx2 or Modlishka. Their popularity surged because they turn multi-factor authentication from a security control into a forwarding service. MFA solves the wrong equation. It proves possession of a device or a code at a specific moment, but it does not prove the integrity of the session path. The browser believes it is talking to the real Microsoft tenant. The server believes it is talking to the legitimate user. The attacker is the man-in-the-middle, and no cryptographic handshake between client and identity provider is properly validated by the user. Once the session cookie is stolen, the automation begins. Google's report describes "automated scripts to pull data from cloud services." In my own incident audits, I have seen these scripts take the form of PowerShell modules for Microsoft Graph, or Python scripts that hit Okta's admin endpoints. They enumerate users, identify mailboxes associated with M&A pipelines, download SharePoint document centers, and query Teams chats. For a private equity firm, the crown jewels are not in database secrets. They are in unclosed deal memos, private fund structures, litigation holds, and HR files about key partners. A single compromised session from a managing director or general counsel can exfiltrate more value than a malicious smart contract. The timing matters. Google observed a shift in the summer. Through June, the group focused on technology, transportation, and hospitality—sectors where trade secrets, source code, and client data are easy to monetize. In July and August, the infrastructure pointed at private equity firms, law firms, and financial rating agencies. This is a deliberate pivot to target liquidity event information. The attackers are not looking for intellectual property. They are looking for deal terms that can be leveraged for extortion, insider trading, or simply arbitraged on the dark web. And apparently, some firms paid. Google does not name them. Reuters could not confirm the extent of actual breaches. But the fact that payments occurred in at least some cases is a signal that this campaign has crossed from espionage to organized extortion. Now, let's step into the red wire. If I were conducting the audit for UNC6671, I would begin with the 72 URLs. DomainTools and urlscan have already done the initial triage. I would look for infrastructure anomalies: certificate transparency logs that connect the phishing domains to the command-and-control infrastructure; DNS registrations across multiple TLDs; and the use of reverse proxy fingerprints in HTTP response headers. One detail that would not surprise me is the use of TLS certificates from free providers, since the attackers do not need a high reputation. I would also check whether some of the URLs share a common canonical name or IPv6 address. If they do, we are looking at a single operator or, more likely, a service-as-a-service model for vishing. The report states the operations uniformly leverage the same three components, which suggests that UNC6671 is not a single amateur hacking group, but a supply chain of access brokers selling a "compromise as a service." That is a shift in threat modeling that compliance teams have not yet absorbed. The deeper lesson here is not about the next attack; it is about the gap between what security vendors promise and what private equity firms actually enforce. Most firms spend heavily on endpoint detection and response, network segmentation, and Zero Trust architectures. Yet a phone call reaches a knowledge worker, and all of those technological safeguards become ornamental. Why? Because the identity plane, the very layer that should be the strongest, has been reduced to a helpdesk conversation. The attacker does not need to exploit a vulnerability in the Okta client. The attacker simply needs to manipulate the person in front of the screen. In my 2018 Solidity reentrancy audit for the Parity multi-sig library, I spent three weeks tracing ownership update sequences, and I found a logic flaw that allowed nested calls to re-enter the check function before the state change. The fix was not another firewall. It was a reordering of state transitions and formal verification. This Wall Street campaign is the same debate, but the code is human process. The state transition is: "employee receives phone call" → "employee doubts" → "employee clicks link" → "session cookie stolen." The vulnerability is that there is no atomic way to reset the employee's trust in an unknown incoming call. You cannot patch the human brain, but you can redesign the induction. For example, any urgent IT request that arrives by phone and directs to a login page should be automatically rejected unless the user validates the request through a preconfigured TOTP generator or a hardware-bound key. That is a state-machine fix, not a training session. We also need to discuss what this attack reveals about MFA. The industry mantra "MFA is your best defense" is only true if the MFA is phishing-resistant. FIDO2, WebAuthn, and passkeys resist this attack class because the credential is bound to the origin and to the device. When you use a hardware authenticator, the browser validates the Relying Party ID. An AiTM proxy cannot pass that check because its domain differs from the real Microsoft tenant. Yet, from the persistence of this campaign, I would bet that most of the victim institutions are still using push notifications, SMS one-time codes, or software authenticators. Those are all phishable. The solution is not to train users to be suspicious; it is to remove the possibility of MFA forwarding altogether. There is another technical detail that many analysts miss. The Google report calls out "tailored" helpdesk calls. That word implies a deep reconnaissance loop. The attacker knows the employee's manager, the type of laptop issued, the helpdesk ticketing system's branding, and often the employee's recent request history. This is not a spray-and-pray robocall. For each target, the attacker likely footprints the corporate SSO login page, captures the exact logo, and replicates the password-reset flow. I have seen such kits in the shared telemetry of commercial AiTM operations: the portal is a 1:1 clone, including the footer with the company address and the privacy policy link. The only deviation is the destination URL, which is masked by a URL shortener or a lookalike domain. How do the attackers get the employee's personal mobile number? Through data brokers that aggregate corporate email, job titles, and phone numbers. In the United States, business contact databases are often sold legally. You can buy a list of "Managing Directors at Private Equity Firms" with personal mobile numbers for a few thousand dollars. The report does not mention the initial discovery method, but I would not be surprised to find that UNC6671 uses a standard B2B lead generation API. This is another reason why the attack is so hard to defend: the personal phone number is not part of the corporate identity directory, so it is invisible to your IAM monitoring. Let me point out a structural flaw in the post-breach response. Google says "some firms paid." That is a policy failure, not just a security failure. If an attacker understands that the victim will eventually pay, the expected value of the campaign increases. The smarter countermeasure is to have a prearranged, Board-approved policy that prohibits paying extortion demands and provides a data-recovery playbook. But the world of private equity is different from a bank. A leaked deal memo can destroy a fund's reputational standing, even if the data was encrypted in transit and at rest. The reputational damage is instant. So the rational calculus for a private equity partner is to pay quickly and quietly. This asymmetry is exactly why the attackers chose this vertical. They are not attacking a technical weakness; they are attacking an incentive structure. Now, the contrarian angle. Everyone will read this and conclude that private equity needs better security awareness. They will schedule quarterly phish tests and add "voice phishing" to the employee handbook. That is theater. The actual blind spot is the organization's willingness to pay. Google says some firms paid. When an attacker knows the victim has a checkbook and a valuation to protect, the rational decision is to keep calling. This attack is a business model. The defenders think they are dealing with a technical vulnerability, but the attackers are running a well-understood cost-benefit calculus. If 30 percent of their targets pay, the campaign is profitable. The only way to make it unprofitable is to ensure that no one pays, and that requires a legal and operational policy now, before the voice call arrives. Then, there is the AI factor. Vishing can only scale if the attacker has enough human operators to make calls that feel natural. The current version is still human-powered, but the report is a preview. I work on proof-of-personhood protocols for AI agents, and the exact same problem exists in that domain: how does an autonomous system verify that the entity on the other side is human and authorized? For UNC6671, the next iteration will likely use synthetic voices that clone the CIO's cadence or the helpdesk manager's accent. With the price of synthesis dropping to near zero, there will be thousands of tailored calls per day. Your firewall will never see them. Identity infrastructure will need to respond with cryptographic attestations that tie a session to a known device, not to a social interaction. We do not build for today; we build for the failure case. The failure case here is not "employee clicked a link." It is "the enterprise has no method to prove that a session belongs to a specific person after a human gave the session away." The value of a session cookie is exactly like a private key. The art is the hash; the value is the proof. If the proof is stolen, the art is worthless. In this campaign, the proof is the MFA response, and it is forwarded by the victim. Reentrancy doesn't survive scrutiny, but vishing survives because scrutiny is not applied to the auditory channel. Take this to the boardroom. The next time a security vendor promises zero trust, ask which attack paths are out of scope. If the vendor does not name helpdesk phone calls and personal mobile devices, they are selling you a perimeter that does not exist. The forward-looking action is clear: conduct a vishing drill before the next SOC 2 audit, enforce WebAuthn on every cloud application with business risk, and require that any security-sensitive support request is challenged via a hardware token. Then, and only then, will MFA begin to mean something. Otherwise, the next headline will be routine. The call will be recorded, the portal will be taken down, and the data will be gone. The only question is whether your firm will be the next anonymous statistic in Google's report.