Cyberpediapor Brain
PTDEENESFRITNL

Roubo de cookies de sessão e tokens de portador

Um cookie de sessão roubado permite passar por um colaborador sem palavra-passe nem segundo fator. Mecanismo, caso real e reflexos.

Em 30 segundos

Onde acontece
No posto de trabalho (software malicioso), num site falso que retransmite a verdadeira página de início de sessão1, ou num navegador comprometido8.
O que o atacante quer
Retomar uma sessão já aberta, ler mensagens e agir em nome da vítima, contornando alguns segundos fatores2.
O reflexo
Terminar sessão nos serviços quando acabar, revogar as sessões em caso de dúvida, fechar regularmente as sessões do navegador.
Se já aconteceu
Avisar de imediato o suporte informático, porque a sessão roubada continua utilizável enquanto estiver ativa2.

Do que se trata

Quando um colaborador inicia sessão no correio eletrónico ou numa ferramenta em linha, o serviço entrega-lhe um pequeno elemento de identificação, quase sempre um cookie, que prova que já está autenticado. Se um atacante se apoderar desse elemento, pode entrar como se fosse a vítima, sem conhecer a palavra-passe1.

Do lado do colaborador, em regra nada é visível: a sessão continua, e o trabalho também. Esta ficha explica de onde vem o roubo, o que um atacante faz com ele e o que cada pessoa pode fazer para reduzir o risco.

Perguntas diretas

O que é um cookie de sessão?

Depois de um início de sessão bem-sucedido, muitas aplicações web usam um cookie de sessão como prova de autenticação1. O protocolo web não memoriza, por si só, quem é quem de um pedido para o seguinte: o servidor envia então ao navegador um token, que o navegador apresenta em cada troca3.

O que é um token de acesso e em que difere do cookie?

Um token de acesso serve para fazer pedidos autorizados em nome de um utilizador ou de um serviço. É comum nas aplicações em linha (SaaS) e nos serviços cloud4. Os dois objetos têm a mesma fraqueza: quem o apresenta é aceite como a pessoa que o obteve. A SP 800-63B do NIST, versão substituída desde 1 de agosto de 2025 pela SP 800-63-4, indicava, aliás, que a presença de um token de acesso OAuth não deve ser interpretada como a presença do utilizador na ausência de outros sinais, e que esse token pode continuar válido muito depois do fim da sessão de autenticação5.

O meu segundo fator não me protege?

Protege o início de sessão, não a sessão que se segue. A MITRE indica que esta técnica contorna alguns protocolos de autenticação multifator, uma vez que a sessão já está autenticada2. A Microsoft esclarece que não se trata de uma falha da autenticação multifator: o cookie roubado autentica o atacante, seja qual for o método de início de sessão do utilizador6.

Durante quanto tempo um cookie roubado continua utilizável?

Os cookies permanecem muitas vezes válidos durante muito tempo, mesmo que a aplicação não seja usada ativamente1. O atacante pode usá-lo enquanto o cookie estiver ativo2. A OWASP nota também que um limite de inatividade não trava um atacante que tenha tomado a sessão: ele pode gerar atividade para a manter aberta7.

1Na pele do atacante1 min

O atacante procura um elemento reutilizável, e não um segredo para adivinhar. Os cookies encontram-se no disco, na memória do navegador e no tráfego de rede para sistemas remotos. Outras aplicações do posto podem também guardar em memória cookies de autenticação, por exemplo as que se ligam a serviços cloud1.

Depois de obter o cookie, o atacante importa-o para um navegador que controla. Passa então a usar o site como o utilizador, enquanto a sessão estiver ativa. Pode consultar informações sensíveis, ler mensagens de correio ou fazer o que a conta da vítima tem o direito de fazer2.

No caso do token de acesso, uma via descrita é o phishing: o atacante regista uma aplicação armadilhada e envia uma ligação para levar a vítima a conceder-lhe o acesso. Uma vez concedido o token, a aplicação pode obter um acesso potencialmente duradouro à conta4. Os tokens de acesso têm por vezes uma duração limitada, mas o atacante pode também roubar um token de renovação, que lhe dá novos tokens de acesso sem pedir nada ao utilizador4.

2O que vê no ecrã1 min

O colaborador não vê nada: podem existir alertas do lado do administrador (ver abaixo). No caso de um site falso de retransmissão (descrito abaixo), a página é igual à verdadeira: a única diferença visível é o endereço6. Depois de introduzida a palavra-passe, a vítima é redirecionada para a página legítima, e o ataque prossegue em segundo plano6.

Segue-se uma ilustração neutralizada do endereço de um site falso de retransmissão. É inventada para o exemplo.

Excerto
Ilustração (endereço fictício, neutralizado):
hxxps://login[.]exemple-connexion[.]invalid/
[página idêntica à verdadeira página de início de sessão, só o endereço difere]

Existem alguns sinais indiretos. Se o atacante iniciar sessão enquanto a vítima trabalha, podem surgir alertas de «deslocação impossível» do lado do administrador6. Regras desconhecidas na caixa de entrada são outro sinal: no caso descrito abaixo, o atacante criou uma para que a vítima não visse as respostas do seu alvo6.

3Por baixo do capôEquipas de TI2 min

As fontes citadas aqui descrevem três vias de roubo.

  • O software ladrão: programas maliciosos visam os cookies dos navegadores presentes no posto1. Alguns extraem o cookie de sessão e enviam-no para o servidor do atacante1.
  • O site falso de retransmissão: no ataque dito do intermediário (adversary-in-the-middle), o atacante coloca um servidor proxy entre o utilizador e o site visado. Capta assim a palavra-passe e o cookie de sessão6. Ferramentas livres como Evilginx2, Modlishka e Muraena automatizam este procedimento6.
  • O navegador comprometido: um atacante pode injetar software num navegador para herdar os cookies, as sessões HTTP e os certificados de cliente do utilizador, e depois usá-los para entrar numa intranet autenticada8. Esta técnica pode também contornar a autenticação de dois fatores8. Pode exigir direitos particulares no posto8.

Por que funciona a reutilização do cookie? O cookie é a prova do início de sessão: o servidor não volta a verificar a palavra-passe a cada página6. A SP 800-63B do NIST admite outros métodos de identificação segura do dispositivo, entre os quais o TLS mútuo e a ligação de token (token binding)5. A OWASP recomenda associar o identificador de sessão a outras propriedades do cliente, como o endereço IP ou o User-Agent. Reconhece, porém, que um atacante hábil pode contornar este controlo, por exemplo partilhando a mesma rede que a vítima ou copiando o User-Agent7.

Quanto às durações, a OWASP cita limites de inatividade habituais de 2 a 5 minutos para aplicações de grande valor e de 15 a 30 minutos para aplicações de baixo risco. Para um funcionário de escritório que usa uma aplicação todo o dia, cita um limite absoluto de 4 a 8 horas7. A SP 800-63B do NIST, substituída desde 1 de agosto de 2025 pela SP 800-63-4, pedia que os segredos de sessão fossem apagados ou invalidados ao terminar sessão5.

4AutópsiasCasos reais2 min

Campanha de phishing com site falso de retransmissão contra o Microsoft 365 (documentada a 12 de julho de 2022)

A 12 de julho de 2022, a Microsoft publica a análise de uma campanha de grande dimensão. Segundo os seus dados, tentou visar mais de 10 000 organizações desde setembro de 20216. Os atacantes usaram sites de retransmissão para roubar palavras-passe e desviar a sessão da vítima, mesmo com a autenticação multifator ativada6.

Numa das vagas observadas, uma mensagem de correio com um anexo HTML anunciava uma mensagem de voz. O anexo mostrava uma falsa barra de transferência e redirecionava depois para um site de retransmissão construído com Evilginx2, que reproduzia a página de início de sessão da organização6. A vítima introduzia as credenciais, era redirecionada para a página legítima office.com, e o atacante ficava autenticado em seu nome6.

O passo seguinte visava a fraude de pagamento. Segundo a Microsoft, passaram por vezes apenas cinco minutos entre o roubo e o início da fraude. O atacante usava o cookie roubado para entrar no correio em linha, por vezes com um cookie que já trazia a indicação de autenticação multifator6. Procurava depois trocas de mensagens ligadas a pagamentos, apagava a mensagem de phishing inicial e criava uma regra na caixa de entrada que arquivava e marcava como lidas as respostas do seu alvo, para que a vítima não notasse nada6. Por fim, apagava as suas próprias respostas das pastas de itens enviados e eliminados6.

A Microsoft recomenda autenticações resistentes ao phishing (FIDO 2.0 ou certificados) e políticas de acesso condicional, que avaliam cada tentativa de utilização de um cookie roubado6.

5O que faz1 min

Estes gestos vêm das fontes citadas aqui. O seu efeito é reduzir a duração ou o alcance de uma sessão roubada, não garantir que ela não o seja.

  • Terminar sessão de forma explícita nos serviços quando acabar. A OWASP indica que fechar o navegador não força de modo fiável o fim da sessão e preconiza um fim de sessão explícito, com limites de tempo no servidor7.
  • Revogar as suas sessões se surgir uma dúvida (posto infetado, página de início de sessão suspeita). As fontes citadas aqui não detalham o procedimento: o suporte informático da empresa indica-o.
  • Fechar regularmente as sessões abertas no navegador. A MITRE recomenda fechar regularmente todas as sessões do navegador8.
  • Verificar o endereço antes de introduzir a palavra-passe: o endereço é a única diferença visível entre um site falso de retransmissão e o verdadeiro6.
  • Comunicar qualquer dúvida ao suporte informático, sem demora: enquanto a sessão estiver ativa, o atacante pode usá-la2.

Do lado da empresa, a MITRE cita a configuração dos navegadores para eliminar regularmente os cookies persistentes2.

Ficha

Identificador
CP-048
Ala
1. Ataques e técnicas
Competência Brain
Dominar as palavras-passe (master_passwords)
Reflexo Brain
cr-023
Esquema
G3 · Corte anatómico
Idiomas
de, en, es, fr, it, nl, pt
Fontes
8 fontes verificadas em 3 de novembro de 2026
Fontes8 fontes
  1. MITRE ATT&CK, «Steal Web Session Cookie». https://attack.mitre.org/techniques/T1539/ (consultado em 3 de novembro de 2026)
  2. MITRE ATT&CK, «Use Alternate Authentication Material: Web Session Cookie». https://attack.mitre.org/techniques/T1550/004/ (consultado em 3 de novembro de 2026)
  3. OWASP, «Session hijacking attack». https://community.owasp.org/attacks/Session_hijacking_attack (consultado em 3 de novembro de 2026)
  4. MITRE ATT&CK, «Steal Application Access Token». https://attack.mitre.org/techniques/T1528/ (consultado em 3 de novembro de 2026)
  5. NIST, «NIST Special Publication 800-63B». https://pages.nist.gov/800-63-3/sp800-63b.html (consultado em 3 de novembro de 2026)
  6. Microsoft, «From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud», 12 de julho de 2022. https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/ (consultado em 3 de novembro de 2026)
  7. OWASP, «Session Management - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (consultado em 3 de novembro de 2026)
  8. MITRE ATT&CK, «Browser Session Hijacking». https://attack.mitre.org/techniques/T1185/ (consultado em 3 de novembro de 2026)

Citar este artigo

Brain, «Roubo de cookies de sessão e tokens de portador», Cyberpedia, 2026. https://startbrain.io/cyberpedia/pt/articles/roubo-cookies-sessao-tokens-portador/

BibTeX 
@misc{brain_cp048_pt_2026,
  author = {Brain},
  title = {Roubo de cookies de sessão e tokens de portador},
  year = {2026},
  howpublished = {Cyberpedia},
  url = {https://startbrain.io/cyberpedia/pt/articles/roubo-cookies-sessao-tokens-portador/},
  note = {CC BY 4.0}
}
Licença CC BY 4.0