EntraGoat Cenário 3: Explorando a propriedade do grupo em Entra ID

Nota do editor

Este cenário faz parte de uma série de exemplos que demonstram o uso do EntraGoat, nosso ambiente de simulação Entra ID. Pode ler uma visão geral do EntraGoat e o seu valor aqui.

Membro do grupoNavio naufragado-Navegou em águas administrativas

O cenário 3 do EntraGoat demonstra como os recursos administrativos legítimos do Entra ID - propriedade de grupos, grupos atribuíveis a funções e gerenciamento principal de serviços - podem ser encadeados em um caminho de escalonamento de privilégios não intencional de um usuário com pouco privilégio para o Administrador Global.

O atacante começa com uma conta de suporte de TI comprometida que possui vários grupos, incluindo um que é atribuível a uma função com o Application Administrator função. Ao adicionar-se a este grupo, o atacante herda a função e obtém um controlo alargado sobre as aplicações e os princípios de serviço em todo o inquilino.

A partir daí, ao identificar um comitente de serviço de alto valor que seja membro de outro grupo atribuível a uma função que detenha o Privileged Authentication Administrator o atacante adiciona-lhe um segredo de cliente, autentica-se como o principal de serviço privilegiado e repõe a palavra-passe do Administrador Global.

Este cenário destaca a forma como as funcionalidades Entra ID individualmente legítimas, quando combinadas com a propriedade de um grupo mal configurado, podem transformar-se numa cadeia de escalonamento de privilégios que eleva uma conta de baixo nível a uma ameaça para todo o inquilino.

Visão geral do caminho de ataque

1. História do primeiro ponto de apoio: O atacante autentica-se como Michael ChenO utilizador do cenário é um especialista em suporte informático comprometido que, de acordo com a descrição do cenário, "gere alguns grupos de segurança".
2. Enumeração: O atacante descobre a propriedade de seis grupos, incluindo um grupo atribuível a uma função chamado IT Application Managers que contém o Application Administrator papel.
3. Escalada de privilégios: O atacante acrescenta-se ao grupo de segurança para herdar o papel privilegiado.
4. Serviço de orientação principal: Com o Application Administrator o atacante identifica a função de diretório Identity Management Portal chefe de serviço como membro de um grupo com o Privileged Authentication Administrator e acrescenta-lhe um segredo de cliente.
5. Pivotagem: O atacante autentica-se através do fluxo OAuth2 de concessão de credenciais do cliente como a entidade de serviço comprometida com o segredo recentemente adicionado.
6. Compromisso da conta: Utilizando os privilégios inerentes ao principal de serviço, o atacante redefine a palavra-passe do Administrador Global, autentica-se como GA e recupera o sinalizador de cenário.

Fluxo de ataque

A Figura 1 mostra o fluxo deste ataque.

Porque é que este ataque funciona

Este cenário encadeia várias caraterísticas legítimas do Entra ID que, quando mal configuradas, criam um caminho de escalonamento:

• Propriedade do grupo: O modelo de propriedade de grupo da Entra ID concede amplo controle sobre a associação e as propriedades. Embora se destine a delegar tarefas administrativas, torna-se arriscado quando aplicado a grupos atribuíveis a funções ou concedido a utilizadores inadequados, uma vez que um proprietário pode adicionar-se diretamente (ou qualquer conta controlada) ao grupo e herdar as funções atribuídas.
• Grupos atribuíveis a funções: Os grupos de segurança atribuíveis a funções permitem aos administradores atribuir funções de diretório a grupos e não a utilizadores individuais, simplificando a gestão de funções à escala ao fazer com que qualquer membro do grupo receba automaticamente as funções atribuídas. Quando combinado com permissões de propriedade de grupo, isto cria uma via de escalonamento de privilégios em que os proprietários de grupo podem efetivamente conceder a si próprios as funções atribuídas aos grupos que controlam.
• Membro do grupo principal do serviço: As entidades de serviço, tal como os utilizadores, podem ser membros de grupos de segurança e herdar quaisquer funções atribuídas a esses grupos. Esta conceção permite aos administradores gerir as permissões das aplicações através da associação a grupos, em vez de atribuições de funções individuais. No entanto, os mandantes de serviço apresentam superfícies de ataque únicas que os utilizadores regulares do Entra ID não têm. Estes mecanismos adicionais criam mais vectores potenciais para obter acesso não autorizado a qualquer entidade de serviço privilegiada que possua membros de grupos privilegiados.
  • Podem ser comprometidos através de relações de propriedade (como se viu no Cenário 1).
  • Estão sujeitos a controlos de gestão de aplicações - identidades com o Application Administrator ou Cloud Application Administrator funções, funções personalizadas que incluem a função microsoft.directory/applications/credentials/update ou microsoft.directory/servicePrincipals/credentials/update acções, ou mandantes de serviços com o Application.ReadWrite.All que pode adicionar ou modificar as credenciais do responsável pelo serviço.
  • Podem ser geridos de forma programática através de APIs e fluxos de trabalho de automatização.
  • Ao contrário das identidades de utilizador, não podem ser atribuídas como elegíveis para o PIM; só podem ter atribuições de função activas (que podem ter um limite de tempo). Quando uma entidade de serviço se encontra num grupo atribuível a uma função, o seu acesso contorna os controlos de ativação just-in-time do PIM, proporcionando uma associação a uma função sempre ativa durante a janela de atribuição.
  • Podem autenticar-se num contexto apenas de aplicação (credenciais de cliente OAuth2) utilizando um segredo ou certificado de cliente, que contorna os controlos centrados no utilizador, como a autenticação multifunções interactiva e os requisitos de acesso condicional interativo.
• Âmbito do Administrador de Aplicações: A função fornece um controlo alargado sobre os registos de aplicações e entidades de serviço, incluindo a capacidade de adicionar credenciais de autenticação (segredos e certificados) a aplicações no inquilino, criando oportunidades para os atacantes fazerem backdoor de entidades de serviço de elevado valor que não estejam configuradas com o bloqueio de instância de aplicação.

Cada um desses recursos do Entra ID é legítimo e necessário para a delegação administrativa, mas, em combinação, eles criam caminhos de escalonamento de privilégios não intencionais que podem elevar uma identidade com pouco privilégio até Administrador global.

Como detetar e defender-se contra a utilização indevida da propriedade de grupos

Monitorar a propriedade do grupo é um requisito fundamental de segurança em qualquer ambiente Entra ID.

Os proprietários podem gerir a associação, alterar as propriedades do grupo e controlar indiretamente quaisquer funções de diretório atribuídas aos seus grupos. Sem uma visibilidade clara das relações de propriedade e das atribuições de funções, os caminhos de escalonamento de privilégios através de grupos atribuíveis a funções podem permanecer ocultos tanto para os defensores como para os auditores.

Os defensores devem monitorizar e correlacionar:

• Que grupos atribuíveis a funções existem no locatário?
• Que funções de diretório são atribuídas a estes grupos?
• Quem é o seu proprietário e que justificação comercial existe para essa propriedade?
• Algum utilizador sem privilégios possui grupos com atribuições de funções privilegiadas?
• Quais são os mandantes de serviço que são membros de grupos atribuíveis a funções?
• Existem grupos não utilizados ou órfãos que possam ser desactivados?

As soluções Semperis ajudam a colmatar as lacunas na compreensão destas questões com várias camadas de defesa, começando com indicadores de exposição (IOEs) e indicadores de compromisso (IOCs).

Esses indicadores detectam e alertam automaticamente sobre padrões perigosos e configurações incorretas - como grupos atribuíveis a funções com proprietários inadequados, diretores de serviços com permissões perigosas e linhas de base de governança de grupos fracas que permitem o escalonamento de privilégios por meio da manipulação de membros de grupos.

Mergulho profundo no cenário: Apresentação passo a passo da solução

Você pode encontrar o passo a passo completo e os comandos que o acompanham no repositório EntraGoat GitHub em solutions/EntraGoat-Scenario3-Solution.ps1.

Etapa 1: Ponto de apoio inicial

Começamos o Cenário 3, como Figura 2 mostra, com acesso a um utilizador pouco privilegiado comprometido chamado Michael ChenMichael é um especialista em suporte informático. A história de fundo diz-nos que Michael possui vários grupos de segurança - uma configuração incorrecta que prepara o terreno para a escalada.

Autenticamo-nos com as suas credenciais utilizando Connect-MgGraph e, em seguida, executar Get-MgContext para confirmar o nosso contexto de segurança atual (Figura 3).

Etapa 2: Enumeração

Em seguida, uma vez que a dica nos aponta nesta direção, enumeramos todos os grupos que pertencem ao utilizador atual(Figura 4).

Descobrimos que ele possui seis grupos no total. Para avaliar o potencial de escalonamento de privilégios, verificamos se algum deles é atribuível a uma função e se tem efetivamente funções atribuídas(Figura 5).

Há um grupo que se destaca imediatamente: IT Application Managers, que detém o Application Administrator papel.

Esta função é poderosa, uma vez que concede controlo total sobre todos os registos de aplicações e entidades de serviço no locatário, incluindo a capacidade de adicionar segredos ou certificados a quaisquer aplicações de terceiros (no caso de não estarem configuradas com bloqueio de instância de aplicação). Em seguida, o atacante pode utilizar a identidade da entidade de serviço para se autenticar no locatário através do fluxo de concessão de credenciais de cliente OAuth 2.0, operando num contexto apenas de aplicação que ignora as protecções centradas no utilizador.

Nota: As etapas de enumeração acima podem ser agrupadas em funções auxiliares dedicadas (por exemplo, Get-GroupsOwnedBy para a propriedade e Get-GroupRoles para funções atribuídas) para tornar o processo mais interativo e detalhado, semelhante à forma como as ferramentas de código aberto apresentam os resultados.

A Figura 6 e a Figura 7 mostram a implementação.

A Figura 8 mostra o aspeto da saída quando executamos esta função de enumeração com o ID do utilizador atual.

Embora isso possa ser útil em ambientes grandes, o Microsoft Graph também fornece um cmdlet muito mais eficiente: Get-MgUserOwnedObject (Figura 9).

Get-MgUserOwnedObject enumera todos os objectos de diretório pertencentes a um utilizadoreliminando a necessidade de consultar cada tipo de objeto (grupos, dispositivos, aplicações e entidades de serviço) individualmente, ao contrário da nossa implementação intencional. O comando pode ser ajustado um pouco com o Sonnet para obter uma saída mais agradável (Figura 10).

O comando Get-MgUserOwnedObject normalmente faz um pedido API para https://graph.microsoft.com/v1.0/users/{userId}/ownedObjects (possivelmente adicionando mais um ou dois pedidos, dependendo da paginação), sendo o resto tratado pela lógica local do PowerShell para processar, extrair e formatar a resposta.

Em comparação, o Get-GroupsOwnedBy A função que criámos, que pode ser mais interactiva e fácil de utilizar, torna 100-1000x pedidos de APIembora verifique apenas um tipo de objeto pertencente.

Ao selecionar ferramentas de enumeração, é sempre uma boa ideia dar prioridade à eficiência. Menos chamadas de API significam menos logs e uma pegada de deteção menor. Há muitas ferramentas de código aberto incríveis (e algumas menos incríveis) para enumerar ambientes de ID Entra. O ponto principal é que, embora as ferramentas possam ser atalhos úteis, elas nunca devem ser usadas como caixas pretas. Se puder ler o código-fonte, faça-o. Reserve um tempo para entender como as consultas são construídas, quais pontos de extremidade da API estão sendo atingidos e quais dados estão realmente sendo retornados. As ferramentas são tão eficazes quanto a compreensão que o operador tem dos seus métodos e limitações.

Passo 3: Construir a cadeia de ataque

Ser proprietário de um grupo com Application Administrator apresenta um potencial significativo de escalonamento de privilégios porque, quando nos adicionamos como membro, podemos gerir (== adicionar um segredo de cliente a) qualquer principal de serviço no locatário, o que abre várias vias para o comprometimento do locatário.

Mas acrescentarmo-nos agora seria ruidoso e desnecessário de uma perspetiva OPSEC. Em primeiro lugar, devemos confirmar que existe uma entidade de serviço privilegiada que podemos utilizar para chegar à cadeia seguinte do ataque - a função GA.

Está na altura de procurar diretores de serviços de elevado valor.

Nota: Para este passo a passo, vamos concentrar-nos na enumeração de entidades de serviço com funções privilegiadas que podem redefinir a palavra-passe do GA com apenas alguns passos:

• Administrador de funções privilegiadas (PRA)
• Administrador de Autenticação Privilegiado (PAA)
• Administrador Global (GA)

Dito isto, num inquilino real, não deve querer parar por aí. É igualmente importante enumerar as entidades de serviço com outras funções e com permissões de aplicação poderosas, uma vez que estas podem abrir caminhos de escalonamento igualmente perigosos, como se vê no Cenário 2.

Começaremos por utilizar a função Get-MgRoleManagementDirectoryRoleAssignment para verificar se algum responsável de serviço tem funções privilegiadas atribuídas diretamente (Figura 11).

Resultado? Nenhum. Nem um único diretor de serviço detém diretamente GA, PRA ou PAA no meu inquilino.

Mas esse não é o conjunto completo de diretores de serviço que podem ter funções privilegiadas atribuídas. O Entra ID permite grupos atribuíveis a funções e, assim como os usuários, os diretores de serviço podem ser membros desses grupos. Se um grupo tiver GA, PRA ou PAA, então qualquer diretor de serviço dentro dele herda esses privilégios. Esse é um vetor de escalonamento frequentemente negligenciado.

Assim, de seguida, enumeramos todos os grupos que são atribuíveis a funções e verificamos quais os que têm funções atribuídas(Figura 12).

Agora que temos uma lista de grupos privilegiados, precisamos de inspecionar os seus membros. Como a função Get-MgGroupMember opera na v1.0, ele não mostra os membros principais do serviço. Para resolver isso, vamos envolver uma chamada direta para o /beta numa função auxiliar (Figura 13).

Agora podemos utilizá-lo para filtrar a participação do diretor de serviço nos grupos privilegiados(Figura 14).

Agora as coisas ficam interessantes - descobrimos possíveis diretores de serviço com funções privilegiadas. Dependendo do seu ambiente, pode haver muitos mais.

Podemos simplesmente escolher o primeiro ($targetSPs[0]), mas por uma questão de consistência (e para que todos os jogadores tenham o mesmo caminho sem arriscar a estabilidade do inquilino), vamos concentrar-nos no Identity Management Portal, como Figura 15 espectáculos. Esta faz parte do guião de configuração e não vai quebrar nada no caso de uma mudança de funcionalidade (dedos cruzados).

Nesta fase, já mapeámos toda a cadeia de ataque. Eis como vamos passar do atual utilizador pouco privilegiado até ao Administrador Global:

1. Acrescentarmo-nos ao IT Application Managers para herdar o grupo Application Administrator papel.
2. Utilize essa função para adicionar um segredo de cliente ao Identity Management Portal diretor de serviço.
3. Autentique-se como o principal do serviço.
4. Utilizar os privilégios herdados do PAA para repor a palavra-passe do Administrador global.
5. Inicie sessão como Administrador global com a nova palavra-passe.
6. Recuperar a bandeira para provar o compromisso.

Passo 4: Executar o percurso de ataque

Primeiro, adicionamo-nos como membros da IT Application Managers grupo, como Figura 16 espectáculos.

Como os tokens não são atualizados automaticamente, podemos desconectar e reautenticar para obter um novo token de acesso com a nova função atribuída. Conforme discutido no Cenário 2, essa etapa não é obrigatória, pois a maioria dos pontos de extremidade do Entra ID geralmente avalia as atribuições de função dinamicamente.

Podemos utilizar o parse-JWTToken pela BARK para ver a função de administrador da aplicação adicionada (o wids dentro do token JWT que Figura 17 mostra) atribuídos ao utilizador.

Com Application Administrator nas nossas mãos, podemos adicionar um acesso de backdoor ao Identity Management Portal (Figura 18), como fizemos em Cenário 1.

Isso nos dá acesso persistente ao principal de serviço, independente de qualquer conta de usuário. Podemos usá-lo para autenticar como o principal de serviço para o Entra ID, como mostra a Figura 19 .

O passo seguinte é encontrar o utilizador alvo do GA e repor a sua palavra-passe(Figura 20).

Por fim, podemos autenticar-nos como o GA e recuperar a bandeira (Figura 21). Utilizaremos Get-MSGraphTokenWithUsernamePassword para autenticar a partir do CLI (tal como em Cenário 2), mas também pode definir um TAP (como em Cenário 1) e efetuar o registo interactivamente a partir do portal Azure ou do centro de administração Entra ID.

Cenário 3 concluído!

Etapa 5: Limpeza

Não se esqueça de executar o script de limpeza(Figura 22) para reverter o ambiente do locatário para o seu estado original.

Lições aprendidas

O cenário 3 revela como erros de configuração aparentemente pequenos na propriedade de grupos podem se transformar em cascata em comprometimento total do locatário. A cadeia de ataque (de utilizador pouco privilegiado a Administrador Global) não exigiu técnicas sofisticadas, apenas uma compreensão do modelo de delegação da Entra ID, como funciona a herança de funções e o plano de controlo das identidades principais de serviço.

A principal conclusão: A propriedade de grupos é uma delegação administrativa disfarçada. Quando os utilizadores possuem grupos atribuíveis a funções, controlam efetivamente quaisquer funções atribuídas a esses grupos. As entidades de serviço amplificam este risco porque podem ser comprometidas através de várias vias para além do tradicional roubo de credenciais - relações de propriedade, funções de gestão de aplicações e acesso programático.

O cenário mostra que, em ambientes modernos de identidade na nuvem, os caminhos de escalonamento de privilégios raramente são lineares. Estes percursos passam por relações de propriedade, associações de grupos e identidades de entidades principais de serviços de formas que exigem que os defensores pensem sistematicamente sobre relações de identidade em vez de permissões individuais.

O especialista de suporte de TI com poucos privilégios não precisava de quebrar nada - o caminho de escalonamento estava incorporado na configuração do inquilino desde o início.

Aceite o seu próximo desafio EntraGoat

GitHub - Semperis/EntraGoat
O que é EntraGoat? Um ambiente de simulação Entra ID deliberadamente vulnerável
Começando com o EntraGoat: Quebrando o Entra ID da maneira inteligente
Cenário 1: Abuso de propriedade de principal de serviço no Entra ID
Cenário 2: Explorando permissões de gráfico somente de aplicativo no Entra ID
Cenário 6: Explorando a autenticação baseada em certificado para se passar por administrador global no Entra ID

Nota final

1. https://github.com/BloodHoundAD/BARK

Declaração de exoneração de responsabilidade

Este conteúdo é fornecido apenas para fins educacionais e informativos. Destina-se a promover a consciencialização e a correção responsável das vulnerabilidades de segurança que possam existir nos sistemas que possui ou que está autorizado a testar. O uso não autorizado dessas informações para fins maliciosos, exploração ou acesso ilegal é estritamente proibido. A Semperis não endossa ou tolera qualquer atividade ilegal e se isenta de qualquer responsabilidade decorrente do uso indevido do material. Além disso, a Semperis não garante a exatidão ou a integridade do conteúdo e não assume qualquer responsabilidade por quaisquer danos resultantes da sua utilização.