Help desk vira alvo crítico de ataques contra identidades

Centrais de suporte técnico se tornaram um ponto de entrada para grupos que desejam assumir contas corporativas sem explorar uma falha de software. O alvo são empresas com equipes de atendimento internas ou terceirizadas, sobretudo quando o processo permite redefinir MFA, trocar telefone ou recuperar acesso com dados pessoais fáceis de obter. A ação prioritária é retirar decisões de alto risco do atendimento baseado apenas em perguntas cadastrais e exigir uma segunda prova independente antes de alterar a autenticação de qualquer conta privilegiada.

O ataque começa pelo suporte

O padrão descrito por autoridades e pesquisadores não depende necessariamente de malware no primeiro momento. O criminoso pesquisa a vítima, reúne informações profissionais e pessoais e liga para o help desk simulando uma troca de aparelho, perda do telefone ou bloqueio do autenticador. A conversa é construída para parecer urgente, mas o objetivo operacional é obter um reset de MFA, registrar um novo dispositivo ou alterar dados de recuperação.

O problema é estrutural: o atendente pode estar autorizado a resolver a solicitação, mas não tem meios suficientes para distinguir o titular legítimo de alguém que conhece seu nome, cargo, gestor e outros dados usados no cadastro. Quando o fluxo de recuperação trata conhecimento de informação estática como prova de identidade, a central passa a funcionar como um mecanismo de emissão de credenciais.

O alerta conjunto sobre o grupo Scattered Spider descreve ataques contra grandes organizações e seus help desks de TI. O documento também recomenda MFA resistente a phishing, controles de execução de aplicações e backups offline testados. A recomendação não é apenas técnica: ela indica que a recuperação de conta precisa ser tratada como uma operação de segurança, com autorização, registro e possibilidade de revisão.

Por que o MFA pode falhar

MFA reduz o risco de uma senha roubada, mas não impede um atacante de convencer o suporte a substituir o segundo fator. O criminoso não precisa quebrar a criptografia do autenticador; basta persuadir alguém com permissão administrativa a mudar a relação entre a conta e o dispositivo confiável.

Esse tipo de abuso também contorna controles que a equipe costuma medir de forma isolada. Um painel pode mostrar que não houve login impossível, que a senha não foi exposta e que o desafio adicional foi concluído. Ainda assim, a conta pode ter sido tomada durante uma alteração legítima registrada pelo próprio sistema. Por isso, o evento de redefinição precisa ser correlacionado com a criação de sessão, a mudança de número telefônico, o registro de aplicativo autenticador e a elevação de privilégios.

A análise da Mandiant sobre o UNC3944 descreve operadores usando engenharia social contra service desks para obter acesso inicial a contas privilegiadas. O relatório cita informações pessoais e profissionais usadas para contornar a verificação e registra pedidos de redefinição de MFA associados a uma suposta troca de telefone. O detalhe decisivo para o defensor é que o ataque explora o procedimento de recuperação, não uma vulnerabilidade específica no provedor de identidade.

Decisão operacional imediata

A organização deve separar claramente três tipos de solicitação: desbloqueio de baixo risco, recuperação de conta comum e alteração de autenticação privilegiada. O primeiro pode continuar no atendimento padrão. Os dois últimos precisam de controles adicionais, e qualquer mudança em uma conta administrativa deve sair da fila normal.

O segundo canal não deve ser outro contato fornecido durante a ligação. O atendente deve usar um diretório corporativo confiável, um gestor já cadastrado ou um procedimento presencial previamente definido. Se a pessoa alegar perda simultânea do telefone, e-mail e acesso ao dispositivo, isso deve aumentar o nível de verificação, não reduzir a exigência.

O que procurar nos registros

Comece por uma busca retrospectiva nas alterações de autenticação e recuperação. Priorize contas com privilégios elevados, acesso a cofres de segredos, consoles cloud, sistemas de pagamento e ferramentas de administração. Compare o horário do chamado com a criação de sessões, mudanças de localização, novos dispositivos, tokens emitidos e consultas incomuns a dados.

Também vale procurar sequências em que uma alteração de MFA seja seguida rapidamente por inclusão em grupo privilegiado, consentimento de aplicativo, criação de chave de acesso ou exportação de dados. O intervalo entre os eventos é menos importante que a relação causal: a redefinição pode ser o primeiro sinal visível de uma tomada de conta.

Não descarte chamados encerrados como “usuário validado”. Revise o método usado para validar, quem aprovou a exceção e se o atendente recebeu pressão para ignorar uma regra. Gravações e transcrições devem ser protegidas, mas precisam estar disponíveis para investigação. Uma frase agressiva, uma alegação de emergência ou a tentativa de impedir o retorno por canal oficial são indicadores úteis de engenharia social.

Prioridades para a equipe

P1: suspenda resets manuais de MFA para contas administrativas até que exista aprovação independente. Revogue sessões e tokens emitidos após alterações suspeitas, preserve os chamados e verifique se houve acesso a dados ou movimentação lateral. Se houver evidência de comprometimento, trate a conta como incidente, não como simples problema de suporte.

P1: bloqueie a possibilidade de o mesmo atendente solicitar, aprovar e executar uma alteração de autenticação. Essa separação reduz o risco de abuso interno e cria uma barreira contra a manipulação de um único operador.

P2: migre contas críticas para MFA resistente a phishing e mantenha contas de emergência com armazenamento, monitoramento e testes controlados. O fator resistente não elimina o risco de recuperação fraudulenta, mas reduz a utilidade de páginas falsas e códigos capturados.

P2: treine o help desk com cenários de pressão, não apenas com listas de sinais. O exercício deve medir se o atendente consegue interromper a chamada, consultar o procedimento e escalar sem receio de descumprir uma meta de tempo.

O indicador de sucesso não é a ausência de reclamações de usuários bloqueados. É a capacidade de provar quem autorizou cada mudança, qual evidência foi usada e quais eventos ocorreram depois. Se a empresa não consegue responder a essas perguntas, o processo de recuperação ainda é uma superfície de ataque aberta.

Fontes

O alerta conjunto da CISA sobre o Scattered Spider reúne técnicas observadas e recomendações de mitigação para organizações. A análise da Mandiant sobre o UNC3944 detalha o abuso de centrais de suporte e o impacto sobre aplicações SaaS.

Para complementar o plano interno, veja também como reduzir acessos de identidades de cargas na nuvem e como ataques exploram fluxos legítimos de login.