Trocar a senha pode deixar uma sessão roubada ainda utilizável. Veja como a contenção do dispositivo, a invalidação de tokens, os controles de sessão dos aplicativos e a recuperação da conta se complementam.
Um aplicativo web pode continuar com uma sessão ativa após a troca da senha da conta. Dependendo de suas capacidades, um malware de roubo de informações pode coletar senhas armazenadas, além de cookies de sessão, tokens de autenticação, chaves de API e outros dados locais. Se essas informações já saíram do dispositivo, remover o malware não as invalida.
Uma senha é um segredo apresentado durante a autenticação. Um token de acesso permite que um aplicativo acesse recursos específicos, enquanto um token de atualização pode obter um novo token de acesso quando o protocolo permite. Uma sessão de aplicativo costuma continuar por meio de um cookie separado ou de um segredo de sessão emitido após a autenticação. Esses mecanismos podem pertencer à mesma conta, mas não necessariamente têm o mesmo prazo de validade ou controle de revogação.
Que tipos de acesso podem continuar após uma troca de senha?
A troca de senha impede novos logins que dependam da senha antiga. Não se pode presumir que ela encerre todos os tokens ou sessões de aplicativos que ainda sejam válidos. Nas orientações de acesso emergencial da Microsoft para o Entra, bloquear novos logins e revogar tokens de atualização impede que o usuário obtenha novos tokens do Entra. No entanto, um token de acesso existente pode funcionar até o fim de seu prazo de validade padrão de uma hora. O Continuous Access Evaluation pode reduzir esse intervalo nos cenários compatíveis do Microsoft 365; isso não significa que todos os tokens serão invalidados instantaneamente.
Um cookie de sessão emitido pelo aplicativo precisa ser tratado separadamente. O Entra não pode revogar diretamente um token de sessão emitido pelo próprio aplicativo. O NIST SP 800-63B-4 descreve a mesma separação em sistemas federados: o provedor de identidade (IdP) e a parte confiável (RP) estabelecem e encerram suas sessões de forma independente. Encerrar a sessão do provedor de identidade não encerra, por si só, a sessão de todos os aplicativos conectados.
Essa distinção é útil para um invasor. O MITRE ATT&CK documenta como um cookie de sessão web roubado, ainda válido e reutilizável, pode ser importado para um navegador controlado por um invasor. Como a sessão já está autenticada, alguns fluxos de autenticação podem não exigir uma nova etapa de MFA. Isso descreve uma capacidade, não uma prova de que uma conta específica foi tomada por um invasor.
Contenção do dispositivo e controles da conta
O dispositivo suspeito é isolado conforme o plano de resposta a incidentes da organização, enquanto se avalia a necessidade de preservar evidências relevantes. Se a conta tiver privilégios elevados ou acesso a dados sensíveis, o bloqueio de novos logins e o encerramento dos caminhos de acesso atuais podem começar antes da conclusão da análise completa do dispositivo. As trocas de senha, a recuperação da conta e as tarefas administrativas são realizadas por meio de um dispositivo e de um canal confiáveis, para que as novas credenciais não sejam expostas ao sistema suspeito.
Dados de acesso armazenados no dispositivo
A análise não se limita às senhas salvas após o período em que se suspeita que a infecção ocorreu. O início de uma infecção pode ser incerto, e um malware de roubo de informações pode acessar credenciais que já estavam armazenadas no dispositivo. Com base nas evidências do incidente, a análise abrange perfis de navegador, contas usadas ou armazenadas localmente, cookies de sessão, tokens e chaves de API. A limpeza ou a reinstalação do sistema no dispositivo não invalida senhas, tokens ou chaves que talvez já tenham sido roubados.
Controles de tokens e sessões
Os controles documentados do provedor de identidade são usados para bloquear novos logins, invalidar tokens de atualização quando houver suporte e encerrar sessões do IdP. Em seguida, os aplicativos críticos são verificados separadamente, e suas próprias sessões são encerradas por meio dos controles de cada aplicativo. Uma mensagem de “sucesso” em uma tela de administração não comprova que todo o acesso foi encerrado. Ainda importam o tipo de token, sua condição de expiração prevista e o momento em que cada aplicativo voltará a exigir autenticação.
A senha e os demais dados de acesso incluídos no escopo do incidente são substituídos ou invalidados a partir de um dispositivo confiável. A inclusão de uma chave de API, de um token de desenvolvedor ou de outra credencial armazenada localmente depende das evidências do incidente e do comportamento do sistema afetado. O objetivo não é redefinir todas as contas indiscriminadamente, mas determinar quais senhas, tokens, chaves ou cookies de sessão podem ter saído do dispositivo e continuar utilizáveis.
Alterações de persistência
Um invasor pode criar uma forma de voltar a acessar a conta, em vez de depender apenas da sessão atual. As orientações de resposta da Microsoft para uma conta de e-mail comprometida no Microsoft 365 recomendam verificar métodos de MFA e dispositivos não reconhecidos, consentimentos indesejados para aplicativos, funções administrativas não autorizadas, encaminhamento de e-mails e regras ocultas da caixa de entrada. Essa lista é específica do Microsoft 365; os controles equivalentes e seus efeitos variam entre provedores.
Um método de MFA não reconhecido ou suspeito é removido ou invalidado. Se o método do usuário legítimo precisar ser cadastrado novamente, a titularidade é verificada primeiro por meio de um canal de recuperação confiável, e apenas um novo método controlado por esse usuário é cadastrado. Cadastrar novamente um método adicionado por um invasor preservaria o caminho de acesso, em vez de encerrá-lo.
O MFA não revoga uma sessão ativa
O MFA cria mais uma barreira para iniciar uma nova sessão com uma senha roubada, mas não invalida, por si só, um cookie reutilizável de uma sessão já autenticada. Os métodos de MFA também oferecem proteções diferentes. Os requisitos para autenticadores do NIST não consideram os códigos de uso único inseridos manualmente resistentes a phishing e citam WebAuthn/FIDO2 como exemplo de autenticação resistente a phishing. Uma autenticação mais forte protege os logins futuros; uma sessão roubada que continua válida ainda precisa ser encerrada separadamente.
O que os logs podem — e não podem — comprovar
Quando disponíveis, os registros de login e de ações sensíveis referentes ao período do incidente podem revelar locais e horários incomuns, concessões de acesso a aplicativos e alterações na conta. Para o Microsoft 365, o provedor orienta a não restringir a busca inicial de auditoria cedo demais e recomenda analisar os registros desde o início da atividade suspeita até a remediação. Não encontrar nenhum evento suspeito não prova que a conta esteja segura. O resultado só é significativo dentro dos limites da telemetria disponível, do período de retenção, das fontes consultadas e do intervalo de tempo analisado.
Da mesma forma, a evidência de que uma credencial ou um cookie foi exposto não é, por si só, evidência de uso não autorizado bem-sucedido ou de tomada de controle da conta. Exposição, tentativa de uso observada e tomada de controle confirmada continuam sendo situações distintas. Caminhos de acesso potencialmente válidos ainda exigem uma resposta proporcional, cujo escopo depende do nível de privilégio da conta, da sensibilidade dos dados e das evidências disponíveis. O guia de avaliação após um vazamento da LeakData aborda essa distinção mais ampla entre exposição e uso indevido confirmado.
O registro do incidente lista as sessões encerradas no provedor de identidade e nos aplicativos, as condições de expiração previstas para os tokens, as alterações não autorizadas removidas e as lacunas na análise dos logs. Isso deixa claro quais caminhos de acesso foram tratados e quais incertezas permanecem.