UNC6671 helpdesk number spoofing targets enterprise cloud accounts

UNC6671 helpdesk number spoofing has appeared in recent intrusions targeting financial services, private equity and professional-services organisations, according to Google Threat Intelligence Group and Mandiant. The researchers said callers have impersonated internal IT staff, in at least some cases displaying a legitimate helpdesk number, before taking over cloud accounts and extracting data for extortion.

The August 6 update describes a campaign that has remained active despite the alleged May retirement of the BlackFile extortion brand. Google says its analysis links the activity to UNC6671 and to several extortion brands, including Redact, Pink, Helix and Falcon, while allowing that splintered affiliates or shared phishing infrastructure remain possible explanations for some overlaps.

How does UNC6671 helpdesk number spoofing work?

The calls often go to employees’ personal mobile phones, a choice Google says is intended to take targets beyond usual corporate security tools and support channels. The callers present an urgent request, such as a compulsory passkey deployment or multi-factor authentication update, and direct the employee to a site made to resemble the company’s sign-in page.

This is a live adversary-in-the-middle attack. As the employee enters credentials at the imitation portal, the attacker relays them to the legitimate single sign-on provider. The victim may then approve or enter a multi-factor authentication challenge as part of what they believe is the security process. Google says the attackers capture credentials and MFA tokens, then register an attacker-controlled authentication device to retain access.

The campaign is characterised by Google as data-theft extortion. Its reports say UNC6671 has used the resulting identity session to reach Microsoft 365 and Okta environments, including connected services such as SharePoint, OneDrive, Zendesk and Salesforce.

Cloud data collection and attempts to avoid detection

After obtaining access, the group has used automated Python and PowerShell scripts, Microsoft Graph and direct HTTP requests to collect files, Google said. Captured session cookies can be reused to retrieve documents directly, rather than through a conventional download process.

That distinction has consequences for monitoring. Google said direct retrieval can generate a FileAccessed event instead of FileDownloaded in Microsoft 365 audit logs, potentially receiving less scrutiny where security teams focus on download activity. It also reported signs of scripted access, including Python or PowerShell user-agent strings while a session presents itself as Microsoft Office.

In more recent activity, Google said compromised email accounts were used to seek password resets for non-single-sign-on applications. The operators then deleted reset confirmations, secondary notices and alerts related to security or MFA configuration changes, according to the report.

What should organisations examine?

Google says these incidents result from social engineering rather than a vulnerability in vendor products or infrastructure. It recommends phishing-resistant MFA where possible; its earlier analysis says FIDO2 security keys and passkeys are more resistant to this type of manipulation than push- or SMS-based methods.

• Require escalation or multiple approvals for privileged-account password and MFA resets.
• Use in-person verification where a remote reset cannot be verified safely, according to guidance from security vendor Push Security.
• Review unexpected account-security changes, new MFA-device registrations and unusual cloud-access telemetry, including FileAccessed activity and indications of scripted requests.

Caller ID alone is not a reliable identity check when a legitimate helpdesk number can be spoofed. The reported attack instead depends on persuading an employee to complete a real-time authentication flow under a false IT-support pretext.

This story draws on original reporting from PYMNTS.