Em 29 de setembro de 2026, a equipe de resposta a incidentes da Microsoft, empresa de tecnologia dos Estados Unidos, publicou o relato de um caso de intrusão. Nele, uma única identidade comprometida alcançou repositórios, esteira de entrega e credenciais de clusters Kubernetes. O relato descreve as etapas do percurso, sem datar o incidente.
O ponto que interessa à gestão está na ligação entre sistemas confiáveis. Uma identidade com poder para editar código, alterar a definição de um pipeline e alcançar recursos de produção dá a um único comprometimento um percurso longo. A esteira de entrega existe para automatizar trabalho, e esse mesmo desenho a transforma em caminho de acesso.
A conta caiu antes de qualquer sistema
O acesso inicial veio de um processo de redefinição de senha por autoatendimento. O grupo, que a Microsoft chama de Storm-3068, assumiu a conta e registrou os próprios métodos de autenticação. Esse registro deu a ele controle total da identidade e um acesso persistente.
Para quem desenha o processo de recuperação, o relato recomenda monitorar redefinições de senha com padrão incomum. Nas contas privilegiadas, ele recomenda limitar a exposição ao autoatendimento e exigir autenticação multifator resistente a phishing. Vale conferir também se o recadastro de segundo fator exige uma segunda validação e se a devolução dos privilégios passa por alguém de fora do pedido.
O mapa estava dentro da plataforma de desenvolvimento
Com a conta em mãos, o atacante voltou o foco para o Azure DevOps. Ele usou ferramentas administrativas legítimas e scripts automatizados para enumerar repositórios, projetos, pipelines e ambientes de implantação. Ao mapear os caminhos de implantação confiáveis e os recursos conectados, ele encontrou onde ampliar o alcance.
A plataforma de desenvolvimento guarda o endereço dos ambientes, o nome das credenciais disponíveis e a regra de quem executa o quê. O relato faz o mesmo alerta: repositórios, pipelines, conexões de serviço e configurações de implantação podem dar ao atacante um roteiro do ambiente mais amplo da organização. Um inventário honesto dessa superfície muda a conversa interna sobre risco de repositório.
O pipeline buscou as credenciais
O passo seguinte usou a automação a favor do ataque. O atacante criou um pipeline malicioso para coletar credenciais de Kubernetes em escala. As permissões da conta comprometida bastaram para publicar esse pipeline, que tinha autorização para acessar mais de 50 recursos.
O relato resume o método em uma linha: o atacante usou serviços legítimos de identidade e de nuvem, sem malware e sem exploração de falha de software.
Os investigadores reconstruíram a etapa seguinte pelos registros de auditoria do Azure DevOps e pelo histórico de versões do Git. Esses registros mostraram que o atacante guardou em um repositório sete arquivos de configuração de cluster roubados, com as credenciais de acesso aos clusters visados. Para a NowCy, esse trecho justifica proteger o registro, porque ele liga a alteração na esteira ao avanço sobre a nuvem.
Leitura NowCy: a esteira é uma fronteira com regras próprias
A esteira de entrega herda a confiança das identidades que a alteram. O caso expõe esse defeito de desenho: a conta tomada já tinha permissão para publicar um pipeline com acesso a mais de 50 recursos. Na leitura Zero Trust da NowCy, a esteira é uma fronteira, com autorização própria em cada passo. Os controles que o relato recomenda sustentam esse princípio:
- aprovação obrigatória para mudanças de código, com política de proteção de branch contra alteração não autorizada;
- restrição de commit direto nas branches críticas, para que toda mudança siga o processo de revisão e aprovação;
- controle das permissões de pipeline, com limite sobre quem cria, altera e executa pipelines de build e de implantação;
- menor privilégio em identidades, plataformas de desenvolvimento e recursos de nuvem, para reduzir o impacto de uma conta comprometida.
A NowCy acrescenta a esses controles o inventário de segredos da esteira e a separação entre quem escreve a mudança e quem a libera. Cada credencial precisa aparecer ligada ao pipeline que a consome, ao ambiente de destino, ao responsável e à condição de rotação. O registro de alteração e de execução precisa ficar fora do alcance de quem administra a própria definição, no limite que a plataforma permitir.
Um teste de fronteira por pipeline
Escolha o pipeline que alcança o ambiente mais sensível e responda quatro perguntas com evidência na mão. Quem altera a definição? Quem libera essa alteração? Quais credenciais e ambientes a execução atinge? O registro permite reconstruir mudança, liberação e execução?
Uma identidade que responde a mais de uma dessas perguntas indica uma ligação para revisar. Quando a separação já existe no papel, o próximo passo é testá-la com uma credencial válida usada fora do contexto esperado.
Fontes e limites
A apuração vem do relato de resposta a incidente publicado em 29 de setembro de 2026.
A fonte afirma o percurso entre identidade, plataforma de desenvolvimento, pipeline e credenciais de Kubernetes, além dos controles recomendados. Ela descreve um caso atendido pela equipe de resposta e não demonstra que todo ambiente de esteira tenha a mesma exposição. São leitura da NowCy a esteira tratada como fronteira, a separação entre autoria e liberação, o inventário de segredos e as perguntas de revisão acima. Esses pontos pedem ajuste às plataformas e aos processos de cada empresa.