Como detectar backdoors do Azure Active Directory
Como detectar backdoors do Azure Active Directory: Federação de identidade
Durante a violação do Solarwinds realizada pelos agentes de ameaça russos, uma das tĂŠcnicas utilizadas pelos agentes de ameaça para obter o controle do Azure Active Directory (AAD) de uma vĂtima foi criar um backdoor do AAD por meio da federação de identidade. A implicação desse ataque era que os atores da ameaça conseguiam fazer logon e personificar qualquer usuĂĄrio do Microsoft 365 (M365) e ignorar todos os requisitos do MFA, bem como evitar qualquer necessidade de inserir uma senha vĂĄlida. Como vocĂŞ pode imaginar, se os controles de detecção corretos nĂŁo estiverem em vigor - isso pode permitir a persistĂŞncia dos atores da ameaça para se passar por qualquer usuĂĄrio e manter o acesso e o controle da instância AAD / M365 da vĂtima.
A tĂŠcnica de backdooring AAD ĂŠ uma tĂŠcnica que tende a ser usada apĂłs o comprometimento - em que um invasor jĂĄ obteve acesso a uma conta com privilĂŠgios de Administrador Global ou Administrador de Identidade HĂbrida. Como tal, ĂŠ crucial que as organizaçþes monitorem as contas que recebem esses dois privilĂŠgios.
Hå muitas maneiras de um invasor obter privilÊgios de Administrador Global dentro do AAD - uma dessas tÊcnicas Ê realizar o escalonamento de privilÊgios em entidades de serviço com um proprietårio que tenha privilÊgios de Administrador Global. Eu escrevi uma postagem de blog anterior cobrindo aplicativos do Azure backdoor e abuso de entidade de serviço aqui .
A intenção deste post Ê para cobrir a forma de criar um anúncio Azure backdoor utilizando o AADInternals ferramenta por @DrAzureAD, o portal AAD eo módulo MSOnline PowerShell . Como tal, dividi esta postagem do blog em duas seçþes - a primeira focando na detecção e a segunda no fluxo de ataque.
Metodologia de Detecção
Para detectar um backdoor malicioso do AzureAD, existem trĂŞs elementos principais a serem considerados na metodologia de anĂĄlise:
- Revise todos os nomes de domĂnio federados no AAD
- Revise os registros de auditoria e registros de auditoria unificados para quaisquer domĂnios federados recentemente
- Revise os registros de auditoria para ImmutableIds sendo adicionados / criados para uma conta
- Revise todos os logons anĂ´malos nos logs de login do Azure e nos logs de auditoria unificados (UAL)
Etapa 1: RevisĂŁo de nomes de domĂnio federadosNo portal do AAD, a seção âNomes de domĂnio personalizadosâ lista todos os domĂnios relevantes para a instância. Nesta seção especĂfica, recomendo revisar todos os domĂnios que tĂŞm a marca âfederadoâ ao lado.
Para detectar um backdoor malicioso do AzureAD, existem trĂŞs elementos principais a serem considerados na metodologia de anĂĄlise:
- Revise todos os nomes de domĂnio federados no AAD
- Revise os registros de auditoria e registros de auditoria unificados para quaisquer domĂnios federados recentemente
- Revise os registros de auditoria para ImmutableIds sendo adicionados / criados para uma conta
- Revise todos os logons anĂ´malos nos logs de login do Azure e nos logs de auditoria unificados (UAL)
No portal do AAD, a seção âNomes de domĂnio personalizadosâ lista todos os domĂnios relevantes para a instância. Nesta seção especĂfica, recomendo revisar todos os domĂnios que tĂŞm a marca âfederadoâ ao lado.
Etapa 2: detectar quaisquer domĂnios federados recentemente no AAD
Os logs de auditoria do AAD e os logs de auditoria unificados rastrearĂŁo a atividade relativa Ă criação de um domĂnio federado recentemente. Esses eventos nĂŁo devem ocorrer com frequĂŞncia, portanto, configurar um alerta sobre isso nĂŁo deve gerar muito ruĂdo. Como o AAD armazena o log de auditoria e a atividade de log de entrada por 7 a 30 dias com base na licença, tambĂŠm recomendo configurar a mesma detecção nos logs de auditoria unificados.A detecção deve se concentrar em olhar os seguintes campos para uma correspondĂŞncia:
- Atividade: "Definir autenticação de domĂnio"
- IssuerURI: "http: //any.sts/*"
- LiveType: "Federado"
A captura de tela abaixo mostra como isso ĂŠ representado nos logs de auditoria no portal.
Uma revisĂŁo posterior dos logs de auditoria deve mostrar uma sequĂŞncia de atividades pertencentes Ă verificação do domĂnio malicioso junto com a atividade de federação. Eu tambĂŠm caçaria as seguintes atividades:- Verificar domĂnio: sucesso ou falha
- Adicionar domĂnio nĂŁo verificado: sucesso
Etapa 3: detectar modificaçþes em ImmutableIDs para contas
Para que uma porta dos fundos seja configurada, o usuĂĄrio personificado com credenciais de Administrador Global / Administrador de Identidade HĂbrida precisa ter um ImmutableID configurado. Isso criarĂĄ um evento nos registros de auditoria do AAD. Eu escreveria uma detecção que procurasse:- Atividade: "Atualizar usuĂĄrio"
- Propriedades atualizadas incluĂdas: "SourceAnchor"
Como vocĂŞ pode ver na imagem abaixo - o ImmutableID que criei era âhappyeggâ. Ao detectar a existĂŞncia de mapeamento de âPropriedades atualizadas incluĂdasâ para âSourceAnchorâ, vocĂŞ pode detectar a criação / modificação do ImmutableID.
Etapa 4: analise os logins anĂ´malos
Ă difĂcil revisar os logs de entrada do AAD para verificar esse comportamento, pois os invasores podem basicamente se passar por qualquer usuĂĄrio e fazer logon. A premissa da porta dos fundos ĂŠ que os invasores podem contornar o MFA. Quando realizei esse ataque em minha instância de teste, ele gerou os eventos a seguir com esses detalhes, que nĂŁo devem ser muito comuns para um usuĂĄrio. No entanto, com base nesse ataque, esses eventos de logon podem variar e podem gerar falsos positivos. Eu manteria isso em mente antes de transformar isso em uma consulta de detecção.
Você tambÊm pode se concentrar na detecção de logins anômalos gerais que correspondem a outros IoCs coletados em termos de IPs, strings de agente de usuårio etc. dentro dos Logs de auditoria unificados (UAL).
A detecção deve se concentrar em olhar os seguintes campos para uma correspondência:
- Atividade: "Definir autenticação de domĂnio"
- IssuerURI: "http: //any.sts/*"
- LiveType: "Federado"
- Verificar domĂnio: sucesso ou falha
- Adicionar domĂnio nĂŁo verificado: sucesso
- Atividade: "Atualizar usuĂĄrio"
- Propriedades atualizadas incluĂdas: "SourceAnchor"
Metodologia de Ataque
Esta próxima seção se concentra em como realizar esse ataque. Contei muito com a documentação escrita por @DrAzureAD em seu blog aqui . Fiz isso de maneira um pouco diferente, mas você tambÊm pode fazer tudo usando apenas AADInternals.
Etapa 1: definir a string ImmutableID para o usuĂĄrio que vocĂŞ deseja personificar
Para que esse ataque funcione, o usuårio que você estå personificando precisa ter um conjunto de ImmutableID. Usei o módulo MSOnline para realizar esta seção. Eu primeiro fiz uma verificação para ver se havia algum ImmutableIDs definido em meu locatårio:
A conta que eu queria segmentar ĂŠ minha conta de administrador global - entĂŁo, usando o MSOnline, defini um ImmutableID para essa conta como âhappyeggâ.
Etapa 2: registrar um domĂnio malicioso
Para que isso funcione, vocĂŞ precisa registrar / criar um domĂnio malicioso que pode ser usado como backdoor. Segui a recomendação @DrAzureAD e gerei um grĂĄtis usando www.myo365.site chamado âevildomain.myo365.siteâ.
Decidi adicionar o domĂnio ao meu locatĂĄrio por meio do portal do AAD. VocĂŞ pode fazer isso clicando em âNomes de domĂnio personalizadosâ e adicionando seu nome de domĂnio personalizado lĂĄ. Ele o guiarĂĄ por uma verificação em que vocĂŞ precisarĂĄ garantir que o domĂnio malicioso que vocĂŞ criou tenha o mesmo campo TXT que o emitido pela Microsoft. A documentação da Microsoft sobre como adicionar um nome de domĂnio personalizado estĂĄ aqui .
Etapa 3: criar a porta dos fundos do AAD
Usei AADInternals para fazer isso da mesma forma que @DrAzureAD detalhado em seu blog. Isso entĂŁo fornece um IssuerURI que vocĂŞ utilizarĂĄ para fazer o login.
Etapa 4: Faça login por meio do backdoor do AAD
Usando o AADInternals novamente, eu loguei - como vocĂŞ pode ver na captura de tela abaixo, ele abre automaticamente um navegador e mostra a mensagem âContinuar conectado?â pĂĄgina. Ao clicar em âSIMâ, vocĂŞ ĂŠ levado automaticamente ao M365 conectado como esse usuĂĄrio. Ataque completo!
ReferĂŞnciashttps://o365blog.com/post/aadbackdoor/https://docs.microsoft.com/en-us/powershell/module/msonline/set-msoluser?view=azureadps-1.0https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domainhttps://docs.microsoft.com/en-us/powershell/module/msonline/?view=azureadps-1.0
Coisas brilhantes. Obrigado.
RESPONDERRESPONDER