Sessões Sequestradas e HARs Inocentes: Como a Okta Deu as Chaves da Casa ao Invasor (Outubro/2023)

Em outubro de 2023, a Okta; supostamente a fortaleza da identidade digital; teve sua armadura furada com algo tão banal quanto… um arquivo HAR. Sim, aquele arquivo que você manda pro suporte quando o seu botão não funciona. Só que nesse caso, o botão que “não funcionava” era a segurança.

O incidente expôs tokens de sessão de clientes por meio do sistema de suporte da própria Okta, resultando no sequestro de sessões(session hijacking) de gigantes como Cloudflare, BeyondTrust, e 1Password. O ataque foi elegante, discreto, e honestamente, nem precisou de muito esforço. Um verdadeiro passeio no parque para quem sabe onde clicar.

Como Tudo Começou: Um caso clássico de “Oops”

Toda brecha de segurança começa com algo pequeno. Às vezes, um clique. Outras vezes, um esquecimento. Neste caso, foi pura comodidade disfarçada de burrice operativa. A sequência do desastre é quase didática; perfeita para ser usada em aulas de “O que não fazer com credenciais corporativas” :

1. Um funcionário da Okta usava o Google Chrome em sua conta pessoal para acessar recursos internos da empresa.
2. E como todo bom profissional desatento, deixou o Chrome salvar sua senha de uma conta de serviço com acesso ao sistema de suporte(Help Center) da própria Okta.
3. Um atacante comprometeu essa conta pessoal do google; como? Phishing, vazamento anterior, extorsão emocional, tanto faz. O importante é que a porta estava destrancada, e brilhando com um tapete escrito “entre”.
4. Bingo. Acesso direto ao painel de suporte da Okta; e com isso, acesso aos arquivos HAR que os clientes haviam enviado buscando ajuda técnica.

Tradução ofensivamente honesta: a empresa que oferece autenticação segura para o mundo corporativo teve seu próprio sistema comprometido por causa de uma senha salva no navegador pessoal…

O atacante então simplesmente reutilizou os tokens contidos nesses HARs para acessar sessões administrativas de clientes como BeyondTrust e Cloudflare. Sem precisar quebrar MFA, sem brute force, sem reverse shell. Só leitura e colagem. E o melhor (ou pior): Ninguém percebeu por semanas… O alerta só veio depois que outras empresas, mais atentas, desconfiaram de acessos suspeitos; e a Okta ligou os pontos… Tarde demais, como de costume.

HAR: O Pequeno Grande Vazamento

O HAR (HTTP Archive) é uma daquelas coisas que parecem inocentes até você olhar dentro. Tecnicamente, ele é um arquivo .har que registra: ° Todas as requisições HTTP feitas durante uma sessão ° Cabeçalhos, payloads, cookies e códigos de resposta ° Tokens de autenticação ativos, aqueles que o navegador usa para manter você logado Em outras palavras: se o seu navegador fosse um diário, o HAR seria a confissão completa com senha, localização e anotações marginais. Esse tipo de arquivo é amplamente utilizado por times de suporte técnico para reproduzir bugs e erros de interface, o que é ótimo do ponto de vista de troubleshooting. Mas é um pesadelo de segurança quando enviado sem sanitização... E foi exatamente isso que aconteceu aqui:

“Ei, suporte, meu botão de login não funciona. Aqui esta meu HAR.” Tradução realista: “Segue o token da minha sessão administrativa, aproveita e atualiza meus dados bancários.”

Com esses arquivos em mãos, o invasor saltou direto para sessões ativas de clientes corporativos, como quem entra numa festa VIP com crachá falsificado, só que legitimo. E como os tokens estavam válidos, o sistema aceitou sem questionamentos. Nem MFA, nem captcha, nem uma única sobrancelha levantada.

Ataque: Roube agora, pergunte depois

Com um arquivo HAR em mãos, o invasor não precisou de ferramentas exóticas, força bruta ou ataques avançados. O ataque foi puro copy-paste estratégico, com um toque de “por que não?”. A receita do desastre, versão fast-food ofensivo:

1. Abra o HAR como quem abre uma caixa de bombons: tokens por todo lado.
2. Extraia o token de sessão (sid); aquele cookie que diz “sou eu mesmo, pode confiar”.
3. Injete esse token diretamente no navegador ou em ferramentas como o Burp Suite, cURL, ou até mesmo num script Python meia-boca.
4. Voilà: acesso direto ao painel administrativo do cliente, sem precisar digitar uma única senha ou passar por qualquer autenticação multifator.

E o mais incrível? Isso funciona com um nível de esforço próximo a zero. Abaixo, o exemplo de um script real para demonstrar como é fácil invadir… a sua própria conta, claro. 👀

# Como invadir sua própria conta com um HAR (para fins educativos, claro)

import json, requests

# Carregamos o arquivo HAR exportado do navegador — cheio de requisições HTTP
har = json.load(open('har_de_teste.har'))

# Procuramos entre todos os cookies enviados pelas requisições
# até encontrar aquele com nome 'sid', que representa a sessão ativa
token = next(
    c['value'] for e in har['log']['entries']
    for c in e['request']['cookies']
    if c['name'] == 'sid'
)

# Criamos uma nova sessão do Python usando a biblioteca requests
s = requests.Session()

# Injetamos o cookie de sessão na nova sessão — fingindo ser o usuário original
s.cookies.set('sid', token, domain='corp.exemplo.com')

# Fazemos uma requisição ao painel administrativo da empresa
resp = s.get('https://corp.exemplo.com/admin')

# Se o token for válido, teremos acesso total — status 200 = sucesso
print(f"Status: {resp.status_code}")

Isso não é um ataque “sofisticado”. É um ataque “escancaradamente funcional”. E como os tokens estavam ativos e válidos, o servidor os aceitou com um sorriso no rosto. Moral da história: com um HAR bem alimentado, o atacante não precisa pedir permissão, ele simplesmente entra e toma posse.

Impacto: Menos de 1%, Mas Com Gosto de 100%

Quando a fumaça baixou e os logs pararam de gritar, a Okta contabilizou:

• 134 empresas afetadas
• 5 delas com sessões administrativas sequestradas
• Dados pessoais vazados: nome, email, cargo, o pacote básico de “só o suficiente para causar problemas reais”.

E tudo isso, por causa de um… bendito arquivo HAR A resposta da Okta? Um classico corporativo:

“Apenas 1% dos nossos clientes foram afetados.”

Tradução: “mas eram o 1% que importa”

Empresas como Cloudflare e BeyondTrust estavam na lista. E quando a camada mais crítica da infraestrutura digital global é comprometida, a porcentagem vira irrelevante. É como dizer que só caiu um andar do prédio, mas era a fundação. A cereja no topo? Os arquivos HAR foram enviados por solicitação do próprio suporte técnico da Okta. Ou seja: a cadeia de confiança que deveria proteger virou a principal fonte de exposição.

Medidas Corretivas: O Balde Depois da Inundação Assim que a merda bateu no ventilador, a Okta correu para apagar o incêndio com o extintor padrão: revogar, desativar, banir e prometer que “dessa vez aprendemos”. Medidas adotadas:

• Revogação imediata de todos os tokens encontrados nos HARs comprometidos, um "deslogar geral" movido pelo pânico.
• Desativação da conta de serviço que serviu de passarela VIP para o atacante, agora provavelmente repousando no Active Directory dos esquecidos.
• Proibição de login corporativo em perfis pessoais do Chrome, só faltou uma cartilha de "como usar o navegador em 2025"

Depois da tempestade, veio a promessa de céu limpo com um pacote de medidas de segurança:

• IP Binding: associar sessões a IPs específicos, como quem coloca tornozeleira eletrônica em cada requisição.
• Zero Standing Privileges: privilégios temporários concedidos sob demanda. Nada de acesso perpétuo por “conveniência”.
• MFA com step-up para ações sensíveis: autenticação adicional para operações críticas. Agora, deletar um usuário exige mais que um clique sonâmbulo.

Em resumo: boas medidas, mas com aquele sabor agridoce de correção que só chega depois da manchete negativa.

Lições de Segurança: Manual de Como Não Ser o Próximo

Vulnerabilidades exploradas

• A2 Quebra de autenticação e gerenciamento de sessão O sistema aceitava tokens como se fossem contratos assinados em cartório. O HAR trouxe esses tokens de bandeja.
• A3 / A9 Exposição de dados sensíveis Tokens, cookies, cabeçalhos, informações de identificação, tudo ali, embalado num HAR como brinde de luxo pro atacante.
• Falta de uma política real de Zero Trust Sessões validadas eram tratadas como “usuário autenticado” sem mais questionamentos. Confiava-se no token como se ele fosse inviolável. Não era.
• Sessões longas sem binding com IP ou user-agent O atacante poderia estar usando o token de um servidor da Somália com um navegador esotérico, e ninguém levantaria a sobrancelha.

Boas práticas negligenciadas

• Sanitização de HARs antes do envio Ferramentas como o HAR Sanitizer da Cloudflare existem. São públicas. Gratuitas. E ignoradas. O que foi enviado ao suporte técnico foi praticamente um “manual de acesso root” com o título “Ajuda aqui por favor”.
• Monitoramento efetivo de contas de serviço Contas de serviço com privilégios administrativos devem ser monitoradas como se fossem celebridades no aeroporto. Atividade suspeita? Alerta. Login incomum? Investigação. Aqui, passaram batido.
• Proibição de uso de credenciais corporativas em ambientes pessoais É difícil defender qualquer prática onde uma conta corporativa é usada em um Chrome logado na conta pessoal do Gmail. Isso deveria ser regra básica. Como “não mexa em produção sexta à noite”.

Conclusão: Nem Sempre É Preciso Explodir a Porta, Às Vezes Ela Está Aberta O caso Okta não foi um ataque cinematográfico com códigos piscando e hackers de capuz digitando furiosamente em um porão escuro. Foi um crime de oportunidade. Discreto. Limpo. Corporativo. A falha foi humana. Salvar senhas em navegadores pessoais, enviar arquivos HAR crus, e tratar tokens como se fossem cookies de chocolate tudo isso é script básico de um incidente de segurança. O estrago foi técnico. Sessões administrativas sequestradas, dados sensíveis vazando, e uma cadeia de confiança rompida por dentro. E o aprendizado? Vai depender de quem ficou acordado durante a reunião de segunda-feira, ou quem vai fingir que “estava no mute” enquanto o incidente era discutido. Esse caso é a lembrança brutal de que:

“Um token de sessão ativo é tão valioso quanto a senha… às vezes até mais...”

E que, sinceramente, mandar logs crus para o suporte técnico é a versão digital de deixar a porta da frente aberta com um bilhete escrito “volto logo”. Zero-day? Phishing avançado? Exploração de RCE? Não. Só alguém pedindo ajuda com um botão quebrado… e entregando junto o crachá, a chave da sala do servidor, e o cartão do refeitório.

REFERENCIAS: Okta — Unauthorized Access to Support Case Management System (Root Cause & Remediação) https://sec.okta.com/articles/2023/11/unauthorized-access-oktas-support-case-management-system-root-cause

Okta — October 2023 Security Incident: Update e Ações Recomendadas https://sec.okta.com/articles/october-security-incident-recommended-actions

Okta — Encerramento da Investigação (HAR Files) https://sec.okta.com/articles/harfiles

The Hacker News — Violação de Dados na Okta Afetou 134 Clientes https://thehackernews.com/2023/11/oktas-recent-customer-support-data.html

Cloudflare — Introducing HAR Sanitizer: Secure HAR Sharing https://blog.cloudflare.com/introducing-har-sanitizer-secure-har-sharing/

Rezonate — Como Atacantes Usaram Arquivos HAR contra Clientes da Okta https://www.rezonate.io/blog/har-files-attack-okta-customers/

Krebs on Security — Hackers Stole Access Tokens from Okta’s Support Unit https://krebsonsecurity.com/2023/10/hackers-stole-access-tokens-from-oktas-support-unit/

Nightfall AI — Okta Data Breach: What Happened, Impact, and Security Lessons Learned https://www.nightfall.ai/blog/okta-data-breach-what-happened-impact-and-security-lessons-learned