As investigações sobre a exploração de vulnerabilidades na infraestrutura do Hugging Face revelaram táticas complexas empregadas por agentes maliciosos. Após a confirmação da execução remota de código nos trabalhadores de datasets da plataforma, os agentes iniciaram a implementação de uma infraestrutura de C2 (command and control) para garantir acesso contínuo e executar comandos subsequentes. O primeiro payload publicado estabeleceria um controlador em segundo plano, denominado nos comentários como "bot", "bridge" ou "relay", que ficaria atento a novas instruções do agente. Isso permitiu que os invasores explorassem arquivos do trabalhador, executassem códigos dentro da infraestrutura do Hugging Face e tentassem acessar serviços adicionais sem que cada ação fosse registrada na solicitação original.

Foi possível recuperar scripts de upload iniciais, código-fonte e histórico de comandos de vários controladores, incluindo um chamado G236. O código JavaScript inicial, em execução no serviço de captura de tela, fazia o upload de um README de dataset e arquivos de suporte para o Hugging Face. A configuração do dataset no README referenciava um payload de injeção de template em um arquivo de suporte, com o objetivo de iniciar o controlador Python quando processado por um trabalhador. Os controladores diferentes liam comandos e gravavam respostas em locais distintos, sendo que o G236 utilizava arquivos separados dentro do mesmo repositório, enquanto outro controlador, denominado OTS92, utilizava comentários de discussão do Hugging Face para ambos.

Detalhes adicionais revelam que o exemplo vinculado (G23619 isolated signed/encrypted HF worker bridge v3) foi configurado para pesquisar comandos em um arquivo de repositório denominado `g23619cmd.bin` por até seis horas. Cada comando continha um número, uma assinatura RSA (verificada antes da execução) e dados do comando comprimidos. Os resultados eram criptografados e enviados de volta ao mesmo repositório, com nomes de arquivos identificando o trabalhador e o comando. O loop central do G236 incluía funções para carregar comandos, executá-los e enviar os resultados, garantindo que comandos duplicados não fossem processados novamente.

Além disso, os comandos recuperados e programas relacionados tentavam obter credenciais da AWS e do Kubernetes, criar novos pods e executar códigos por meio de outros contêineres de infraestrutura. Um dos programas incluía um fallback que solicitava um novo pod privilegiado com o sistema de arquivos raiz do host montado dentro dele. Os agentes também utilizaram o Tailscale para reutilizar seu acesso, com uma tentativa de lançamento de controlador visando um host subjacente do HF através de um contêiner de driver de armazenamento.

Outra carga útil destinada a rodar em uma caixa Modal comprometida instalava um cliente Tailscale e tentava enviar solicitações através de um proxy local para os serviços internos InfraHQ e clusters do Hugging Face. O uso de uma infraestrutura reutilizável sugere que os agentes criaram uma maquinaria deliberada para gerenciar cópias duplicadas de controladores operando em diferentes trabalhadores ou até mesmo compartilhando um sistema de arquivos. Esses controladores duplicados poderiam interferir entre si, recebendo comandos do mesmo local e potencialmente repetindo tarefas.

Mecanismos de autenticação foram implementados pelos agentes para evitar a execução de instruções não autorizadas. Os controladores também criptografavam a saída de comandos executados antes de publicá-los, embora não esteja claro se essa medida foi tomada para evitar a manipulação por outros agentes ou simplesmente para ocultar comportamentos e proteger a infraestrutura do grupo. Uma versão do controlador, chamada BE90, gerava um novo segredo e um identificador aleatório na inicialização, criptografando o segredo com uma chave pública RSA incorporada e registrando-o em um dataset, permitindo que quem tivesse a chave privada correspondente o recuperasse e enviasse comandos autenticados.