A operação BlackFile combina phishing por voz, interceptação AiTM de MFA e exfiltração automatizada em Microsoft 365, Okta, SharePoint, OneDrive, Salesforce e Zendesk.
| Componente | Contas corporativas federadas por SSO, principalmente em Microsoft 365, Okta, SharePoint, OneDrive, Salesforce, Zendesk, Entra e Microsoft Teams. |
| Vetor | Chamadas de vishing para celulares pessoais de funcionários, com pretexto de atualização de passkeys ou MFA, redirecionando a vítima para páginas SSO falsas operadas em modelo adversary-in-the-middle. |
| Impacto | Comprometimento de credenciais, aprovação de MFA em tempo real, registro de novo dispositivo de autenticação, acesso persistente a SaaS e exfiltração de grandes volumes de arquivos e dados corporativos. |
| Prioridade | Migrar MFA para chaves FIDO2 ou passkeys resistentes a phishing, revisar eventos de registro de fatores, tratar FileAccessed suspeito como possível exfiltração e revogar sessões comprometidas. |
| Artefatos | Domínios e padrões observados incluem enrollms[.]com, passkeyms[.]com, setupsso[.]com, além de python-requests/2.28.1, WindowsPowerShell/5.1, FedAuth, FileDownloaded e FileAccessed. |
| IoCs | O IP 179.43.185.226 aparece em amostras de telemetria de SharePoint, mas a infraestrutura inclui nós de VPN comercial e provedores de hospedagem que variam durante a campanha. |
O cluster UNC6671, associado à marca de extorsão BlackFile, conduz uma operação centrada em identidade contra organizações que dependem de SSO e aplicações SaaS. A atividade não decorre de uma vulnerabilidade em Microsoft 365, Okta ou outro fornecedor citado; o acesso inicial depende de engenharia social por voz, coleta de credenciais em tempo real e uso indevido de sessões válidas. O alvo operacional é obter uma conta legítima com acesso suficiente para navegar por repositórios corporativos, localizar dados sensíveis e transferir conteúdo para infraestrutura controlada pelo atacante antes que a organização consiga invalidar sessões, fatores de autenticação e tokens.
A campanha observada desde o início de 2026 atingiu dezenas de organizações na América do Norte, Austrália e Reino Unido. O ator utiliza telefonistas contratados ou operadores dedicados para ligar a funcionários em celulares pessoais, reduzindo a visibilidade de controles corporativos sobre canais de suporte. O roteiro costuma simular uma exigência interna de migração para passkeys, recadastramento de MFA ou atualização de segurança, o que cria uma justificativa plausível para a vítima visitar uma página de autenticação falsa e aceitar prompts de MFA que aparecem em sequência.
Depois do acesso, a operação se desloca para Microsoft 365, SharePoint, OneDrive, Okta e aplicações conectadas como Salesforce e Zendesk. A etapa de coleta inclui buscas por termos como confidential e SSN, indicativos de priorização de contratos, documentos jurídicos, dados de clientes, registros de RH, diretórios corporativos e informações de suporte. Em seguida, scripts em Python e PowerShell automatizam a transferência em massa, inclusive por caminhos que podem gerar eventos de acesso em vez de eventos clássicos de download.
O ataque começa com uma chamada de vishing sincronizada com a infraestrutura de phishing. O operador direciona a vítima para um subdomínio visualmente alinhado ao portal SSO da organização e mantém a conversa ativa enquanto o usuário insere credenciais. No modelo AiTM, a página falsa não precisa apenas armazenar usuário e senha; ela repassa a autenticação para o provedor legítimo, recebe o desafio de MFA e induz a vítima a aprovar uma notificação push, informar um código SMS ou fornecer um TOTP. A aprovação é então reutilizada pelo atacante para concluir a sessão válida no ambiente real.
A persistência é estabelecida rapidamente por meio do registro de um novo fator de MFA ou dispositivo controlado pelo atacante. Essa janela é crítica porque, em muitos ambientes, a criação de um fator adicional pode ocorrer antes que o SOC correlacione a ligação, o login anômalo, a falha ou abandono de desafios anteriores e a mudança de configuração de segurança da conta. Em Okta, eventos como system.multifactor.factor.setup precedidos por falhas de user.authentication.auth_via_mfa ou desafios abandonados são sinais importantes de que o fluxo de autenticação foi manipulado durante a interação social.
Com a identidade comprometida, a fase de exfiltração deixa de depender de navegação manual. O ator usa APIs formais, requisições HTTP diretas e bibliotecas como python-requests para acessar URLs de documentos em SharePoint e OneDrive. Cookies de sessão válidos, incluindo FedAuth, podem ser reaproveitados para transmitir conteúdo diretamente para fora do ambiente. Esse comportamento pode aparecer como FileAccessed, não necessariamente como FileDownloaded, porque a requisição se parece com busca de conteúdo por um cliente web ou cliente headless, e não com um comando explícito de download pela interface.
A superfície exposta inclui usuários com acesso a dados de alto valor em SaaS, especialmente contas com permissão para bibliotecas jurídicas, diretórios de projetos, documentos financeiros, exports de CRM, tickets de suporte e repositórios operacionais. O risco aumenta quando uma conta comprometida tem SSO amplo para várias aplicações, quando o registro de novos fatores de autenticação não exige validação forte adicional e quando políticas condicionais confiam apenas em MFA tradicional, reputação básica de aplicativo ou identificação declarada de cliente.
A campanha também explora falhas de processo. Ao telefonar para celulares pessoais, o operador evita filas formais de help desk, gravações corporativas, banners de segurança e integrações internas de chat. O pretexto de implantação de passkeys é particularmente sensível porque organizações reais estão migrando para autenticação resistente a phishing; isso faz com que solicitações incomuns de inscrição de fator pareçam compatíveis com mudanças legítimas. Ambientes que não publicaram um processo claro de inscrição, não restringem domínios usados para autenticação e não treinam usuários para interromper chamadas suspeitas ficam mais expostos.
A infraestrutura de phishing evoluiu de domínios individualizados por vítima para um padrão baseado em subdomínios. Exemplos observados incluem temas de inscrição e passkey nos domínios enrollms[.]com, passkeyms[.]com e setupsso[.]com. Esses artefatos ajudam no hunting retrospectivo, mas não devem ser tratados como lista suficiente de bloqueio, porque os domínios podem ser registrados e usados em poucos minutos. A defesa precisa combinar reputação, idade de domínio, padrão de nomenclatura, origem da autenticação e mudanças de MFA.
- Contas SSO com acesso a SharePoint, OneDrive, Salesforce, Zendesk, ServiceNow, Entra e Microsoft Teams.
- Usuários que podem cadastrar novos fatores MFA sem aprovação fora de banda ou política de dispositivo gerenciado.
- Repositórios com documentos legais, dados de RH, contratos, estimativas de projeto, tickets de suporte e registros de clientes.
- Ambientes que priorizam alertas de
FileDownloadede deixamFileAccessedde alto volume com menor severidade.
A telemetria de Microsoft 365 Unified Audit Log deve ser analisada com foco em discrepâncias entre aplicação declarada, agente de usuário e volume de operações. Um padrão relevante é a combinação de ApplicationDisplayName ou ClientAppName aparentando cliente conhecido, enquanto UserAgent revela automação, como python-requests/2.28.1 ou WindowsPowerShell/5.1. Essa diferença indica que a sessão pode estar sendo usada por script e não por navegação interativa. O campo IsManagedDevice igual a falso, quando combinado com localização incomum e grande número de eventos, aumenta a prioridade de investigação.
Eventos FileAccessed devem entrar na mesma fila analítica de exfiltração quando houver cliente headless, origem incomum ou quantidade de arquivos incompatível com uso humano. Em um caso observado, um script Python acessou e baixou mais de um milhão de arquivos em SharePoint e OneDrive a partir de IP remoto. Em outro, dezenas de milhares de interações com arquivos do SharePoint ocorreram em sequência curta. Consultas internas por termos de classificação, siglas de dados pessoais ou palavras associadas a documentos confidenciais também podem revelar triagem feita pelo atacante antes da extração.
No provedor de identidade, a investigação deve correlacionar chamadas ao help desk, alterações de MFA, logins de VPN comercial, provedores de hospedagem, falhas de autenticação e registros de dispositivos. O IP 179.43.185.226 aparece em amostras de eventos relacionados a SharePoint, mas a infraestrutura do ator inclui nós comerciais de VPN e endereços rotativos. Assim, o bloqueio por IP isolado tem valor limitado; a detecção deve priorizar encadeamentos de comportamento, incluindo novo fator MFA, primeiro uso de dispositivo, sessão não gerenciada, acesso volumétrico e agente de usuário de biblioteca.
system.multifactor.factor.setuplogo após falhas ou desafios abandonados de MFA para a mesma conta.FileAccessedouFileDownloadedem alto volume comUserAgentcontendopython-requests,PowerShell, Go ou ferramenta de linha de comando.AppAccessContextindicando cliente headless, aplicação inesperada ou divergência entreClientAppNameeUserAgent.- Autenticações originadas de VPN comercial, hospedagem ou geografia fora do padrão do usuário.
- Buscas internas por
confidential,SSNe termos equivalentes usados para localizar dados de maior valor.
Após a coleta, o ator inicia contato de extorsão por contas de e-mail de consumo geradas programaticamente, inicialmente sem marca explícita. Quando a vítima responde por canais criptografados como Tox ou Session, os operadores passam a usar a identidade BlackFile. As exigências começaram com valores na casa de milhões de dólares em algumas negociações e puderam ser reduzidas para valores de seis dígitos baixos quando houve engajamento. A pressão inclui prazos curtos, alegações de volume em terabytes e menção a dados de SharePoint, Microsoft 365, Salesforce, Zendesk, diretório corporativo e registros de infraestrutura.
O padrão de comunicação mudou ao longo de 2026. Nas primeiras fases, os prazos de resposta eram de 24 ou 48 horas; depois, a campanha passou a usar janelas de 72 horas com assuntos padronizados em caixa alta. O canal também mudou: Tox apareceu em comunicações iniciais, enquanto Session passou a ser o mecanismo preferencial depois da adoção formal da marca BlackFile. A partir de março de 2026, houve uso de contas corporativas comprometidas e Microsoft Teams para ampliar credibilidade e entrega, reduzindo a chance de filtragem por gateways de e-mail externos.
A infraestrutura pública da marca incluiu um site de vazamento lançado em 6 de fevereiro de 2026. O site não seguiu o modelo de máxima exposição típico de outros grupos de extorsão: não havia promoção ampla, indexação agressiva ou publicação integral observada dos conjuntos de dados. Em vez disso, foram vistos exemplos limitados de arquivos e listagens de diretórios. O site saiu do ar no fim de abril de 2026, reapareceu brevemente em 11 de maio de 2026 com uma mensagem indicando encerramento sob aquele nome e voltou a ficar inacessível. Isso aponta para possível rebranding, pausa operacional ou reorganização de infraestrutura, não para eliminação confirmada da capacidade do grupo.
- E-mails de extorsão enviados por contas Gmail com nomes aleatórios e, em fases posteriores, por contas internas comprometidas.
- Comunicação exigida por Tox nas primeiras ocorrências e por Session após a consolidação da marca BlackFile.
- Escalada por spam contra funcionários, mensagens para executivos e abuso de canais internos como Microsoft Teams.
- Site de vazamento BlackFile lançado em fevereiro de 2026 e indisponível no momento da publicação original.
A resposta deve começar pela contenção de identidade. Contas com indícios de vishing ou AiTM precisam ter sessões revogadas, senhas redefinidas, fatores MFA revisados e dispositivos recém-registrados removidos. A equipe também deve verificar se houve criação de regras de caixa postal, aplicativos consentidos, tokens persistentes, sessões ativas em SaaS conectados e acessos por Microsoft Teams ou e-mail interno usados para ampliar a extorsão. Quando houver evidência de exfiltração, a preservação de logs de Microsoft 365 UAL, Okta, Entra, SharePoint, OneDrive, Salesforce e Zendesk deve ocorrer antes de expiração ou rotação de retenção.
A mitigação estrutural é migrar de MFA vulnerável a intermediação para métodos resistentes a phishing. Chaves FIDO2 e passkeys vinculadas ao domínio correto reduzem o valor de páginas AiTM porque a autenticação depende da origem criptográfica do site legítimo. SMS, TOTP e aprovações push continuam úteis em alguns cenários, mas são insuficientes contra um operador que conversa com a vítima em tempo real e transforma o desafio em parte de um falso processo de inscrição. Para mudanças de fator, a organização deve exigir etapa fora de banda controlada, dispositivo gerenciado ou aprovação de suporte com validação independente.
A detecção deve ser ajustada para refletir exfiltração via acesso direto. SOCs que só escalam FileDownloaded podem perder fluxos em que scripts transmitem documentos com cookies válidos e geram FileAccessed. Regras devem medir velocidade de acesso, diversidade de arquivos, bibliotecas atingidas, origem de rede, tipo de agente de usuário e ausência de dispositivo gerenciado. Controles de proteção de credenciais, reputação de domínio e alerta no navegador corporativo ajudam a interromper a submissão de senha fora do domínio autorizado, mas não substituem treinamento operacional para que usuários encerrem chamadas e acionem canais oficiais quando alguém pedir inscrição de autenticação por telefone.
- Implantar MFA resistente a phishing com FIDO2 ou passkeys e restringir cadastro de novos fatores a fluxos verificados.
- Revogar sessões, invalidar cookies, remover dispositivos MFA suspeitos e revisar consentimentos de aplicativos após qualquer suspeita de AiTM.
- Criar alertas para
FileAccessedem massa,FileDownloadedem massa e agentes de usuário comopython-requests/2.28.1eWindowsPowerShell/5.1. - Correlacionar eventos de identidade, origem de rede, dispositivo não gerenciado, mudanças de MFA e acessos a repositórios SaaS.
- Treinar help desk e usuários para negar solicitações telefônicas de MFA ou passkey que não tenham sido iniciadas por processo interno validável.
0 Comentários