Campanhas recentes estão usando páginas e mensagens que imitam convites, organizações e fluxos normais de autenticação para comprometer contas pessoais e profissionais. O alvo inclui pessoas ligadas a universidades, defesa, governos, organizações sem fins lucrativos e centros de pesquisa. A prioridade para a defesa é tratar códigos de dispositivo, senhas de aplicativo, URLs de autorização e aprovações inesperadas como eventos de identidade de alto risco, não como simples tentativas de phishing.
O que mudou no ataque
O relatório do Google Threat Intelligence Group descreve clusters de espionagem atribuídos com confiança moderada a atores ligados à Rússia. O ponto comum não é uma ferramenta única, mas o abuso de fluxos legítimos. A vítima pode receber um convite para uma reunião, um pedido relacionado a um evento diplomático ou uma solicitação de compartilhamento de ficheiro. A página seguinte pode encaminhar o utilizador para um provedor real de identidade, tornando a interação visualmente plausível.
Esse desenho reduz a eficácia de treinamentos baseados apenas em aparência. O domínio pode parecer legítimo, o login pode ocorrer numa página verdadeira e a solicitação final pode pedir apenas um código, uma URL ou a criação de uma credencial para um aplicativo. O resultado, porém, é uma autorização concedida ao invasor ou uma credencial reutilizável fora do controle imediato da organização.
Há uma diferença operacional relevante entre roubar uma senha e induzir uma autorização. A troca de senha pode não revogar sessões, tokens OAuth, senhas de aplicativo ou dispositivos já autorizados. Por isso, a investigação precisa reconstruir a cadeia de autenticação e autorização, incluindo aplicações conectadas, consentimentos, sessões e alterações recentes nos métodos de acesso.
Três caminhos observados
Um dos caminhos usa senhas de aplicativo. A mensagem convence a pessoa a criar uma senha com nome associado à atividade ou à organização falsificada. Em operações anteriores, o atacante pedia que a vítima enviasse o valor por e-mail; em variantes mais recentes, o valor é inserido num formulário de autenticação controlado pelo criminoso. Uma MFA tradicional pode não impedir esse abuso quando a própria vítima cria e entrega uma credencial alternativa.
Outro caminho usa phishing de OAuth. A vítima inicia um login legítimo, mas é instruída a partilhar a URL completa ou um código de verificação. A aprovação resultante pode conceder acesso a uma conta sem que o atacante precise conhecer a senha principal. O risco aumenta quando aplicações de terceiros têm permissões amplas, ficam sem revisão ou são tratadas como integrações permanentes.
Também foram observadas solicitações de códigos de dispositivo para contas Microsoft e WhatsApp. A mensagem apresenta o código como etapa de uma chamada, conferência ou convite. Se a vítima o digita num dispositivo do atacante, a sessão é vinculada ao ambiente criminoso. A ação parece simples e legítima porque usa o fluxo oficial do provedor; a fraude está no contexto e em quem controla o dispositivo que recebe a autorização.
Quem deve ser priorizado
O risco não está limitado a administradores. Pesquisadores, assessores, professores, equipes de relações internacionais, profissionais de defesa, funcionários de organizações civis e pessoas que participam de eventos públicos podem ser escolhidos pelo valor informacional dos seus contactos. Uma conta pessoal comprometida pode servir como ponto de confiança para atingir a caixa corporativa, colegas, parceiros ou fontes.
Equipes com ambientes híbridos devem olhar além do diretório central. Contas pessoais usadas para recuperação, aplicativos autorizados, caixas partilhadas, mensageria e serviços de colaboração podem manter acesso depois de uma troca de senha. O inventário de identidade precisa responder quem autorizou cada aplicativo, que permissões foram concedidas, quando ocorreu o consentimento e qual sessão foi criada.
Procedimento de resposta
| Prioridade | Ação | Evidência a preservar |
|---|---|---|
| P1 | Suspender a conta suspeita, revogar sessões e tokens, remover consentimentos e desativar senhas de aplicativo desconhecidas. | Registos de login, auditoria de aplicações, mensagens recebidas e horários de autorização. |
| P1 | Verificar outras contas com o mesmo endereço, domínio de recuperação, dispositivo ou aplicação autorizada. | Relações entre identidades, IPs, agentes de utilizador, dispositivos e permissões. |
| P2 | Bloquear domínios e URLs de infraestrutura usada no golpe, sem bloquear indiscriminadamente os provedores legítimos. | URL completa, cabeçalhos, anexos, redirecionamentos e cópias da página. |
| P2 | Reforçar políticas contra consentimento de aplicações e exigir autenticação resistente a phishing para acessos sensíveis. | Alterações de política, exceções aprovadas e testes de recuperação. |
Na triagem, procure logins bem-sucedidos que ocorram depois de falhas anormais, consentimentos novos, criação de senhas de aplicativo, alterações de métodos de autenticação e acessos a partir de dispositivos nunca vistos. A correlação temporal é mais útil do que um indicador isolado. Uma conta que aprovou uma aplicação e, logo depois, consultou mensagens ou ficheiros fora do seu padrão merece contenção imediata.
Como melhorar a deteção
Crie alertas para concessões de OAuth fora do catálogo aprovado, aplicações com permissões de leitura de correio ou ficheiros, códigos de dispositivo emitidos em resposta a mensagens externas e alterações de credenciais alternativas. A regra deve incluir o iniciador, o recurso autorizado, a origem, o dispositivo e a revogação posterior. Sem esses campos, a equipa pode ver o alerta, mas não consegue decidir o alcance.
O Google também descreve páginas que recolhem sinais do sistema antes de apresentar a etapa seguinte. Fingerprinting, domínios parecidos com serviços conhecidos e convites personalizados são pistas para priorizar a análise. A equipa não deve depender de uma lista fixa de domínios: campanhas desse tipo podem trocar infraestrutura rapidamente. O controlo mais durável é limitar permissões, reduzir aplicações autorizadas e exigir confirmação por um canal independente quando o pedido envolve código ou autorização.
O caso reforça a necessidade de complementar a MFA com proteção contra phishing. Chaves de segurança e passkeys vinculadas ao domínio reduzem a possibilidade de entregar uma autenticação válida numa página impostora, mas não eliminam o risco de uma pessoa autorizar conscientemente uma aplicação maliciosa. A política precisa combinar autenticação forte, governança de aplicações e revisão de consentimentos.
Decisão para a equipe
Se a organização não consegue listar as aplicações autorizadas, as senhas de aplicativo existentes e as sessões ativas de cada conta privilegiada, deve tratar essa lacuna como risco operacional imediato. Comece pelas identidades com acesso a correio, repositórios, documentos sensíveis e administração cloud. Revogue o que não tiver proprietário, finalidade e data de revisão.
Para utilizadores de alto interesse, substitua a formação genérica por exercícios curtos: não partilhar códigos, não criar senhas de aplicativo a pedido de terceiros, não colar URLs de autorização numa conversa e confirmar convites por um canal conhecido. O objetivo não é apenas reconhecer uma página falsa, mas interromper a transferência de confiança para um fluxo que o atacante controla.
Essa abordagem também evita um erro comum na resposta: encerrar o incidente depois de trocar a senha. A recuperação só está completa quando tokens, sessões, aplicações, credenciais alternativas e regras de encaminhamento foram revistos. Caso contrário, o invasor pode conservar acesso por um mecanismo que não aparece no fluxo normal de redefinição.
Fontes
Google Threat Intelligence: fluxos legítimos de autenticação usados contra pessoas de interesse.
Unit 42: ataques de credenciais em larga escala e sinais para auditoria.
Para contexto operacional, veja também como conter phishing que rouba sessões mesmo com MFA e como ataques de voz procuram acessos de nuvem.