Purple-Teaming Azure IAM

Nota da pasta 04 - Purple Teaming em Cloud e Containers, no Capítulo 19 (Purple Teaming Contínuo).
Trata do purple teaming de identidade no Azure e Entra ID, com técnicas testáveis de abuso de role assignment, abuso de app registration e consent phishing simulado, hipóteses, telemetria esperada e verificação de detecção.
Dialoga com o hunting de identidade do Capítulo 08, com o hunting em cloud e SaaS e com o BAS contínuo da pasta 03 deste capítulo.

1. Contexto e Posicionamento na Biblioteca

A identidade é o novo perímetro, e no Azure essa frase é literal: quem controla identidades e atribuições de papel controla a assinatura inteira, com pouca superfície de endpoint para o EDR observar. O purple teaming de IAM no Azure validará detecções que operam sobre logs de controle de plano, os audit logs e os sign-in logs do Entra ID, e essa validação exige testes que tocam apenas permissões e configurações, nunca dados. É um domínio em que a emulação é barata, a telemetria é nativa e o risco de dano é baixo quando o teste roda em tenant de laboratório, o que a torna a porta de entrada ideal para o purple teaming em cloud.

Esta nota cobre a superfície IAM com três famílias de técnicas testáveis, o desenho de hipóteses e a verificação de detecção. Dialoga com o hunting de identidade e autenticação do Capítulo 08, que descreve o que caçar, e com o hunting em cloud e SaaS do mesmo capítulo, que cobre os campos dos logs. O regime operacional é o mesmo do capítulo: tenant de teste dedicado, contas sintéticas, autorização formal e resultados no índice do painel de cobertura. Nenhum teste descrito deve rodar no tenant de produção.

2. A Superfície IAM no Azure e os Pré-Requisitos de Telemetria

A superfície de identidade do Azure se organiza em duas camadas que as detecções precisam distinguir. A camada do Entra ID, ex-Azure AD, concentra aplicativos, app registrations, atribuições de papel administrativo, políticas de acesso condicional e consentimento. A camada do Azure RBAC concentra atribuições de papel sobre assinaturas, grupos de recursos e recursos. As técnicas de abuso vivem na interação entre as camadas: um papel administrativo no Entra que permite consentir aplicativos em todo o tenant, por exemplo, é a peça central de uma cadeia de comprometimento que começa e termina sem tocar uma máquina virtual.

A telemetria essencial está nos logs nativos, e o pré-requisito do programa é tê-los ingeridos no SIEM com as mesmas regras de produção. Os audit logs do Entra registram eventos de controle de plano, como adição de membro a papel, criação de app registration e concessão de consentimento. Os sign-in logs registram cada autenticação com detalhes de risco, MFA e aplicativo. No lado do Azure RBAC, o Activity Log registra escritas de controle de plano, incluindo criação de role assignments. A tabela organiza as fontes e os eventos mais úteis para os testes desta nota.

Os pré-requisitos operacionais completam a base. O tenant de teste precisa espelhar as configurações relevantes de produção, políticas de acesso condicional representativas, papéis nomeados iguais, e as contas de teste precisam de licenças que gerem os mesmos campos de log. Sem esse espelhamento mínimo, as regras testadas em laboratório comportam-se diferente em produção, e o resultado da rodada perde validade.

A leitura dos logs de identidade depende de um punhado de campos recorrentes, e a tabela fixa o vocabulário que as consultas de verificação desta nota usam.

3. Técnicas Testáveis e Telemetria Esperada

As três famílias de técnicas cobertas aqui representam os padrões de abuso de identidade mais frequentes em relatórios públicos de incidentes, e todas produzem telemetria determinística nos logs nativos. A tabela mapeia cada técnica, o teste correspondente e a telemetria esperada, servindo de roteiro de construção do conjunto de testes.

Cada teste tem guardrails explícitos, e os dois mais importantes valem destaque. O teste de consent phishing simulado usa um app registration criado no tenant de laboratório, com nome que não se pareça com marcas reais, para evitar qualquer confusão com campanha externa, e o consentimento é concedido por conta de teste que tem escopo limitado ao lab. O teste de desativação de MFA, quando incluído em programas avançados, é sempre o último da rodada, com política de reversão imediata, porque altera o estado de segurança do tenant de teste.

4. Hipóteses e Testes Purple Team

O desenho do teste parte de hipótese de detecção no mesmo formato do ciclo de hunting da biblioteca: se o adversário fizer X, então o log Y deve registrar Z e a regra R deve alertar. Três hipóteses de referência estruturam a rodada de IAM, e cada uma se decompõe em testes executáveis.

• Se um administrador comprometido se auto-atribui um papel privilegiado, o AuditLogs deve registrar Add member to role com a conta como actor e o papel como alvo, e a regra de papel elevado fora de processo de mudança deve alertar.
• Se o adversário persiste por credencial em app registration, o AuditLogs deve registrar Update application com adição de segredo ou certificado, e a regra de credencial nova em app com escopos sensíveis deve alertar.
• Se a cadeia começa por consent phishing simulado, o AuditLogs deve registrar Consent to application com escopos elevados e o SignInLogs deve registrar a primeira autenticação do app, e a regra de consentimento com escopos de perigo deve alertar.

A execução dos testes em laboratório é direta, com portal, CLI ou PowerShell, e a escolha do instrumento deve seguir o que a detecção precisa observar. O bloco a seguir registra a sequência do teste de auto-atribuição de papel, com os parâmetros documentados para reprodutibilidade.

# Teste PT-AZ-01: auto-atribuição de papel administrativo em tenant de lab
# Pré-requisitos: conta de teste com User Administrator e PIM desabilitado no lab
# Variáveis: USER_OID e ROLE_ID do tenant de lab, nunca de produção

az login --tenant 00000000-1111-2222-3333-444444444444 --allow-no-subscriptions

# registrar o estado anterior da atribuição para a limpeza
az role assignment list --all --query "[].{p:principalId, r:roleDefinitionId}" > estado-anterior.json

# executar a atribuição de papel elevado à conta de teste
az role assignment create \
  --assignee-object-id "${USER_OID}" \
  --assignee-principal-type User \
  --role "Global Administrator" \
  --scope "/"

# registrar o horário exato do passo para a janela de verificação
date -u +"%Y-%m-%dT%H:%M:%SZ" >> janela-teste-pt-az-01.txt

O registro do horário em arquivo é o detalhe que viabiliza a verificação: a janela do teste no SIEM começa nesse timestamp menos a margem de ingestão e termina alguns minutos depois, e é dentro dela que os alertas são procurados.

5. Exemplo: Teste de Abuso de Privilégio e Verificação

A verificação do teste PT-AZ-01 consulta os audit logs do Entra na janela registrada. A consulta KQL a seguir exemplifica a busca pelo evento de atribuição de papel e pelos alertas da regra correspondente no Microsoft Sentinel, sendo o padrão adaptável a outros SIEMs.

// Verificação do teste PT-AZ-01 na janela registrada
AuditLogs
| where TimeGenerated between (datetime(2025-10-13 14:00) .. datetime(2025-10-13 14:20))
| where OperationName == "Add member to role"
| extend Actor = tostring(initiatedBy.user.userPrincipalName)
| extend Alvo = tostring(parse_json(tostring(TargetResources[0].modifiedProperties[0].newValue)))
| where Actor startswith "pt-" or Alvo has "Global Administrator"
| project TimeGenerated, Actor, Alvo, OperationName, CorrelationId

A leitura da ficha de resultado segue o padrão do capítulo. Se a consulta mostra o evento e o alerta da regra de papel elevado disparou, o resultado é detectado e a rodada registra a meta atingida. Se o evento existe e o alerta não veio, o resultado é só telemetria e a regra entra no backlog com a evidência anexada. Se nem o evento apareceu, o gap é de coleta, e o diagnóstico começa pelo conector do Entra no SIEM de laboratório. O corollário operacional é que a limpeza revoga a atribuição imediatamente após a verificação, com o estado anterior de referência salvo no primeiro passo do teste.

O teste de consent phishing simulado segue o mesmo ciclo, com uma peculiaridade de desenho: ele também valida o controle preventivo, não apenas o detectivo. Se o tenant de lab tem a política de bloqueio de consentimento de usuário configurada, o teste deve falhar por controle, e esse é um desfecho positivo que a ficha registra como bloqueado. Se o consentimento passa, a detecção deve alertar, e o gap de prevenção e o de detecção são registrados em campos distintos, porque geram trabalhos diferentes em times diferentes.

6. Automação das Rodadas de Identidade

A rodada de identidade automatiza bem porque os testes são chamadas de API idempotentes e a telemetria é nativa. O job semanal do BAS contínuo pode incluir o conjunto de IAM da mesma forma que inclui o conjunto de endpoint, com os testes executados por script versionado, a janela registrada automaticamente e a classificação publicada no índice de resultados. O bloco a seguir esboça a rotina em pseudocódigo de agendador.

Rotina semanal de identidade, tenant de lab:
  1. verificar saúde dos conectores do Entra no SIEM de lab
  2. executar PT-AZ-01, auto-atribuição de papel, registrar janela
  3. executar PT-AZ-02, credencial nova em app registration, registrar janela
  4. executar PT-AZ-03, consentimento de app de teste, registrar janela
  5. executar PT-AZ-04, autenticação com perfil de risco sintético
  6. aguardar janela de ingestão de 10 minutos
  7. para cada teste, classificar detectado, só telemetria ou não detectado
  8. revogar todas as atribuições e credenciais criadas e confirmar a revogação
  9. publicar resultados no índice BASResults e calcular regressões

O passo 8 é o que separa a automação responsável da imprudente, e a verificação da revogação é obrigatória, não presumida. Um job que cria papéis elevados e falha silenciosamente na limpeza transforma o tenant de lab em alvo interno, e por isso a confirmação de revogação entra no índice como registro de passo, com status próprio e alarme quando falha.

A verificação da limpeza também cabe em consulta, e o padrão a seguir confere que nenhuma atribuição criada pela rodada permanece ativa no tenant de lab.

// Verificação de limpeza: atribuições de papel restantes da rodada
AuditLogs
| where TimeGenerated > ago(1d)
| where OperationName in ("Add member to role", "Remove member from role")
| summarize Adicoes = countif(OperationName == "Add member to role"),
            Remocoes = countif(OperationName == "Remove member from role")
  by iniciador = tostring(initiatedBy.user.userPrincipalName)
| where iniciador startswith "pt-"
| extend Limpo = Adicoes == Remocoes

A coluna calculada de estado limpo é o registro de passo 8 em forma de evidência, e qualquer linha com valor falso aciona o alarme de limpeza da rodada. O mesmo padrão se aplica a credenciais de app registration e a consentimentos concedidos, com os OperationName correspondentes, e os três checkpoints de limpeza entram no relatório da rodada como itens próprios.

7. Erros Comuns e Pontos de Atenção

• Executar os testes no tenant de produção por conveniência, mesmo com contas de teste, pois a telemetria real e os alertas reais de produção não são o ambiente de validação; tenant de lab espelhado é requisito.
• Conceder a contas de teste mais privilégio do que o teste exige, reproduzindo no lab o problema que o programa combate; privilégio mínimo também vale para os testes.
• Usar nomes de aplicativo e domínios que imitem marcas reais no teste de consent phishing, criando risco de confusão com campanha externa; nomes de lab são explícitos e documentados.
• Esquecer a revogação de papéis, credenciais e consentimentos ao fim da rodada, acumulando exposição no lab; a confirmação de revogação é passo registrado.
• Julgar regras de identidade sem checar a saúde do conector de logs no SIEM, culpando a regra por um gap de ingestão; saúde de coleta é pré-verificação da rodada.
• Ignorar as políticas de acesso condicional no desenho do teste, validando detecções contra um tenant sem as proteções que a produção tem; o espelhamento mínimo inclui essas políticas.

8. Integração com o Restante da Biblioteca

Os resultados das rodadas de identidade alimentam o índice e o painel de cobertura da pasta 03, e as regras ajustadas retornam ao conjunto do ator prioritário quando a cadeia do adversário envolve identidade cloud, como é comum em atores de espionagem e de crime financeiro. O hunting de identidade do Capítulo 08 fornece as queries de caça que complementam as regras, e o gap que a rodada expõe em caça, comportamento testado que nenhuma query cobre, vira hipótese de hunting no fluxo do Capítulo 07. A nota de emulação em Kubernetes complementa o quadro cloud com o plano de dados dos clusters, e a nota de CI/CD fecha o ciclo com o gate de detecção.

Para a governança, a rodada de identidade é o artefato que conecta a CTI aos donos de IAM: as técnicas testadas vêm dos relatórios de ator prioritário, e os gaps encontrados viram requisitos concretos de hardening de identidade, como redução de papéis globais, PIM em papéis administrativos e política de consentimento restrita. Essa conversão de resultado de teste em requisito de controle é o que dá ao purple teaming em cloud o seu papel no programa integrado da biblioteca.