Esta publicação é uma coleção de vários cenários comuns de ataques ao Microsoft Entra ID (anteriormente conhecido como Azure Active Directory) e como eles podem ser mitigados ou detectados.
Esta publicação é uma coleção de vários cenários comuns de ataque no Microsoft Entra e como eles podem ser mitigados ou detectados. Todos os cenários, percepções e comentários incluídos são baseados nas experiências dos colaboradores durante suas simulações de ataque, hands-on ou cenários do mundo real.
Ela deve ser considerada um documento vivo, que será atualizado à medida que as práticas evoluem e as técnicas de ataque e defesa mudam. Convidamos especialistas em identidade ou segurança da comunidade a trabalharem juntos nesta publicação e contribuírem com atualizações, feedbacks, comentários ou novas adições.
Em todos os capítulos, seguimos a mesma diretriz na estrutura do capítulo. Ao ler, você pode esperar encontrar:
As seções a seguir contêm uma breve descrição de cada capítulo que você pode encontrar no 'Entra ID Attack & Defense Playbook'.
A ideia inicial para criar o 'Azure AD Attack & Defense Playbook' veio de Thomas Naunheim. Nossa primeira chamada no Teams foi em algum momento do outono de 2020, quando Thomas apresentou a ideia e ela foi vendida imediatamente.
O primeiro capítulo foi sobre o ataque 'Password Spray', onde nos concentramos fortemente no mecanismo de detecção do Entra ID Protection (anteriormente conhecido como Azure AD Identity Protection) para detectar ataques do tipo 'password spray'. Durante o primeiro capítulo, aprendemos que o tempo de calendário para finalizar a pesquisa pode ser significativamente maior do que o esperado devido à complexidade da pesquisa e aos diferentes ângulos da investigação. O escopo, como em qualquer tipo de trabalho em projeto, é extremamente importante.
Nos capítulos mais recentes, tivemos a sorte de contar com outros membros da comunidade envolvidos no projeto, como Joosua Santasalo, Fabian Bader e Christopher Brumm, como parceiros de treino e revisores.
O MITRE ATT&CK Framework é comumente usado para mapear Táticas, Técnicas e Procedimentos (TTPs) para ações de adversários e emular defesas em organizações ao redor do mundo. Neste playbook, utilizamos o MITRE ATT&CK framework v11 em todos os capítulos para mapear Técnicas, Táticas e Procedimentos (TTPs) aos cenários de ataque. Isso ajuda as Blue Teams a construir defesas para os cenários correspondentes.
Você pode esperar encontrar várias regras de detecção nos capítulos individuais com base no cenário de ataque específico. Como o playbook tem um grande número de regras de detecção, decidimos criar uma visualização que contenha todos os cenários de ataque mapeados para TTPs. Leve também em consideração que cada capítulo individual possui uma visualização para o cenário de ataque correspondente.
Abrir no MITRE ATT&CK Navigator
As capacidades de detecção relacionadas aos produtos de segurança da Microsoft (Microsoft Defender XDR, Microsoft Sentinel, Microsoft Entra ID Connect, Microsoft Defender for Cloud) serão abordadas na parte de detecção dos cenários de ataque. Os modelos de regras personalizadas para o Microsoft Sentinel, que foram desenvolvidos para o playbook, também são mapeados para as TTPs. As regras de detecção estão disponíveis como Modelo de Regra do Microsoft Sentinel (pronto para implantar) em JSON (formato ARM Template) aqui.
Abrir no MITRE ATT&CK Navigator
Nota: Usamos o mapeamento de TTP existente dos modelos de regras do Microsoft Sentinel e da correlação de incidentes do Microsoft 365. Algumas detecções não oferecem cobertura completa do MITRE ATT&CK e não estão incluídas nesta visualização.
Normalmente, um capítulo levou aproximadamente 1-2 meses de tempo de calendário, então foi um esforço considerável reunir todos os quatro (4) capítulos e o apêndice. Durante os últimos dois (2) anos, pesquisamos os seguintes cenários:
“Um ataque de password spray é quando vários nomes de usuário são atacados usando senhas comuns em uma força bruta unificada para obter acesso não autorizado.”
O capítulo foi inicialmente criado em novembro de 2020 e atualizado em novembro de 2021 para incluir as atualizações mais recentes dos produtos de segurança do Microsoft Ignite 2021.
O capítulo contém uma breve descrição do ataque e das ferramentas usadas para simular o ataque do tipo password spray. Na parte de detecção, várias soluções de segurança da Microsoft são usadas, como Microsoft Sentinel e Defender for Cloud Apps.
Nas notas laterais, há algumas considerações para o ambiente on-premises e ADFS, caso ainda estejam em uso.
“Em um ataque de concessão de consentimento ilícita, o atacante cria um aplicativo registrado no Azure que solicita acesso a dados como informações de contato, e-mail ou documentos. O atacante então engana um usuário final para conceder consentimento a esse aplicativo para acessar seus dados, seja por meio de um ataque de phishing ou injetando código ilícito em um site confiável. Após o aplicativo ilícito receber o consentimento, ele tem acesso aos dados em nível de conta, sem a necessidade de uma conta organizacional.
Medidas normais de remediação, como redefinir senhas para contas comprometidas ou exigir Autenticação Multifator (MFA) nas contas, não são eficazes contra esse tipo de ataque, pois esses são aplicativos de terceiros e externos à organização. Esses ataques aproveitam um modelo de interação que pressupõe que a entidade que chama as informações é automação, não um humano.”
O capítulo contém uma descrição do ataque e a explicação de por que é importante proteger e monitorar as atividades em torno do framework de consentimento do Entra ID. No capítulo de detecção, usamos as seguintes soluções:
Como o tópico é grande e complicado, a parte de mitigação contém instruções e detalhes sobre como você pode reduzir a superfície de ataque no seu ambiente.
Nos dois cenários de ataque a seguir, focamos em service principals privilegiados como parte de pipelines de release no Azure DevOps (ADO) e na visibilidade (potencialmente) limitada na auditoria.
ADO é um tópico amplo e, neste capítulo, o escopo é limitado apenas aos cenários mencionados acima. O mesmo caminho é seguido aqui:
Quando trabalhamos neste capítulo, passamos muito tempo nas técnicas de detecção, o que foi complicado principalmente por causa do esquema de log de auditoria do ADO. No entanto, o trabalho árduo compensa e conseguimos atingir nosso alvo definido e detectar ataques no Microsoft Sentinel.
O capítulo contém informações aprofundadas sobre como proteger o ambiente do Azure DevOps no capítulo de mitigação.
Service Principals em Pipelines do Azure DevOps
Neste documento, focamos principalmente no seguinte cenário:
Fora do escopo estão a escalada de privilégios e os caminhos de ataque do servidor AADC em direção ao Active Directory (incluindo o abuso da conta do conector Azure AD DS).
O capítulo mais recente, lançado em 14 de março de 2022, trata do abuso da conta de serviço de sincronização do Microsoft Entra Connect. Para ser preciso, a conta do AAD Connect é responsável por executar ações no lado do Azure AD.
O tópico e o cenário de ataque foram extremamente interessantes para o trabalho de pesquisa e, mesmo tendo trabalhado muito com o Microsoft Entra Connect no passado, tenho de admitir que aprendi muito durante o período dos últimos dois (2) meses. Fizemos algumas descobertas interessantes que não tínhamos notado antes.
Se você leu até aqui, encorajo você a conferir as consultas KQL para o Microsoft Sentinel que criamos durante nosso trabalho de pesquisa.
Conta de Serviço de Sincronização do Microsoft Entra Connect
A Microsoft introduziu o Windows 11 com o requisito de usar um chip Trusted Platform Module (TPM). Isso aumentou muito as capacidades de usar os recursos de segurança do Windows 11, incluindo uma camada extra de proteção para cenários de autenticação baseados em nuvem. O Primary Refresh Token (PRT) e outras chaves relevantes podem ser bem protegidos pelo TPM no Windows 11, mas também no Windows 10 e nas versões do Windows Server de 2016 em diante. Levando isso em consideração, neste documento focamos principalmente nos seguintes cenários:
Replay do Primary Refresh (PRT) e outros tokens emitidos
O objetivo do Entra ID Security Config Analyzer é fornecer uma solução que extraia a configuração de segurança do Entra ID dos endpoints selecionados da Microsoft Graph API e ingira os dados no Log Analytics. O Azure Workbook é usado para visualização de dados, e o Microsoft Sentinel pode ser usado para criar alertas/incidentes quando uma alteração crítica de configuração é detectada.
A imagem a seguir descreve a arquitetura da solução EIDSCA, as soluções usadas e os fluxos de dados:
Arquitetura de referência para integrar o EIDSCA como parte do ambiente do Microsoft Sentinel. Os dados serão ingeridos no mesmo workspace do Sentinel. Depende da sua implementação e design se você deseja ter uma integração com um workspace dedicado, operacional ou existente do Sentinel.
Os controles EIDSCA também são usados no Maester, mais informações na documentação do Maester
Entra ID Security Config Analyzer (EIDSCA)
Diferentes tokens desempenham um papel crucial na autenticação em nuvem. Portanto, é importante entender sua mecânica e como os adversários podem explorá-los se eles caírem em mãos erradas. Entender isso pode ajudar a construir proteção contra ataques de identidade.
O roubo de token ocorre quando um adversário obtém acesso e compromete tokens. Uma vez roubados, o adversário pode reproduzir os tokens roubados e acessar a conta comprometida. No cenário AiTM, o adversário pode contornar o requisito de MFA, porque as declarações de MFA já estão incluídas no token e os requisitos de autenticação são atendidos. Portanto, o adversário obtém acesso ao ambiente. Vamos detalhar o cenário, a detecção e a mitigação mais adiante neste documento.
Para encontrar mais informações sobre tokens de segurança do Entra ID, consulte os seguintes recursos do Microsoft Learn:
O capítulo 'Replay of Primary Refresh (PRT) and other issued tokens from an Azure AD joined device' do Entra ID Attack & Defense Playbook esclarece o replay de PRT, token de acesso e token de atualização:
Neste capítulo, estamos focando no tipo de ataque Adversary-in-the-Middle (AiTM), em que o adversário intercepta o cookie de sessão da vítima e depois o reproduz para acessar o serviço de entrada.
Cibercriminosos atualmente usam técnicas de phishing AiTM para contornar as proteções de autenticação multifator (MFA) em escala. Essas técnicas avançadas foram democratizadas e ampliadas por meio do modelo econômico de cibercrime phishing-como-serviço (PhaaS), que gerou várias ofertas de serviços desde 2021.
Hoje em dia, o número de plataformas PhaaS com capacidade AiTM continuou a crescer ao longo de 2023-2024, com serviços existentes adicionando capacidades AiTM às suas plataformas e serviços recém-criados incorporando técnicas de phishing AiTM nativamente. Embora as formas tradicionais de phishing de credenciais ainda existam, o número de ataques de phishing AiTM excede aqueles sem essa capacidade.
O objetivo final do phishing AiTM é roubar credenciais de usuário e cookies de sessão. Os navegadores armazenam cookies de sessão para permitir que os usuários acessem serviços sem ter que se autenticar repetidamente. O phishing AiTM visa cookies de sessão e credenciais para contornar as proteções tradicionais de MFA.
Mais informações sobre PhaaS:
Todo serviço web moderno implementa uma sessão com o usuário após a autenticação bem-sucedida, para que o usuário não precise se autenticar em todas as novas páginas que visitar. Essa funcionalidade de sessão é habilitada por um cookie de sessão emitido por um serviço de autenticação após a autenticação inicial. O cookie de sessão serve como prova para o servidor web de que o usuário foi autenticado e mantém uma sessão ativa no site.
Em um ataque de phishing AiTM, um atacante intercepta o cookie de sessão do usuário alvo e posteriormente o reproduz para acessar o serviço de login. Como o cookie demonstra que a verificação de MFA já foi concluída (declaração incluída no token), ele satisfaz o requisito de MFA, permitindo que o atacante contorne as proteções de MFA e obtenha acesso à conta de usuário comprometida.
No phishing AiTM por meio de proxy reverso, o proxy é implantado entre um usuário e o site ou aplicativo legítimo que o usuário deseja visitar (como portais de login da Microsoft ou LinkedIn). O proxy reverso encaminha as solicitações do usuário ao serviço real e intercepta as respostas. Esse tipo de configuração possibilita que o adversário roube e intercepte a senha do alvo e o cookie de sessão que comprova sua sessão ativa e autenticada com o site.
Os kits de phishing que têm sido populares entre os adversários são: EvilGinx, Modlishka, Muraena e "Office 365" (EvilProxy). Esses kits de phishing permitem que os adversários realizem ataques de phishing AiTM usando servidores de proxy reverso.
Nota lateral: Em muitas campanhas, o aplicativo alvo nos logs do Entra ID tem sido o OfficeHome.
Diagrama de ataque de phishing AiTM por meio de proxy reverso (figura inicial dos relatórios de Inteligência de Ameaças do Microsoft Defender XDR).
Outro método de AiTM é chamado de 'phishing AiTM por meio de retransmissão síncrona'. Nesse tipo de ataque, uma cópia ou imitação de uma página de login é apresentada ao alvo, como ocorre em ataques de phishing tradicionais. Se um usuário fornecer suas credenciais nessa página, elas serão armazenadas em um servidor controlado pelo atacante, onde a instância do kit de phishing, incluindo seu painel administrativo, está instalada. Basicamente, isso significa que a entrada do usuário está sendo roubada, incluindo credenciais de login, códigos de autenticação de dois fatores (MFA) e cookies de sessão.
Os servidores de retransmissão são normalmente fornecidos e controlados pelo grupo de atores por trás do desenvolvimento e pelos stakeholders responsáveis pela plataforma PhaaS. Um exemplo desse tipo de grupo é o Storm-1295, que está por trás da plataforma Greatness PhaaS, de acordo com os relatórios de Inteligência de Ameaças da Microsoft.
Diagrama de phishing AiTM por meio de retransmissão síncrona (figura inicial dos relatórios de Inteligência de Ameaças do Microsoft Defender XDR).
Atualizar ou adicionar conteúdo (Pull Request): Como já mencionamos, gostamos de ter um documento vivo, conduzido pela comunidade Entra! Compartilhe seus resultados e percepções como parte deste projeto! Envie um pull request para adicionar seu conteúdo a este projeto.
Issues/Conteúdo desatualizado: Os recursos de proteção ou as ferramentas mudam continuamente. Atualize o conteúdo desatualizado (como parte de um pull request) ou crie uma issue para apontá-lo.
Revisor: Também procuramos especialistas que queiram revisar ou discutir o conteúdo existente ou novo antes da publicação!
Feedback: Sinta-se à vontade para sugerir cenários de ataque/defesa que possam ser interessantes para a comunidade. Nós os adicionaremos ao backlog e à coleção de ideias!
Este é um projeto conduzido pela comunidade e não uma solução ou produto oficial. O código ou qualquer outra amostra de consulta é fornecido "AS IT IS", sem garantia de qualquer tipo, expressa ou implícita, incluindo, mas não se limitando às garantias implícitas de comercialização e/ou adequação a uma finalidade específica. Esta amostra não é suportada por nenhum programa ou serviço de suporte. Nós também renunciamos a todas as garantias implícitas, incluindo, sem limitação, quaisquer garantias implícitas de comercialização ou adequação a uma finalidade específica. Todo o risco decorrente do uso ou desempenho da amostra e da documentação permanece com você. Em nenhum caso nós, seus autores ou qualquer outra pessoa envolvida na criação, produção ou entrega do script seremos responsáveis por quaisquer danos (incluindo, sem limitação, danos por perda de lucros comerciais, interrupção de negócios, perda de informações comerciais ou outras perdas pecuniárias) decorrentes do uso ou da incapacidade de usar a amostra ou a documentação, mesmo que a Microsoft tenha sido informada da possibilidade de tais danos.
 Sami Lamppu 💬 📖 |  Thomas Naunheim 💬 📖 |
 Joosua Santasalo 💬 📖 |  Markus Pitkäranta 💬 📖 |  Christopher Brumm 💬 📖 |  Fabian Bader 💬 📖 |  Nestori Syynimaa 💬 📖 |  Robbe Van den Daele 💬 📖 |
