Pacotes falsos de correção ortográfica em Python escondiam trojan de acesso remoto distribuído via PyPI
Dois pacotes maliciosos publicados no repositório oficial Python Package Index (PyPI) foram descobertos se passando por bibliotecas de correção ortográfica, enquanto, na realidade, tinham como objetivo instalar um trojan de acesso remoto (RAT) nas máquinas das vítimas. Batizados de spellcheckerpy e spellcheckpy, esses pacotes chegaram a ser baixados mais de mil vezes antes de serem finalmente retirados do ar.
A análise técnica mostrou que o código malicioso não estava exposto de forma óbvia nos arquivos principais da biblioteca, como costuma acontecer em ataques mais simples. Em vez disso, os atacantes optaram por esconder o payload dentro de um arquivo de dicionário em idioma basco, comprimido e com aparência totalmente legítima. Esse arquivo, chamado eu.json.gz, simulava conter apenas frequências de palavras, algo comum em ferramentas de correção ortográfica, o que ajudou a despistar inspeções superficiais.
Dentro desse arquivo comprimido, os criminosos ocultaram um payload codificado em Base64. Ao ser decodificado, esse conteúdo era responsável por fazer o download e executar um trojan de acesso remoto completo, escrito em Python. Esse RAT permitia que o invasor coletasse informações da máquina comprometida, recebesse comandos à distância e os executasse como se estivesse operando localmente no sistema da vítima.
Um ponto que chamou atenção dos pesquisadores foi a sofisticação da cadeia de ativação do ataque. As versões iniciais dos pacotes funcionavam como “sementes dormentes”: o código malicioso era extraído, mas não era de fato executado. Essa abordagem ajudou a construir uma falsa sensação de legitimidade ao longo do tempo, já que quem testava o pacote em seu estágio inicial não percebia qualquer comportamento anormal.
O gatilho real só foi acionado em uma atualização posterior, especificamente na versão spellcheckpy 1.2.0, lançada em janeiro de 2026. A partir dessa versão, o código passou a ser executado automaticamente no momento em que a biblioteca era importada em um projeto Python. Bastava um simples import para que o processo malicioso começasse em segundo plano, sem qualquer interação adicional do usuário.
Outro detalhe técnico relevante é que a ativação do payload também podia ocorrer por meio da chamada de uma função específica. Quando a função test_file() era executada com determinados parâmetros, o pacote realizava a decodificação do conteúdo em Base64 presente no arquivo eu.json.gz e iniciava a sequência de infecção. Essa combinação de gatilho automático via import e ativação condicional por função mostra que o ataque foi cuidadosamente arquitetado para dificultar sua detecção em testes superficiais.
Na segunda fase do ataque, depois que o payload era ativado, o malware se conectava a um domínio externo para baixar o RAT completo. Uma vez instalado, esse trojan oferecia ao atacante controle remoto sobre a máquina comprometida, incluindo capacidade de executar comandos arbitrários, coletar dados sensíveis, mapear o ambiente, instalar novos componentes maliciosos e potencialmente movimentar-se lateralmente em redes corporativas.
O servidor de comando e controle (C2) utilizado para orquestrar o RAT estava associado a uma infraestrutura já observada anteriormente em outras operações maliciosas. De acordo com os pesquisadores, há indícios de que essa mesma estrutura de C2 já havia sido vinculada a campanhas atribuídas a grupos patrocinados por Estados-nação, o que eleva o nível de gravidade do incidente. Isso sugere que não se trata apenas de um ataque oportunista, mas possivelmente de uma operação mais ampla e bem financiada.
Esse episódio também não é completamente isolado no contexto do ecossistema Python. Em 2025, um outro pacote que se passava por ferramenta de correção ortográfica já havia sido identificado no PyPI com comportamento semelhante, também distribuindo malware por meio de um componente aparentemente inofensivo. A recorrência de pacotes com o mesmo tema (spell checking) e a reutilização de técnicas parecidas levantam a hipótese de um mesmo grupo ou, no mínimo, de atores que se inspiram diretamente em ataques anteriores.
O caso reforça uma tendência preocupante: o uso crescente de repositórios oficiais de software como vetor de ataques à cadeia de suprimentos. PyPI, npm e outros ecossistemas de pacotes abertos se tornaram alvos valiosos, porque um único pacote comprometido pode atingir milhares de desenvolvedores e, por consequência, inúmeros produtos e serviços que dependem daquele componente. Esse tipo de ataque é particularmente perigoso em ambientes corporativos e em sistemas críticos, em que bibliotecas de terceiros são amplamente utilizadas.
Além disso, pesquisadores têm chamado atenção para uma técnica relativamente nova no cenário de ameaças: o chamado slopsquatting. Nessa abordagem, criminosos se aproveitam de pacotes inexistentes “inventados” por modelos de inteligência artificial em respostas geradas a usuários. Quando alguém copia e cola o nome sugerido pela IA e tenta instalar o pacote, os atacantes já o registraram previamente em um repositório público, mas com código malicioso. Ou seja, exploram diretamente a confiança excessiva em respostas automatizadas e a falta de verificação manual de referências.
Para desenvolvedores, o incidente reforça a necessidade de adotar práticas mais rigorosas ao lidar com dependências de terceiros. Entre as medidas recomendadas estão: verificar a reputação do autor do pacote, conferir o histórico de versões, analisar o código-fonte sempre que possível, desconfiar de pacotes com nomes muito parecidos com bibliotecas populares e evitar instalar módulos pouco conhecidos em ambientes de produção sem testes prévios em ambientes isolados.
Equipes de segurança e times DevSecOps também precisam reforçar controles na pipeline de desenvolvimento. Isso inclui o uso de scanners de dependências, validação automática de integridade de pacotes, políticas de allowlist para bibliotecas aprovadas, além de monitoramento contínuo para detectar comportamentos anômalos originados de novos componentes recém-instalados. Em organizações maiores, é cada vez mais importante tratar o gerenciamento de dependências como uma parte estratégica da segurança da informação.
Outra boa prática é isolar ambientes de desenvolvimento e testes, reduzindo o impacto caso um pacote malicioso seja instalado. O uso de containers, ambientes virtuais e máquinas de desenvolvimento segregadas da rede interna crítica diminui as chances de que um simples import de biblioteca comprometa sistemas sensíveis ou dados confidenciais.
Do ponto de vista educacional, o episódio evidencia a importância de capacitar desenvolvedores em temas de segurança. Muitos profissionais ainda enxergam a escolha de bibliotecas como uma decisão puramente técnica ou de produtividade, sem considerar os riscos de segurança atrelados à origem e ao comportamento desses componentes. Treinamentos recorrentes, guias internos de boas práticas e revisão de código com foco em dependências externas podem mitigar significativamente esse tipo de ameaça.
Em última análise, casos como o dos pacotes spellcheckerpy e spellcheckpy mostram que a confiança automática em repositórios oficiais já não é suficiente. Embora plataformas como o PyPI adotem mecanismos de verificação e removam pacotes maliciosos assim que detectados, os atacantes continuam a evoluir suas táticas, explorando brechas, disfarçando payloads e usando nomes e descrições aparentemente inofensivos.
Para a comunidade de desenvolvimento e o ecossistema de cibersegurança, o recado é claro: a segurança da cadeia de suprimentos de software deixou de ser um tema opcional e passou a ser um pilar fundamental em qualquer projeto, do script pessoal ao sistema corporativo de grande escala. Vigilância constante, validação criteriosa de dependências e integração de segurança em todas as etapas do ciclo de desenvolvimento são hoje requisitos básicos para reduzir o impacto desse tipo de ameaça.