Netresec detalha evolução do protocolo C2 do AtlasRAT, de 'SFuck' a 'BFuck'
O pesquisador Erik Hjelmvik (Netresec) mapeou a evolução do canal de comando e controle do AtlasRAT, backdoor associado ao grupo chinês Silver Fox (também rastreado como Void Arachne/TA4922/SwimSnake). O malware migrou de um handshake em texto claro iniciado por 'SFuck' para uma variante 'BFuck' com criptografia ChaCha20, e mais recentemente passou a se camuflar em TLS na porta 443. O artigo publica assinaturas Suricata e uma lista de IOCs (IPs, domínios e fingerprints JA3) para detecção em rede.
O AtlasRAT é um backdoor de acesso remoto utilizado pelo grupo de ameaça chinês conhecido como Silver Fox (银狐), também identificado em relatórios anteriores como Void Arachne, TA4922 ou SwimSnake. O grupo costuma distribuí-lo junto com outras famílias como ValleyRAT e Gh0st RAT, frequentemente embutido em instaladores de VPN trojanizados, conforme pesquisa anterior da HexaStrike citada no artigo. A análise da Netresec se concentra especificamente na forense de rede do protocolo de comando e controle, isto é, como identificar o tráfego do implante em capturas de pacotes e logs de fluxo, sem depender de amostras binárias.
Tecnicamente, o canal C2 passou por pelo menos três gerações. A versão original, apelidada de 'SFuck', inicia cada conexão com a sequência de bytes 53 46 75 63 6b 00 00 00 (ASCII 'SFuck' seguido de três bytes nulos) em texto claro, o que a tornava trivialmente detectável por assinatura. Em março de 2026 os operadores adicionaram uma camada de ofuscação XOR com chave fixa iniciando em a7 3b f1 8c, e a partir de maio de 2026 surgiu a variante 'BFuck' (byte inicial trocado de 'S' para 'B'), que passou a usar ChaCha20 para cifrar o corpo dos pacotes, mantendo um cabeçalho de 56 bytes em claro com campos de sequência, tamanho comprimido, tamanho original, flags, a chave ChaCha20 de 32 bytes e um nonce de 8 bytes transmitidos junto do próprio pacote. Em julho de 2026 uma terceira variante abandonou as portas não padronizadas 886/9899 TCP e migrou o C2 para dentro de um túnel TLS na porta 443, usando certificados X.509 forjados e handshakes com impressões JA3/JA3S específicas, numa tentativa clara de se misturar a tráfego HTTPS legítimo e dificultar bloqueio por porta ou payload.
Para defensores, o artigo é relevante porque traduz essa evolução em artefatos acionáveis: quatro regras Suricata (SIDs 1471105 a 1471108) cobrindo o check-in SFuck, o check-in BFuck, o handshake TLS característico e o certificado forjado, além de uma lista de IOCs com oito endereços IP de C2, domínios como laicaishuli[.]com e zixungongsi[.]top, as impressões JA3/JA3S e o hash SHA-1 do certificado X.509 usado na variante TLS. A Netresec também menciona que sua própria ferramenta de análise de fluxo, FlowCarp, consegue reconhecer variantes do protocolo mesmo sem assinatura prévia porque modela padrões de tamanho e tempo de pacotes além do simples check-in inicial — algo relevante para quem faz forense de rede e precisa lidar com protocolos C2 que mudam rapidamente de 'byte mágico'.
O caso ilustra bem como a análise de tráfego de rede continua sendo uma camada de detecção complementar à análise de binários: mesmo quando o malware adota criptografia forte e se esconde em TLS, metadados de handshake (JA3/JA3S, certificados autoassinados com padrões específicos) e estrutura de pacotes continuam vazando informação suficiente para construir assinaturas. Para equipes de resposta a incidentes e peritos que atuam com apreensão de tráfego ou logs de proxy/firewall, as assinaturas e IOCs publicados servem tanto para triagem retroativa (buscar indicadores já em logs históricos) quanto para hunting ativo em ambientes sob suspeita de comprometimento por Silver Fox.