Tokens, OAuth e Sessões

Nota 04 do capítulo 26, que aprofunda o plano de controle das notas anteriores: a arquitetura de tokens e OAuth que as identidades usam todos os dias.
O foco é como os mecanismos funcionam, como são abusados e como caçar padrões anômalos de token e de consentimento.
Dialoga com as notas 02 e 03 deste capítulo, com a nota 15 do capítulo 08 (phishing AiTM) e com o capítulo 03 (TTPs).

1. Contexto e Posicionamento na Biblioteca

A sessão moderna não é uma senha repetida a cada acesso, mas um conjunto de tokens com ciclos de vida próprios: o access token que autoriza cada chamada, o refresh token que renova o acesso em silêncio, o cookie de sessão que segura a continuidade no navegador e as permissões OAuth que definem o que cada aplicativo pode fazer. O atacante moderno não quebra criptografia, rouba artefatos válidos e os usa dentro do prazo, e por isso a caça precisa entender a arquitetura para reconhecer o abuso. Esta nota fecha o capítulo 26 cobrindo a arquitetura, os fluxos OAuth, os abusos conhecidos, os padrões de caça e os controles de proteção.

A nota pressupõe o hunting de identidade da nota 02 e o ambiente híbrido da nota 03, e se conecta ao phishing AiTM da nota 15 do capítulo 08, que é o vetor de captura mais comum de tokens. O exemplo final executa uma caça de consent abuse ponta a ponta, do sinal na auditoria à resposta e ao produto de inteligência.

2. Arquitetura de Tokens e Sessões

O modelo de identidade moderna emite artefatos com papéis distintos, e o confundimento entre eles é a primeira barreira do analista. O access token é a credencial de curta duração apresentada a cada chamada de API; o refresh token é a credencial de longa duração que obtém novos access tokens sem reautenticação; o ID token carrega a afirmação de identidade para a aplicação; e o cookie de sessão mantém o navegador do usuário contínuo num portal. A tabela abaixo organiza os artefatos com o portador, a duração típica e o risco dominante de cada um.

O formato JWT merece leitura técnica mínima: três segmentos codificados, cabeçalho com o algoritmo, payload com as declarações, incluindo identidade, emissor, audiência e validade, e assinatura que o receptor valida. O payload é legível por qualquer um, e o analista pode decodificar um token capturado em laboratório para confirmar escopos e validade, o que orienta a janela de resposta: o access token expira rápido, mas o refresh token sobrevive e é ele que precisa ser revogado.

O ciclo de vida operacional importa tanto quanto a taxonomia: tokens são emitidos, renovados e revogados individualmente ou por cadeia, e o mecanismo de detecção de reuso do provedor destrói a família de refresh tokens quando um token já rotacionado reaparece. Esse mecanismo é, na prática, um sensor de roubo instalado no provedor: o reuso detectado indica que o atacante carregava um artefato antigo, e o evento correspondente entra na caça como confirmação de captura, mesmo sem qualquer anomalia geográfica adicional. A leitura desses eventos de invalidação é fonte de caça subaproveitada na maioria dos programas. A sessão resultante é o que o atacante deseja, e é o objeto central das caçadas das seções seguintes.

3. OAuth 2.0: Fluxos, Scopes e Consentimento

O OAuth 2.0 é o protocolo de autorização que governa como uma aplicação ganha acesso em nome de um usuário, e o consentimento é o momento em que o usuário, ou o administrador, aprova os escopos solicitados. O modelo é sadio quando o escopo é mínimo e o consentimento é informado, e é exatamente essa premissa que o abuso ataca: a tela de consentimento aprova escopos que o usuário não sabe ler, em nome de um aplicativo que não sabe que instalou. A tabela abaixo resume os fluxos com o uso legítimo e o risco principal de cada um.

A leitura tática da tabela concentra-se em dois pontos. O primeiro é o device code, que virou vetor de campanha real: o atacante gera um pedido de device code, convence a vítima, por telefone ou mensagem, a abrir a página legítima e digitar o código, e a aprovação concede a sessão do atacante, técnica documentada em grupos como o Storm-2372. O segundo é o consentimento administrativo: quando um aplicativo pede escopos altos e um administrador aprova, o acesso persiste por meses sem qualquer usuário visível, e por isso o evento de consentimento é um dos sinais de caça mais valiosos de todo o plano de identidade.

Escopos e papéis não são sinônimos, e a distinção importa na caça: o escopo OAuth define o que a aplicação pode fazer com os recursos do usuário, enquanto o papel administrativo define o que a identidade pode fazer na plataforma. Um aplicativo com escopo Mail.ReadWrite não administra nada, mas lê e escreve todas as mensagens do usuário, e é essa diferença que orienta a gravidade do consentimento abusivo. A revisão de permissões cobre os dois planos, porque o atacante busca o plano de menor fricção disponível naquele momento.

4. Abusos Conhecidos

O catálogo de abuso de tokens e sessões é estável e bem documentado nos relatórios de ameaças, e a tabela abaixo organiza os cinco padrões que concentram a maioria dos incidentes modernos, com a mecânica e as referências de atores publicamente registradas.

A mecânica do AiTM merece o detalhe que conecta com a nota 15 do capítulo 08: o MFA acontece de verdade, o segundo fator é concluído pela vítima no portal real, e o proxy guarda o resultado, por isso a defesa por MFA tradicional falha e a resposta precisa revogar sessão, não apenas senha. O replay é o sinal de caça mais limpo do catálogo, porque o token capturado é usado onde o original nunca estaria, e o próprio provedor sinaliza a detecção de reuso quando o refresh token invalidado reaparece, evento que indica família de tokens roubada e destruída pelo mecanismo de revogação em cadeia.

5. Hunting por Padrões de Token

A caça por padrão de token usa os campos de sessão e de identificador dos logs de sign-in, em especial o UniqueTokenIdentifier e o SessionId, e compara o uso observado com o baseline de dispositivo, geografia e aplicação. O padrão mais produtivo é o uso impossível: o mesmo token ou a mesma sessão empregados em dois contextos geográficos dentro da janela de validade, que é fisicamente implausível mesmo com viagem real.

// Uso impossível: mesmo identificador de token em ASNs distintos em 24 horas
union SigninLogs, AADNonInteractiveUserSignInLogs
| where ResultType == 0
| summarize paises = dcount(Country), asns = dcount(ASN), usos = count(),
            primeiro = min(TimeGenerated), ultimo = max(TimeGenerated)
    by UserPrincipalName, UniqueTokenIdentifier
| where asns >= 2 and datetime_diff('minute', ultimo, primeiro) < 1440
| order by asns desc

// Refresh anômalo: renovação fora do padrão de aplicação e de horário da organização
AADNonInteractiveUserSignInLogs
| where ResultType == 0 and SignInEventTypes has "RefreshToken"
| where AppDisplayName !in ("Microsoft Authentication Broker", "Windows Sign In")
| summarize renovacoes = count(), apps = dcount(AppDisplayName),
            paises = dcount(Country) by UserPrincipalName, bin(TimeGenerated, 1h)
| where paises >= 2 or renovacoes > 15
| order by renovacoes desc

O device code phishing tem assinatura própria nos logs: o evento de autenticação aparece com o protocolo de fluxo de dispositivo e, com frequência, com uma combinação de rede do navegador da vítima e de local do ataque que não se repete no histórico do usuário. A consulta abaixo isola o fluxo na telemetria, e cada resultado merece revisão junto à linha do tempo de contato da vítima, porque a aprovação costuma ser precedida de telefonema ou de mensagem com o código.

// Fluxo de device code: autenticações com protocolo de dispositivo
SigninLogs
| where AuthenticationProtocol == "deviceCode"
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress,
          Country, UserAgent
| order by TimeGenerated desc

O enriquecimento determina o veredito: o ASN de saída pertence a provedor de hosting ou de VPN residencial, o dispositivo associado existe no inventário e o aplicativo envolvido tem justificativa de negócio. Sem esse enriquecimento, o padrão de token afoga em falso positivo de cache e de balanceamento, e com ele o sinal vira detecção de altíssima precisão, candidata natural à ponte caça para deteção do capítulo 18.

6. Controles: Proteção de Token, CAE e Governança de Consentimento

Os controles modernos atacam a mecânica do roubo em três frentes. A proteção de token vincula o artefato ao dispositivo, tornando inútil o token roubado em outra máquina, e é o antídoto direto ao replay. A avaliação contínua de acesso, o CAE, reavalia a sessão em tempo quase real contra eventos críticos, como desabilitação de conta e mudança de risco, reduzindo a janela de uso de um token comprometido de horas para minutos. O MFA de phishing resistente, com FIDO2 ou equivalente baseado em dispositivo, elimina a captura do segundo fator que sustenta o AiTM.

A governança de consentimento completa o conjunto no plano OAuth. O fluxo administrativo exige que escopos altos sejam aprovados por administrador e não pelo usuário final, o inventário de aplicativos com revisão periódica de permissões corta o acúmulo de escopos injustificados, e a política de bloqueio de editores não verificados reduz a superfície de consent phishing. A revogação fecha o ciclo de resposta: revogar sessões e refresh tokens, remover concessões do aplicativo abusado e rotacionar segredos, na ordem, porque revogar apenas a senha deixa o token vivo.

A governança de sessão completa o conjunto com decisões que a plataforma expõe e os programas raramente usam: frequência de reautenticação ajustada ao risco da aplicação, revogação de sessões como primeiro passo de qualquer resposta e inventário de sessões ativas em contas privilegiadas. O inventário de sessões vivas é o espelho do inventário de aplicativos, e os dois alimentam a mesma revisão trimestral. A métrica que governa o conjunto é simples: quanto tempo um artefato roubado continuaria válido depois do alerta.

7. Exemplo de Caça: Consent Abuse

A hipótese do caso: aplicativos OAuth com escopos de leitura e escrita de caixa postal são aprovados por administrador fora do processo formal de homologação, e o evento de consentimento está na auditoria do Entra ID com todos os campos necessários para a caça. A consulta abaixo lista os consentimentos de escopos altos com o administrador que aprovou e a aplicação beneficiada.

AuditLogs
| where OperationName in ("Consent to application", "Add delegated permission grant")
| extend Admin = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| extend App = tostring(TargetResources[0].displayName)
| extend Escopos = tostring(TargetResources[0].modifiedProperties)
| where Escopos has_any ("Mail.ReadWrite", "Mail.Send", "Files.ReadWrite.All",
                         "User.ReadWrite.All", "RoleManagement.ReadWrite.Directory")
| project TimeGenerated, Admin, App, Escopos
| order by TimeGenerated desc

A saída fictícia do exercício trouxe o caso típico: às 21h47 de uma sexta-feira, o aplicativo "RelatorioFinanceiro-Br" recebeu os escopos Mail.ReadWrite e Mail.Send de um administrador cuja própria sessão, conferida nos logs de sign-in, havia sido estabelecida 40 minutos antes de um ASN de hosting em outro país, com MFA concluído por push aprovado na décima primeira tentativa, o MFA fatigue da nota 02. A sequência fechou a cadeia: roubo de sessão, uso da sessão para consentir aplicativo, persistência via concessão OAuth.

A resposta seguiu a ordem da seção 6: revogação das sessões e dos refresh tokens do administrador, remoção das concessões do aplicativo, bloqueio do aplicativo e revisão das mensagens acessadas no período, com o log de auditoria da caixa confirmando exportação de anexos em dois dias de janela. O produto da caça foi triplo: a detecção permanente de consentimento com escopos altos por sessão de risco, a revisão dos aplicativos já aprovados por aquele administrador e a atualização do perfil de ameaça no TIP com a cadeia AiTM para consentimento, que agora entra como hipótese prioritária no ciclo da nota 02.

O protocolo de resposta a consent abusivo abaixo cobre as etapas que encerram a persistência, e a ordem importa porque o aplicativo continua operando até que a concessão seja removida.

1. Bloquear o aplicativo na plataforma, impedindo novas emissões de token.
2. Remover as concessões e permissões concedidas ao aplicativo.
3. Revogar sessões e refresh tokens do administrador que aprovou.
4. Revalidar os fatores de segurança do administrador e revisar os consentimentos dele.
5. Revisar o acesso do aplicativo ao conteúdo no período de concessão.
6. Registrar a cadeia no TIP e atualizar a deteção permanente.

8. Erros Comuns e Pontos de Atenção

O erro mais comum é tratar token como detalhe técnico do login e ignorar o ciclo de vida, revogando senha enquanto o refresh token continua renovando acesso ao atacante. O erro mais grave é confundir consentimento com instalação inofensiva, deixando aplicativos com escopos altos ativos por meses sem revisão. Ambos se corrigem com a mesma mudança de moldura: o artefato de sessão é a credencial real, e o consentimento é uma concessão de acesso administrada.

Completam a lista os itens abaixo.

• Revogar apenas a senha no resposta a AiTM, deixando cookie e refresh token operáveis para o atacante.
• Ignorar o dispositivo no enriquecimento, transformando o padrão de token em fábrica de falsos positivos de cache.
• Tratar o device code como fluxo exótico sem risco, quando é vetor de campanha ativa com engenharia social por telefone.
• Não inventariar aplicativos com escopos altos, permitindo que concessões antigas sobrevivam a equipes inteiras.
• Caçar apenas contas humanas, ficando cego para segredos de aplicativo vazados que operam sem usuário.

• Deixar o CAE desativado por receio de impacto, mantendo a janela de uso do token roubado em horas.

• Conferir apenas o access token na resposta, ignorando a família de refresh tokens que renova o acesso do atacante.

• Aprovar consentimentos de emergência sem registro, criando concessões sem dono que nenhuma revisão encontra.

9. Integração com o Restante da Biblioteca

A nota fecha o circuito de identidade do capítulo 26: a nota 02 fornece os sinais e a rotina de caça, a nota 03 cobre as pontes híbridas e esta nota detalha os artefatos que circulam nas pontes, com os controles de proteção que reduzem a superfície. A nota 15 do capítulo 08 conecta com o vetor de captura, e o capítulo 18 recebe as detecções derivadas dos padrões de token e de consentimento. Na frente de inteligência, as cadeias de abuso documentadas aqui alimentam o documento de campanha da nota 09 do capítulo 25 e os PIRs cloud da nota 01, e o framework CTH ancora o conjunto nos controles de preparação de caça e de resposta. A síntese do capítulo é a que abre a próxima etapa de estudo: em ambientes modernos, o perímetro é a sessão, e defendê-lo exige entender o que a sessão carrega.