Veja exatamente como começou a invasão da MGM Resorts. Um hacker encontrou um funcionário no LinkedIn. Ele ligou para o suporte de TI, fingiu ser esse funcionário e solicitou a redefinição da senha e do MFA. O atendente do suporte atendeu ao pedido. A ligação durou dez minutos. O prejuízo da MGM com a invasão foi de 100 milhões de dólares.
Sem malware. Sem zero-day. Sem qualquer tipo de exploração técnica. Apenas um telefonema.
Ao ler isso, o instinto é buscar uma solução tecnológica: um MFA mais robusto, ferramentas de verificação de identidade, novos protocolos para o suporte. Essas coisas são importantes. Mas elas tratam do que aconteceu depois que o atendente tomou a decisão errada. Elas não resolvem o motivo pelo qual o atendente não teve a menor chance de tomar a decisão certa.
Aquele atendente nunca tinha treinado para isso. Ninguém o colocou em uma simulação de chamada com um invasor que já sabia o nome do funcionário, seu departamento, seu gerente e o roteiro exato para criar um senso de urgência sem levantar suspeitas. Ele não tinha um padrão de reconhecimento no qual se basear. Aquela ligação de dez minutos foi a primeira vez que ele se deparou com esse cenário – e era real.
É sobre essa lacuna que trata este artigo.
Seu suporte de TI foi projetado para ajudar as pessoas. Os invasores fizeram a engenharia reversa disso.
Seu suporte de TI existe para resolver problemas rapidamente. Um funcionário está bloqueado em sua conta, em pânico antes de uma reunião, incapaz de acessar o sistema de que precisa – e o suporte resolve isso rapidamente. Velocidade e prestatividade são as métricas. Esse design está correto.
Os invasores estudaram esse design cuidadosamente. Eles constroem chamadas que parecem e soam como as situações de maior urgência e mais rotineiras que os atendentes lidam todos os dias: conta bloqueada, telefone novo, não consegue receber o código MFA, reunião em vinte minutos, precisa resolver isso agora. Cada elemento da chamada é projetado para parecer uma segunda-feira difícil e comum.
Os métodos de verificação que a maioria dos suportes usa – ID do funcionário, nome do gerente, últimos quatro dígitos de um número de telefone – são inerentemente vulneráveis a essa abordagem. Todas as informações necessárias para passar por essas verificações estão, para a maioria dos funcionários, disponíveis publicamente: LinkedIn, sites de empresas, comunicados à imprensa, gravações de chamadas de resultados. A engenharia social agora responde por 60% dos incidentes de violação de dados. O suporte de TI não foi projetado com essa ameaça em mente. E isso fica evidente.
O roteiro não muda porque não precisa mudar.
A tentação é tratar o caso da MGM como um ponto fora da curva – uma invasão anômala que levou a controles melhores e que ficou no passado. Os dois anos que se seguiram tornaram isso impossível.
Em abril de 2025, a Marks & Spencer revelou um ataque de ransomware após invasores enganarem seu suporte de TI para redefinir as credenciais de funcionários. Em maio de 2025, o Co-op Group confirmou que dados de membros foram acessados após engenharia social contra o suporte técnico. A Harrods confirmou uma tentativa de acesso não autorizado na mesma semana. Três grandes varejistas do Reino Unido. Duas semanas. O mesmo manual de instruções.
O grupo por trás desses ataques – Scattered Spider, rastreado pela Mandiant como UNC3944 – não mudou suas táticas entre o caso da MGM em 2023 e a onda de ataques ao varejo no Reino Unido em 2025. A CISA atualizou seu aviso em julho de 2025 confirmando novas TTPs, mas a abordagem fundamental permaneceu idêntica: encontrar o alvo no LinkedIn, ligar para o suporte técnico, passar-se pelo funcionário, redefinir as credenciais e implantar o ransomware.
A Mandiant e a Unit 42 alertaram em junho de 2025 que o Scattered Spider havia migrado para atacar os setores de aviação, companhias aéreas e transporte – a quarta mudança de setor do grupo em aproximadamente oito semanas. O suporte técnico não está sendo visado de forma oportunista. Ele está sendo visado sistematicamente, em escala, porque funciona.
O relatório M-Trends 2026 da Mandiant, construído com base em mais de 500.000 horas de investigações de resposta a incidentes, confirma: o phishing por voz é agora o segundo vetor de infecção inicial mais comum globalmente. Em ambientes de nuvem, especificamente, ele é o número um.
Seu suporte técnico não está seguro só porque ainda não foi atingido. Ele está seguro apenas até que o grupo, trabalhando em uma lista de alvos, chegue ao seu nome.
A ligação para a qual seus agentes não estão preparados
Entender o ataque no nível do roteiro é o que torna possível o treinamento por simulação. O treinamento de conscientização genérico diz aos agentes que a engenharia social existe. Ele não os coloca em uma chamada com alguém executando o ataque em tempo real.
O roteiro padrão de vishing para suporte técnico possui três elementos estruturais que se repetem em praticamente todos os incidentes documentados.
Uma identidade plausível, montada a partir de fontes públicas. Antes da ligação, o atacante passou vinte minutos no LinkedIn. Ele sabe o nome do funcionário alvo, cargo, gestor e departamento. Pode saber o formato do e-mail do funcionário e se ele foi mencionado publicamente em comunicados da empresa. Nada disso exige habilidade técnica. Exige apenas uma conta gratuita e paciência.
Um pretexto rotineiro apresentado como urgente. Os pretextos mais comuns nos incidentes do Scattered Spider envolvem um novo telefone que exige o reenrollment do MFA, uma conta bloqueada que impede o acesso a um sistema necessário imediatamente ou um alerta de segurança que o funcionário "recebeu" e que exige a verificação de credenciais. A urgência é calibrada para parecer uma emergência normal – irritante e sensível ao tempo, mas não suspeita. O funcionário que está sendo impersonado, nessa narrativa, está apenas tendo um dia ruim.
Um pedido específico que se enquadra na autoridade normal do agente. O atacante não está pedindo nada incomum. Mais de 40% de todos os chamados de help desk são redefinições de senha. O reenrollment do MFA é uma solicitação rotineira. O pedido é indistinguível de um legítimo porque foi projetado para ser.
O que se pede ao agente para reconhecer não é um e-mail suspeito com um remetente grafado incorretamente. É um fluxo de trabalho familiar, executado sob pressão normal, por alguém que soa exatamente como um colega em apuros. Nenhum treinamento focado em sinais de alerta de e-mail prepara alguém para isso.
Os quatro reflexos que sua equipe de help desk precisa praticar
Conscientização não é preparação. Ler sobre um roteiro de vishing não é o mesmo que lidar com um sob pressão em tempo real. Funcionários treinados por meio de simulação superam consistentemente aqueles treinados por módulos de vídeo quando ataques reais ocorrem. A equipe de help desk precisa especificamente de quatro coisas – não como conhecimento, mas como reflexo praticado.
Reconhecimento de padrões estruturais, não reconhecimento de voz
Em um mundo onde a clonagem de voz por IA pode replicar a voz de uma pessoa específica a partir de três segundos de áudio, a voz não pode ser o sinal. O que pode ser o sinal é a estrutura da chamada: urgência mais autoridade mais um pedido para pular ou abreviar a verificação normal. Essa combinação – independentemente de como a voz soa – é o alerta. Agentes que internalizaram esse padrão detectam chamadas que agentes que buscam por "algo que soa estranho" perderão todas as vezes.
Verificação fora de banda como padrão, não como escalonamento
O controle de processo mais eficaz contra o vishing de help desk é uma chamada de verificação para um número conhecido – não o número fornecido pelo chamador, não um retorno para o número da solicitação, mas um número obtido diretamente do diretório interno. Exigir essa etapa antes de qualquer redefinição de credencial bloqueia a maioria das tentativas de engenharia social. Agentes que praticaram esse reflexo o executam automaticamente. Agentes que apenas leram sobre isso tratam como atrito e o ignoram sob pressão.
Tratamento específico para solicitações de redefinição de MFA
A redefinição de MFA e o registro de novos dispositivos são as solicitações específicas que desbloqueiam todo o resto para um atacante. Uma redefinição de senha importa, mas uma redefinição de MFA é o verdadeiro prêmio – ela contorna o controle que deveria tornar a senha irrelevante. Essas solicitações precisam ser tratadas como mudanças privilegiadas: verificação rigorosa necessária, cada solicitação registrada com o método de verificação usado, exceções encaminhadas para uma fila treinada em vez de aprovadas no primeiro nível. Os agentes precisam ter internalizado que uma solicitação de redefinição de MFA de um chamador desconhecido é categoricamente diferente de uma chamada rotineira de conta bloqueada – mesmo quando as duas parecem idênticas no momento.
Um protocolo claro para quando algo parece errado
O agente do help desk que suspeita de uma chamada fraudulenta não tem um roteiro para o que acontece a seguir. Ele precisa de um – a quem escalar, como encerrar a chamada sem alertar o atacante, como documentar e relatar imediatamente. Os dados do M-Trends 2026 da Mandiant mostram que o tempo entre o acesso inicial e a transferência para um grupo de ameaça secundário caiu para 22 segundos em alguns casos. O intervalo entre uma chamada suspeita e um comprometimento total de credenciais pode ser de minutos. Saber o que fazer após reconhecer um ataque é tão importante quanto reconhecê-lo.
Por que o treinamento genérico de conscientização em segurança não tem resposta para isso
A maioria dos programas de conscientização em segurança é construída em torno de um único canal: e-mail. As simulações testam taxas de cliques em links suspeitos. Os módulos explicam como identificar indicadores de phishing em um cabeçalho. As métricas relatam quem concluiu o treinamento anual.
Nada disso prepara um agente de help desk para uma chamada de vishing. Nem parcialmente. Nem como base. O modelo de ameaça, o canal, a psicologia e a resposta necessária são todos diferentes.
O M-Trends 2026 da Mandiant destaca especificamente a necessidade de treinar a equipe de help desk de TI em engenharia social ao vivo, baseada em voz – tratando isso como um requisito distinto do treinamento de phishing por e-mail, e não como uma subcategoria dele.
As plataformas genéricas de SAT não têm mecanismos para desenvolver essa habilidade. Elas não simulam chamadas. Elas não refletem os fluxos de trabalho de tickets reais da sua organização, seu provedor de identidade, seus procedimentos de verificação ou os pretextos específicos que um atacante que passou tempo no seu LinkedIn usaria. Um módulo sobre vishing não é uma simulação. Uma simulação baseada nos fluxos de trabalho de uma empresa fictícia não é preparação para uma chamada que visa a sua.
Uma simulação construída em torno de uma empresa fictícia não prepara sua equipe para nada
Uma simulação de vishing para seu help desk de TI não é um roteiro genérico de chamador suspeito lido por um ator. É um cenário construído em torno do contexto específico da sua organização – porque é exatamente isso que o atacante constrói.
O Phishing Simulator da Frame gera simulações de vishing para help desk construídas em torno do seu ambiente real: nomes e cargos reais dos seus funcionários, seu provedor de identidade – seja Okta, Microsoft Entra ou ServiceNow –, sua configuração real de MFA e fluxos de trabalho de redefinição, sua terminologia interna. A simulação que seu agente recebe soa como uma chamada sobre seus sistemas, usando sua linguagem, referenciando seus processos. Não uma empresa genérica. A sua.
Quando o Scattered Spider passa a visar seu setor – como fez de cassinos para varejo, seguros e companhias aéreas em cerca de dezoito meses –, sua equipe de help desk pode estar executando uma simulação construída em torno desse pretexto exato no mesmo dia em que a ameaça se torna relevante. Não quando a próxima atualização de conteúdo for lançada.
E quando um agente falha – aceita a chamada, redefine as credenciais, registra o novo dispositivo –, o Content Studio da Frame gera automaticamente o próximo treinamento dele focado exatamente no que o enganou. A falha torna-se o currículo. Eles praticam o cenário específico que não conseguiram lidar, construído em torno dos fluxos de trabalho reais que enfrentarão novamente, até que o reflexo esteja consolidado.
O invasor que liga para o seu help desk já treinou isso. Ele executou esse roteiro em centenas de organizações. A única questão é se o atendente que atende a ligação também treinou.
Resumo
- A invasão da MGM começou com um telefonema de vishing de dez minutos para o help desk de TI – reconhecimento no LinkedIn, falsificação de identidade de funcionário, redefinição de credenciais, US$ 100 milhões em prejuízos
- O grupo Scattered Spider usou o mesmo manual contra a Marks & Spencer, Co-op, Harrods e seguradoras e companhias aéreas dos EUA até 2025 – o mesmo ataque, novos alvos, sempre.
- O phishing por voz é agora o 2º vetor de infecção inicial globalmente e o vetor nº 1 em ambientes de nuvem, segundo o M-Trends 2026
- Os agentes de help desk não falham por descuido – eles falham porque nunca treinaram esse cenário sob a pressão do tempo real
- Os quatro reflexos que a equipe de help desk precisa: reconhecimento de padrões estruturais, verificação fora de banda como padrão, tratamento específico para solicitações de redefinição de MFA e um protocolo claro para chamadas suspeitas
- Programas genéricos de treinamento de conscientização de segurança (SAT) simulam e-mails – eles não simulam chamadas baseadas no provedor de identidade, sistema de tickets e fluxos de trabalho de verificação reais da sua organização
- O Frame gera simulações de vishing para help desk baseadas no seu ambiente real – suas ferramentas, seus fluxos de trabalho, sua marca – em minutos, com treinamento pós-falha que transforma cada erro em um ciclo de aprendizado completo
Agende uma demonstração e veja como o Frame cria simulações de vishing para help desk baseadas na sua organização real – no mesmo dia em que uma nova ameaça se torna relevante.
