18 de agosto de 2026
As empresas têm vindo a reforçar a segurança do acesso principal há anos, recorrendo a métodos como o SSO, a MFA, as chaves de acesso e a abordagem Zero Trust. No entanto, qualquer programa de identidade continua a necessitar de um procedimento de recuperação. Quando um utilizador perde um dispositivo ou fica sem acesso, a organização tem de decidir se deve reiniciar a MFA, emitir novas credenciais ou associar um novo dispositivo.
Curiosamente, a recuperação de contas é talvez a área mais perigosa da superfície de ataque, mas raramente recebe o mesmo nível de atenção. Os atacantes nem sempre precisam de contornar diretamente a autenticação multifatorial (MFA) quando conseguem persuadir um serviço de assistência ou um fluxo de trabalho de recuperação a ignorá-la.
Se a recuperação depende de factos conhecidos, de códigos que possam ser partilhados ou do discernimento de um agente, trata-se, na verdade, de verificar o que alguém tem ou sabe – e não se a pessoa certa está realmente presente.
Como funciona, na prática, a recuperação de contas atualmente
Antes de analisarmos como a recuperação é alvo de ataques, vale a pena esclarecer como é que a maioria das organizações a gere, na prática.
Numa empresa típica, um colaborador que tenha sido excluído tem duas formas de regressar.
Redefinição de palavra-passe em regime de autoatendimento (SSPR): um colaborador confirma algo que sabe ou algo que possui: perguntas de segurança, um número de identificação de colaborador ou um código de acesso único enviado para um número registado ou para um e-mail de reserva. O sistema redefine a credencial ou regista um novo dispositivo.
Serviço de assistência: O procedimento assistido consiste, normalmente, numa chamada telefónica para o serviço de assistência informática. É frequentemente utilizado quando o colaborador perdeu o dispositivo ou o autenticador de que o SSPR depende. O agente faz uma breve série de perguntas de verificação, geralmente baseadas nos registos dos Recursos Humanos, e, em seguida, efetua a redefinição manualmente. No caso de contas com privilégios, pode haver uma etapa de aprovação. Muitas vezes, porém, não há. Estes dados podem ser interceptados, ter sido obtidos numa violação de segurança ou ter sido extraídos previamente do alvo. É essa lacuna que se revela tão perigosa.
Em última análise, nenhuma das duas vias verifica a identidade da pessoa. Ambas verificam dados sobre a pessoa. Esta distinção é importante, porque os casos que o SSPR não consegue tratar são precisamente aqueles em que há mais em jogo e em que os controlos são mais fracos.
A recuperação através do serviço de assistência técnica é agora uma via comprovada de violação de segurança
Isto não é mera teoria. Sabemos que a engenharia social pode contornar controlos de identidade reforçados, visando os fluxos de trabalho de apoio e recuperação, e que a recuperação através do serviço de assistência técnica é o método de entrada documentado em algumas das intrusões mais devastadoras dos últimos dois anos.
Na verdade, a Gartner descreve a recuperação de contas devido a palavras-passe esquecidas ou credenciais perdidas como «a parte mais arriscada do ciclo de vida da gestão de identidades».
O Scattered Spider utilizou-o na MGMe, novamente, nos ataques de 2025 contra M&S, Co-op e Qantas. Na MGM, bastou uma única chamada telefónica de dez minutos para contornar uma infraestrutura de segurança de vários milhões de dólares. Após os incidentes no setor retalhista do Reino Unido, o NCSC instou especificamente as organizações a reverem os processos de redefinição de palavras-passe do serviço de assistência, incluindo a forma como os funcionários são autenticados antes das redefinições, especialmente no caso de contas com privilégios elevados.
A dimensão do caso está documentada. Uma queixa do Departamento de Justiça dos EUA, tornada pública em setembro de 2025, alegava pelo menos 120 intrusões em redes envolvendo 47 entidades norte-americanas, com as vítimas que pagaram pelo menos 115 milhões de dólares em resgates. Os procuradores descreveram um método consistente em quase todos os casos: ligar para o serviço de assistência, solicitar a redefinição de uma palavra-passe, assumir o controlo de uma conta administrativa e, em seguida, utilizar esse acesso para extrair dados.
A questão não é que os agentes sejam descuidados; é que o processo lhes exige que tomem uma decisão de identidade de alto risco com base em sinais que os atacantes podem facilmente falsificar em grande escala. A recuperação da conta não deve depender de alguém decidir se um pedido parece legítima; deve exigir prova de presença genuína.
Avanços no texto gerado por IA e clonagem de voz facilitam a realização destas chamadas. Um atacante que liga para o serviço de assistência alegando ser um colaborador que ficou sem acesso à conta pode agora soar exatamente como esse colaborador, o que elimina uma das poucas verificações instintivas de que um agente dispunha. Mas o ataque não depende disso. Um atacante bem preparado pode utilizar dados violados, contexto do LinkedIn, terminologia interna e uma história convincente. Sob pressão, pede-se ao agente para «simplesmente reiniciar a autenticação multifatorial» ou «ajudar-me a voltar a aceder à minha conta».
O FBI e a CISA documentaram o passo mais importante. Os atacantes não se limitaram a repor as palavras-passe. Repuseram também os tokens de autenticação multifator (MFA) e, em seguida, registaram os seus próprios dispositivos de autenticação. A reposição não lhes concedeu acesso temporário. Tornou-os nos utilizadores de confiança.
Por que razão os controlos de recuperação de sistemas legados falham
A maioria dos fluxos de recuperação baseia-se em dois tipos de fatores fracos.
- Fatores de conhecimento, tais como perguntas de segurança, identificações de funcionários, nomes de gestores ou datas de nascimento, são tão confidenciais quanto a última violação de segurança ou pesquisa no LinkedIn. Comprovam o conhecimento de algo, não uma identidade verificada.
- Fatores de posse, tais como códigos de acesso únicos por SMS, aplicações de autenticação ou dispositivos de reserva, podem ser partilhados, são suscetíveis a phishing e, muitas vezes, não estão disponíveis no momento exato em que a recuperação é necessária. Se o utilizador tiver perdido o dispositivo, um controlo vinculado ao dispositivo não pode ser a única forma de recuperar o acesso. Os códigos de acesso únicos (OTP) podem continuar a apoiar o processo de recuperação, mas não devem ser considerados como prova de identidade.
Chaves de acesso e os dados biométricos nativos do dispositivo são mais seguros do que as palavras-passe, mas não resolvem todos os casos extremos do ciclo de vida. As chaves de acesso continuam a necessitar de recuperação e novo registo quando se muda de dispositivo. O Face ID e outros sistemas biométricos locais semelhantes autorizam a utilização de um dispositivo; por si só, não comprovam novamente à organização que o titular da conta é a pessoa real que está agora a solicitar a recuperação.
A solução: voltar a verificar a pessoa, e não a credencial
A recuperação deve ser verificada, pelo menos, com o mesmo nível de rigor que o processo de início de sessão que substitui. Em vez de perguntar: «Será que esta pessoa tem conhecimentos suficientes para parecer legítima?», a organização deve perguntar: «Será que a pessoa certa e real está presente neste momento?»
Isso requer uma detecção de vivacidade, que confirme que um rosto apresentado durante uma verificação pertence a uma pessoa real que se encontra fisicamente presente naquele momento, e não a uma fotografia, a uma gravação ou a um conteúdo sintético.
Nem todas as soluções são iguais, e a diferença é relevante na fase de avaliação, e não aqui. Alguns sistemas são testados apenas contra ataques direcionados à câmara. São menos os que são testados contra ataques introduzidos diretamente no software, contornando completamente a câmara. Se chegar à fase de comparar fornecedores, essa é a pergunta a fazer: que tipos de ataque é que isto foi testado de forma independente e por quem?
No processo de recuperação, isso altera o fluxo. O utilizador confirma os dados de contacto, digitaliza um documento de identificação, se necessário, realiza uma digitalização facial com verificação de vitalidade e só então redefine as credenciais ou volta a associar um dispositivo.
E como a verificação gera um registo de uma pessoa identificada, em vez de uma resposta correta a uma pergunta, a reinicialização deixa para trás as provas que o processo anterior nunca gerou.
A recuperação biométrica baseada na nuvem pode ser executada tanto num dispositivo novo como num antigo, pelo que o telemóvel perdido não se torna o único ponto de falha. Além disso, isenta o serviço de assistência da decisão mais arriscada, reduz o número de pedidos de reinicialização e proporciona às equipas de segurança um registo de auditoria mais claro a partir do momento da nova vinculação.
O que deve demonstrar um excelente processo de recuperação de contas?
Os responsáveis pela segurança não precisam de mais uma solução alternativa de baixa fiabilidade. Precisam de um plano de recuperação que responda às seguintes perguntas:
- Isso volta a verificar a identidade da pessoa ou limita-se a verificar novamente uma credencial?
- Funciona quando o dispositivo original do utilizador já não existe?
- Isso deixa um registo de quem foi verificado, e não apenas de que o processo foi seguido?
- A sua capacidade de funcionamento em tempo real foi testada de forma independente e em relação a que parâmetros?
- Consegue acompanhar o ritmo das ameaças emergentes, das novas táticas de engenharia social e de suplantação de identidade?
Se a resposta for «não», o processo de recuperação poderá ser mais vulnerável a ataques do que o próprio processo de início de sessão que se supõe que protege.
A recuperação de contas já não é apenas um inconveniente administrativo. É aqui que os sistemas de identificação mais robustos falham, caso a pessoa não seja novamente verificada. As organizações que estão a antecipar-se a esta realidade estão a passar de perguntas do tipo «o que sabe?» e «o que tem?» para «consegue provar que é a pessoa certa e real?»
Veja a sessão na íntegra
Este artigo baseia-se na nossa sessão sobre deepfakes no local de trabalho, que inclui demonstrações ao vivo e o contexto mais alargado do ciclo de vida da identidade, desde o recrutamento à distância até às reuniões e às ações de alto risco da força de trabalho.
Veja «Stranger Things» no local de trabalho: proteger a sua organização contra o «Upside Down» das deepfakese, em seguida, descubra como o iProov Workforce Solution Suite garante a recuperação de contas e a reatribuição de dispositivos – os momentos em que os controlos baseados em credenciais são mais vulneráveis.
