UNC6671 BlackFile Vishing + AiTM SSO Extortion Campaign — Microsoft 365 & Okta Identity Compromise

Indicators

• Employee reports unsolicited call to personal mobile from someone claiming to be internal IT or help desk mandating a 'passkey migration' or 'MFA update'
• Sign-in from an AiTM reverse-proxy IP immediately followed by legitimate session activity — impossible-travel or token-replay alert in Azure AD / Okta
• New OAuth application consent granted in Microsoft 365 tenant shortly after a suspicious authentication event (Operation: 'Add app role assignment to service principal', 'Consent to application')
• Bulk download or enumeration activity against SharePoint, OneDrive, or Exchange via Microsoft Graph API (FileDownloaded, FileSyncDownloadedFull events)
• Python or PowerShell scripts detected executing against Microsoft 365 or Okta APIs for programmatic data exfiltration
• TOX communication channel contact or ransom note referencing 'BlackFile' data leak site (DLS)
• Credential harvesting domain in browser history or proxy logs not matching the organisation's legitimate SSO URL
• MFA factor downgrade or new factor enrollment events in Okta System Log following suspicious authentication

Likely causes

• Use of legacy (non-phishing-resistant) MFA methods (TOTP, SMS, push) that AiTM proxies can relay in real time, allowing session token theft without defeating the MFA prompt
• Employees answering unsolicited calls on personal phones outside corporate endpoint monitoring, making social engineering easier and harder to detect
• Insufficient Conditional Access policies that do not enforce device compliance or restrict sign-in from known-bad or anonymous proxy IP ranges
• Absence of user-and-entity behaviour analytics (UEBA) alerting on anomalous bulk data access patterns via Microsoft Graph or Okta APIs
• Lack of controls restricting OAuth application consent, enabling attackers to establish persistent access via rogue app registrations
• Employees unfamiliar with vishing tactics accept the IT pretext and voluntarily enter credentials on attacker-controlled harvesting sites

Diagnostic steps

1. Collect and review Microsoft Entra ID sign-in logs for the affected user(s) for 72 hours surrounding the reported vishing call. Filter for sign-ins from unexpected IP addresses, ASNs associated with hosting providers or anonymisation services, and 'Interrupted' or 'Success' events immediately followed by impossible-travel alerts. Navigate to Entra ID > Sign-in logs > filter by User and Date range.
   Confirm whether an AiTM credential relay succeeded and identify the attacker-controlled session origin IP and timestamp.
2. Query the Microsoft 365 Unified Audit Log for OAuth application consent events in the window following suspicious sign-in. Search: Operations 'Add app role assignment to service principal' and 'Consent to application'. Also search for bulk file access events (FileDownloaded, FileSyncDownloadedFull) against SharePoint and OneDrive. Use Security & Compliance Center > Search > Audit log search.
   Determine whether the attacker established persistent OAuth access or began exfiltrating data via Microsoft Graph after obtaining a valid session token.
3. Review Okta System Log for the affected user(s): filter on event types 'user.session.start', 'policy.evaluate_sign_on', and 'application.lifecycle.update'. Cross-reference client IP addresses against known UNC6671 harvesting infrastructure. Check for MFA factor downgrade or new factor enrollment events. Navigate to Okta Admin > Reports > System Log.
   Identify AiTM relay activity in Okta and determine whether the attacker enrolled a new authenticator to maintain access after the initial session.
4. Interview the targeted employee to establish the exact timeline: when they received the call, what pretext was used (e.g., 'passkey migration', 'MFA update'), which URL they were directed to, and what credentials or MFA codes they provided. Collect browser history and any SMS/push notifications received during the call.
   Corroborate technical log evidence, recover the attacker's credential harvesting domain for blocklisting, and establish the precise window of compromise for downstream forensics.
5. Search proxy, DNS, and endpoint logs for connections to the credential harvesting domain identified in step 4. Expand the query to identify any other employees who may have visited the same or similar domains. Check for shared registrar, hosting ASN, or certificate patterns in UNC6671's known infrastructure.
   Determine the full scope of affected users and identify additional harvesting domains to block and report.
6. Check for Python or PowerShell process execution on any endpoints or Azure Automation / Logic App resources associated with compromised accounts. Review Microsoft 365 audit logs for Graph API calls consistent with bulk mail export, SharePoint enumeration, or user directory harvesting.
   Confirm whether the exfiltration phase has begun and estimate the volume and sensitivity of data accessed for breach notification decisions.

Resolution path

• 1. IMMEDIATE — Revoke all active sessions for confirmed or suspected compromised accounts in Entra ID: navigate to Entra ID > Users > [user] > Authentication methods > Revoke sessions, or use PowerShell: `Revoke-AzureADUserAllRefreshToken -ObjectId <UserObjectId>`. In Okta: Admin > Directory > People > [user] > More Actions > Expire All Sessions.
• 2. IMMEDIATE — Disable or quarantine the compromised account(s) and reset credentials. In Entra ID: set 'Block sign in' to Yes under user properties. Require re-registration of all MFA factors after reset to prevent attacker-enrolled authenticators persisting.
• 3. IMMEDIATE — Revoke any OAuth application consents granted during the attack window. In Entra ID: Enterprise Applications > [suspicious app] > Properties > Delete, and remove associated service principal permissions.
• 4. SHORT-TERM — Block attacker-identified credential harvesting domains and IP addresses at the web proxy, DNS resolver, and email gateway. Share IOCs with Microsoft (report to MSTIC) and Okta Security.
• 5. SHORT-TERM — Enable or enforce Conditional Access policies requiring phishing-resistant MFA (FIDO2 security keys or Microsoft Authenticator passkey) for all Microsoft 365 and Okta access. Remove weaker MFA methods (SMS, voice call) from tenant-wide policy.
• 6. SHORT-TERM — Audit and restrict OAuth app consent: set tenant-wide user consent to 'Do not allow user consent' and require admin approval for all app registrations. Navigate to Entra ID > Enterprise Applications > Consent and permissions.
• 7. MEDIUM-TERM — Engage HR and corporate communications to alert all employees about UNC6671 vishing tactics: IT will never call personal phones to demand MFA resets; employees should hang up and call the IT help desk on the official number.
• 8. MEDIUM-TERM — Preserve all relevant logs (Entra ID sign-in logs, Okta System Log, Microsoft 365 UAL, proxy logs) in immutable storage for potential law enforcement referral and breach notification compliance.

Prevention

• Deploy phishing-resistant MFA (FIDO2 hardware security keys or passkeys) as the mandatory authentication method for all Microsoft 365 and Okta access — remove SMS, voice call, and TOTP options from policy to eliminate AiTM relay viability.
• Enforce Conditional Access policies in Entra ID and Okta that require managed/compliant devices, restrict sign-in from anonymous proxies and high-risk IP ranges, and alert on impossible-travel events in real time.
• Disable user-driven OAuth application consent in Microsoft 365 and Okta; require explicit admin approval for all new application registrations to prevent attackers establishing persistent access via rogue apps.
• Train all employees — with regular simulated vishing exercises — that IT will never call personal phones to demand credential or MFA updates; establish a verified callback procedure (official help desk number) as the only legitimate support channel.
• Implement UEBA alerting on bulk data access patterns (SharePoint/OneDrive mass download, Exchange mailbox export) via Microsoft Graph API to detect the exfiltration phase before data leaves the tenant.
• Monitor domain registration and certificate transparency logs for newly registered domains mimicking your organisation's SSO URLs, and pre-emptively block them at the DNS and proxy layer.
• Establish a dedicated vishing reporting channel (e.g., a Slack/Teams command or email alias) so employees can immediately report suspicious calls, enabling rapid IOC collection before a compromise is completed.

Tools

• Microsoft Entra ID (Azure AD) admin portal — identity and session management
• Microsoft 365 Unified Audit Log (UAL) — data exfiltration and OAuth consent forensics
• Okta Admin Console / System Log — SSO session and authenticator forensics
• Microsoft Graph API — programmatic audit log retrieval and account remediation
• PowerShell + AzureAD / Microsoft.Graph modules — bulk session revocation and account management
• Corporate web proxy / DNS resolver — IOC blocking and historical query review
• SIEM / UEBA platform — correlation of AiTM and exfiltration indicators across log sources

References

• Welcome to BlackFile: Inside a Vishing Extortion Operation — Google Threat Intelligence Group