Active Directory e Microsoft Entra ID

Nota 03 do capítulo 26, que mapeia o ambiente híbrido de identidade: a superfície do AD on-premises, a do Entra ID e as pontes entre os dois planos.
O foco são as TTPs de cada lado, os ataques que atravessam sincronização e federação e a correlação de caça híbrida.
Dialoga com a nota 09 do capítulo 08 (hunting em AD), com as notas 02 e 04 deste capítulo e com o capítulo 03 (TTPs).

1. Contexto e Posicionamento na Biblioteca

A grande maioria das grandes organizações opera identidade em modo híbrido: o Active Directory on-premises que nasceu com a empresa, o Microsoft Entra ID que nasceu com o cloud e a ponte de sincronização que os costura. O atacante trata esse conjunto como um único sistema de identidade com duas superfícies e duas ou três pontes, e a defesa que olha apenas um lado permanece cega para metade das técnicas. Esta nota mapeia as superfícies, as TTPs de cada lado e as pontes que as conectam, fechando com a correlação de caça híbrida e um exemplo de anomalia de sincronização.

A nota pressupõe o hunting de identidade da nota 02 deste capítulo e o catálogo de TTPs do capítulo 03, e usa a telemetria de eventos do Windows introduzida na nota 09 do capítulo 08. O objetivo é construir a visão integrada que permite ao hunter seguir uma cadeia de ataque que começa no Kerberos do AD e termina em um aplicativo OAuth no Entra ID, ou o inverso, começar no cloud e descer ao on-premises.

2. O Ambiente Híbrido e suas Superfícies

O ambiente híbrido tem três componentes estruturais e três modos de sincronização que definem a superfície de ataque. O AD DS mantém o plano de autenticação Kerberos e NTLM no domínio; o Entra ID mantém o plano de autenticação moderno para o cloud; e o Entra Connect sincroniza objetos e atributos entre os dois, com uma conta de serviço dedicada que escreve no diretório cloud. A tabela abaixo resume os componentes e os modos com o risco característico de cada um.

A leitura estratégica da tabela é que cada modo de autenticação desloca o ativo crítico de lugar: no PHS o segredo está na sincronização, no PTA está no agente, na federação está no certificado de assinatura do ADFS. O hunting híbrido precisa, por isso, cobrir as três residências de segredo, e a nota 04 deste capítulo complementa o quadro com o plano de tokens e sessões que circula depois da autenticação.

A segmentação em camadas de privilégio, o modelo de tiers, organiza a superfície e orienta a prioridade da caça: contas de Tier 0, com controle direto ou indireto sobre o domínio e sobre o híbrido, recebem telemetria reforçada e restrições de logon, e a conta de sincronização pertence a essa camada por definição. O hunter usa a mesma segmentação para calibrar limiares, porque um evento raro em conta de Tier 0 exige investigação imediata enquanto o mesmo evento em conta padrão apenas agrega à fila de triagem. O inventário de tiers é, portanto, pré-requisito do hunting híbrido, e a sua ausência aparece na primeira onda de falsos positivos.

3. TTPs no Lado On-Premises

O catálogo on-premises é dominado pelo ecossistema Kerberos e pelo modelo de delegação do AD, e a telemetria de eventos do Windows é madura e bem documentada. A tabela abaixo organiza as técnicas de maior prevalência com o mapeamento ATT&CK e o evento principal de caça.

A característica que define a caça on-premises é a densidade de correlação possível: o mesmo servidor Windows emite os eventos de autenticação, de acesso a objeto e de serviço, e o hunter constrói cadeias curtas, como rajada de 4769 seguida de 4662 de replicação, que quase não geram falso positivo.

A leitura da tabela também orienta a coleta: sem os eventos 4769, 4662 e 7045 encaminhados, metade das técnicas do catálogo fica invisível, e a lacuna de coleta precisa aparecer no inventário de dados do framework CTH. O lado on-premises é onde o atacante obtém os privilégios que atravessam a ponte, e por isso a caça aqui tem valor antecipatório sobre o cloud: a kerberoasting de hoje é a mudança de permissão cloud da semana que vem. A prioridade de coleta segue essa lógica de cadeia, e não a conveniência de cada fonte. O lado on-premises também concentra o risco estrutural de privilégio: o membro do grupo de administradores de domínio que loga em estação de usuário abre a cadeia completa de roubo de credencial que termina na ponte de sincronização.

4. TTPs no Lado Entra ID

O catálogo cloud é dominado por abuso de identidade moderna, e a telemetria muda de natureza: em vez de eventos de sistema, o hunter consome logs de sign-in e de auditoria do provedor. A tabela abaixo organiza as técnicas de maior prevalência com o comportamento observado e a telemetria correspondente.

O contraste com o lado on-premises orienta a arquitetura de caça: no Entra ID a raridade absoluta vale menos e a correlação com identidade vale mais, porque a plataforma já filtra a maior parte do ruído de rede. O registro administrativo, quem consentiu, quem registrou, quem resetou, é o campo mais produtivo, e a cadeia típica moderna é a combinação: vishing para reset de MFA, login novo, registro de dispositivo e consentimento de aplicativo, tudo em horas.

5. As Pontes: Sincronização e Federação

As pontes são onde o híbrido se torna único sistema para o atacante, e três mecanismos concentram o risco. A primeira ponte é a conta de sincronização do Entra Connect, que tem permissão de escrita no diretório cloud e, se o servidor de sync for comprometido, transforma mudanças no AD em mudanças administrativas no Entra ID, inclusive por group write-back. A segunda é o Golden SAML, em que o atacante que extrai o certificado de assinatura do ADFS forja asserções para qualquer usuário, inclusive administradores globais, sem tocar em senha e sem MFA, técnica documentada em casos como o APT29 e a intrusão via SolarWinds. A terceira é o agente PTA, que recebe a senha em texto claro no fluxo de validação e, comprometido, captura credenciais em escala.

A consequência analítica é a direção do fluxo: a ponte carrega ataque nos dois sentidos, e o hunter precisa avaliar cada achado perguntando de qual lado a iniciativa nasceu. Um grupo sincronizado com membro novo é inofensivo se o dono do grupo aprovou, e crítico se a mudança nasceu de uma estação comprometida com acesso de escrita no AD.

A proteção operacional das pontes tem checklist estabelecido: o servidor de sync e o host do agente PTA pertencem ao Tier 0 e não recebem logon interativo de administradores comuns, o certificado de assinatura do ADFS é mantido em módulo de segurança com acesso restrito, e a rotação do KRBTGT segue o calendário de resposta a incidentes. O hunting desses ativos acompanha a mesma disciplina: qualquer logon, serviço ou script novo nesses hosts entra na fila de análise, porque a rotina normal deles é conhecida e pequena. A exceção investigada é sempre mais barata do que a exceção assumida.

6. Hunting Híbrido com Correlação

A caça híbrida exige telemetria dos dois lados na mesma plataforma de análise, com o relógio sincronizado e o identificador de usuário normalizado entre o sAMAccountName e o UPN. O padrão de correlação mais produtivo é a sequência entre lados: eventos on-premises que precedem mudanças cloud, e mudanças cloud que autorizam acessos on-premises. A tabela abaixo apresenta os pares de sinal de maior valor.

A consulta abaixo exemplifica o padrão de sequência entre lados, unindo o reset de senha no AD ao registro de fatores de segurança no Entra ID dentro de 24 horas, janela típica de preparação de acesso pelo atacante.

let resets = SecurityEvent
  | where EventID == 4724
  | project T0 = TimeGenerated, Alvo = TargetUserName;
AuditLogs
| where OperationName == "Register security information"
| extend Alvo = tostring(TargetResources[0].userPrincipalName)
| join kind=inner resets on Alvo
| where TimeGenerated > T0 and TimeGenerated < T0 + 24h
| project Alvo, ResetAD = T0, RegistroMFA = TimeGenerated
| order by Alvo asc, RegistroMFA asc

As ferramentas de suporte também ajudam: soluções de detecção dedicadas a AD enriquecem a telemetria com a resolução dos protocolos Kerberos e LDAP, e o encaminhamento dos eventos on-premises para a mesma plataforma de análise cloud é o pré-requisito prático das consultas desta seção. O custo de manter a telemetria unificada é menor do que o custo de investigar um híbrido com metade da história em cada repositório. A nota 01 do capítulo 12 trata exatamente do risco de dado ausente ou tardio no inventário de caça.

7. Exemplo de Caça: Anomalia de Sincronização

A hipótese do caso: a conta de sincronização escreve no cloud o que o AD manda escrever, e o atacante que controla o servidor de sync a usa para mudanças que o fluxo normal nunca faria, como alterações em contas privilegiadas fora da janela de manutenção. A caça parte da auditoria do Entra ID filtrando as operações iniciadas pela conta de sincronização e compara com a linha de base de horários e de alvos.

AuditLogs
| where OperationName has_any ("Update user", "Add member to group")
| extend Iniciador = tostring(parse_json(tostring(InitiatedBy.app)).displayName)
| where Iniciador has "Directory Synchronization"
| extend Alvo = tostring(TargetResources[0].userPrincipalName)
| extend Atributo = tostring(TargetResources[0].modifiedProperties[0].displayName)
| summarize mudancas = count(), alvos = make_set(Alvo), atributos = make_set(Atributo)
    by bin(TimeGenerated, 1h)
| where hourofday(TimeGenerated) !between (2 .. 5)
| order by mudancas desc

A saída fictícia do exercício trouxe um cluster suspeito: três atualizações de usuário às 09h40 de uma terça-feira, com o atributo de endereços de proxy alternativos alterados em duas contas de diretoria, padrão compatível com a preparação de redirecionamento de mensagem. A verificação no lado on-premises confirmou que a mesma mudança nasceu de uma estação de usuário com evento 4662 de escrita no atributo, e não do servidor de sync em sua rotina. A resposta removeu os endereços injetados, isolou a estação de origem, rotacionou as credenciais da conta de sincronização e gerou duas entregas: a deteção permanente do padrão de proxyAddress alterado por sync fora da janela, e a atualização do perfil de ameaça no TIP com a técnica observada, alimentando o PIR sobre proteção da infraestrutura de sincronização.

O ponto analítico que o caso fixa é a direção da investigação: a anomalia apareceu no cloud, mas a origem estava no on-premises, e a linha do tempo só fechou com os eventos da estação de origem. Essa travessia entre planos é o padrão do ambiente híbrido e exige que o hunter tenha acesso simultâneo às duas telemetrias, com o relógio sincronizado e a identidade normalizada. O caso entrou para a base de caças da equipe como hipótese reutilizável, e a consulta da seção 6 virou execução mensal no cronograma.

8. Erros Comuns e Pontos de Atenção

O erro estrutural é operar duas caçadas paralelas, uma para o AD e outra para o Entra ID, sem a plataforma comum que permite a correlação entre lados, perdendo exatamente as cadeias que atravessam a ponte. O erro técnico frequente é não normalizar a identidade entre sAMAccountName e UPN, quebrando os joins e gerando achados que parecem falsos por artefato de dado. Ambos se corrigem com a mesma decisão de arquitetura de dados, telemetria híbrida unificada e identidade normalizada.

Completam a lista os itens abaixo.

• Tratar a conta de sincronização como infraestrutura invisível, sem monitorar o que ela escreve e quando escreve.
• Ignorar o modo de autenticação do híbrido e caçar Golden SAML num ambiente que opera com PHS, onde a ponte é outra.
• Deixar o KRBTGT sem rotação após incidente com DCSync, permitindo o Golden Ticket indefinidamente.
• Não auditar os grupos sincronizados por write-back, porta de entrada de privilégio cloud a partir do AD.
• Excluir contas de serviço da caça de identidade, ficando cego para as identidades mais usadas nas pontes.

• Correlacionar sem sincronizar relógios entre fontes, produzindo sequências falsas que contaminam a linha do tempo.

• Deixar o servidor de sincronização fora do perímetro de caça por ser infraestrutura "estável".

• Assumir que PTA e PHS exigem as mesmas deteções, ignorando que os segredos vivem em lugares diferentes.

9. Integração com o Restante da Biblioteca

A nota estende a caça de identidade da nota 02 e antecipa a mecânica de tokens da nota 04, e recebe do capítulo 03 o enquadramento das TTPs e do capítulo 08, nota 09, a base de telemetria de eventos do Windows usada na correlação. As deteções híbridas alimentam o capítulo 18, e a proteção da infraestrutura de sincronização conecta com os controles do framework CTH dedicados a identidade e a preparação de caça. Na frente de inteligência, os achados híbridos são material de primeira ordem para o documento de campanha, porque revelam o domínio operacional do adversário sobre o ambiente como um todo, e o perfil de ameaça atualizado no TIP fecha o loop que o capítulo 26 se propõe a manter em movimento.