Logs de atividades do Azure AD Graph: ingestão e detecção de ameaças para reduzir a lacuna de visibilidade.

Os registros de atividades do AAD Graph agora podem ser integrados ao Elastic e usados para detecção de ameaças na solução SIEM/XDR. Essa frase não deveria ser empolgante, mas é. Durante a maior parte da última década, essa parcela de telemetria simplesmente não existia como um fluxo de registros acessível ao cliente. Os Registros de Atividades do Microsoft Graph (a interface moderna do graph.microsoft.com ) foram lançados oficialmente em abril de 2024. A superfície legada do graph.windows.net, a única que as ferramentas adversárias de fato atingem, permaneceu oculta até o início de 2026.

Esta postagem percorre o ciclo de ponta a ponta. Por que a visibilidade é importante, como ingerir os logs no Elasticsearch, como gerar um reconhecimento realista manualmente e com o ROADrecon, e como analisar o resultado no ES|QL. Tudo abaixo foi validado em um ambiente de locação real.

Principais conclusões

• Os logs de atividade do AAD Graph chegam ao Elastic por meio da integração com o Azure e são armazenados em logs-azure.aadgraphactivitylogs-* com extração completa do ECS.

• A ROADtools, a AADInternals e outras empresas parceiras têm operado com uma lacuna de visibilidade há anos. Os defensores não estavam conseguindo capturar as jogadas.

• O AAD Graph está "descontinuado", mas ainda pode ser consultado na maioria dos locatários. A versão 1.61 da API interna ainda retorna dados que o Microsoft Graph não retorna.

• Os campos ECS são do tipo terra (event.action, event.outcome, http.request.method, source.ip, user.id, user_agent.original). Os extras do conjunto de dados permanecem consultáveis em azure.aadgraphactivitylogs.properties.*.

• Cinco mecanismos de busca detectam a atividade de forma confiável: agentes de usuário de ferramentas, abrangência de endpoints, uso indevido da API *-internal , incompatibilidades de ID de cliente FOCI e picos de 4xx.

Uma breve história da visibilidade dos defensores

Os defensores passaram anos trabalhando em logins, acesso condicional, atribuição de funções e concessão de consentimento OAuth. Há muito pouco conteúdo que aborde as APIs de diretório subjacentes que as ferramentas adversárias realmente acessam. A razão é estrutural: não existiam registros acessíveis ao cliente para essas APIs. Os Registros de Atividades do Microsoft Graph foram lançados primeiro (prévia em outubro de 2023, lançamento oficial em abril de 2024). O AzureADGraphActivityLogs finalmente apareceu no início de 2026.

Durante a maior parte da última década, a enumeração do AAD Graph permaneceu invisível para os SOCs, não porque a telemetria estivesse oculta, mas sim porque ela simplesmente não existia. ROADtools, AADInternals, MSOLSPray, Microburst. Nenhuma delas produziu dados que pudessem ser capturados por terceiros, mesmo com uma configuração de registro perfeita.

Isso muda no dia em que os logs do AzureADGraphActivityLogs começarem a ser registrados no seu índice de logs da plataforma.

O AAD Graph está "descontinuado", mas ainda está bastante ativo.

Uma breve recapitulação. O Azure AD Graph é a API REST legada para objetos de diretório Entra ID, hospedada em https://graph.windows.net/{tenantId}/{objecttype} com versões de API como 1.5, 1.6 e 1.61-internal. A Microsoft vem recomendando a migração de todos para o Microsoft Graph desde 2019, e a data de descontinuação já foi adiada diversas vezes.

A obsolescência não desapareceu. Em 2026, o AAD Graph ainda poderá responder a solicitações em ambientes onde os caminhos de acesso legados permanecem disponíveis ou onde os aplicativos não foram explicitamente bloqueados de usá-lo. Algumas razões pelas quais continua sendo um alvo de ataques:

• As ferramentas de ataque não foram adaptadas. ROADrecon ainda o usa para gather. O AADInternals possui dezenas de cmdlets que o encapsulam.

• As versões da API *-internal retornam mais dados. 1.61-internal expõe strongAuthenticationDetail embutido no objeto do usuário durante uma caminhada normal pelo diretório. O equivalente do Microsoft Graph reside atrás de um endpoint /authentication/methods separado, protegido por UserAuthenticationMethod.Read.All. Essa assimetria é exatamente o que as ferramentas de enumeração em massa exploram.

• O bloco não é uma simples alternância. O controle blockAzureADGraphAccess reside por aplicativo em application.authenticationBehaviors, portanto, bloquear em todo o locatário significa iterar cada registro de aplicativo. A maioria dos ambientes não fez isso porque algumas automações legadas ainda dependem da API. O sistema de desativação gradual de firmware da Microsoft funciona de acordo com o cronograma da Microsoft, e não o do provedor de serviços de defesa.

• A visibilidade era inexistente, permitindo que equipes de ataque e adversários explorassem os endpoints da API em busca de informações relevantes.

O tráfego legítimo do AAD Graph é dominado por um pequeno número de chamadas de primeira parte da Microsoft. Em nosso locatário de teste, a ordem, por volume, foi Microsoft.OData.Client, Microsoft Azure Graph Client Library, uma cauda UA vazia de AppIds de primeira parte, Microsoft ADO.NET Data Services, e o portal do Azure (UAs do Chrome em relação ao ID do aplicativo do portal). Qualquer coisa fora desse conjunto reconhecível é ferramenta interna ou atividade não autorizada. Isso faz dele um conjunto de dados sólido para busca e detecção de ameaças. Se você estiver capturando isso.

Configurando o pipeline de ingestão

Se você já estiver executando a integração do Elastic Azure com o encaminhamento de configurações de diagnóstico para um hub de eventos, dê uma olhada rápida nesta seção. Provavelmente você só precisa habilitar mais uma categoria de registro. Do início ao fim, são cerca de 20 minutos de percurso.

Etapa 1: Uma pilha para receber os registros

Qualquer implementação do Elastic funciona. Um período de teste do Elastic Cloud é a opção com menos atrito para prototipagem. Outra opção para começar é o Elastic Container Project . A integração com o Azure já lida com os logs de atividades do AzureADGraph assim que é ativada.

Etapa 2: Adicione a integração com o Azure

No Kibana, Integrações > Logs do Azure > Adicionar Logs do Azure. Insira a sua string de conexão do Event Hub, o nome do Event Hub e uma conta de armazenamento para o checkpoint de offset, tudo em um Event Hub na mesma assinatura que o seu locatário.

Habilite especificamente o fluxo de dados de logs do Azure v2. Esse é o ponto de entrada para os Registros de Atividade do AAD Graph. O roteador de eventos corresponde category == "AzureADGraphActivityLogs" e redireciona os documentos para logs-azure.aadgraphactivitylogs-*, onde o pipeline do conjunto de dados aplica a extração ECS completa.

Também separamos os Logs de Atividade do Azure AD Graph em um item de integração próprio, para que você possa pesquisar por "Logs de Atividade do Azure AD Graph" e instalá-los diretamente por meio do modelo de política.

Etapa 3: Ative as configurações de diagnóstico no Entra ID

Este é o passo que a maioria dos defensores não dá. A categoria AzureADGraphActivityLogs, nas configurações de diagnóstico, é mais recente. Mesmo que suas configurações de diagnóstico do Entra ID já estejam configuradas há algum tempo, a nova categoria precisa ser verificada novamente. Caso contrário, os dados ficam restritos aos limites do ambiente do locatário da Microsoft.

No portal do Azure:

1. ID de entrada > Monitoramento > Configurações de diagnóstico > + Adicionar configuração de diagnóstico.
2. Dê um nome a isso.
3. Em Logs, verifique AzureADGraphActivityLogs. Já que você está mexendo nisso, vale a pena ativar os logs MicrosoftGraphActivityLogs, SignInLogs e AuditLogs, caso ainda não estejam ativados. A integração lida com todas elas.
4. Em Detalhes do destino, selecione Transmitir para um hub de eventos (o mesmo do passo 2).
5. Salvar.

Etapa 4: Verifique se o fluxo de dados está ocorrendo.

Dentro de alguns minutos, você deverá começar a ver os eventos. Verificação de sanidade mais rápida:

FROM logs-azure.aadgraphactivitylogs-*
| LIMIT 20

Se os documentos retornarem com os campos event.action, http.request.method e zure.aadgraphactivitylogs.properties.* preenchidos, está tudo certo. Se nada aparecer, os motivos mais comuns são uma permissão esquecida no hub de eventos, um erro de digitação na string de conexão ou a categoria do AAD Graph simplesmente não estar marcada.

Para forçar alguns eventos, faça login no portal do Azure e clique em Usuários ou Aplicativos. O portal ainda utiliza o AAD Graph internamente para obter detalhes de alguns objetos. Se isso não gerar nada, este loop curl irá:

TOKEN=$(az account get-access-token --resource https://graph.windows.net --query accessToken -o tsv)
TID=$(az account show --query tenantId -o tsv)
for obj in users groups servicePrincipals applications tenantDetails; do
  curl -sS -o /dev/null -H "Authorization: Bearer $TOKEN" \
    "https://graph.windows.net/$TID/$obj?api-version=1.6&\$top=5"
done

Forma de campo

Assim que os dados começam a fluir, as propriedades são armazenadas como campos tipados de nível superior. As que importam para a caça:

• ECS, preenchido diretamente: event.action (um verbo semântico derivado de método + coleção, por exemplo, users-read, batch-execute), event.outcome, event.duration, http.request.method, http.response.status_code, source.ip e source.geo.*, user.id, user_agent.original (mais subcampos analisados), url.path, azure.tenant_id, cloud.service.name = "Azure AD Graph".
• Conjunto de dados específico sob zure.aadgraphactivitylogs.properties.*: app_id,, app_id, api_version, actor_type, roles, scopes, wids, identity_provider, client_auth_method, sign_in_activity_id, token_issued_at.
• related.user obtém ambos user.id e properties.app_id, portanto, os pivôs na dimensão do cliente OAuth funcionam em conjunto com o pivô do usuário.

O JSON bruto permanece em event.original para reprodução forense. Você não deve precisar enfiar a mão lá dentro para caçar normalmente. Se você fizer isso, a função JSON_EXTRACT() do ES|QL é a alavanca.

Enumeração de grafos AAD com ROADrecon

Para saber o que caçar, você precisa saber como é a atividade. Os dois conjuntos de ferramentas abaixo são as fontes mais comuns de tráfego do AAD Graph em fluxos de trabalho de equipes vermelhas e pesquisa de segurança. Executei ambos os testes em nosso ambiente de teste.

Nota: Não me responsabilizo pelo uso indevido deste código. Execute essas ferramentas somente em inquilinos que você possui ou para os quais você tem autorização explícita por escrito para testar.

ROADrecon: Teste de enumeração em massa

ROADrecon é o módulo de coleta de dados do ROADtools, a estrutura de pesquisa Entra ID de Dirk-jan Mollema. Altamente recomendável se você ainda não o utilizou. O comando gather percorre todos os tipos de objetos relevantes no diretório (usuários, grupos, entidades de serviço, aplicativos, dispositivos, funções de diretório, atribuições de funções, atribuições de funções elegíveis, concessões de permissão OAuth2, unidades administrativas) e grava o resultado no SQLite.

A configuração segue o fluxo de trabalho padrão:

pip install roadrecon
roadrecon auth --device-code -c 04b07795-8ddb-461a-bbee-02f9e1bf7b46 -r https://graph.windows.net

O fluxo de código do dispositivo fornece um URL e um código. Usamos a CLI do Microsoft Azure como padrão (1b730954-1685-4b74-9bfd-dac224a7b894 - AAD PowerShell), que retornou 403s em nosso locatário. Após efetuar o login:

roadrecon gather

Executando o roadrecon gather com o token resultante concluído sem problemas. Do ponto de vista do locatário, a execução produziu pouco mais de ~2.000 chamadas e registros do AAD Graph em aproximadamente 1 minutos. Enumeração em massa de todos os tipos de objetos que o ROADrecon conhece.

A partir disso, podemos fazer algumas detecções iniciais para começar a sinalizar essas anomalias.

Campos-chave para detecção de ameaças no AAD Graph

Antes de começar a busca, aqui estão alguns campos iniciais sólidos para detectar anomalias.

Detecção e prevenção

Detecção

O pré-requisito para qualquer detecção do AAD Graph é ter os registros em primeiro lugar. A categoria de diagnóstico AzureADGraphActivityLogs precisa ser habilitada no Entra ID e roteada para um destino que você possa consultar (no mínimo um espaço de trabalho do Log Analytics, idealmente também encaminhado para um hub de eventos para ingestão elástica, conforme descrito na seção de configuração acima). Até que isso seja feito, as chamadas descritas nesta publicação acontecem inteiramente fora do alcance das câmeras, e nenhuma das buscas abaixo será realizada.

Se você não conseguir ingerir dados no Elasticsearch agora, habilite a configuração de diagnóstico mesmo assim e envie para o Log Analytics. Os equivalentes em KQL das buscas abaixo são simples, e os dados se acumulam com retenção mesmo sem processamento adicional.

Prevenção

Não existe um único botão de desativação do AAD Graph para todo o locatário no portal. O controle real da camada de aplicação é:

• application.authenticationBehaviors.blockAzureADGraphAccess

Um valor booleano por aplicativo no recurso do aplicativo (Microsoft Graph beta, documentação). Bloquear em grande escala significa percorrer cada registro de aplicativo e alterá-lo manualmente ou programaticamente. A própria Microsoft está implementando o processo de descontinuação gradual dos seus produtos, seguindo o cronograma estabelecido por ela. Quanto mais o jogo avança, menor é a superfície a ser defendida.

Enquanto isso, os defensores podem se mover nos mesmos eixos:

• Audite os aplicativos em seu locatário que ainda possuem tokens para graph.windows.net. Defina blockAzureADGraphAccess = true naqueles que não precisam. Qualquer coisa que ainda dependa do AAD Graph para de funcionar de forma abrupta, revelando automações legadas que você nem sabia que tinha.

• Aplicar o Acesso Condicional com o Azure AD Graph como recurso de destino. A entidade de serviço do Azure AD Graph (00000002-0000-0000-c000-000000000000) não aparece no seletor de aplicativos CA padrão, mas está coberta pelas políticas Todos os recursos e pode ser segmentada individualmente por meio da abordagem de filtro de atributo de segurança personalizado. A alteração de aplicação de março da Microsoft 2026 torna isso mais prático: os escopos de baixo privilégio (User.Read, People.Read, etc.) que costumavam ser excluídos automaticamente da aplicação da CA agora são tratados como acesso ao AAD Graph, portanto, todas as políticas de recursos realmente os restringem. A CA realiza a avaliação no momento da emissão do token, portanto, os tokens já válidos continuam funcionando até expirarem.

• Aplique a AC (Autenticação Certificada) às ferramentas de ataque dos clientes FOCI (Microsoft Teams, Microsoft Office, OneDrive, Azure PowerShell, etc.). Exigir dispositivos gerenciados e em conformidade. O caminho de troca falha se o cliente subjacente não conseguir fazer login.

• Para usuários que utilizam entidades de serviço, o Workload Identities Premium adiciona autoridades certificadoras (CA) com escopo para entidades de serviço. As condições se limitam à localização, ao risco de proteção de identidade e ao contexto de autenticação; o único controle de concessão é o bloqueio. Útil para resumir caminhos de contexto externo e de risco, não para restringir um SP a aplicativos de nuvem específicos, como faz a CA do usuário.

• Desative o fluxo de código do dispositivo para usuários que não precisam dele. roadrecon auth --device-code é o caminho de menor resistência em todo o pipeline acima e é extremamente comum em phishing OAuth.

Detecção de comportamento

Enviamos regras de detecção que abrangem os formatos de reconhecimento do gráfico AAD documentados acima. Cada um reside no repositório de regras de detecção do Elastic e é executado nativamente no fluxo de dados analisado logs-azure.aadgraphactivitylogs-* .

Acesso ao Azure AD Graph com User-Agent suspeito - Regra de correspondência KQL. Acionado quando o AAD Graph recebe tráfego de strings de user-agent que correspondem a famílias de ferramentas ofensivas (Python, aiohttp, curl, Go-http-client, axios, AzureHound, BloodHound, AADIntenals, etc). Sinal de referência sólido, pois nenhum componente nativo da Microsoft se identifica como qualquer um deles, enquanto as ferramentas padrão se identificam. 

Azure AD Graph: Alta taxa de erros 4xx provenientes de agregação de usuários no ES|QL. Acionado quando um único chamador produz uma proporção excepcionalmente alta de respostas 4xx no gráfico AAD em um curto período de tempo. O uso de tokens para reconhecimento e força bruta deixa um rastro de erros 403 e 404, pois as ferramentas percorrem endpoints para os quais não têm permissão, solicitam IDs de objeto que não possuem ou usam um ID de cliente não autorizado para o AAD Graph. 

Acesso ao Azure AD Graph com cliente e usuário incomuns - Regra KQL new_terms, gravidade média. É acionado quando um par (cliente OAuth de chamada, usuário conectado) aparece no AAD Graph pela primeira vez nos últimos 14 dias. Detecta trocas de FOCI, tokens de atualização obtidos por phishing resgatados para clientes que o usuário normalmente não utiliza e tokens roubados usados em clientes desconhecidos. Ignora aplicativos próprios conhecidos que foram comumente observados interagindo com o Azure AD e que possuem o backend de propriedade da Microsoft.

Acesso ao Azure AD Graph com usuário e ASN incomuns - regra de correspondência KQL. Exclui as organizações ASN comuns da Microsoft / AWS / GCP / Akamai / Cloudflare e sinaliza o tráfego do AAD Graph originado fora desse conjunto. As ferramentas adversárias normalmente se aproveitam de ISPs residenciais, provedores de VPS ou redes de anonimato que produzem uma distribuição de ASN diferente daquela usada por chamadas legítimas de primeira parte. Ajustável por locatário, através da configuração da lista de ASNs excluídos.

Enumeração de Potenciais do Azure AD Graph (ROADrecon) - agregação ES|QL, alta severidade. Requer um user-agent aiohttp e uma sequência de mais de 500 solicitações do AAD Graph a partir de uma única identidade. O comando `gather` do ROADrecon usa o aiohttp por padrão e percorre todos os tipos de objetos de diretório, portanto, a combinação é essencialmente uma impressão digital da ferramenta. Maior severidade do que a regra genérica de UA não Microsoft porque o requisito adicional de burst remove a classe de falso positivo de protótipo de desenvolvedor.

Entrada de código de dispositivo OAuth ID para login no Azure AD Graph Enumeration - sequência EQL, alta severidade. Conecta-se a um login de código de dispositivo bem-sucedido no público legado do AAD Graph (00000002-0000-0000-c000-000000000000) em um dispositivo não gerenciado com enumeração de diretório em graph.windows.net pelo mesmo usuário em cinco minutos. O phishing de código de dispositivo obtém um token OAuth sem acessar a senha ou a autenticação multifator (MFA) do usuário, de modo que as leituras imediatas do Graph de usuários, entidades de serviço, aplicativos, atribuições de função, políticas ou detalhes do locatário sob esse token revelam a identidade comprometida que está sendo controlada pelo invasor. A sequência de fluxos de dados cruzados remove a classe de falsos positivos de evento único que as outras regras do gráfico AAD carregam.

Visibilidade do AAD Graph: o que vem a seguir?

Durante a maior parte da última década, a atividade do AAD Graph foi o equivalente telemétrico da matéria escura. Sabíamos que estava lá porque as ferramentas de análise de adversários continuavam apontando para ele, mas os clientes não tinham um fluxo de diagnóstico ao qual se inscrever nem registros para consultar. Os Logs de Atividade do Microsoft Graph reduziram a diferença pela metade quando foram lançados em abril de 2024. O AzureADGraphActivityLogs finalmente concluiu a outra metade no início de 2026.

Agora que os dados existem, o resto depende de nós. Adicione a nova configuração de diagnóstico, aponte-a para um hub de eventos, integre-a à sua pilha de sistemas, ative as detecções (ou crie as suas próprias) e comece a monitorar.

As detecções neste post são um ponto de partida. Uma vez que o tráfego do AAD Graph esteja chegando à sua infraestrutura e você tenha uma noção do comportamento normal em seu locatário, os mesmos padrões se generalizam. Os usuários legítimos que utilizam o serviço Microsoft formam um pequeno grupo reconhecível, e qualquer coisa fora desse grupo merece uma análise mais detalhada.

A atividade sempre esteve presente. A visibilidade finalmente também.

Boa caçada!

Referências

Os seguintes itens foram referenciados ao longo da pesquisa acima:

• Integração elástica com o Azure
• ROADtools GitHub
• Wiki do ROADtools
• Bloodhound com recursos do Azure AD
• AADInternals
• Documentação do AADInternals
• Migre seus aplicativos do Azure AD Graph para o Microsoft Graph.
• Configure as definições de diagnóstico do Microsoft Entra para registos de atividades.
• Aceda aos registos de atividade do Microsoft Graph
• Os registros de atividades do Microsoft Graph agora estão disponíveis para o público em geral.
• O elo perdido: AADGraphActivityLogs finalmente chegou.
• Elevação de privilégios no Azure AD - Assumindo as permissões padrão do aplicativo como Administrador do Aplicativo
• Abuso do SSO do Azure AD com o token de atualização primário

Sobre o Elastic Security Labs

O Elastic Security Labs é o braço de inteligência de ameaças da Elastic Security, dedicado a gerar mudanças positivas no cenário de ameaças. O Elastic Security Labs disponibiliza pesquisas públicas sobre ameaças emergentes, com análises dos objetivos estratégicos, operacionais e táticos dos adversários, e integra essas pesquisas aos recursos de detecção e resposta do Elastic Security. Siga o Elastic Security Labs no Twitter @elasticseclabs e confira nossas pesquisas em www.elastic.co/security-labs/.