Contratar um teste de invasão em Microsoft 365 e Azure deixou de ser iniciativa pontual e passou a integrar o orçamento de segurança de organizações que tratam dados sensíveis. O motivo é prático: quanto mais a operação migra para a nuvem da Microsoft, mais o tenant concentra identidades, caixas de email, documentos, segredos e cargas de trabalho críticas — e mais valioso ele se torna como alvo. Um erro de configuração de permissão ou uma política de acesso mal ajustada pode abrir caminho para movimentação lateral e elevação de privilégio sem que nenhuma senha seja quebrada.
Para decisores de TI, segurança da informação e compliance, a dúvida raramente é "se" testar, mas "como" testar dentro das regras. A Microsoft permite avaliar seus próprios recursos, mas proíbe ações que atinjam a infraestrutura compartilhada, e essa fronteira precisa estar clara antes do primeiro pacote ser enviado. Somam-se a isso a escolha de metodologia, a definição de escopo entre Microsoft 365 e Azure e a necessidade de transformar os achados em evidência utilizável em auditoria.
Este artigo percorre o processo completo: o que a Microsoft autoriza e restringe, as diferenças de superfície de ataque entre os dois ambientes, as fases do teste e o que esperar dos entregáveis — para que a contratação seja técnica, documentada e alinhada ao risco real do negócio.
O que é um teste de invasão em Microsoft 365 e Azure
Um teste de invasão em Microsoft 365 e Azure é uma avaliação controlada e autorizada que simula as técnicas, ferramentas e fluxos de ataque que um invasor real usaria contra o tenant Microsoft de uma organização. O objetivo não é "derrubar" o ambiente, mas identificar caminhos de exploração viáveis: credenciais expostas, permissões excessivas, aplicações mal configuradas, políticas de acesso frágeis e recursos do Azure acessíveis indevidamente. Diferente de um vulnerability scan automatizado, o pentest combina descoberta técnica com raciocínio humano para encadear falhas aparentemente isoladas em uma rota de comprometimento.
No contexto Microsoft, o teste cobre dois planos distintos que se comunicam: o plano de identidade e colaboração do Microsoft 365 (Entra ID, Exchange Online, SharePoint, Teams, OneDrive) e o plano de infraestrutura e aplicação do Azure (assinaturas, redes virtuais, storage accounts, VMs, Azure AD/Entra, Key Vault, funções e políticas). Um pentest bem desenhado avalia também a intersecção entre eles — por exemplo, uma identidade de usuário comum que, por herança de grupo ou role assignment, consegue elevar privilégio sobre uma assinatura inteira.
Para empresas que operam ambientes financeiros ou processam transações via Pix, esse tipo de teste ganha peso adicional. Um pentest em Microsoft 365 e Azure, quando documentado adequadamente, serve como evidência de conformidade em auditorias e processos de certificação ISO 27001.
O que a Microsoft permite (e o que proíbe) em testes de penetração
A Microsoft adota uma postura específica para testes de segurança em seus serviços de nuvem: ela não exige autorização prévia para pentest na maioria dos recursos do Azure e do Microsoft 365, mas impõe regras rígidas sobre o que pode ser executado. A política oficial, publicada nas Regras de Engajamento para Testes de Penetração da Microsoft, estabelece que determinadas atividades são proibidas por afetarem a infraestrutura compartilhada de outros clientes ou a estabilidade do serviço.
O princípio central é simples: você pode atacar seus próprios recursos e identidades, mas não pode atacar a plataforma em si. Testes que visem a infraestrutura da Microsoft, que tentem sair do escopo do seu tenant ou que simulem ataques volumétricos contra serviços compartilhados configuram violação dos termos de uso e podem gerar suspensão da conta ou ação legal. A responsabilidade de conhecer e respeitar esses limites é da organização contratante e do fornecedor de pentest.
Regras de engajamento e notificação de testes
Para a maioria dos testes em Azure e Microsoft 365, não é necessário notificar a Microsoft com antecedência. A empresa entende que pentests autorizados pelo próprio cliente fazem parte da operação normal de segurança. No entanto, há exceções: atividades que geram tráfego anômalo em larga escala, testes de resiliência que possam impactar o serviço e qualquer ação que envolva simulação de ataque contra a infraestrutura da Microsoft exigem comunicação prévia e, em muitos casos, aprovação formal.
As regras de engajamento também determinam que o teste deve se limitar a assinaturas, tenants e recursos sob controle direto do cliente. Testar a resiliência de um serviço consumido de forma compartilhada — como tentar derrubar o endpoint de login do Entra ID — é proibido. O documento da Microsoft é atualizado periodicamente e deve ser revisado no início de cada projeto, pois atividades que eram permitidas em um ano podem ser restringidas no seguinte.
Atividades de red team e simulação de DDoS
Atividades de red team — simulações realistas de adversário com objetivo de comprometer ativos específicos — seguem as mesmas regras gerais de pentest, mas com escopo mais controlado. A Microsoft permite que organizações conduzam exercícios de red team contra seus próprios ambientes Azure e Microsoft 365, desde que as ações permaneçam dentro dos limites do tenant. O que muda é a necessidade de documentação interna mais rigorosa: em setores regulados, o red team precisa estar amarrado a um cenário de ameaça aprovado pela diretoria ou pelo comitê de segurança.
Simulação de DDoS é o ponto mais restritivo. A Microsoft proíbe explicitamente que clientes gerem ataques de negação de serviço contra seus próprios recursos hospedados no Azure, mesmo que o alvo seja uma VM ou aplicação própria. O motivo é técnico: tráfego volumétrico direcionado a um recurso do Azure pode saturar a infraestrutura subjacente e afetar outros tenants. Para testar resiliência a DDoS, a orientação oficial é usar o Azure DDoS Protection em conjunto com cenários de simulação aprovados pela Microsoft, nunca executar um ataque real.
Diferenças entre pentest em Microsoft 365 e pentest em Azure
Embora compartilhem o mesmo diretório de identidades (Microsoft Entra ID, antigo Azure AD), o Microsoft 365 e o Azure apresentam superfícies de ataque com naturezas distintas. O Microsoft 365 é, essencialmente, um conjunto de aplicações SaaS: o atacante mira usuários, caixas de email, documentos, permissões de colaboração e configurações de tenant. O Azure é uma plataforma IaaS/PaaS: o atacante mira assinaturas, APIs de gerenciamento, redes, segredos, contas de serviço e recursos de computação.
Essa diferença muda a metodologia, as ferramentas e o perfil do profissional. Um pentest focado em Microsoft 365 exige profundo conhecimento de Exchange Online, SharePoint Online, Teams, políticas de DLP, regras de transporte de email e controles de acesso condicional. Um pentest de Azure exige domínio de ARM (Azure Resource Manager), RBAC, Managed Identities, Key Vault, rede virtual, containers e serverless. Projetos maduros tratam os dois como um único ambiente de identidade, mas com planos de teste separados.
Superfície de ataque no Microsoft 365: identidade, email e colaboração
No Microsoft 365, a identidade é o perímetro. O teste começa pelo inventário de usuários, grupos, papéis administrativos e políticas de autenticação: quem tem MFA ativo, quem está excluído, quais contas de serviço existem, quais usuários possuem acesso administrativo permanente e se há contas convidadas (guest users) com permissões excessivas. Um único usuário com papel de Global Administrator sem MFA representa, na prática, uma rota direta para o comprometimento total do tenant.
A camada de email e colaboração é o segundo vetor mais explorado. Testes de phishing simulado, regras de encaminhamento maliciosas no Exchange Online, permissões de caixa postal delegadas, compartilhamento externo de sites do SharePoint e links anônimos do OneDrive são alvos clássicos. O pentest avalia ainda se há aplicações OAuth de terceiros com consentimento amplo — um vetor frequentemente ignorado que permite a um atacante manter acesso persistente sem tocar em senhas.
Superfície de ataque no Azure: assinaturas, recursos e plano de controle
No Azure, o plano de controle (ARM) é o alvo de maior valor. O pentest mapeia a hierarquia de management groups, assinaturas, resource groups e recursos, e avalia quem tem permissão de escrita, leitura ou exclusão em cada camada. Um usuário com papel de Contributor em uma assinatura pode criar VMs, alterar redes e acessar dados via extensões — sem nunca ter recebido uma senha de servidor. A enumeração de role assignments e a detecção de permissões herdadas são etapas críticas.
O plano de dados também é testado: storage accounts com acesso anônimo ou chaves expostas, Key Vault com políticas de acesso excessivamente permissivas, VMs com portas de gerenciamento abertas para a internet, bancos de dados SQL sem firewall adequado e AKS com API pública. Cada recurso do Azure tem seu próprio modelo de autenticação e autorização, e o pentest precisa cobrir essa heterogeneidade sem cair na armadilha de testar apenas o que é mais visível.
Metodologia e fases de um pentest em ambiente Microsoft
Um teste de invasão em Microsoft 365 e Azure segue, em linhas gerais, a mesma estrutura de um pentest tradicional: reconhecimento, enumeração, exploração, pós-exploração e relatório. O que muda é a natureza dos alvos — não há "máquinas" para comprometer no Microsoft 365, e no Azure a exploração frequentemente se dá por abuso de configuração e de APIs, não por exploits de memória. A metodologia precisa ser adaptada para o modelo de responsabilidade compartilhada da nuvem.
O escopo define quais tenants, assinaturas, usuários e recursos serão testados, além das regras de exclusão (contas de produção sensíveis, por exemplo). O teste pode ser black box (sem credenciais), gray box (com credenciais de usuário comum) ou white box (com acesso total à documentação e configuração). Em ambientes Microsoft, o gray box é o formato mais comum e produtivo: ele simula o cenário realista de um usuário interno comprometido ou de um atacante que obteve credenciais válidas.
Reconhecimento e enumeração de tenant e assinaturas
O reconhecimento começa pela descoberta de informações públicas: domínios associados ao tenant, endpoints de login, configurações de autenticação expostas no endpoint openid-configuration do Entra ID, registros DNS e certificados. O pentester tenta identificar se o tenant aceita autenticação legada, quais métodos de MFA estão habilitados e se há sincronização com Active Directory on-premises — o que abre a porta para ataques como pass-the-hash se a floresta local estiver comprometida.
No Azure, a enumeração foca em identificar todas as assinaturas acessíveis, a estrutura de resource groups e os recursos expostos publicamente. Ferramentas de enumeração consultam APIs públicas do Azure para mapear storage accounts, VMs, web apps e bancos de dados sem precisar de credenciais internas. O objetivo é construir o mapa completo da superfície antes de qualquer tentativa de exploração.
Testes de identidade com Microsoft Entra ID
O Entra ID é o coração da segurança Microsoft, e por isso recebe atenção desproporcional no pentest. A fase de identidade testa: políticas de senha e bloqueio de conta, presença e bypass de MFA, permissões de aplicações OAuth, papéis administrativos, grupos dinâmicos com regras manipuláveis, convites de guest user e sincronização de hashes com o AD local. Um teste comum é verificar se um usuário comum consegue registrar uma aplicação no Entra ID e, a partir dela, obter tokens com permissões elevadas.
Outro vetor crítico é o abuso de consentimento de aplicações. Se o tenant permite que usuários comuns consintam com aplicações de terceiros, um atacante pode criar um app malicioso que solicita permissões de leitura de email ou de escrita em arquivos, induzir a vítima a consentir e manter acesso persistente sem credenciais. O pentest documenta quais aplicações já possuem consentimento no tenant, quem concedeu e quais permissões foram dadas.
Exploração de configurações incorretas e movimentação lateral
A exploração em ambientes Microsoft raramente envolve exploits de software. O vetor dominante é a configuração incorreta: um storage account com chave de acesso em repositório público, uma VM com identidade gerenciada com permissão excessiva, um Key Vault acessível por qualquer usuário do tenant, uma política de acesso condicional com exceção ampla demais. O pentester encadeia essas falhas para demonstrar o impacto real: de um usuário comum a leitura de dados sensíveis ou a administração da assinatura.
A movimentação lateral no Azure segue o fluxo de identidades gerenciadas e role assignments. Uma VM comprometida pode ter uma Managed Identity com papel de Contributor sobre a assinatura; a partir dela, o atacante cria novos recursos, acessa segredos e pivoteia para outros serviços. No Microsoft 365, a movimentação lateral se dá por delegação de caixa postal, compartilhamento de sites e abuso de aplicações OAuth já consentidas. O relatório final precisa mostrar cada salto lateral como um passo encadeado, não como falhas isoladas.
Ferramentas usadas em testes de invasão em Microsoft 365 e Azure
O ecossistema de ferramentas para pentest em ambientes Microsoft evoluiu muito nos últimos anos. Hoje há opções maduras, muitas delas open source, específicas para Entra ID, Exchange Online, SharePoint e Azure Resource Manager. A escolha da ferramenta depende da fase do teste e do tipo de credencial disponível. Abaixo, as principais categorias e exemplos concretos:
- Reconhecimento de tenant: AADInternals, AzureHound, MicroBurst
- Enumeração de identidade: AzureHound (BloodHound para Azure), ROADtools, Stormspotter
- Testes de autenticação: MSOLSpray, o365spray para password spraying
- Abuso de aplicações OAuth: TokenTactics, GraphRunner
- Exploração de recursos Azure: MicroBurst, Azucar, ScoutSuite, Prowler
- Phishing e simulação de adversário: Evilginx2, GoPhish, frameworks de red team como Caldera
Ferramentas de auditoria contínua como ScoutSuite e Prowler são usadas tanto em pentest quanto em monitoramento pós-teste, pois geram um baseline de configuração que pode ser comparado ao longo do tempo. Já ferramentas como AzureHound e Stormspotter mapeiam relações de privilégio e rotas de ataque no Entra ID e no Azure, funcionando como um "mapa de estradas" para o pentester e, depois, para a equipe de defesa. A combinação de ferramentas automatizadas com análise manual é o que separa um pentest superficial de uma avaliação com valor real para a organização.
Principais falhas encontradas em ambientes Microsoft 365 e Azure
Certos padrões de falha aparecem com frequência consistente em tenants Microsoft de empresas de médio e grande porte. Não são vulnerabilidades de software da Microsoft, mas decisões de configuração tomadas ao longo do tempo — muitas vezes por equipes diferentes, sem documentação centralizada. Conhecer esses padrões ajuda a priorizar o que corrigir mesmo antes do pentest começar:
- MFA ausente em contas administrativas: o vetor mais comum de comprometimento de tenant
- Perfis administrativos permanentes: usuários com Global Admin sem uso de PIM (Privileged Identity Management)
- Autenticação legada habilitada: protocolos como IMAP, POP3 e SMTP auth permitindo bypass de MFA
- Consentimento de aplicação irrestrito: usuários comuns podendo aprovar apps OAuth com permissões amplas
- Storage accounts com chaves expostas ou acesso anônimo: dados sensíveis acessíveis sem autenticação
- Role assignments excessivos no Azure: Contributor ou Owner concedidos a grupos inteiros ou contas de serviço
- Key Vault com políticas permissivas: qualquer usuário do tenant lendo segredos de produção
- Falta de segregação entre ambientes: dev, staging e produção na mesma assinatura sem controles de rede
Um padrão especialmente perigoso em ambientes financeiros é a combinação de autenticação legada habilitada com contas de serviço que possuem acesso a dados de transações. Nesse cenário, um ataque de password spraying contra o endpoint legado pode obter acesso a caixas postais ou arquivos com dados de clientes sem nunca enfrentar o MFA. O pentest documenta essas cadeias de falha com evidências técnicas e estimativa de impacto, permitindo que a correção seja priorizada por risco real e não por gravidade teórica de cada item isolado.
Como escolher e contratar um fornecedor de pentest para Microsoft 365 e Azure
A contratação de um fornecedor de pentest para ambientes Microsoft exige critérios diferentes dos usados para pentest de infraestrutura tradicional. O fornecedor precisa demonstrar conhecimento específico de Entra ID, Exchange Online, SharePoint, ARM, RBAC e das regras de engajamento da Microsoft — não apenas experiência genérica com ferramentas como Metasploit ou Nessus. A pergunta-chave é: o fornecedor entende o modelo de responsabilidade compartilhada e sabe testar identidade em nuvem?
Critérios práticos para avaliar fornecedores:
- Metodologia documentada: o fornecedor deve apresentar um framework claro, alinhado a PTES, OWASP ou MITRE ATT&CK Cloud
- Experiência comprovada em Entra ID: capacidade de testar políticas de acesso condicional, MFA, PIM e aplicações OAuth
- Conformidade com as regras da Microsoft: conhecimento explícito do que é permitido e proibido, com histórico de testes sem incidentes
- Relatório acionável: entregas que priorizam achados por risco e apresentam passos de correção claros, não apenas CVEs
- Seguro e responsabilidade: cobertura de responsabilidade civil profissional para o caso de impacto não intencional
Para empresas do setor financeiro, vale verificar se o fornecedor tem familiaridade com os requisitos do Banco Central e com ambientes que processam Pix. Um pentest que não documenta adequadamente o escopo, a metodologia e os achados tem valor limitado em auditoria — e pode precisar ser refeito. O contrato deve especificar o que será testado, o que está fora de escopo, as janelas de teste e o formato do relatório final. A relação entre pentest e serviços contínuos de segurança também importa: um fornecedor que também atua com serviços gerenciados de TI com equipe certificada Microsoft consegue transformar os achados do teste em um plano de correção integrado ao monitoramento contínuo.
Do relatório à correção: como priorizar os achados
O relatório de pentest é o início do trabalho de correção, não o fim. A priorização deve seguir uma lógica de risco — probabilidade de exploração versus impacto no negócio — e não a ordem em que os achados foram descobertos. Uma falha de MFA em conta administrativa, mesmo que tecnicamente "simples", tem prioridade máxima porque é o vetor mais explorado em incidentes reais. Já uma configuração de hardening de baixo impacto pode esperar o próximo ciclo de manutenção.
Um método eficaz de priorização em três camadas:
- Correção imediata (0–7 dias): MFA em contas administrativas, remoção de permissões excessivas, revogação de consentimentos OAuth suspeitos, fechamento de acesso anônimo a storage accounts
- Correção planejada (7–30 dias): implementação de PIM, eliminação de autenticação legada, segregação de ambientes, revisão de políticas de Key Vault
- Correção estrutural (30–90 dias): redesenho de role assignments, implementação de acesso condicional granular, adoção de monitoramento contínuo de configuração
Cada achado do relatório deve ser vinculado a um responsável, um prazo e uma evidência de correção. Ferramentas como ScoutSuite e Prowler podem ser reexecutadas após a correção para validar objetivamente que a falha foi eliminada — um processo que transforma o pentest de evento pontual em ciclo de melhoria contínua. Para organizações que já operam com monitoramento de backup em serviços gerenciados, a integração dos achados ao monitoramento de segurança existente reduz o tempo entre detecção e correção.
