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