IDENTIDADE / ENGENHARIA SOCIAL / SAAS

Uma ligação convincente pode transformar processos legítimos de suporte, recuperação de conta e autenticação em caminhos para o comprometimento da identidade. Campanhas recentes mostram criminosos combinando vishing, páginas falsas, códigos de MFA e abuso de SSO para alcançar aplicações SaaS e dados corporativos sem explorar uma vulnerabilidade no software.
Durante anos, a defesa contra invasões concentrou grande parte do esforço em senhas fortes e autenticação multifator. Esse modelo continua necessário, mas os ataques mais recentes mostram uma mudança importante: em vez de quebrar o mecanismo de autenticação, criminosos procuram convencer pessoas e processos autorizados a executarem etapas legítimas em benefício do atacante.
O Google Threat Intelligence Group acompanha diferentes clusters financeiramente motivados que utilizam phishing por voz, ou vishing, para comprometer ambientes corporativos. Entre eles, UNC6040 ficou conhecido por campanhas direcionadas ao Salesforce, enquanto operações observadas em 2026 ampliaram o padrão para credenciais de Single Sign-On (SSO), Microsoft 365, Okta e outras aplicações SaaS. O ponto em comum é a exploração da confiança depositada em interações de suporte e procedimentos de identidade.
A ligação não precisa roubar a senha
O telefonema funciona como uma interface de engenharia social. O atacante pode se apresentar como suporte de TI, fornecedor ou técnico responsável por uma atualização obrigatória. A vítima é conduzida a uma página de autenticação, orientada a fornecer um código ou persuadida a aprovar uma ação que parece fazer parte de um procedimento corporativo.
No caso documentado do UNC6040, o GTIG observou vítimas sendo orientadas a autorizar uma aplicação conectada controlada pelo atacante no Salesforce. A campanha abusou de versões modificadas ou personalizadas de ferramentas com funcionalidades semelhantes ao Data Loader para consultar e exfiltrar grandes volumes de dados. Segundo o Google, os casos observados dependeram da manipulação do usuário, e não da exploração de uma vulnerabilidade inerente ao Salesforce.
MFA pode continuar funcionando exatamente como projetado e, ainda assim, o ataque ser bem-sucedido. Se a vítima entrega um código, aprova um fluxo OAuth, registra um novo método de autenticação ou autoriza uma aplicação acreditando estar seguindo o suporte legítimo, o criminoso contorna a intenção do controle sem necessariamente quebrar sua tecnologia.
O suporte de TI tornou-se parte do perímetro de identidade
O problema ganha outra dimensão quando o criminoso inverte o papel e se apresenta como o próprio funcionário diante do help desk. Processos de recuperação de conta existem justamente para situações em que o usuário perdeu uma senha, um telefone ou um fator de autenticação. Isso significa que o suporte possui capacidade operacional para alterar controles que normalmente impediriam o acesso do atacante.
Em avaliações de Red Team, a Mandiant relata ter conseguido persuadir service desks a redefinir credenciais e modificar diferentes formas de MFA. A conclusão não é que o suporte deva deixar de ajudar usuários, mas que operações de alto impacto sobre identidade precisam de um nível de verificação proporcional ao privilégio que concedem.

SSO transforma uma identidade em várias portas
Single Sign-On reduz atrito e melhora a administração de identidades, mas também concentra valor. Uma conta comprometida no provedor de identidade pode oferecer ao atacante caminhos para várias aplicações conectadas. Em maio de 2026, o GTIG descreveu a operação UNC6671, associada à marca BlackFile, usando vishing e técnicas de adversário-no-meio para comprometer SSO e alcançar ambientes Microsoft 365, Okta, SharePoint, OneDrive, Zendesk e Salesforce.
Depois da autenticação, a atividade pode deixar de se parecer com uma invasão tradicional. O atacante utiliza uma identidade válida, sessões legítimas e APIs que fazem parte do funcionamento normal da plataforma. O desafio do SOC passa a ser distinguir o comportamento esperado de um usuário daquele produzido por alguém que assumiu sua identidade.
MFA resistente a phishing reduz uma parte importante do risco
A conclusão não deve ser que MFA perdeu valor. Ao contrário: autenticação multifator continua sendo um controle fundamental. A diferença está na qualidade do fator e no desenho dos processos ao redor dele. Métodos resistentes a phishing, como passkeys e chaves de segurança baseadas em padrões criptográficos adequados, reduzem a dependência de códigos que podem ser solicitados por telefone ou capturados por páginas falsas.
Entretanto, até uma autenticação tecnicamente robusta pode ser enfraquecida se o processo de recuperação permitir que um atacante registre um novo fator após convencer o suporte de que é o usuário legítimo. Por isso, a segurança da autenticação precisa incluir também enrollment, reset, recuperação, revogação e atendimento.
OAuth e aplicações conectadas exigem a mesma disciplina
Outra lição das campanhas contra SaaS é que autenticar o usuário não encerra a decisão de segurança. Aplicações conectadas podem receber permissões por OAuth e continuar acessando dados de acordo com os escopos concedidos. Um usuário legitimamente autenticado pode, sob engenharia social, autorizar uma integração controlada pelo atacante.
Esse cenário exige inventário de aplicações OAuth, revisão de escopos, restrição de quem pode aprovar integrações e monitoramento de novos consentimentos. Organizações também precisam observar downloads volumosos, consultas incomuns, criação de aplicações, alterações de MFA, novos dispositivos e acessos originados de infraestrutura incompatível com o histórico do usuário.
Quando a identidade comprometida alcança CRM, colaboração, armazenamento e sistemas corporativos, o incidente pode resultar em exposição de dados, fraude, extorsão, comprometimento de comunicações internas e movimentação lateral entre serviços. A investigação também se torna mais complexa porque parte da atividade utiliza credenciais e interfaces legítimas.
Como fortalecer o help desk contra vishing
A verificação de identidade precisa ser independente do canal que originou a solicitação. Uma chamada recebida não deveria, sozinha, estabelecer confiança suficiente para redefinir senha, substituir MFA ou registrar dispositivo. Para solicitações sensíveis, a organização pode encerrar a chamada e realizar contato por um canal corporativo previamente cadastrado, validar tickets existentes e aplicar aprovação adicional conforme o risco.
O próprio GTIG recomenda verificação positiva de identidade para mudanças de senha e MFA, além de procedimentos específicos quando alguém se apresenta como fornecedor. Nesses casos, a orientação é interromper a interação e validar a solicitação por contatos confiáveis já registrados pela organização.
Treinamento também precisa evoluir. O usuário não deve aprender apenas a “não clicar em links”. Precisa compreender que técnicos legítimos não devem solicitar códigos de MFA, que telas de consentimento merecem a mesma atenção de uma tela de login e que chamadas inesperadas envolvendo passkeys, SSO, migração ou atualização de autenticação devem ser verificadas por outro canal.
Detecção precisa correlacionar identidade e SaaS
Como o atacante pode utilizar credenciais válidas, a defesa precisa acompanhar a sequência dos eventos. Uma alteração de MFA seguida por autenticação em novo dispositivo, consentimento OAuth, acesso a múltiplos SaaS e transferência atípica de dados constitui um sinal muito mais forte quando analisado como uma cadeia do que como eventos isolados.
Logs do provedor de identidade, help desk, aplicações SaaS, endpoints e ferramentas de segurança precisam ser correlacionados. Controles de acesso condicional, postura de dispositivo, restrições geográficas quando adequadas, gestão de sessão e resposta automatizada a identidades de risco ajudam a limitar o tempo disponível para o atacante.
Conclusão
Vishing contra suporte e usuários mostra que identidade é um sistema sociotécnico. Senhas, MFA, SSO e OAuth podem ser tecnicamente sólidos, mas continuam inseridos em processos conduzidos por pessoas. Quando o criminoso entende esses processos melhor do que a organização os protege, uma conversa pode abrir uma porta que nenhum exploit precisou quebrar.
A defesa mais consistente combina autenticação resistente a phishing, verificação forte no help desk, menor privilégio, governança de aplicações conectadas e monitoramento capaz de acompanhar a identidade entre diferentes serviços. Em ambientes SaaS, proteger o login é apenas o começo; também é necessário proteger tudo o que pode alterar, recuperar, delegar ou ampliar essa identidade.
Referências
- Google Threat Intelligence Group — Welcome to BlackFile: Inside a Vishing Extortion Operation
- Mandiant — Vishing for Access: Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft
- Mandiant — UNC6040 Proactive Hardening Recommendations
- Mandiant — Hello, Operator? A Technical Analysis of Vishing Threats
- Google Cloud — Cloud Threat Horizons Report H1 2026


Be the first to comment