Microsoft adverte campanha de phishing que usa Unicode Tags para evitar filtros

A Microsoft advertiu sobre uma campanha massiva de phishing que aproveita caracteres Unicode invisíveis — concretamente do bloco conhecido como Unicode Tags (U+E0000–U+E007F) — para fragmentar palavras-chave financeiras e evitar filtros de correio. De acordo com a descrição técnica divulgada pela equipe de pesquisa de segurança da Microsoft, o método consiste em intercalar pontos de código não visíveis dentro de palavras como "funding" para que continuem a ser vistos normais ao usuário, mas deixem de coincidir com cadeias literales ou expressões regulares empregadas por detectores e filtros automáticos.

Atos confirmados: a Microsoft identificou um pico de atividade que começou no início de fevereiro de 2026, entrou em uma fase de alto volume durante aproximadamente três meses e diminuiu notavelmente após 15 de maio de 2026. Os pesquisadores estimam volumes de envio em dias úteis entre 1 e 2,37 milhões de e-mails, com uma cadência semanal marcada (práticamente inativos aos fins de semana e ativos de segunda a sexta-feira). A campanha reutilizou a plataforma de automação do ActiveCampaign para distribuir milhares de e-mails, e foi ligada — de acordo com análises anteriores do equipamento FIRE de Fortra — a tentativas de capturar dados de requerentes de empréstimos (SBA) e produzir sites falsos de aparência convincente. Microsoft e terceiros detectaram centenas de domínios emissores descartáveis com temas financeiros e redireções de cliques através de domínios de tracking próprios da plataforma (por exemplo, domínios de seguimento do ActiveCampaign).

Como funciona tecnicamente: o bloco Unicode Tags contém "copias" de caracteres ASCII que não se renderizam visivelmente em muitas interfaces; originalmente se ideou para rotulagem linguística e está maiormente em desuso. Ao intercalar estes pontos de código entre letras, a sequência de 'bytes' já não contém a sub- sequência literal procurada por um filtro (por exemplo, "funding"), mas ao mostrar-se ao utilizador ou ao normalizar-se por alguns tubos de parseu o resultado volta a ser lido como a palavra original. Os detectores que fundamentam sua lógica em coincidências exatas ou em regex que não contemplam caracteres intercalados falham em identificar a palavra-chave. Além disso, este padrão — às vezes denominado "ASCII smuggling" — alimenta um risco agregado em contextos onde modelos de linguagem (LLMs) ou sistemas automatizados ingerem o texto sem uma limpeza prévia: se o conteúdo malicioso permanecer incorporado, pode servir como vetor para injeções de instruções ou para que um LLM aceite e execute indiretamente comandos encobertos.

O que está confirmado e o que permanece incerto: está confirmado que a técnica foi usada em escala e que a infraestrutura de envio incluiu ActiveCampaign como canal de distribuição; também está documentada a reutilização de domínios financiarizados descartáveis. É uma estimativa, baseada em telemetria e nos relatórios da Microsoft, que a campanha atingiu milhões de mensagens diárias e seguiu o padrão semanal descrito. O que não está publicamente confirmado nos relatórios disponíveis é a identidade do ator ou atores por trás da operação e até que ponto a rede de domínios está centralizada ou fragmentada entre vários grupos. Além disso, a relação exata entre as ondas detectadas em fevereiro-Maio de 2026 e as campanhas anteriores relatadas em 2025 por Fortra é descrita como ligada ou coerente, mas não necessariamente com atribuição probatória completa.

Impacto real e riscos: a técnica reduz a eficácia de assinaturas e regras estáticas, permitindo que tráfego malicioso alcance bandejas de entrada ou que mensagens de spear-phishing altamente personalizadas escapem de controles. Para pequenas e médias empresas (o branco declarado de acordo com Fortra), isto representa um risco de perdas financeiras directas (fraude, adiantamentos falsos), roubo de credenciais e preparação de ataques mais dirigidos (engenharia social posterior). Ao apoiar-se em uma plataforma de marketing com reputação e com IPs autenticados, além disso, o envio pode sortear filtros baseados em reputação, complicando a detecção baseada apenas em origem ou em histórias de envio.

Medidas concretas a tomar pelos leitores e administradores: em primeiro lugar, para usuários finais, a proteção básica continua a ser válida e prioritária: não clicar links em e-mails suspeitos, verificar remetentes por canais oficiais, e usar MFA em todas as contas que gerem dinheiro ou informação sensível. Antes de introduzir credenciais ou dados financeiros, confirmar por telefone ou pelo portal oficial da entidade.

Para equipes de segurança de e-mail e administradores TI há ações técnicas específicas e aplicáveis de imediato: normalizar antes de analisar - isto é, remover ou mapear pontos de código invisíveis do bloco Tags - e aplicar essa versão canônica ao motor de detecção; isso evita a dependência de padrões literales vulneráveis. Como segunda linha, implementar regras de detecção que busquem caracteres não imprimíveis intercalados dentro de palavras-chave sensíveis ou padrões de conduta (em vez de apenas coincidências contíguas). Se a sua solução de e-mail permitir uma inspeção profunda, adicione uma regra para bloquear ou marcar mensagens que utilizem em massa caracteres da categoria "Tags" ou qualquer outro intervalo de controle/invisível. Paralelamente, monitorizar remessas que utilizem fornecedores de marketing legítimos e manter comunicação com esses fornecedores para detectar abusos de contas e fluxos automatizados. Não substitua estas defesas pela única confiança em reputação: configurar DMARC, DKIM e SPF ajuda, mas não evita que campanhas aproveitem contas de plataformas autorizadas.

Para aqueles que operam ou exibem modelos de linguagem, a recomendação prática é análoga: pré-processar e sanear qualquer texto de entrada para remover caracteres de rotulagem invisíveis antes de alimentar um LLM, e fixar limites e regras explícitas que distingam entre instruções de usuário e conteúdo de terceiros incorporado. A tokenização e a normalização de Unicode devem ser utilizadas como parte da canalização de segurança para minimizar vetores de prompt injection.

Responsabilidade dos fornecedores: plataformas de e-mail marketing e automação devem reforçar a detecção de abuso em contas, monitorar picos de atividade, e evitar que os fluxos de tracking leitimen envios claramente maliciosos. A Microsoft e o ActiveCampaign já referiram nos seus comunicados que os fornecedores detectam alguns desses padrões e tratam a presença maciça de caracteres invisíveis como sinal de suspeita; ainda assim, os equipamentos de segurança devem exigir aos fornecedores transparência e mecanismos de bloqueio mais automáticos para campanhas que violem políticas.

Para aprofundar a natureza técnica dos caracteres Unicode e dos riscos associados, consultar a documentação do Unicode em https://unicode.org/, análises e guias de segurança e publicações de fornecedores https://www.microsoft.com/security/blog/. Essas leituras ajudam a entender por que uma simples sequência de bytes pode mudar radicalmente a eficácia de uma regra de detecção e por que a higiene de entrada (normalizar e limpar) é agora uma defesa crítica.

Em resumo: a campanha evidencia que técnicas concebidas para enganar sistemas automatizados foram adaptadas e escaladas com infra-estruturas legítimas, e que as defesas devem evoluir desde regras textuais estáticas a canalizações que saneem e normalizem o texto antes da análise. Para usuários e organizações, a combinação de higiene digital (MFA, verificação de remetentes), saneamento prévio e coordenação com fornecedores constitui a resposta prática mais efetiva face a esta classe de evasão.