Abuso de identidade no Teams e Slack quadruplica, diz Unit 42

A Unit 42, divisão de pesquisa de ameaças da Palo Alto Networks, publicou em 20 de agosto de 2026 uma análise sobre o abuso de identidade em plataformas corporativas de colaboração. O dado central: os alertas de atividade maliciosa associados a ferramentas como Microsoft Teams e Slack, observados na telemetria de endpoints da empresa, mais do que quadruplicaram nos últimos doze meses. E 99% desses alertas se relacionam a operações de phishing por chat.

O texto, assinado por Bill Batchelor, parte de uma constatação que já é consenso em arquitetura de segurança — a identidade substituiu o perímetro de rede como principal fronteira de confiança — para apontar uma consequência menos discutida: os controles de segurança continuaram concentrados em e-mail e em eventos de autenticação, enquanto o que acontece dentro de uma sessão já autenticada de colaboração permanece, na maior parte das organizações, sem visibilidade.

Uma ressalva de leitura antes de seguir. O número de quatro vezes é relativo e vem da base de clientes da Palo Alto Networks; a Unit 42 não publica valores absolutos nem uma amostra global. Serve como indicador de tendência dentro de um conjunto específico, não como medida do mercado.

Por que a mensagem no chat convence mais que o e-mail

Quando uma conta de colaboração é comprometida, o atacante não herda apenas credenciais. Herda o contexto da identidade: as permissões daquele usuário, suas relações internas e externas, e as conversas em andamento. Um pedido que levantaria suspeita em um e-mail vindo de fora — “aprova esse MFA para mim”, “instala essa ferramenta de acesso remoto”, “manda o arquivo” — parece rotina quando chega por uma mensagem direta dentro de uma plataforma autenticada e homologada pela empresa.

Há um segundo diferencial em relação ao e-mail: a interatividade. Plataformas de chat permitem conversa em tempo real, o que dá ao atacante a chance de responder objeções e ajustar a engenharia social durante o próprio ataque. O phishing deixa de ser uma isca estática e passa a ser um diálogo.

A superfície é ampliada por recursos legítimos que existem justamente para viabilizar trabalho distribuído: federação externa, contas de convidado, espaços compartilhados e integrações de terceiros. Cada um deles é um caminho autorizado por onde um atacante pode alcançar um usuário interno sem cruzar nenhuma barreira que a empresa monitore de perto.

Três estágios documentados em casos reais

A Unit 42 organiza o problema por estágio de intrusão, mapeado em técnicas do MITRE ATT&CK.

Estágio	Técnica ATT&CK	Padrão de abuso
Acesso inicial	T1566 (Phishing)	Phishing de identidade por canais externos de colaboração
Furtividade	T1684.001 (Impersonation)	Personificação via notificações legítimas, conteúdo hospedado e mensagens diretas
Persistência	T1556 (Modify Authentication Process)	Remoção de MFA e exfiltração de credenciais por webhook nativo do Slack

Acesso inicial

A Unit 42 relata que atacantes abusam da federação externa no Teams para iniciar conversas com vítimas se passando por suporte de TI ou outro pessoal de confiança. A sequência típica começa com um pedido de conversa e evolui para instruções de visitar um site de phishing, aprovar uma solicitação de MFA, instalar software de acesso remoto ou entregar credenciais. A Okta Threat Intelligence documentou padrão semelhante, com links enviados por mensagens diretas, menções em canais e notificações legítimas, redirecionando vítimas a proxies de phishing do tipo adversário no meio, capazes de capturar credenciais e tokens de MFA.

Um detalhe operacional relevante para times de detecção: a mensagem inicial costuma ser invisível para o SOC. O que aparece é o efeito. A Unit 42 mostra um caso em que a vítima recebeu um arquivo RAR em um chat do Teams, baixou-o para a pasta Downloads, abriu-o com o WinRAR e extraiu uma lpk.dll maliciosa — uma DLL antiga, que se disfarça de biblioteca de pacote de idioma do Windows e é usada em ataques de carregamento lateral de DLL. O detalhe importa porque desmente a ideia de que canais novos exigem malware novo: famílias antigas continuam funcionando quando o vetor de entrega muda.

Personificação

Três casos públicos de 2026 ilustram o padrão, e todos foram confirmados de forma independente por seus respectivos responsáveis:

Janeiro de 2026 — Fireblocks. Atacantes se passaram por executivos, recrutadores e gerentes de contratação da empresa de infraestrutura para criptoativos. O contato começava em redes sociais, avançava para entrevistas por Google Meet e terminava com uma tarefa de revisão de código: clonar um repositório e rodar comandos de instalação, incluindo npm install, que executava código malicioso. A Fireblocks avaliou a atividade como alinhada ao padrão da campanha Contagious Interview, ligada à Coreia do Norte.
Março de 2026 — pacote axios no npm. O mantenedor principal foi alvo de uma operação encenada: os atacantes clonaram a identidade visual e a liderança de uma empresa conhecida e montaram um espaço no Slack com canais, perfis de funcionários e histórico de mensagens fabricados. A interação migrou para uma reunião no Teams, onde o mantenedor foi convencido a instalar o que parecia um componente ausente e era, na verdade, um trojan de acesso remoto. Com a conta npm comprometida, duas versões maliciosas foram publicadas em 31 de março, introduzindo uma dependência que não existia até aquele dia. Reportagens posteriores atribuíram a operação ao agrupamento norte-coreano rastreado como UNC1069.
Abril de 2026 — OpenSSF e Linux Foundation. Um aviso de alta severidade publicado em 7 de abril por Christopher Robinson, diretor de tecnologia da OpenSSF, alertou para a personificação de um líder conhecido da Linux Foundation no Slack do grupo de trabalho TODO. As mensagens diretas levavam a um link hospedado no Google Sites, que reproduzia um fluxo de autenticação do Google Workspace e terminava pedindo a instalação de um certificado raiz falso — o que permite interceptar tráfego criptografado. Em macOS, o processo também baixava e executava um binário.

O denominador comum não é a sofisticação técnica. É o uso de uma identidade reconhecida dentro de um processo de negócio familiar — recrutamento, revisão de código, coordenação comunitária — para tornar o pedido malicioso indistinguível do trabalho normal.

Persistência via webhook legítimo

O caso mais inventivo do relatório vem de uma intrusão de dezembro de 2025 investigada pelo CERT Polska. Em appliances de firewall e VPN comprometidos de uma indústria na Polônia, o atacante usou o mecanismo de scripts embutido no próprio equipamento para criar tarefas agendadas semanais. Um script recuperava a senha de uma identidade privilegiada. Outro alterava as configurações de segurança e desabilitava o segundo fator de autenticação dessa conta. Um terceiro usava a capacidade nativa de notificação por Slack do appliance para enviar os resultados a um canal controlado pelo atacante.

Não houve ferramenta de exfiltração. Não houve canal encoberto. O equipamento de segurança exfiltrou as próprias credenciais usando um recurso documentado, previsto para alertas operacionais. A técnica corresponde à sub-técnica T1567.004 do MITRE ATT&CK, exfiltração por webhook.

A implicação prática é que o firewall de perímetro se torna um ponto de observação valioso: appliances de rede que enviam requisições para hooks.slack.com — sobretudo com agentes de usuário incomuns, como curl, ou vindos de sistemas sem integração aprovada — merecem investigação. O Microsoft Teams suporta fluxos equivalentes de webhook de entrada e deve entrar no mesmo escopo.

O que fazer, e o que os controles atuais não cobrem

A recomendação estruturante da Unit 42 é tratar plataformas de colaboração como parte da superfície de ataque de identidade, com o mesmo rigor aplicado a e-mail e à infraestrutura de autenticação. Isso se desdobra em algumas frentes.

Reduzir exposição. Revisar federação externa, acesso de convidados e integrações de terceiros, limitando comunicação externa a organizações confiáveis e mantendo um processo periódico de revisão e remoção de contas de convidado que já não têm justificativa.

Reconhecer o limite do MFA. Autenticação multifator, acesso condicional e avaliação de risco de sessão reduzem a chance de comprometimento inicial, mas não impedem que um atacante abuse de uma sessão válida. Uma vez dentro, o controle preventivo já cumpriu seu papel — o que resta é detecção comportamental: volume de mensagens fora do padrão, compartilhamento inesperado de arquivos, comunicação com tenants externos desconhecidos.

Verificação fora de banda. Nenhuma aprovação de MFA, instalação de ferramenta de acesso remoto, compartilhamento de credencial ou alteração de acesso deveria ocorrer com base apenas em uma mensagem. Pedidos de alto risco precisam de confirmação por um canal secundário conhecido — telefone cadastrado, sistema de chamados, processo interno documentado. Esse é o controle mais barato e o que mais falta nos casos analisados.

Treinamento que inclua o chat. Muita gente reconhece indicadores de phishing por e-mail e não aplica o mesmo ceticismo a uma mensagem direta ou a uma notificação da plataforma. Simulações de phishing que cobrem apenas e-mail deixam essa lacuna aberta.

Monitoração ativa. Logs de autenticação, atividade de mensagens, eventos de compartilhamento de arquivos e interações com tenants externos devem entrar no SIEM e ser correlacionados com telemetria de identidade e de endpoint. Firewalls, appliances de VPN, balanceadores e switches gerenciados também precisam entrar na cobertura, com atenção a atividade administrativa, mudanças de configuração, uso de webhooks de saída e conexões incomuns a serviços SaaS.

Limitações e o que ainda não está claro

Alguns pontos permanecem em aberto no relatório. A Unit 42 não detalha a metodologia de classificação dos alertas, nem quantos dos 99% relacionados a phishing por chat resultaram em comprometimento efetivo — alerta não é incidente. Também não há indicação de quanto do crescimento observado decorre de aumento real de ataques e quanto vem da melhoria da própria telemetria e da adoção crescente dessas plataformas, que amplia naturalmente a base exposta. São ressalvas metodológicas comuns em relatórios de fornecedor e que não invalidam a tendência, mas recomendam cautela com o número isolado.

Vale registrar também que a Unit 42 encerra o texto com uma lista de produtos próprios como parte da mitigação. As recomendações de processo descritas acima — verificação fora de banda, revisão de federação, ingestão de logs — independem de fornecedor e são as que sustentam o valor prático da pesquisa.

Conclusão

A mensagem central do relatório é que autenticação deixou de ser suficiente para estabelecer confiança. Saber quem está autenticado responde apenas metade da pergunta; a outra metade é como essa identidade autenticada está se comunicando, e quando um canal legítimo passa a ser usado de forma ilegítima.

Para as equipes brasileiras que operam Microsoft 365 ou Google Workspace com integrações de chat — praticamente todas as empresas de médio e grande porte — o exercício imediato é simples e desconfortável: verificar quantos tenants externos estão federados, quantas contas de convidado ainda existem sem uso, e se os logs de mensagens e de compartilhamento de arquivos chegam ao SIEM. Na maioria dos casos, a resposta às três perguntas revela um ponto cego que nenhum controle de e-mail cobre.