150 operações destrutivas em 35 minutos

A Microsoft publicou uma análise de uma intrusão na nuvem em que um atacante que segue como Storm-3168 tentou mais de 150 operações destrutivas ou de recolha de credenciais dentro de um inquilino Azure em 35 minutos. A fase de eliminação durou cerca de sete minutos e incluiu mais de 100 tentativas de apagar contas de armazenamento.

A Sysdig, que documentou o grupo pela primeira vez em julho, segue-o como JADEPUFFER e descreve-o como a primeira operação de ransomware documentada conduzida por um modelo de linguagem.

Os alvos foram contas de armazenamento Azure, onde a maioria das eliminações teve êxito; Key Vaults; bases de dados SQL, onde as tentativas falharam por as versões de API usadas não serem suportadas; Function Apps e planos de App Service; e os bloqueios de proteção do Azure Site Recovery e do Azure Backup — isto é, os controlos que tornam a restauração possível.

A entrada foi um tíquete público do GitHub

O ponto de entrada é o que os defensores deviam ler duas vezes. A Microsoft diz que os atacantes usaram dois principais de serviço comprometidos no mesmo inquilino — as identidades não humanas que permitem a aplicações e ferramentas automatizadas autenticarem-se no Azure.

Uma chave esquecida na fechadura de uma porta de madeira
As credenciais tinham sido expostas em texto simples num tíquete público do GitHub. Foto ilustrativa. Alexey Demidov · pexels · Pexels License

As suas credenciais, escreve a Microsoft, «tinham sido previamente expostas em texto simples num tíquete público do GitHub». O segredo foi depois editado, mas «continuou acessível através do histórico público de edições do tíquete».

Nada disso exige IA. O que sugere orquestração é a velocidade: a cronologia da Microsoft mostra o primeiro principal de serviço a enumerar recursos durante 15,5 horas, o segundo a arrancar 90 minutos depois, uma varredura de configuração do App Service às 16 horas, depois a fase de destruição de sete minutos e uma recolha de credenciais 30 minutos mais tarde.

Sem nota de resgate

O detalhe invulgar é o que não aconteceu. A Microsoft di-lo sem rodeios: «Não observámos uma nota de resgate nem confirmámos exfiltração bem-sucedida de dados na atividade aqui descrita.»

Filas de estantes de armazenamento num grande armazém
O atacante removeu primeiro os bloqueios de cópia e recuperação. Foto ilustrativa. Engin Akyurt · pexels · Pexels License

Ainda assim, o atacante removeu primeiro os bloqueios de cópia e recuperação, que é exatamente o que faz uma operação de extorsão para que pagar seja a única saída. Ou a exigência chegou por um canal que a Microsoft não viu, ou a destruição era o objetivo.

A Microsoft enquadra o caso como exemplo de «ataques orquestrados por IA, em que agentes de ameaça podem coordenar operações complexas pós-compromisso em ambientes de nuvem com maior velocidade e escala». O seu próprio artigo não detalha que sistema de agentes o Storm-3168 usou, e a distinção merece nota: a velocidade está documentada; atribuir essa velocidade a um modelo é a caracterização que a Sysdig faz do grupo, não algo que a Microsoft demonstre neste texto.

O que fazer

As mitigações da Microsoft são pouco vistosas e na maioria anteriores aos agentes: ativar o Defender for Cloud, manter as credenciais fora de repositórios e fios de tíquetes, rodar de imediato credenciais expostas, aplicar privilégio mínimo aos principais de serviço e proteger a infraestrutura de cópias. Recomenda também as suas próprias ferramentas de defesa com agentes.

A lição transferível é mais estreita. Um segredo colado num tíquete do GitHub há dois anos sempre foi um risco. O que mudou é o pouco tempo que um defensor tem agora entre a credencial ser encontrada e as contas de armazenamento desaparecerem.