O ataque TrustSink no Microsoft Entra revela uma forma sofisticada de abuso da infraestrutura de identidade em nuvem. Descoberta pelo Varonis Threat Labs, a técnica explora a confiança depositada pelo Microsoft Entra ID em provedores externos de autenticação multifator para transformar um componente legítimo do processo de login em um mecanismo de captura de senhas.
Diferentemente de um phishing tradicional, o TrustSink não depende apenas de convencer a vítima a acessar um endereço falso. O invasor precisa primeiro obter privilégios elevados no ambiente e registrar um Método de Autenticação Externa (EAM) controlado por ele. A partir daí, o provedor fraudulento pode apresentar uma interface semelhante à da Microsoft, coletar a senha e devolver ao Entra um token de autenticação válido.
O problema se torna ainda mais sério porque trocar a senha não necessariamente elimina o ataque. Enquanto o provedor malicioso permanecer configurado no locatário, novos logins poderão continuar passando por ele. Entender esse mecanismo é essencial para equipes responsáveis por Microsoft Entra ID, segurança de identidade, ambientes híbridos e infraestrutura em nuvem.
Como funciona o ataque TrustSink no Microsoft Entra
O Microsoft Entra ID permite integrar provedores externos ao processo de autenticação por meio dos Métodos de Autenticação Externa, ou EAM. O recurso foi desenvolvido para permitir que organizações utilizem um provedor externo de MFA em determinados fluxos de autenticação.
Em uma configuração legítima, existe uma relação de confiança entre o Entra ID e o provedor externo. O Entra direciona o usuário ao serviço configurado e posteriormente recebe uma resposta indicando que a autenticação foi concluída.
O TrustSink explora justamente essa relação de confiança.
Segundo o Varonis Threat Labs, o Microsoft Entra valida a resposta criptográfica fornecida pelo provedor externo. Entretanto, essa validação não significa que o conteúdo apresentado ao usuário dentro da interface do provedor seja legítimo. Um provedor controlado pelo invasor pode apresentar uma página falsa enquanto continua fornecendo ao Entra uma resposta criptograficamente válida.
Essa diferença é fundamental para entender a técnica: o Entra pode confiar na autenticidade da resposta recebida sem conseguir determinar se o usuário acabou de entregar sua senha a um operador malicioso.
Imagem: Varonis
O papel dos privilégios elevados na configuração do EAM fraudulento
O TrustSink não é, inicialmente, um ataque que qualquer usuário comprometido consegue executar. O invasor precisa alcançar uma conta com privilégios suficientes para modificar configurações relacionadas à autenticação externa.
Na pesquisa publicada pela Varonis, o cenário envolve privilégios administrativos capazes de alterar essas configurações, incluindo funções como Administrador Global e Administrador de Política de Autenticação.
Isso transforma o TrustSink em um exemplo de ataque pós-comprometimento. O invasor primeiro precisa obter controle de uma identidade privilegiada. Depois, em vez de simplesmente utilizar essa conta administrativa, pode modificar a própria infraestrutura de autenticação para criar um mecanismo persistente de coleta de credenciais.
Esse detalhe reforça a importância do princípio do menor privilégio. Quanto maior o número de identidades capazes de modificar políticas e métodos de autenticação, maior também é a superfície disponível para esse tipo de abuso.
Contas administrativas permanentes devem ser tratadas como ativos críticos. A utilização de funções privilegiadas somente quando necessárias, aliada ao monitoramento das alterações realizadas nessas funções, reduz as oportunidades para que um comprometimento inicial evolua para uma invasão mais ampla.
Como o TrustSink captura a senha sem interromper o login
Depois de registrar o provedor externo fraudulento, o invasor passa a ter uma posição privilegiada dentro do fluxo de autenticação.
O usuário inicia o login normalmente. Após inserir seu identificador e senha, o Microsoft Entra solicita a autenticação multifator de acordo com as políticas configuradas.
Em determinado momento, o fluxo encaminha o usuário para o provedor externo.
É nesse ponto que entra a página controlada pelo invasor. A interface pode reproduzir elementos visuais associados à experiência de autenticação da Microsoft e solicitar novamente a senha do usuário. O valor informado é então enviado para a infraestrutura controlada pelo atacante.
A técnica é particularmente perigosa porque não precisa necessariamente provocar uma falha de autenticação perceptível.
Depois de capturar a senha, o provedor malicioso pode gerar a resposta esperada pelo Microsoft Entra. Como existe uma chave associada à configuração do provedor, a resposta pode ser assinada e apresentada ao Entra como uma autenticação válida.
Para o usuário, o resultado pode parecer normal: ele fornece os dados solicitados e consegue acessar o serviço.
Para o invasor, entretanto, o processo produziu uma nova credencial que pode ser utilizada em outras etapas do comprometimento.
O ponto central está na separação entre duas coisas diferentes: a validade criptográfica do token e a confiabilidade do conteúdo apresentado ao usuário. O primeiro pode ser verificado pelo Entra, enquanto o segundo depende da segurança e legitimidade do provedor configurado.
Por que trocar a senha não elimina o ataque TrustSink
Uma das características mais importantes do ataque TrustSink no Microsoft Entra é a persistência.
Em um incidente convencional de roubo de senha, o administrador pode tentar invalidar o acesso redefinindo a credencial comprometida. Essa medida continua sendo necessária, mas pode não ser suficiente quando existe um provedor externo fraudulento instalado na cadeia de autenticação.
Se o EAM malicioso continuar associado ao locatário, novos processos de autenticação poderão continuar passando pelo mesmo mecanismo.
Assim, o usuário pode receber uma nova senha, utilizá-la normalmente e acabar fornecendo essa nova credencial ao provedor fraudulento durante outro login.
Por isso, a remoção do mecanismo de captura precisa fazer parte da resposta ao incidente.
A equipe de segurança deve identificar e remover a configuração não autorizada, investigar os objetos relacionados e somente então realizar a redefinição das credenciais potencialmente expostas.
A investigação também deve considerar outros componentes que possam ter sido criados ou modificados durante o comprometimento, como aplicativos registrados, entidades de serviço, permissões, concessões de consentimento e políticas de autenticação.
Como proteger o Microsoft Entra contra o TrustSink
A principal defesa contra o TrustSink é impedir que um comprometimento administrativo consiga permanecer oculto dentro da infraestrutura de identidade.
O primeiro passo é manter um inventário dos Métodos de Autenticação Externa utilizados pela organização. Cada provedor configurado precisa ter uma justificativa operacional clara, proprietário definido e processo de revisão.
Qualquer alteração inesperada deve ser investigada rapidamente.
Os logs de auditoria do Microsoft Entra são importantes nesse processo porque permitem identificar alterações realizadas em configurações, aplicativos e objetos relacionados à identidade. A correlação entre essas informações pode ajudar a reconstruir a sequência de eventos durante um incidente.
Também é importante monitorar os logs de entrada, procurando comportamentos incompatíveis com o padrão habitual da organização, especialmente quando uma nova configuração de autenticação aparece pouco antes de atividades suspeitas.
Proteja as contas administrativas
Como o TrustSink depende de privilégios elevados, proteger as contas administrativas é uma das principais medidas preventivas.
Funções como Administrador Global devem ser atribuídas somente quando realmente necessárias. Sempre que possível, privilégios permanentes devem ser substituídos por mecanismos que permitam ativação controlada e temporária.
As contas administrativas também devem utilizar autenticação resistente a phishing.
Entre as tecnologias recomendadas pela Microsoft estão FIDO2, chaves de segurança, Windows Hello para Empresas e autenticação baseada em certificados. Esses mecanismos reduzem a exposição a ataques que dependem da reprodução de páginas de login ou da captura de códigos de autenticação.
Audite alterações na política de autenticação
A segurança do Microsoft Entra não depende apenas das credenciais dos usuários. Políticas, aplicativos, métodos de autenticação e permissões administrativas também fazem parte da superfície de ataque.
Por isso, alterações nesses componentes devem ser monitoradas como eventos de segurança.
Uma organização pode estabelecer alertas para mudanças inesperadas em métodos de autenticação externa, criação de aplicações privilegiadas, modificações em políticas de Acesso Condicional e alterações realizadas por contas administrativas fora do padrão operacional.
Esse tipo de monitoramento ajuda a detectar um ataque antes que o invasor consiga utilizar a persistência para capturar um volume maior de credenciais.
O que o TrustSink revela sobre a segurança de identidade
O TrustSink demonstra que proteger o MFA não significa apenas ativar uma segunda etapa de autenticação. É necessário proteger também os mecanismos que controlam essa autenticação.
A técnica descoberta pelo Varonis Threat Labs explora uma característica legítima do Microsoft Entra para introduzir um componente malicioso na cadeia de confiança. O resultado é um cenário em que uma senha pode ser capturada enquanto o processo de login continua funcionando normalmente.
Para administradores, a resposta passa por uma combinação de medidas: redução de privilégios administrativos, auditoria contínua, monitoramento das políticas de autenticação, investigação de provedores externos desconhecidos e adoção de métodos resistentes a phishing.
Em caso de suspeita de comprometimento, simplesmente redefinir a senha pode não ser suficiente. É necessário verificar se existe algum mecanismo persistente capaz de capturar a nova credencial.
O TrustSink também reforça uma regra importante para ambientes corporativos: a infraestrutura de identidade deve ser tratada como parte central da superfície de segurança, e não apenas como uma ferramenta para autenticar usuários.
Revisar regularmente os métodos de autenticação externa, limitar quem pode modificá-los e monitorar alterações no Microsoft Entra ID são medidas que podem reduzir o risco de ataques desse tipo.
Compartilhe este conteúdo com sua equipe de TI e segurança e aproveite a oportunidade para revisar as políticas de autenticação e os privilégios administrativos do Microsoft Entra ID no ambiente da sua organização.
