Uma campanha de ciberespionagem mostra como o intervalo entre a divulgação pública de uma vulnerabilidade e sua utilização em ataques reais está ficando cada vez menor.
Pesquisadores da Acronis Threat Research Unit identificaram um grupo rastreado como Red Heron explorando a vulnerabilidade crítica CVE-2026-60004 contra servidores Gitea expostos à internet.
Segundo a investigação, o grupo examinou 1.386 instâncias do Gitea distribuídas por sete países e manteve separadamente uma base com 477 sistemas localizados em Taiwan. A atividade resultou em 13 organizações confirmadamente comprometidas em seis países.
As vítimas confirmadas estavam no Canadá, Argentina, Taiwan, Estados Unidos, Qatar e Sri Lanka, distribuídas da seguinte maneira: quatro organizações em Taiwan, quatro nos Estados Unidos, duas no Canadá e uma em cada um dos outros três países.
Mas o número de organizações invadidas conta apenas parte da história.
Em alguns ambientes, os atacantes não pararam no servidor Gitea. A investigação encontrou evidências de roubo de código-fonte, coleta de credenciais, implantação de mecanismos de persistência e movimentação lateral pela infraestrutura interna.
Em um dos casos, o comprometimento avançou até proporcionar acesso administrativo root a um cluster Proxmox formado por três nós.
Isso transforma o episódio em algo maior do que uma vulnerabilidade em uma plataforma de desenvolvimento.
É um exemplo de como comprometer o lugar onde uma empresa guarda seu código pode abrir caminho para comprometer muito mais.
O que é o Gitea?
O Gitea é uma plataforma open source de hospedagem e gerenciamento de repositórios Git.
Em termos simplificados, permite que uma organização mantenha uma infraestrutura semelhante à oferecida por serviços como GitHub ou GitLab, mas hospedada em seus próprios servidores.
Essa característica é atraente para empresas que desejam maior controle sobre código, dados e infraestrutura.
Também torna esses servidores extremamente interessantes para atacantes.
Um ambiente Gitea corporativo pode armazenar muito mais do que arquivos de programação.
Repositórios podem conter configurações.
Scripts de implantação.
Documentação interna.
Histórico de desenvolvimento.
Referências a servidores.
Tokens.
Chaves.
Credenciais inseridas acidentalmente.
Informações sobre infraestrutura.
Um invasor que consiga comprometer esse ambiente pode obter uma espécie de mapa técnico da organização.
A porta de entrada foi a CVE-2026-60004
A campanha explorou a CVE-2026-60004, vulnerabilidade crítica de execução remota de código no Gitea.
O problema havia sido divulgado publicamente em julho.
Acronis afirma que, poucos dias depois da divulgação, o Red Heron já havia transformado um código de prova de conceito disponível publicamente em uma estrutura automatizada de exploração escrita em Python.
A ferramenta recebeu o nome exp_enhanced.py.
A partir de 29 de julho de 2026, o framework já era capaz de automatizar diferentes etapas do ataque.
Isso incluía registrar contas em servidores vulneráveis, explorar a falha, copiar repositórios e remover determinados vestígios da atividade.
Ou seja, o atacante não precisava realizar manualmente cada invasão.
A exploração foi industrializada.
De prova de conceito para arma em poucos dias
Esse detalhe é particularmente relevante para equipes de segurança.
Quando uma vulnerabilidade é divulgada, normalmente ocorre uma sequência previsível.
O fabricante publica uma correção.
Pesquisadores analisam a falha.
Informações técnicas aparecem.
Uma prova de conceito é desenvolvida.
Atacantes adaptam esse conhecimento.
Começa a exploração.
O problema é que esse ciclo está acelerando.
No caso investigado pela Acronis, o Red Heron teria convertido rapidamente o conhecimento público sobre a CVE em uma ferramenta preparada para encontrar e comprometer servidores em escala.
O que antes poderia proporcionar semanas para uma empresa atualizar um sistema vulnerável pode agora proporcionar apenas alguns dias.
1.386 servidores foram examinados
A infraestrutura encontrada pelos pesquisadores ajudou a revelar a escala da operação.
O Red Heron havia catalogado 1.386 instâncias do Gitea em sete países.
Além delas, havia uma base separada contendo 477 sistemas de Taiwan.
Esses números não significam que todos esses servidores foram comprometidos.
Essa distinção é fundamental.
1.386 representa o universo de instâncias examinadas pela campanha identificada pela Acronis.
As invasões confirmadas foram 13.
Também não é correto simplesmente somar os 1.386 aos 477 e afirmar que 1.863 organizações foram atacadas. Tratam-se de conjuntos de infraestrutura identificados pelos pesquisadores, e o número de organizações por trás desses servidores não necessariamente corresponde ao número de máquinas.
Taiwan recebeu atenção especial
A existência de uma base específica contendo centenas de sistemas taiwaneses chamou particularmente a atenção dos pesquisadores.
O grupo também utilizava rótulos em chinês simplificado para classificar alvos de diferentes setores.
Entre as categorias identificadas estavam defesa, eleições, energia, aeroespacial, telecomunicações, governo, segurança pública e pesquisa.
Esse comportamento ajudou a Acronis a formular sua avaliação sobre a origem da campanha.
Mas existe uma ressalva essencial.
“Ligado à China” não significa atribuição comprovada
A Acronis avalia o Red Heron como operando dentro de um contexto ligado à China com confiança moderada.
Os pesquisadores apontaram alguns elementos para sustentar essa avaliação.
Uso de chinês simplificado.
Classificação consistente de Taiwan como parte da China.
Perfil dos setores selecionados.
E interesses de coleta de inteligência compatíveis com prioridades chinesas.
Isso é diferente de provar que determinada unidade do governo chinês conduziu a operação.
Até o momento, as evidências públicas disponíveis não permitem transformar essa avaliação em certeza.
Por isso, a formulação mais precisa é tratar o Red Heron como um ator de ameaça com possível vínculo ou contexto chinês, conforme avaliação da Acronis, e não afirmar categoricamente que “a China realizou os ataques”.
Ataques foram muito além do roubo de código
Depois de comprometer o Gitea, os invasores aparentemente utilizavam o acesso inicial para explorar outras partes das redes das vítimas.
A campanha avançou de roubo de repositórios para:
coleta de credenciais;
acesso persistente;
implantação de malware;
reconhecimento da infraestrutura interna;
movimentação lateral;
e comprometimento de sistemas adicionais.
Em um ambiente taiwanês, essa progressão terminou com acesso root a um cluster Proxmox de três nós.
Proxmox é uma plataforma utilizada para virtualização e gerenciamento de servidores.
Conseguir controle administrativo desse tipo de infraestrutura pode ampliar significativamente o alcance de uma invasão, porque diferentes máquinas virtuais e serviços podem estar concentrados naquele ambiente.
Empresa de energia teve segredos e credenciais roubados
A investigação encontrou exemplos concretos do tipo de informação procurada pelos atacantes.
Em uma empresa canadense do setor de energia renovável, o grupo teria obtido repositórios, segredos de configuração, tokens internos, chaves SSH de hosts e aplicações utilizadas internamente.
Esse conjunto é particularmente perigoso.
Código-fonte mostra como sistemas funcionam.
Tokens podem abrir acesso a serviços.
Chaves SSH podem permitir conexões com servidores.
Configurações revelam como diferentes componentes estão conectados.
Uma invasão ao repositório pode, portanto, fornecer os elementos necessários para planejar a próxima etapa do ataque.
Empresa industrial de Taiwan teve centenas de repositórios exfiltrados
Outro caso atingiu uma companhia taiwanesa de automação industrial.
Segundo a investigação, centenas de repositórios foram exfiltrados.
O material incluía projetos relacionados a ferramentas SCADA/HMI, integrações com plataformas de Internet das Coisas, um sniffer de rede, configurações de servidores, produtos de monitoramento e vigilância e aplicações empresariais internas.
SCADA e HMI são tecnologias especialmente relevantes em ambientes industriais.
Elas podem fazer parte do controle e monitoramento de processos físicos.
Isso não significa que o Red Heron tenha comprometido diretamente sistemas industriais ou provocado alterações em processos físicos.
A evidência disponível aponta para o roubo de código e informações relacionadas a essas tecnologias.
Mesmo assim, o valor potencial desse conhecimento para operações futuras é evidente.
Um alvo no Qatar também perdeu código
Em outra organização, localizada no Qatar, os atacantes teriam obtido material relacionado a uma plataforma de aprendizagem, chatbot de inteligência artificial, ferramentas de automação de workflows e plugins WordPress.
A diversidade dos dados reforça uma característica da campanha.
O objetivo aparentemente não era apenas encontrar um tipo específico de software.
Os atacantes procuravam informações técnicas que pudessem possuir valor estratégico ou permitir ampliar o acesso às organizações comprometidas.
JITTERLY: o implante com mais de 30 comandos
Ao investigar um servidor de staging atribuído ao adversário, os pesquisadores encontraram uma ferramenta chamada JITTERLY.
Trata-se de um implante Linux desenvolvido em C++.
O malware oferece mais de 30 comandos de pós-exploração, incluindo capacidades para executar shell, transferir arquivos, finalizar processos, criar túneis de rede, fornecer terminal interativo e realizar movimentação para outros sistemas internos.
O JITTERLY não apareceu pela primeira vez nessa investigação.
Ele já havia sido documentado em julho de 2026 por um pesquisador conhecido como dmpdump, que identificou semelhanças com o agente AdaptixC2.
A descoberta dentro da infraestrutura analisada pela Acronis ajudou a conectar a ferramenta à campanha.
SIXZUT tenta desaparecer dentro do Linux
Dentro do conjunto de ferramentas havia ainda algo mais preocupante.
Os pesquisadores encontraram um rootkit anteriormente não documentado chamado SIXZUT.
Ele utiliza a técnica LD_PRELOAD para interferir no comportamento de funções utilizadas pelo Linux.
Segundo a análise, o SIXZUT modifica 15 funções diferentes para esconder elementos relacionados à atividade maliciosa.
O rootkit pode ocultar arquivos.
Processos.
Conexões de rede.
Também possui mecanismos destinados a dificultar sua remoção e permitir que volte a ser executado caso seja encerrado.
Isso cria um problema sério para resposta a incidentes.
O próprio servidor comprometido pode mentir para o administrador
Rootkits existem justamente para alterar aquilo que o sistema mostra.
Um administrador pode executar uma ferramenta para listar processos.
O processo malicioso não aparece.
Pode procurar determinado arquivo.
O arquivo parece inexistente.
Pode observar conexões de rede.
A conexão do invasor fica escondida.
Isso significa que, depois de um comprometimento profundo desse tipo, simplesmente executar ferramentas tradicionais dentro da máquina afetada pode não fornecer uma visão confiável.
A própria infraestrutura comprometida pode esconder evidências.
Esse é um dos motivos pelos quais incidentes envolvendo rootkits frequentemente exigem investigação a partir de fontes externas e, em situações confirmadas, podem justificar a reconstrução do sistema a partir de uma base confiável.
O ataque ao Gitea é também um ataque à cadeia de software
Existe uma dimensão ainda maior no episódio.
Repositórios são uma das partes centrais da cadeia moderna de desenvolvimento.
Código nasce ali.
Atualizações são armazenadas ali.
Pipelines de CI/CD podem ser acionados a partir dali.
Credenciais podem estar associadas ao ambiente.
Pacotes são construídos a partir desse código.
Produtos chegam aos clientes depois dessas etapas.
Portanto, comprometer a plataforma onde uma empresa desenvolve software cria um risco potencial que vai além daquela organização.
Um atacante que consiga modificar silenciosamente código ou processos de compilação poderia, dependendo das permissões obtidas e da arquitetura do ambiente, tentar transformar uma invasão individual em um problema de cadeia de suprimentos de software.
Não há evidência pública, até agora, de que o Red Heron tenha distribuído atualizações adulteradas para clientes através dos 13 comprometimentos.
Mas a localização do acesso torna esse cenário uma preocupação importante para investigação.
O problema dos segredos dentro dos repositórios
O episódio também reforça uma das regras mais antigas — e frequentemente ignoradas — do desenvolvimento seguro.
Credenciais não deveriam ser armazenadas diretamente em código-fonte.
Na prática, isso continua acontecendo.
Desenvolvedores podem inserir temporariamente uma chave de API.
Um token pode acabar dentro de um arquivo de configuração.
Uma senha pode aparecer no histórico de commits.
Mesmo quando posteriormente removida do arquivo atual, a informação pode continuar armazenada no histórico do Git.
Quando invasores conseguem copiar um repositório inteiro, podem procurar sistematicamente por esses segredos.
Por isso, organizações comprometidas não devem pensar apenas em recuperar o servidor.
Precisam considerar que credenciais presentes nos repositórios podem ter sido copiadas.
Atualizar depois da invasão não elimina o invasor
Existe uma diferença crítica entre corrigir uma vulnerabilidade e responder a um comprometimento.
Se a organização atualiza antes da exploração, o patch pode impedir o ataque.
Se atualiza depois que o invasor já obteve acesso, a situação muda.
A correção fecha a porta original.
Mas o atacante pode ter criado outra.
Pode possuir credenciais.
Pode ter instalado um backdoor.
Pode ter criado usuários.
Pode ter roubado chaves SSH.
Pode ter alcançado outros servidores.
No caso do Red Heron, a presença de JITTERLY e SIXZUT mostra justamente que a campanha possuía mecanismos de pós-exploração e persistência.
Assim, organizações que tiveram instâncias vulneráveis expostas durante o período da campanha precisam tratar o caso não apenas como problema de atualização, mas como possível incidente de segurança.
O Gitea virou apenas a primeira porta
A progressão observada na campanha resume um dos principais problemas da cibersegurança moderna:
Gitea vulnerável → execução de código → roubo de repositórios → credenciais → persistência → movimentação lateral → outros sistemas.
A vulnerabilidade inicial pode existir em apenas um produto.
O comprometimento final não precisa permanecer nele.
Em um dos ambientes analisados, terminou em acesso root a três nós de virtualização.
Em outros, terminou no roubo de informações técnicas altamente sensíveis.
É justamente por isso que servidores de desenvolvimento precisam ser tratados como ativos críticos.
O intervalo entre “falha publicada” e “ataque” está desaparecendo
A CVE-2026-60004 também deixa uma mensagem importante para administradores.
A vulnerabilidade foi divulgada.
Uma prova de conceito tornou-se pública.
Pouco depois, o atacante automatizou sua exploração.
A campanha passou a procurar servidores em escala.
Esse padrão está tornando insuficiente a lógica tradicional de corrigir vulnerabilidades críticas “quando houver tempo na próxima janela de manutenção”.
Para sistemas expostos à internet, especialmente aqueles contendo código, credenciais ou acesso privilegiado, a janela de resposta precisa ser muito menor.
Porque os atacantes também estão automatizando o processo.
Eles não precisam conhecer a empresa.
Não precisam escolher inicialmente uma vítima.
O scanner encontra o servidor.
O exploit testa a vulnerabilidade.
A ferramenta compromete o sistema.
Depois, o invasor decide se aquilo que encontrou possui valor.
Red Heron mostra por que infraestrutura de desenvolvimento virou alvo estratégico
Durante muito tempo, grande parte da defesa corporativa esteve concentrada nos computadores dos funcionários e nos servidores de produção.
A cadeia de desenvolvimento agora merece o mesmo nível de atenção.
Git.
CI/CD.
Gerenciadores de pacotes.
Repositórios de artefatos.
Ferramentas DevOps.
Servidores de automação.
Credenciais de nuvem.
Esses componentes formam uma infraestrutura extremamente poderosa.
Quem controla o ambiente utilizado para construir software pode encontrar caminhos para controlar muito mais.
O Red Heron aparentemente entendeu isso.
A campanha começou procurando servidores Gitea vulneráveis.
Mas, segundo a investigação, não terminou neles.
Ela avançou para código-fonte, credenciais, sistemas internos e infraestrutura de virtualização.
E é justamente esse salto que transforma uma vulnerabilidade em uma operação de ciberespionagem muito mais preocupante.
