Vishing via Microsoft Teams: corretor de acesso inicial usa falso suporte de TI para abrir a porta a gangues de ransomware

A engenharia social aqui é construída em duas fases deliberadas, e a ordem importa: primeiro os atacantes disparam uma onda de spam contra a caixa de entrada da vítima ('spam bombing'), sem nenhum conteúdo malicioso — o objetivo único é gerar uma sensação real e incômoda de que 'algo está errado com meu e-mail'. Só depois, já com a vítima genuinamente estressada e buscando ajuda, o atacante entra em contato pelo Microsoft Teams se passando por um técnico de TI que 'percebeu o problema' e está ligando para resolver. Essa sequência explora um viés psicológico bem documentado: pessoas sob estresse técnico induzido aceitam ajuda de uma autoridade aparente com muito menos ceticismo do que aceitariam em uma abordagem fria.

O golpe se consuma quando a vítima, já convencida, clica em um link de Quick Assist fornecido pelo 'técnico', concedendo acesso remoto real ao computador. A partir daí, o grupo instala GoGRPC e diversas ferramentas de backdoor e proxy, estabelecendo persistência e realizando movimentação lateral e escalonamento de privilégio dentro da rede corporativa — não para roubar dados diretamente, mas para preparar o terreno.

O modelo de negócio por trás da campanha é o de corretor de acesso inicial (initial access broker): depois de estabelecer uma posição sólida dentro da rede da vítima, o grupo não executa o ataque final — ele vende esse acesso já pronto para operadores de ransomware, que assumem a partir daí. A Zscaler observou a campanha se tornando mais seletiva e cada vez mais focada em ambientes corporativos ao longo do semestre, sinal de que o grupo está refinando a segmentação de alvos para maximizar o valor de revenda de cada acesso obtido.

Como o vetor de entrada é inteiramente humano — spam seguido de contato por chat corporativo —, a prevenção prática precisa focar em processo, não em tecnologia isolada: equipes de TI devem deixar claro que jamais entram em contato proativo por Teams oferecendo resolver um problema não reportado pelo próprio usuário; qualquer solicitação de suporte remoto deve ser validada contra um ticket já aberto pelo sistema oficial de helpdesk, nunca aceita apenas porque o problema 'bate' com algo que a vítima está vivendo; e o Quick Assist e ferramentas similares de acesso remoto devem ser restritos ou exigir aprovação adicional para usuários fora da equipe de TI, reduzindo a superfície de ataque mesmo que a engenharia social tenha sucesso.