Descobrindo caminhos de ataque indiretos para controladores de domínio virtualizados no Azure

Na Netwrix Security Research, ajudávamos um cliente com uma avaliação do Entra ID e sabíamos que ele já havia feito o tiering do AD localmente. Também sabíamos que tinham controladores de domínio virtualizados no Azure, mas era difícil identificar qual servidor Windows era realmente um DC. Descobrimos que o Azure Run Command permite executar comandos como SYSTEM, então usamos isso para fazer reconhecimento e identificar os DCs.

Tudo mostrado neste post (capturas de tela, nomes de máquinas, nomes de usuário) vem de um ambiente de laboratório que reconstruímos depois para demonstrar a técnica. Nenhum dado de cliente está incluído.

Para contextualizar, a própria documentação da Microsoft descreve o Run Command como uma forma de executar scripts PowerShell dentro de uma VM Windows através do agente da VM, principalmente para tarefas gerais de gerenciamento, como corrigir problemas de acesso ou de rede em uma máquina. No entanto, ele não verifica qual tipo de VM está sendo usado. Funciona perfeitamente em um controlador de domínio da mesma forma que em qualquer outra VM.

Decidimos criar um script PowerShell com Claude que nos permite executar um comando em várias máquinas Windows ao mesmo tempo, em vez de clicar na consola Executar Comando uma VM de cada vez. Só precisa da permissão Microsoft.Compute/virtualMachines/runCommand/action, que vem com Virtual Machine Contributor ou superior.

O truque é executar cada chamada Invoke-AzVMRunCommand dentro de um ThreadJob em vez do usual Start-Job. Start-Job inicia um processo PowerShell novo por VM e recarrega o módulo Az toda vez, o que desacelera rapidamente após algumas máquinas. ThreadJob roda em uma thread dentro do mesmo processo, então iniciar vários ao mesmo tempo quase não custa nada. Mantemos uma fila de todas as VMs encontradas e a completamos até um número fixo rodando simultaneamente (20 por padrão). Reabastecemos uma vaga assim que uma termina, sem esperar que todo um lote termine para começar o próximo.

Veja como é executar whoami pelo portal para uma máquina de cada vez:

Agora, aqui está o mesmo comando sendo executado em todas as VMs da assinatura ao mesmo tempo, por meio do script PowerShell:

Com isso funcionando, o próximo passo foi encontrar os DCs. A verificação é simples: executar Get-Service NTDS em todas as VMs Windows em execução via Run Command. NTDS é o serviço que gerencia o banco de dados AD DS, então se estiver presente e ativo, essa máquina é um controlador de domínio.

Uma VM estava claramente em execução, mas o Run Command apresentou erro ao tentar acessá-la, enquanto todas as outras VMs na assinatura responderam normalmente. O nome por si só já era uma forte pista. A falha do Run Command encaixa-se exatamente no que se espera de um controlador de domínio bem protegido, com ferramentas de segurança mais rígidas atrapalhando. Aceitar esse erro como verdade e seguir em frente teria significado relatar zero controladores de domínio na assinatura.

Em vez de confiar no erro, perguntamos diretamente ao AD. Qualquer VM ingressada no domínio que o Run Command ainda alcance é usada para consultar o AD via LDAP. Não é necessário módulo do Active Directory, apenas [adsisearcher], um acelerador de tipo PowerShell embutido que já funciona em qualquer máquina ingressada no domínio.

A verificação é um bit userAccountControl chamado SERVER_TRUST_ACCOUNT, valor 8192. O AD só define isso quando um computador é promovido a DC. Adicionamos duas verificações: grupo primário 516 (o grupo "Domain Controllers") e um objeto NTDS Settings correspondente na partição de Configuração.

Uma coisa, porém: um nome de host correspondente sozinho não prova que é esta VM, nem que está no Azure. Os nomes mudam, são truncados e às vezes reutilizados. Então verificamos o IP primeiro, resolvendo o nome do DC para um IP dentro do domínio e comparando com o IP privado que o próprio Azure informa para essa VM. Esse IP só existe se a máquina estiver realmente rodando no Azure, então uma correspondência aí é o mais confiável possível. Quando o DNS não resolve, recorremos a comparar nomes de host, embora consideremos isso menos forte, pois os nomes podem mudar de formas que os IPs não mudam.

Assim que pudemos confirmar com segurança que a máquina que apresentou erro anteriormente era um controlador de domínio, a verdadeira questão foi quem poderia executar comandos arbitrários como SYSTEM nela, pois esse tipo de acesso é Tier-0, ponto final. Não é quem tem Domain Admin; o cliente já havia resolvido isso com sua hierarquia. É quem tem permissões do Azure nessa VM específica, porque o Run Command não se importa com nada no AD. Só importa o Azure RBAC.

É assim que fica. Alguns usuários aparecem mais de uma vez (uma linha por função), junto com um grupo e dois principais de serviço, todos com Owner ou Contributor em algum lugar da cadeia, a maioria herdada da Assinatura e não atribuída diretamente na VM. Cada um deles pode invocar o Run Command contra um controlador de domínio e executar código como SYSTEM. Nada disso tem a ver com quem realmente está nos Domain Admins on-prem.

Neste ponto, o script também pergunta se você quer gerar um gráfico no estilo BloodHound a partir desses dados para visualizar quais principais de segurança têm um caminho, direto ou indireto, para um controlador de domínio virtualizado no Azure. Para nosso laboratório, são 12 principais com caminho para o DC, a maioria herdada da assinatura e não atribuída diretamente à VM. Clique em qualquer nó e a barra lateral detalha exatamente o que é e como chegou lá, incluindo a associação ao grupo, então um nó de Grupo mostrando "3 membros" não é apenas uma contagem. Você pode realmente ver quem está dentro.

Recomendação

Marque seus Controladores de Domínio no Azure com algo como Tier-0-OnPrem-AD no recurso da VM. Parece óbvio, mas a maioria dos ambientes que analisamos não faz isso, por isso identificá-los exigiu um trabalho real em vez de apenas filtrar pela tag. Uma vez marcado, você pode criar uma política: negar novas atribuições de Proprietário ou Colaborador em qualquer coisa com essa tag, ou alertar quando houver alterações.

A marcação apenas informa o que está acontecendo daqui para frente. Não corrige o que já existe. Todos os ambientes que analisamos acumularam permissões nessas VMs ao longo do tempo, a maioria herdada do grupo de recursos ou da assinatura, não atribuída diretamente. É por isso que é fácil de ignorar.Revise quem tem acesso atualmente e pergunte, para cada pessoa e principal de serviço, se ainda precisam ser Proprietário ou Contribuidor em uma máquina que é um controlador de domínio.

Depois de configurado, filtrar é só adicionar a coluna de nível ou digitar Tier-0-OnPrem-AD na barra de filtro, e todos os DC aparecem. Não é necessário script. O que nos custou toda uma pipeline de enumeração agora é um filtro de dois cliques para qualquer pessoa da equipe.

Referências

1. Microsoft Learn: Execute scripts em uma VM Windows no Azure usando a ação Executar Comandos
   https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command
2. Microsoft Learn: Serviço de Metadados de Instância do Azure para máquinas virtuais
   https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service