Ataque no PyPI ligado ao OceanLotus: como o ZiChatBot usou o Zulip para comando e controle

Relatos públicos identificam três bibliotecas falsas envolvidas na campanha:^[1][2]

• uuid32-utils
• colorinal
• termncolor

Há uma nuance importante na atribuição. No texto da Securelist, a Kaspersky afirma que as amostras foram submetidas ao Kaspersky Threat Attribution Engine e que os pacotes podem estar ligados a malware discutido em um relatório de inteligência sobre o OceanLotus.^[3] Já o índice público de pesquisa de ameaças da Kaspersky é mais direto e diz que a empresa atribui a atividade ZiChatBot no PyPI ao OceanLotus APT.^[6] Um resumo público caracteriza essa atribuição como de confiança moderada.^[2]

Da instalação do pacote ao ZiChatBot

O cenário sustentado pelas fontes públicas é o de uma cadeia de dropper multiplataforma. O índice de pesquisa da Kaspersky afirma que os pacotes wheel maliciosos no PyPI miravam Windows e Linux e continham um dropper responsável por entregar o malware chamado ZiChatBot.^[6]

Um resumo público descreve as etapas seguintes como a extração de um dropper DLL ou .SO a partir do pacote wheel, a criação de persistência pelo Registro do Windows ou pelo crontab no Linux, e então a implantação do ZiChatBot.^[2]

Isso amplia a área de investigação. Não basta olhar apenas para servidores de aplicação em produção: estações de desenvolvedores, ambientes virtuais, runners de CI, máquinas de build e imagens de contêiner também podem ter instalado dependências afetadas.

Como o Zulip entrou no comando e controle

O ponto mais incomum da campanha foi o desenho de comando e controle, ou C2. Segundo relatos sobre a análise da Kaspersky, o ZiChatBot não se comunicava com um servidor C2 dedicado. Em vez disso, usava uma série de APIs REST do Zulip, aplicativo público de chat corporativo, como infraestrutura de comando e controle.^[4]

A documentação do Zulip mostra que suas APIs suportam operações compatíveis com esse tipo de desenho baseado em mensagens: enviar mensagens, obter mensagens, fazer upload de arquivos, editar ou apagar mensagens, construir narrows, isto é, recortes ou filtros de mensagens, e trabalhar com tópicos de canais.^[17][21] A documentação de bots também descreve bots capazes de interceptar, visualizar e processar mensagens enviadas por usuários e depois responder com novas mensagens.^[19]

Em alto nível, isso permite imaginar uma lógica em que instruções de operadores sejam representadas como mensagens de chat ou mensagens em tópicos específicos, enquanto o malware busca mensagens relevantes e publica respostas pelo mesmo serviço. As fontes públicas citadas aqui não divulgam o workspace do Zulip, credenciais de bot, sequência exata de endpoints ou conjunto de comandos usados pelo ZiChatBot. A descrição mais segura, portanto, é que o malware abusou de funcionalidades legítimas das APIs REST do Zulip para C2, em vez de depender de infraestrutura C2 própria dos atacantes.^{[4][17][19][21]}

O que esse detalhe não significa

O uso do Zulip não significa que o Zulip tenha sido invadido. Os relatos descrevem abuso de funcionalidades normais de API REST e de mensagens no estilo bot, não um comprometimento do serviço de chat.^[4][19][21]

Também não há, nas fontes citadas, indicação de que a infraestrutura do PyPI tenha sido comprometida. O que a Kaspersky descreve são pacotes wheel maliciosos enviados ao repositório e depois removidos.^[3]

Para defensores, a consequência é clara: tráfego para um serviço legítimo de colaboração ainda pode ser suspeito quando parte de um host, processo, job de CI ou conta de serviço que não deveria falar com aquele serviço. Bloqueios baseados apenas em reputação de domínio podem não enxergar esse padrão. A pergunta correta não é se o Zulip é legítimo; é se aquele processo e aquele ambiente têm motivo legítimo para chamar APIs do Zulip.^[4][21]

O que equipes de segurança devem checar

Comece pelo inventário de pacotes. Procure por uuid32-utils, colorinal e termncolor em máquinas de desenvolvimento, runners de build, ambientes virtuais, arquivos de lock de dependências e imagens de contêiner.^[1][2]

Revise eventos de instalação a partir de julho de 2025, período apontado pela Kaspersky para o início dos uploads maliciosos.^[3] Se algum dos pacotes aparecer em logs ou artefatos, preserve o ambiente para investigação antes de simplesmente apagar a dependência e seguir em frente.

Em Windows, verifique persistência inesperada no Registro. Em Linux, procure entradas suspeitas no crontab. Essas verificações seguem a cadeia de infecção descrita publicamente para a campanha.^[2]

Também vale revisar telemetria de rede e de processo em busca de chamadas às APIs do Zulip feitas por interpretadores Python, processos de instalação de pacotes, workers de CI, servidores ou contas de serviço que normalmente não usam Zulip. O destino pode ser legítimo; o contexto do processo é que decide se o comportamento faz sentido.^[4][21]

Por fim, não trate comportamento funcional como prova de segurança. Nesta campanha, os pacotes aparentemente entregavam o que prometiam, mas também atuavam como droppers para arquivos maliciosos.^[3][4]

Em resumo

A campanha no PyPI ligada ao OceanLotus envolveu pacotes wheel maliciosos enviados a partir de julho de 2025, com nomes públicos como uuid32-utils, colorinal e termncolor.^[1][2][3] Esses pacotes entregavam o ZiChatBot em Windows e Linux, e a escolha operacional que mais chamou atenção foi o uso de APIs REST do Zulip como canal de comando e controle, no lugar de um servidor C2 dedicado controlado pelos atacantes.^[4][6]