UNC6671: Multi-Brand Vishing / AiTM Extortion (BlackFile → Redact / Pink / Helix / Falcon)

UNC6671 is a financially motivated data-theft extortion actor tracked by Google Threat Intelligence Group (GTIG)/Mandiant since early 2026. It does not encrypt: it calls. Operators phone targeted employees on personal mobile numbers, sometimes spoofing the caller ID of the real IT helpdesk, and claim an urgent, mandatory FIDO2 passkey enrollment or MFA update is required. The victim is walked to a lookalike SSO portal (root domains such as createssopasskey[.]com with a victim-specific subdomain) where Adversary-in-the-Middle (AiTM) reverse-proxy infrastructure captures the credential and the live MFA/session token in real time and replays it to the real identity provider. From there, automated python-requests/PowerShell scripts pull data out of Microsoft 365 and Okta at volume, and the operators delete password-reset confirmations and MFA-change security alerts to buy time before the extortion demand lands ($1M–$3M asked, ~$750K typical settlement).

UNC6671 announced BlackFile's "retirement" on May 11, 2026 while continuing to collect ransom payments through the same wallets, then re-emerged across four parallel extortion brands: Redact, Pink, Helix, Falcon, which GTIG's infrastructure analysis shows share the same phishing templates, root-domain naming convention, and back-end proxy infrastructure. Targeting has moved from broad manufacturing/healthcare/insurance (Apr–May 2026) through technology/transportation/hospitality (June) to financial services, private equity, law firms, and rating agencies (July 2026), sectors chosen for leverage in extortion negotiations, not just data volume. Operational tempo has accelerated: new phishing domains were registered roughly once every 1.6 days in June–July 2026, versus once every 2.2 days in April–May.

On August 7, 2026, Levi Strauss & Co. filed an SEC Form 8-K disclosing that an unauthorized third party used social engineering to compromise three employee-issued computers and exfiltrate corporate data. The filing itself names no threat actor and no technique (not vishing, not AiTM, not any specific group); several outlets have connected the timing and TTP profile to UNC6671's known playbook, but that link is circumstantial and unconfirmed by the company. This pack treats the Levi Strauss disclosure as corroborating context for UNC6671's current operational tempo and sector focus, not as a confirmed UNC6671 victim.

Defender priority: this is an identity-and-people problem, not an endpoint-malware problem. The single highest-leverage control is mandating phishing-resistant, origin-bound MFA (FIDO2/WebAuthn passkeys) as the only allowed authenticator for SSO: it renders the AiTM proxy technically unable to relay a valid session regardless of how convincing the phone call is. Everything else in this pack (detection, hardening, containment) is defense in depth around that one control.

Web-hunter note (requirement 8 compliance): every fetched source above was reviewed as untrusted data before use. No source contained text directed at the research agent (no "ignore instructions," no claimed authorization, no embedded requests to run commands or fetch further URLs). One benign false-positive string match ("act as a final fail-safe," describing a technical control in the GTIG hardening section) was manually reviewed and confirmed to be ordinary prose, not an injection attempt. No source was excluded on integrity grounds.

Decision: attribution of the Levi Strauss incident to UNC6671 is reported as unconfirmed / media-inferred throughout this pack, matching what the primary SEC filing and the most careful secondary coverage actually say. Detections and IOCs are built entirely from the GTIG primary report; the Levi Strauss disclosure informs the executive summary and targeting narrative only.

Hunt hypotheses (ordered by fidelity)

1. H1 (high conf). Managed endpoints will show DNS resolution or browser navigation to UNC6671's passkey/SSO-themed root-domain naming pattern before a credential-theft report surfaces elsewhere.
2. H2 (high conf). Managed endpoints or network egress logs will show direct connections to the small, dedicated set of AiTM reverse-proxy and automated-exfiltration IPs GTIG published, since this infrastructure is not shared hosting.
3. H3 (med conf). Okta/Entra sign-in logs will show authentication failures immediately followed by new MFA/passkey factor registration for the same user: the "abandoned challenge, then re-enroll" signature GTIG calls out as the core detection opportunity.
4. H4 (med conf). Okta/Entra sign-in logs will show successful SSO authentication from residential-ISP or boutique-VPN IP ranges that do not match the user's established geographic/ASN baseline.
5. H5 (high conf). Microsoft 365 unified audit logs will show high-volume FileAccessed/FileDownloaded events attributed to scripting-library user agents (python-requests, WindowsPowerShell, Go-http-client) rather than an interactive browser.
6. H6 (med conf). Microsoft 365 audit logs will show deletion of password-reset confirmation or MFA-change security-notification emails, and/or creation of inbox rules that route or delete such messages, within the same session as unusual data access.

Attack chain

Gap acknowledged up front: step 1 (the phone call itself) and step 8 (extortion messaging) have no Falcon telemetry mapping and are marked as coverage gaps in Section 15: they are handled through user training and incident-response process, not detection engineering.

Okta Admin Console

• Security → Multifactor → review which factor types are enabled; confirm SMS/voice/push are not offered as fallback options alongside FIDO2 (a fallback factor is exactly what a vishing call talks a victim into re-enrolling).
• Reports → System Log: manually spot-check system.multifactor.factor.setup events from the last 14 days for a burst pattern (several users enrolling a new factor within the same hour/day with no corresponding helpdesk ticket).

Microsoft Entra admin center

• Protection → Conditional Access → Insights and reporting: check for sign-ins satisfying MFA via a method other than FIDO2/Windows Hello for Business in the last 30 days.
• Identity → Monitoring & health → Sign-in logs: filter for Risk level during sign-in = medium/high combined with a successful MFA satisfaction: GTIG's own detection recommendation for abandoned-challenge-then-enroll.

Microsoft Purview / Exchange admin center

• Audit → Search: filter Operation in (SoftDelete, HardDelete, MoveToDeletedItems) with subject keywords matching password-reset or MFA-change notification templates over the last 30 days.
• Exchange admin center → Mail flow → Rules, and per-mailbox inbox rules: look for newly created rules that move or delete messages from your IdP's or helpdesk's notification sender address.

DNS / registrar monitoring

• UNC6671's root-domain naming convention pairs "passkey," "sso," "okta," or "mfa" with a verb (enroll, setup, deploy, add, sync, portal, etc.). Passive-DNS/certificate-transparency monitoring for new registrations matching *passkey*.com, *sso*.com alongside your own brand name is a higher-recall (and higher-noise) complement to the static domain list in Section 10: treat hits as investigate-only, not block-on-sight.

Helpdesk process control

• Review helpdesk call logs / ticketing for any record of an outbound "mandatory security migration" or "passkey enrollment" campaign in the affected window: if none exists, any employee report of such a call is a live incident, not routine IT communication.

Three queries are strong Custom IOA / Scheduled Search candidates: deterministic, static-indicator matches with low expected noise. The rest are Investigate-only: correlation-heavy, tenant-schema-dependent, or too FP-prone to alert on unattended.

Alert package: Q1 / Q2 (IOA-eligible)

Alert subject: [HIGH] Detection: UNC6671 AiTM/Phishing Infrastructure: endpoint contact with known passkey-vishing domain or proxy IP

Immediate actions: isolate the host pending triage; identify the logged-on user; check whether the user reports a recent "IT helpdesk" or "security migration" phone call; suspend the user's SSO session and force MFA/passkey re-enrollment through a verified out-of-band channel (never the number the caller provided).

Triage checklist: (1) confirm the DNS/network hit against the static IOC list, not a lookalike false match; (2) pull the user's Okta/Entra sign-in history for the surrounding 24h; (3) check for a new MFA/passkey factor registered in that window; (4) check M365 UAL for FileAccessed/FileDownloaded bursts from the same identity; (5) check for deleted security-notification email or new inbox rules; (6) if any of 2–5 are positive, escalate to full incident response per Section 14.

Pivot queries: re-run Q4/Q8 scoped to the specific actor.alternateId/UPN identified; re-run Q6/Q7 scoped to the same UserId across a 30d window to size the exfiltration blast radius.

Playbook A: Enforce phishing-resistant-only MFA in Entra ID (Conditional Access via Microsoft Graph PowerShell)

Prerequisites: Global Administrator or Conditional Access Administrator role; Microsoft.Graph PowerShell SDK installed; break-glass emergency-access accounts already provisioned and excluded from the policy. Reboot required: no (cloud-side policy change, no endpoint reboot). Rollback: disable the Conditional Access policy (state = Disabled) in the Entra admin center or via Update-MgIdentityConditionalAccessPolicy: takes effect immediately, no residual state on endpoints.

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$params = @{
  displayName = "Require phishing-resistant MFA for SSO"
  state = "enabledForReportingButNotEnforced"   # validate in report-only mode first
  conditions = @{
    users = @{ includeUsers = @("All"); excludeUsers = @("REPLACE_WITH_BREAK_GLASS_ACCOUNT_OBJECT_ID") }
    applications = @{ includeApplications = @("All") }
  }
  grantControls = @{
    operator = "AND"
    builtInControls = @()
    authenticationStrength = @{ id = "00000000-0000-0000-0000-000000000004" }  # Phishing-resistant MFA strength
  }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

# After a report-only validation window with no unexpected sign-in blocks, promote to:
#   state = "enabled"

Step 2: equivalent Okta-side policy (Prerequisites: Super Admin role, Okta API token with okta.policies.manage scope. Reboot required: no. Rollback: PUT the prior policy JSON back, or delete the new rule via the Admin Console: takes effect immediately):

curl -X POST "https://REPLACE_WITH_OKTA_ORG.okta.com/api/v1/policies" \
  -H "Authorization: SSWS REPLACE_WITH_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "ACCESS_POLICY",
    "name": "Require FIDO2 WebAuthn for SSO",
    "conditions": { "people": { "groups": { "include": ["REPLACE_WITH_ALL_USERS_GROUP_ID"] } } },
    "settings": {
      "factors": { "webauthn": { "enroll": "REQUIRED" }, "sms": { "enroll": "NOT_ALLOWED" }, "voice_call": { "enroll": "NOT_ALLOWED" } }
    }
  }'

Playbook B: IdP alerting for the abandoned-challenge (auth-failure → MFA-enroll) pattern

Prerequisites: NG-SIEM ingest of Okta System Log or Entra sign-in/audit logs already configured; Falcon Scheduled Search authoring permission. Reboot required: no. Rollback: delete or disable the Scheduled Search: no endpoint or IdP state is changed by the detection itself.

1. Falcon console -> NG-SIEM -> Scheduled Searches -> New
2. Paste Q4 from Section 8 (auth-failure + factor.setup correlation query)
3. Schedule: every 15 minutes, lookback 20 minutes (covers the "immediately followed by" window)
4. Trigger condition: >=1 result row
5. Notification: route to SOC queue as Investigate-only (NOT auto-page) until a
   2-week tuning window with zero false positives from legitimate self-service resets
6. After tuning: promote notification to page on-call analyst

Playbook C: Tamper-resistant mailbox audit logging + security-notification deletion alert

Prerequisites: Exchange Online / Microsoft Purview administrator role; Microsoft 365 E5 or Purview Audit (Premium) license for extended retention. Reboot required: no. Rollback: Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $false reverts logging (not recommended: only for a scoped maintenance window); the alert rule itself can be disabled independently via Disable-ProtectionAlert without touching audit ingestion.

# Ensure unified audit logging is enabled and not owner-disableable
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

# Create an alert policy for deletion of security-notification mail
New-ProtectionAlert -Name "UNC6671 - Security notification deleted" `
  -Category ThreatManagement `
  -NotifyUser "REPLACE_WITH_SOC_DISTRO@REPLACE_WITH_ORG.com" `
  -Operation SoftDelete,HardDelete,MoveToDeletedItems `
  -Severity High `
  -ThreatType Activity

Do not rely on password reset alone: the operators' core objective (session/token replay) already bypassed the password once; account containment must include full session revocation and MFA-factor review, not just a new password.

Validation gates (Section 11): endpoint queries are deployable as-is pending a benign-baseline run; identity/SaaS queries require confirming Identity Protection and M365 UAL ingest per tenant before promotion. No query in this pack should be promoted to a blocking/auto-response action without the Section 11 baseline and positive-test steps completed first.

Full verbatim source snapshots saved at research time: UNC6671-VishingAiTM-Hunt-sources/01-07-*.txt (IOC provenance gate).