Greatness: o kit de phishing como serviço que rouba tokens com device code phishing e redefine a segurança corporativa

O ecossistema do crime cibernético avança rapidamente e um novo capítulo escreve a comercialização de técnicas sofisticadas para contornar controles de segurança: o kit de phishing-as-a-service (PhaaS) conhecido como Greatness Adicionau suporte para o chamado "device code phishing", uma variante que abusa do fluxo legítimo OAuth 2.0 Device Authorization Grant para capturar tokens e sortear fatores de autenticação tradicionais. A novidade não é apenas técnica, mas comercial: serviços como este empacotamento complexidade e a vendem por assinatura, reduzindo drasticamente a barreira para que atacantes pouco especialistas alcancem impactos empresariais graves.

Em termos práticos, device code phishing aproveita um mecanismo pensado para dispositivos com entrada limitada: o serviço apresenta ao usuário uma página legítima do provedor de identidade e pede-lhe para introduzir um código curto em outro dispositivo. O engano funciona porque a página de autenticação é autêntica, mas o atacante controla o fluxo que associa esse código à sessão do vítima. O resultado é que o atacante obtém tokens válidos sem que a vítima esteja diante de uma web de login falsa, o que dificulta a detecção pelos usuários e por controles superficiais de e-mail e navegação. A Microsoft mantém documentação técnica do fluxo de dispositivo que explica como o grant funciona e porque pode ser aproveitado deste modo: OAuth 2.0 Device Authorization Grant (Microsoft).

A convergência de ferramentas —AiTM (adversary‐in‐the‐middle), proxies para roubo de cookies, modelos pré-construídos para e-mails e cadeias de redireccionamento com protecções anti-análises — converte plataformas como Greatness em ecossistemas de ataque. Essa profissionalização traduz-se em campanhas mais eficientes: desde a entrega inicial mediante lures que se aproveitam de listas de remetentes seguros até a exploração de tokens para explorar e exfiltrar dados via Microsoft Graph API. Além disso, a validade prolongada de alguns tokens e a capacidade de gerar Primary Refresh Tokens (PRT) para persistência aumentam o risco de compromisso sustentado.

Um vetor preocupante detectado em campanhas recentes é a exploração de configurações de confiança existentes com fornecedores legítimos (por exemplo, RingCentral). Se uma organização tem um domínio na sua lista de remetentes seguros por ser cliente de um serviço, uma filtragem do fornecedor pode se tornar um guia para atacantes que sabem exatamente quais domínios evitarão os filtros. Isso obriga a repensar a prática de listas brancas automáticas: após uma lacuna de terceiros, as configurações de exclusão devem ser revistas e endurecer imediatamente.

As implicações operacionais são claras: o phishing continua sendo a porta de entrada principal e, graças a PhaaS, os ataques escalam em volume e em sofisticação sem que aumente necessariamente a pericia do atacante. Isto exige uma mudança de estratégia que combine prevenção técnica, detecção afinada e controle do risco humano. A nível de identidade, uma alavanca crítica é a política de acesso: bloquear globalmente o uso do grant de dispositivo ou restringir sua aplicação através de políticas de Conditional Access reduz a superfície de abuso. A Microsoft oferece guias para projetar políticas de acesso condicional que permitam controlar esse tipo de fluxos: Overview of Conditional Access (Microsoft).

Além de ajustar políticas, é imprescindível migrar para métodos de autenticação resistentes ao phishing, como chaves FIDO2 ou certificados baseados em hardware, e eliminar no possível os MFA que dependem de códigos de um único uso introduzidos manualmente ou pedidos de aprovação em aplicações que podem ser simuladas ou interceptadas. A formação do pessoal deve centrar-se num ponto específico: desconfíem de códigos inesperados e de pedidos de reatenticação sem contexto. A combinação de controlos técnicos e sensibilização reduz drasticamente a eficácia de campanhas baseadas em engenharia social.

Na detecção e resposta, é conveniente prestar atenção a sinais precoces: autenticações por fluxos de dispositivos em contas que não devem utilizá-los, aparecimento de novos dispositivos registrados (possivelmente geração de PRT), uso anormal da Microsoft Graph API, criação tardia de regras de bandeja de entrada e acessos desde infra-estruturas proxy que repetem inícios de sessão minutos ou horas após uma campanha. Instrumentar alertas e playbooks para rotação de credenciais, revogação de tokens e bloqueio de sessões suspeitas encurta a janela de ataque e limita o dano.

A ameaça tem também uma dimensão de higiene organizacional: impor políticas de DMARC, SPF e DKIM estritas não é suficiente quando as listas de remetentes seguros se mantêm sem revisão. Após cada notificação de compromisso de um fornecedor, as organizações devem auditar as exclusões de gateway e validar que não existam rotas alternativas que permitam a entrega de phishing. As diretrizes práticas de agências como a CISA sobre como se proteger contra phishing continuam sendo um ponto de partida útil para equipes de segurança e responsáveis por TI: Dicas para se proteger contra phishing (CISA).

Finalmente, não há que perder de vista a economia do crime: o acesso a painéis pré-configurados, suporte pelo Telegram e modelos para usar torna a segurança numa carreira contínua. As infra-estruturas internas devem assumir que a próxima campanha chegará e preparar controlos que não dependam unicamente de que os usuários "não caiam" no engano. Auditorias periódicas de permissões, redução de privilégios, segmentação de acessos e políticas de revogação automática ao detectar comportamento anormal são medidas que, combinadas com autenticação resistente ao phishing e postura de resposta ativa, podem restar eficácia aos serviços como Greatness.

Em resumo, a evolução dos kits de phishing para plataformas integradas de token theft exige uma resposta coordenada: limitar e auditar o uso do device code grant, adotar MFA a teste de phishing, endurecer exclusões de correio após lacunas de terceiros, e melhorar a detecção de uso anómalo de tokens. A defesa eficaz já não é opcional: é a condição para as organizações manterem o controle de suas identidades e ativos na nuvem.