Campanhas recentes de vishing — phishing por voz — estão mirando funcionários de empresas financeiras e ambientes corporativos de nuvem para obter credenciais, roubar sessões e extorquir as vítimas. A ação prioritária é tratar chamadas inesperadas que pedem códigos, aprovação de acesso ou instalação de ferramentas como incidentes de identidade: interrompa a interação, preserve os registros e valide o pedido por um canal independente.
O alerta merece atenção porque o telefone cria uma sensação de legitimidade que uma mensagem isolada nem sempre consegue produzir. O criminoso pode se apresentar como suporte técnico, equipe de segurança, banco ou fornecedor. O objetivo não precisa ser convencer a vítima a revelar uma senha completa. Basta induzi-la a aprovar uma autenticação, abrir uma página controlada pelo atacante ou entregar informações que permitam completar a invasão.
O Google Threat Intelligence Group descreveu uma operação atribuída ao cluster UNC6671 que combinou múltiplas marcas, engenharia social por voz, painéis para capturar credenciais e roubo de dados de aplicações SaaS. A Unit 42, em uma análise independente sobre ataques contra credenciais, também recomenda procurar logins bem-sucedidos logo depois de grandes volumes de falhas. Os dois relatórios apontam para a mesma decisão defensiva: identidade e telemetria de acesso precisam ser investigadas juntas.
O que mudou no ataque
O vishing não é apenas uma ligação que tenta obter uma senha. A chamada funciona como a primeira etapa de uma cadeia. O operador pode confirmar o cargo da pessoa, mencionar um problema plausível e orientar a vítima a visitar uma página de suporte. Essa página pode imitar o provedor de identidade, solicitar um código de uso único ou apresentar um fluxo de autenticação que entrega a sessão ao invasor.
Em campanhas contra ambientes de nuvem, a conta comprometida pode abrir portas para correio eletrônico, arquivos, aplicações de relacionamento com clientes e consoles administrativos. A extensão do dano depende das permissões disponíveis e da existência de controles adicionais. Uma conta comum pode expor conversas e documentos; uma identidade privilegiada pode criar usuários, alterar regras, ler segredos ou desativar mecanismos de segurança.
O relatório do Google também descreve o uso de painéis de captura de credenciais e de roubo de dados de SaaS. Isso indica que a equipe não deve limitar a investigação ao endereço IP de um login. É preciso verificar alterações de sessão, novos dispositivos, regras de encaminhamento de e-mail, consentimentos de aplicações, tokens persistentes e downloads incomuns.
Já a análise da Unit 42 registra que alegações feitas por criminosos nem sempre podem ser verificadas. Essa ressalva é operacionalmente relevante: uma postagem em fórum ou uma ligação convincente não prova uma invasão. A equipe deve separar indícios confirmados, alegações externas e hipóteses de investigação antes de comunicar o incidente à direção.
Primeiras verificações
Comece pelas contas envolvidas na chamada e pelas identidades que apresentaram comportamento semelhante. Preserve os registros antes de revogar tudo, quando isso for compatível com a política de resposta. O objetivo é manter evidência suficiente para reconstruir a sequência sem permitir que o invasor continue ativo.
| Prioridade | Verificação | Decisão |
|---|---|---|
| P1 | Login bem-sucedido após várias falhas, país ou dispositivo inesperado e sessão recente. | Revogar sessões e tokens, redefinir credenciais e confirmar o proprietário por canal independente. |
| P1 | Alteração de método de autenticação, aplicativo consentido ou regra de encaminhamento. | Remover a alteração, bloquear a aplicação e revisar ações realizadas pela conta. |
| P1 | Chamadas que solicitaram código, aprovação, acesso remoto ou instalação. | Identificar outras pessoas contatadas e preservar números, horários e mensagens. |
| P2 | Downloads atípicos, criação de contas e acesso a repositórios ou dados sensíveis. | Ampliar o escopo para os recursos acessados e iniciar análise de possível exfiltração. |
Na plataforma de identidade, procure a sequência completa: tentativa de autenticação, desafio enviado, aprovação, criação ou uso de sessão, mudança de privilégio e acesso a dados. Uma aprovação isolada pode parecer legítima; a combinação com um dispositivo novo, uma localização improvável e uma chamada de suporte durante o mesmo período é mais relevante.
Também vale revisar os registros telefônicos e de colaboração. Procure chamadas de números recém-criados, mensagens que forneçam instruções para contornar o suporte e contatos que compartilhem o mesmo roteiro. A correlação entre usuários pode revelar que a campanha não é um caso individual.
Contenção sem perder evidência
Se houver indício de comprometimento, revogue sessões ativas e tokens de atualização, troque credenciais e suspenda temporariamente a conta quando necessário. A simples troca de senha pode ser insuficiente se o invasor tiver mantido uma sessão válida ou criado um método alternativo de acesso. Revise fatores cadastrados, dispositivos confiáveis, aplicações autorizadas e membros de grupos privilegiados.
Depois da contenção, examine o que a identidade fez. Liste arquivos consultados, mensagens enviadas, regras criadas, chaves geradas, mudanças de configuração e convites externos. Em serviços de nuvem, compare a atividade com o padrão histórico do usuário e verifique se houve acesso automatizado em volume incomum.
Evite apagar imediatamente a caixa postal, o dispositivo ou os registros locais da vítima. Faça uma coleta proporcional à política da organização, registre quem executou cada ação e mantenha uma linha do tempo. A análise precisa responder se houve apenas tentativa, autenticação bem-sucedida, persistência ou acesso a dados.
Quando a conta tiver privilégios administrativos, aplique uma contenção mais ampla. Separe a identidade comprometida das funções de administração, revise contas criadas no mesmo intervalo e procure alterações nos controles de auditoria. Se houver suspeita de exfiltração, envolva jurídico, privacidade e gestão de crise conforme o procedimento interno.
Como reduzir recorrência
A defesa começa por uma regra simples: nenhum suporte legítimo deve exigir que o usuário dite um código, aprove uma solicitação não iniciada por ele ou instale software sob pressão. Essa regra precisa aparecer no treinamento, no portal de suporte e no processo de atendimento. O time de suporte também deve ter um roteiro para encerrar a chamada e abrir uma verificação formal.
Prefira autenticação resistente a phishing para contas críticas e reduza a dependência de fatores que possam ser induzidos por engenharia social. As passkeys ajudam a proteger contas críticas contra páginas falsas, mas não substituem controles de recuperação, menor privilégio e monitoramento de sessões.
Para cada identidade privilegiada, defina proprietário, finalidade, dispositivos permitidos, caminho de recuperação e prazo de revisão. Remova contas sem uso, limite administradores permanentes e exija uma segunda validação para alterações de autenticação. A equipe deve conseguir revogar uma credencial sem depender da pessoa que está sob suspeita.
A telemetria precisa ser suficiente para detectar a cadeia, não apenas o evento final. Centralize falhas e sucessos de login, mudanças de fatores, consentimentos de aplicações, criação de tokens, alterações de regras de e-mail e acessos a dados. O guia sobre logs de segurança e detecção de ataques pode orientar a revisão dos registros e dos alertas que a equipe já possui.
Uma regra de detecção útil combina volume de falhas, sucesso posterior, novo dispositivo e mudança de configuração. Outra procura atividade de uma conta logo após contato telefônico reportado como suspeito. O alerta não precisa afirmar que houve invasão; deve encaminhar o caso para validação rápida, preservando o contexto.
O ponto central é não tratar vishing como treinamento isolado contra usuários. A campanha explora processos: recuperação de conta, suporte, aprovação de acesso, permissões excessivas e baixa visibilidade. Se a organização bloquear apenas o domínio usado na página falsa, o atacante poderá trocar o domínio e repetir o roteiro por telefone. Se, em vez disso, limitar a capacidade de cada identidade, registrar decisões e validar pedidos fora do canal suspeito, o custo do ataque aumenta e a investigação fica mais rápida.
A decisão para hoje é objetiva: audite acessos bem-sucedidos precedidos por falhas, revise alterações recentes em métodos de autenticação e confirme qualquer chamada que tenha pedido código ou aprovação. Em paralelo, selecione as contas críticas para autenticação resistente a phishing e teste a revogação de sessões. Essas medidas reduzem a janela de abuso sem depender de reconhecer previamente o nome da campanha.