Ataque SunBurst abusou de identidades e permissões no Azure AD para exfiltrar dados

A fase em nuvem da campanha usou aplicações e service principals existentes para obter tokens OAuth, ampliar permissões no Microsoft Graph e acessar usuários e e-mails.

Componente	Ambientes Azure AD com aplicações ou service principals existentes e permissões do Microsoft Graph.
Vetor	Após obter acesso administrativo no Azure AD, o operador adiciona credenciais a uma aplicação ou service principal já existente e solicita consentimento administrativo para permissões adicionais.
Impacto	Uso de tokens OAuth para representar a aplicação, consultar dados do tenant e acessar informações de usuários e e-mails dentro do escopo concedido.
Prioridade	Auditar alterações em credenciais de aplicações, concessões de consentimento administrativo e permissões de alto privilégio no Microsoft Graph.
Artefatos	ObjectId, ApplicationId, tenantId, segredo da aplicação, tokens OAuth e permissões como User.ReadWrite.All e Mail.ReadWrite.
Técnicas	Descoberta, acesso a credenciais, elevação de privilégio, evasão de defesa, movimentação lateral e exfiltração em ambiente de nuvem.

Resumo técnico

A fase em nuvem associada ao ataque SunBurst descreve um fluxo pós-comprometimento centrado em identidade, aplicações registradas e permissões delegadas por administrador no Azure AD. O ponto de partida não é uma exploração direta de uma API pública, mas a posse de privilégio administrativo no ambiente de identidade. Com esse nível de acesso, o operador consegue manipular objetos já confiáveis pelo tenant, acrescentar novas credenciais e transformar uma aplicação existente em canal de autenticação para chamadas posteriores ao Microsoft Graph.

O fluxo técnico começa depois do acesso inicial ao ambiente de nuvem. O material recebido indica que a campanha, em seu estágio anterior, usou tokens SAML forjados e registros ilegítimos de relações de confiança SAML para representar usuários com credenciais administrativas. A partir daí, o foco se desloca para o Azure AD: enumerar aplicações e service principals, escolher um objeto com tráfego esperado, adicionar credenciais, ampliar permissões de API, aprovar consentimento administrativo e obter tokens OAuth para operar como a aplicação escolhida.

O valor operacional dessa abordagem está na mistura entre privilégio e aparência legítima. Uma aplicação com padrão de uso intenso, como um aplicativo de arquivamento de e-mail citado no contexto como exemplo hipotético, gera atividade compatível com consultas frequentes a caixas postais e dados de usuários. Ao usar esse tipo de identidade de aplicação, o operador reduz a dependência de sessões interativas de usuário e passa a executar chamadas de API com permissões de aplicação, que podem ter alcance amplo dentro do tenant quando consentidas por administrador.

Fluxo técnico

Depois de obter acesso administrativo ao Azure AD, o operador enumera aplicações existentes e service principals. Essa etapa de descoberta busca objetos que já façam parte do funcionamento normal do ambiente. O contexto descreve preferência por aplicações com tráfego alto, pois elas oferecem melhor cobertura para ações posteriores. Em vez de criar um novo aplicativo claramente suspeito, o fluxo favorece a reutilização de um objeto conhecido, extraindo identificadores como ObjectId e ApplicationId para orientar as próximas operações.

Com o alvo definido, o operador adiciona novas credenciais à aplicação ou ao service principal associado. Essa alteração cria um segredo utilizável para autenticação perante o Azure AD em nome da aplicação. O risco central está no fato de que a credencial adicionada não precisa corresponder a uma conta humana comprometida; ela passa a ser um material de autenticação próprio do objeto de aplicação. Se o ambiente não monitora alterações em credenciais de aplicações, a persistência pode permanecer pouco visível em comparação com logins interativos anômalos.

A etapa seguinte é a ampliação de permissões no Microsoft Graph. O contexto cita a enumeração das permissões disponíveis e a adição de User.ReadWrite.All, seguida pela inclusão de Mail.ReadWrite. Essas permissões são sensíveis porque ampliam o alcance de leitura e escrita sobre objetos de usuário e e-mail. A concessão de algumas permissões exige consentimento administrativo. Como o operador já possui privilégio administrativo, ele consegue acionar e aprovar o fluxo de consentimento, convertendo controle sobre o tenant em capacidade de API persistente para a aplicação.

Após credenciais e permissões estarem estabelecidas, o operador solicita um token de acesso OAuth. A requisição usa identificadores do tenant e da aplicação, além do segredo criado anteriormente. O token resultante permite chamadas autenticadas ao Microsoft Graph com a identidade da aplicação, não com uma sessão normal de usuário. O contexto aponta que esse token viabiliza movimentação lateral, representação da aplicação e execução de ações em seu nome, além de contribuir para ocultar a atividade dentro de padrões esperados do aplicativo escolhido.

Na etapa final, as APIs são chamadas com o token de acesso e com as permissões atribuídas. O impacto descrito inclui a exfiltração de todos os usuários do tenant e de e-mails relacionados a um usuário específico. Esse detalhe delimita o impacto confirmado no contexto: acesso a dados de diretório e mensagens por meio do Microsoft Graph, condicionado às permissões concedidas à aplicação. Não há necessidade de inferir exploração de vulnerabilidade remota ou implantação de malware nesse estágio específico; o núcleo do ataque é abuso de identidade, autorização e consentimento em nuvem.

Superfície afetada

A superfície de risco envolve tenants Azure AD nos quais contas administrativas, relações de confiança SAML, aplicações registradas e service principals possam ser manipulados por um operador já autenticado com privilégio elevado. A exposição não depende apenas de usuários finais: objetos não humanos, como aplicações corporativas e integrações de e-mail, tornam-se ativos críticos porque podem receber credenciais adicionais e permissões de aplicação no Microsoft Graph. Ambientes que concedem privilégios amplos a poucas contas administrativas ou que mantêm consentimento administrativo pouco supervisionado aumentam o alcance desse tipo de fluxo.

Aplicações de alto tráfego são especialmente sensíveis. Um serviço usado para arquivamento de e-mail, sincronização, automação administrativa ou integração com dados de diretório pode gerar chamadas frequentes sem acionar suspeita imediata. Se esse objeto receber Mail.ReadWrite ou User.ReadWrite.All, o escopo de ações possíveis passa a incluir leitura e alteração de e-mails ou objetos de usuário, conforme as permissões aprovadas. O problema defensivo é que a atividade aparece como originada de um componente legítimo do tenant, ainda que a credencial usada tenha sido introduzida pelo operador.

• Tenants Azure AD com contas administrativas comprometidas ou relações SAML abusadas.
• Aplicações registradas e service principals existentes que possam receber novos segredos.
• Permissões de alto privilégio do Microsoft Graph, incluindo User.ReadWrite.All e Mail.ReadWrite.
• Fluxos de consentimento administrativo aprovados sem revisão independente.
• Aplicações com tráfego frequente, especialmente integrações ligadas a e-mail e diretório.

Hunting e telemetria

A investigação deve priorizar eventos de identidade e autorização, não apenas alertas tradicionais de endpoint. O primeiro conjunto de sinais envolve enumeração e alteração de aplicações: listagem incomum de aplicações e service principals, adição de credenciais a objetos existentes, criação de segredos fora de janelas de manutenção e mudanças feitas por contas administrativas que não costumam operar esse tipo de objeto. Como o fluxo depende de credenciais anexadas a aplicações, registros de atualização de credenciais são evidências centrais para reconstruir a linha do tempo.

O segundo conjunto de sinais envolve concessões de permissão e consentimento administrativo. A adição de permissões do Microsoft Graph com amplo escopo, especialmente sobre usuários e e-mails, deve ser tratada como evento de alto risco quando não estiver associada a mudança planejada. O contexto mostra que uma falha inicial por falta de consentimento administrativo pode ser seguida por aprovação feita pelo próprio operador com privilégio. Por isso, a análise precisa correlacionar tentativa de permissão, aprovação de consentimento e uso subsequente do token, em vez de olhar cada evento isoladamente.

A telemetria de uso de API deve procurar chamadas compatíveis com extração em massa ou acesso anômalo por identidade de aplicação. Consultas para listar usuários do tenant, acesso a mensagens de caixas específicas e aumento súbito de volume em uma aplicação já existente são sinais úteis. O ponto defensivo não é bloquear toda aplicação que usa Microsoft Graph, mas estabelecer uma linha de base por aplicação: permissões esperadas, horários de uso, contas administradoras que mantêm o objeto, origem das alterações e padrão normal de chamadas.

• Adição recente de segredo ou credencial em aplicação ou service principal existente.
• Concessão de consentimento administrativo para permissões amplas do Microsoft Graph.
• Inclusão de User.ReadWrite.All ou Mail.ReadWrite sem mudança aprovada.
• Token OAuth emitido para aplicação logo após alteração de credencial ou permissão.
• Chamadas de API para listar usuários do tenant ou acessar e-mails com volume fora da linha de base.
• Atividade administrativa em Azure AD após uso de tokens SAML ou alteração de relações de confiança.

Mitigação

A resposta deve começar pela contenção de identidade. Contas administrativas envolvidas em alterações suspeitas precisam ter sessões revogadas e credenciais revisadas. Em paralelo, aplicações e service principals modificados devem ser avaliados para identificar novos segredos, certificados ou permissões adicionadas durante a janela do incidente. Quando uma credencial não puder ser vinculada a uma mudança legítima, ela deve ser removida e substituída por material controlado, com validação de impacto nas integrações dependentes.

A revisão de consentimento administrativo é essencial. Permissões do Microsoft Graph de grande alcance devem ter justificativa operacional, proprietário responsável e data de aprovação. Em ambientes maduros, a aprovação de consentimento para permissões sensíveis deve exigir revisão separada da conta que solicitou a mudança. Esse controle reduz a chance de um único privilégio administrativo comprometido ser suficiente para transformar uma aplicação legítima em canal de exfiltração.

A validação pós-contenção precisa cobrir logs de API e dados acessados. O contexto confirma acesso potencial a usuários do tenant e e-mails de usuários específicos, portanto a análise deve determinar quais chamadas foram executadas com os tokens emitidos para a aplicação. A rotação de segredos, a remoção de permissões excessivas e a auditoria de service principals devem ser acompanhadas de monitoramento reforçado para novas concessões de consentimento e novas credenciais em objetos de aplicação.

• Revogar sessões e revisar credenciais de contas administrativas associadas às mudanças.
• Remover segredos adicionados a aplicações ou service principals sem justificativa documentada.
• Revisar permissões do Microsoft Graph e retirar escopos que não sejam necessários ao funcionamento da aplicação.
• Auditar aprovações de consentimento administrativo e exigir validação independente para permissões sensíveis.
• Correlacionar emissão de tokens OAuth com chamadas ao Microsoft Graph durante a janela investigada.
• Criar alertas para novas credenciais em aplicações existentes e para concessões de User.ReadWrite.All ou Mail.ReadWrite.