Post cover image

August 9, 2026

Why Your Biggest Attack Surface Might Be a Phone Call

For years, security teams have poured resources into email defenses: spam filters, sandboxing, link analysis, user training on phishing red…

By Paritosh

5 min read

For years, security teams have poured resources into email defenses: spam filters, sandboxing, link analysis, user training on phishing red flags. And it's worked, to a point. Attackers noticed the same thing we did: email is getting harder to abuse. So a growing number of them simply stopped using it.

A campaign tracked by Google's Threat Intelligence Group, attributed to a financially motivated group called UNC6671, is a clean example of where initial access is heading. No malicious attachment. No suspicious link in an inbox. Just a phone call.

How the attack actually works

The group's callers pose as internal IT helpdesk staff. They reach employees directly on personal mobile numbers, not work lines, which already sidesteps most enterprise monitoring. The pretext is almost always the same: an urgent, mandatory security update. Enroll a new passkey. Re-verify MFA. Complete a Microsoft 365 or Okta migration before access gets locked. In some cases, the caller ID is spoofed to match the real helpdesk number, which removes the last bit of hesitation a cautious employee might have had.

The victim is walked to a fake login page that looks identical to the real SSO portal. Behind that page sits adversary-in-the-middle infrastructure, meaning the attacker isn't just harvesting a static password. They're relaying the entire authentication session in real time, capturing the credential and the MFA token together, at the exact moment the victim enters them. That's the part that makes this dangerous: MFA doesn't stop it, because MFA isn't being bypassed, it's being intercepted live.

Once the attacker has a valid, authenticated session, they don't need to "hack in" anywhere. They're already in, with legitimate access. From there, automated Python and PowerShell scripts pull data out of Microsoft 365 and Okta-connected SaaS environments. What began as a phone call ends as a full extortion case, with stolen data used as leverage.

Why this campaign keeps evolving

What's notable isn't just the technique, it's the group's persistence. UNC6671 originally operated under a brand called BlackFile, which was announced as "retired" earlier this year. But the retirement was mostly cosmetic. The same infrastructure and the same operators resurfaced under several new extortion names, and the underlying playbook (vishing, spoofed portals, AiTM capture, scripted exfiltration) hasn't changed. Only the targeting has shifted, moving toward financial services, private equity, and law firms, where stolen deal and client data creates maximum pressure during extortion.

That's a pattern worth sitting with: takedown or rebrand doesn't mean the threat is gone, it means the TTPs go dormant under a new name until defenders stop watching for them.

None

What actually reduces this risk

A few things matter more than others here:

Move critical accounts to phishing-resistant MFA. Push-based and OTP-based MFA can be relayed through an AiTM proxy. FIDO2 passkeys and hardware security keys are built specifically to resist this, since the cryptographic handshake is tied to the legitimate domain, so a spoofed portal can't complete it.

Redefine what "suspicious" looks like. Most phishing training still centers on email. Employees need an equally clear rule for calls: IT and security teams do not ask you to log in live during a phone call, period, no exceptions. That single sentence, repeated often enough, closes most of the social engineering gap here.

Watch identity behavior after login, not just the login attempt. AiTM kits are built to make the authentication itself look completely clean: right password, right MFA, right device fingerprint in some cases. The signal is downstream: unusual session activity, access from new locations or clients, or automated data pulls immediately following a login. Detection has to shift from "was this login malicious" to "is this authenticated session behaving normally."

A closer technical look

A few details from the report are worth calling out for anyone building detections around this:

Infrastructure pattern. UNC6671 has moved away from unique, org-tailored phishing domains toward a subdomain-based model, with a chunk of the domains registered through the same registrar. That's a useful pivot point for threat intel teams: infrastructure reuse across campaigns is often easier to catch than the social engineering itself, so domain registration monitoring and passive DNS correlation should sit alongside any awareness training.

Mapping to MITRE ATT&CK. The chain lines up cleanly with a few well-known techniques, which makes it a good candidate for a purple-team exercise rather than just a training slide:

  • T1566.004 (Phishing: Spearphishing Voice) for the initial vishing call
  • T1557 (Adversary-in-the-Middle) for the live credential and MFA relay
  • T1550.004 (Use Alternate Authentication Material: Web Session Cookie) once the session token is captured and reused
  • T1567 (Exfiltration Over Web Service) for the scripted pull from M365/Okta-connected SaaS apps

Where detection actually has a chance. Because the login itself looks legitimate, the highest-value detection surface is conditional access and session telemetry rather than the authentication event: impossible-travel alerts on a session token immediately reused from a different ASN, new OAuth app consents granted right after a login, or a spike in Graph API/Okta System Log calls from an account that normally shows light, human-paced activity. Any of these, correlated with a helpdesk-themed call reported around the same window, is a strong enough signal to isolate the session and force re-authentication before scripted exfiltration completes.

Infrastructure and IOCs from the report

GTIG published a dedicated indicator collection alongside the writeup, and a few patterns stand out even from a quick scan:

Domain naming convention.

Registrar concentration. A large share of the domains observed between April and August 2026 were registered through two providers: TUCOWS in the earlier wave, shifting to NICENIC INTERNATIONAL GROUP for the majority of domains registered from late April onward. Most sit behind Cloudflare, with a smaller cluster fronted by DDOS-GUARD or Private Layer. That registrar/hosting concentration is a reasonable input for a domain-monitoring or takedown-request workflow.

Operational tempo increased. Domain registration accelerated from roughly one new domain every 2.2 days in the April–May wave to about one every 1.6 days by June–July, with a burst of seven domains stood up in a single 72-hour window in late July. That kind of velocity is itself a signal worth tracking if you're doing proactive domain-squatting or brand-monitoring for your own org's SSO/helpdesk naming conventions.

A sample of the flagged domains and infrastructure (full list is in GTIG's published collection):

Domain                   Registrar              Hosting
passkeyhelpdesk[.]com    NICENIC         Cloudflare / Private Layer
createssopasskey[.]com   NICENIC        Cloudflare / Private Layer
oktaenroll[.]com         TUCOWS               Cloudflare
passkeydeploy[.]com Internet Domain Service BS Corp. DDOS-GUARD
setupsso[.]com           TUCOWS               Cloudflare

Network infrastructure flagged in the report includes AiTM reverse proxy IPs on Private Layer INC (Switzerland) and MEVSPACE (Poland), a phishing reverse proxy on DDOS-GUARD (Russia), and exfiltration traffic routed through both hosting-provider IPs (Tzulo, Hydra Communications) and residential proxy pools on AT&T, Comcast, Starry, and Optimum, likely used to make the SaaS access look like it's coming from a legitimate home connection.

Scripting fingerprints worth alerting on: GTIG called out specific user-agent strings tied to the automated exfiltration stage, including python-requests, WindowsPowerShell, and an Okta Android SDK string used on a Pixel device. Any of these appearing against an account that normally authenticates from a standard corporate browser is worth a closer look.

One evasion detail worth flagging to your SOC: in later intrusions, the group used compromised accounts to reset passwords on non-SSO apps, then deleted the resulting password-reset and MFA-change notification emails to avoid tipping off the user or triggering automated alerts. If your alerting depends on the user seeing and reporting that notification, this specifically defeats it, so alerting should be built on the audit log event itself, not on the assumption that the notification reached anyone.

The bigger shift

This isn't really a story about one threat group. It's a preview of where initial access is going across the board, toward the identity layer, and toward channels like voice that most security stacks were never built to monitor. The attackers didn't need a zero-day. They needed a convincing story and thirty seconds of an employee's trust.

If your organization is still measuring social engineering readiness purely through simulated phishing emails, this is a good week to ask whether that's still the right test.

Source: Google Threat Intelligence Group and Mandiant, "UNC6671 Rebrands: Multi-Brand Vishing Extortion Targets Financial Services and Enterprise Cloud Environments," Google Cloud Blog, August 6, 2026. Full IOC collection published via GTIG's VirusTotal collection linked in the original report.