UNC2814 usou o backdoor GRIDTIDE em campanha global contra telecomunicações e governos

O malware em C abusava da API do Google Sheets como canal de comando e controle, com execução remota de comandos, transferência de arquivos, persistência via systemd e uso de VPN para manter acesso em ambientes comprometidos.

Componente	Backdoor GRIDTIDE, artefatos xapt, xapt.cfg, xapt.service, pmp, pmp.cfg e infraestrutura associada a UNC2814.
Vetor	O acesso inicial específico não foi determinado; a atividade observada envolveu servidores Linux, movimentação lateral por SSH com conta de serviço, persistência via systemd e C2 por chamadas legítimas à API do Google Sheets.
Impacto	Execução arbitrária de comandos shell, upload e download de arquivos, reconhecimento de host, tráfego C2 mascarado como API SaaS e possível exposição de dados pessoais e informações de telecomunicações em ambientes comprometidos.
Prioridade	Caçar execuções suspeitas a partir de /var/tmp, serviços systemd não autorizados, arquivos .cfg em diretórios sensíveis e conexões de processos não navegadores para sheets.googleapis.com com endpoints de leitura, limpeza e atualização de células.
Artefatos	/var/tmp/xapt, /usr/sbin/xapt, /etc/systemd/system/xapt.service, apt.tar.gz, update.tar.gz, amp.tar.gz, hamcore.se2, fire e vpn_bridge.config.
IoCs	Hash SHA256 de xapt: ce36a5fc44cbd7de947130b67be9e732a7b4086fb1df98a5afd724087c973b47; IP de hospedagem de arquivos 130[.]94[.]6[.]228; servidor SoftEtherVPN 38[.]60[.]194[.]21; User-Agent Google-HTTP-Java-Client/1.42.3 (gzip).

Resumo técnico

A campanha atribuída ao UNC2814 atingiu organizações de telecomunicações e entidades governamentais em escala global, com 53 intrusões confirmadas em 42 países e suspeitas de infecção em pelo menos mais 20 países. O grupo é rastreado desde 2017 e é descrito como um ator de espionagem cibernética com provável vínculo com a República Popular da China. A operação analisada não explora uma vulnerabilidade em produtos do Google; o ponto central é o abuso de funcionalidade legítima de API em ambiente SaaS para ocultar tráfego de comando e controle dentro de requisições HTTPS que, em redes corporativas, podem parecer tráfego comum para serviços de nuvem.

O backdoor GRIDTIDE é um binário em C com suporte a execução de comandos shell, upload e download de arquivos. Em vez de depender de um servidor C2 tradicional com protocolo próprio, o malware usa uma planilha como fila de comandos, área de saída e canal de transferência de dados. Esse desenho reduz a utilidade de bloqueios baseados apenas em reputação de domínio, porque parte da comunicação ocorre contra endpoints legítimos de API. Para defesa, o diferencial está em correlacionar processo de origem, caminho do binário, tipo de endpoint chamado, frequência de polling, presença de arquivos de configuração criptográfica e persistência local.

A operação de interrupção desativou projetos de nuvem controlados pelo atacante, contas associadas, acesso à API usada para C2 e infraestrutura conhecida ligada ao UNC2814, incluindo domínios atuais e históricos. Essa remoção reduz o acesso persistente observado, mas não elimina o risco em hosts que ainda tenham binários, serviços, chaves, configurações locais, túneis VPN ou credenciais reutilizadas. Ambientes que operam telecomunicações, plataformas governamentais, servidores de borda e sistemas Linux com acesso a bases de dados pessoais devem tratar os indicadores como ponto de partida para investigação, não como lista completa de cobertura.

Fluxo técnico

A atividade foi detectada em um servidor CentOS quando um processo em /var/tmp/xapt iniciou um shell com privilégio de root e executou sh -c id 2>&1. Esse comando coleta identificadores de usuário e grupo, confirmando se a execução alcançou privilégio administrativo. O nome xapt aparenta ter sido escolhido para se misturar a convenções de ferramentas Linux, embora o artefato observado estivesse fora de um caminho típico de pacote legítimo. A presença de executável curto em /var/tmp, especialmente quando encadeia /bin/sh ou bash, deve ser tratada como sinal forte quando combinada com saída uid=0(root).

Após a execução inicial, o ator usou uma conta de serviço para se mover lateralmente por SSH. A sequência pós-comprometimento incluiu uso de binários nativos do sistema, reconhecimento, escalonamento de privilégio e preparação de persistência. O malware foi inicialmente executado com nohup ./xapt, permitindo que o processo continuasse após o encerramento da sessão interativa. Em seguida, foi criado o serviço /etc/systemd/system/xapt.service; quando habilitado, uma nova instância passou a ser iniciada a partir de /usr/sbin/xapt. Esse padrão deixa rastros em logs de autenticação, histórico de comandos quando disponível, eventos de criação de unidade systemd, alterações em diretórios privilegiados e atividade de processo pai-filho associada a shells.

O GRIDTIDE depende de uma chave criptográfica de 16 bytes em arquivo separado no host. Essa chave é usada para descriptografar configurações do Google Drive com AES-128-CBC. A configuração contém dados de autenticação de conta de serviço, chave privada, identificador da planilha e material necessário para acesso ao documento controlado pelo atacante. Depois da autenticação, o malware limpa as primeiras 1000 linhas das colunas A a Z com o método batchClear, evitando que comandos antigos ou dados residuais interfiram na sessão. Só então o host é perfilado com nome de usuário, nome do endpoint, detalhes do sistema operacional, endereço IP local, diretório atual, idioma e fuso horário, dados que são codificados e gravados na célula V1.

A comunicação é baseada em células. A célula A1 funciona como ponto de polling para comandos e como área de status após a execução. Se não houver comando, o malware espera um segundo e repete; depois de 120 tentativas, passa a usar intervalo aleatório entre 5 e 10 minutos para reduzir ruído. As células A2:A transportam dados, incluindo saída de comando, arquivos enviados ao host e conteúdo exfiltrado em fragmentos. Os comandos do operador usam tipos como C para execução de comandos Bash codificados em Base64, U para upload a partir de dados presentes na planilha e D para download de arquivo local com divisão em blocos de 45 KB. O malware responde com mensagens do tipo S, indicando sucesso ou erro.

Superfície afetada

A superfície principal envolve servidores Linux comprometidos, especialmente sistemas de telecomunicações e ambientes governamentais com acesso a dados pessoais, contas de serviço, SSH e saída HTTPS para serviços SaaS. Um endpoint observado continha nome completo, telefone, data e local de nascimento, número de título de eleitor e número de identificação nacional. Não houve observação direta de exfiltração desses dados nessa campanha específica, mas o acesso obtido permitiria coleta clandestina caso o operador executasse comandos ou baixasse arquivos a partir do host. Em telecomunicações, esse tipo de acesso também pode abrir caminho para registros de chamadas, mensagens SMS não criptografadas e sistemas de interceptação legal quando esses ativos estiverem acessíveis ao servidor comprometido.

O uso de Google Sheets como C2 exige uma abordagem defensiva diferente de bloqueio simples por domínio. Em muitas empresas, sheets.googleapis.com é permitido por necessidade operacional, então a investigação deve diferenciar navegador, serviço corporativo legítimo e processo desconhecido em caminho incomum. A presença dos endpoints /values/A1?valueRenderOption=FORMULA, /values:batchClear, /values:batchUpdate e /values/A2:A?valueRenderOption=FORMULA em tráfego originado por binários sem relação com navegador ou integração aprovada é um indicador de alto valor. O mesmo raciocínio vale para outras plataformas de planilha em nuvem, porque a técnica pode ser adaptada sem alterar a lógica operacional do backdoor.

O pacote de ferramentas também incluiu SoftEther VPN Bridge para conexão criptografada de saída com infraestrutura externa. Arquivos como hamcore.se2, fire e vpn_bridge.config indicam implantação de túnel ou componente de ponte VPN em host já comprometido. Metadados da configuração sugerem uso dessa infraestrutura desde julho de 2018, o que reforça a necessidade de buscar artefatos históricos em backups de logs, imagens de disco, EDR de longo prazo, NetFlow e registros de proxy. A ausência dos IPs atuais em telemetria recente não exclui compromisso antigo, porque o ator pode ter alternado domínios, IPs e nomes de arquivo.

• Servidores Linux com executáveis em /var/tmp, /usr/sbin ou /sbin e nomes curtos como xapt ou pmp.
• Unidades systemd recém-criadas ou alteradas, principalmente /etc/systemd/system/xapt.service.
• Contas de serviço com acesso SSH lateral e uso fora do padrão administrativo esperado.
• Hosts que acessam sheets.googleapis.com a partir de processos não navegadores e sem integração corporativa documentada.
• Ambientes de telecomunicações com bases de PII, registros de comunicação, sistemas de sinalização, ferramentas administrativas ou componentes de interceptação legal acessíveis a partir de servidores Linux.

Hunting e telemetria

A caça deve começar por processo, arquivo e rede em conjunto. No endpoint, procure executáveis com nomes alfanuméricos curtos executados a partir de /var/tmp, criação de arquivos .cfg em /usr/sbin, /sbin ou /var/tmp, execução de nohup, shells iniciados por binários desconhecidos e comandos de perfilamento como id. Em sistemas com EDR, priorize árvores de processo em que um binário fora de diretórios de pacote inicia /bin/sh ou bash, seguido de conexões HTTPS para APIs de planilha ou download de arquivos compactados por curl a partir de IP literal. Em logs Linux, revise auth.log, secure, journalctl, unidades systemd, alterações de permissão e eventos de criação de arquivo em diretórios privilegiados.

Na rede, a detecção precisa correlacionar User-Agent, endpoint e processo. O GRIDTIDE foi associado aos User-Agents Directory API Google-API-Java-Client/2.0.0 Google-HTTP-Java-Client/1.42.3 (gzip) e Google-HTTP-Java-Client/1.42.3 (gzip). Essas strings isoladas podem aparecer em integrações legítimas, portanto a regra prática é cruzá-las com origem Linux incomum, ausência de navegador como processo pai, chamadas repetidas a batchClear e batchUpdate, e polling de A1 com valueRenderOption=FORMULA. Também devem ser investigadas conexões para 130[.]94[.]6[.]228, que hospedou apt.tar.gz, update.tar.gz e amp.tar.gz, e para IPs de VPN como 38[.]60[.]194[.]21, 38[.]54[.]37[.]196, 207[.]148[.]73[.]18, 38[.]60[.]224[.]25, 149[.]28[.]139[.]125, 38[.]54[.]32[.]244, 38[.]54[.]82[.]69, 45[.]76[.]157[.]113, 45[.]77[.]254[.]168 e 139[.]180[.]219[.]115.

Os hashes confirmados ajudam na triagem, mas não devem ser a única camada. Procure ce36a5fc44cbd7de947130b67be9e732a7b4086fb1df98a5afd724087c973b47 para xapt, 01fc3bd5a78cd59255a867ffb3dfdd6e0b7713ee90098ea96cc01c640c6495eb para xapt.cfg, eb08c840f4c95e2fa5eff05e5f922f86c766f5368a63476f046b2b9dbffc2033 para xapt.service, 4eb994b816a1a24cf97bfd7551d00fe14b810859170dbf15180d39e05cd7c0f9 para hamcore.se2 e fire, e 669917bad46a57e5f2de037f8ec200a44fb579d723af3e2f1be1e8479a267966 para vpn_bridge.config. Para YARA, a lógica pública identifica ELF com cadeias relacionadas a JWT, /proc/self/exe, limpeza de intervalo a1:z1000 e respostas S-U ou S-D, o que cobre comportamento interno do binário além de nomes de arquivo.

• Processo não navegador chamando sheets.googleapis.com com /values:batchClear, /values:batchUpdate ou valueRenderOption=FORMULA.
• Execução de /var/tmp/[a-z0-9]{1,10} seguida por /bin/sh, bash ou comando sh -c id 2>&1.
• Criação, modificação ou movimentação de arquivos .cfg em /usr/sbin, /sbin ou /var/tmp.
• Presença de /etc/systemd/system/xapt.service, /usr/sbin/xapt, xapt.cfg, pmp.cfg, hamcore.se2, fire ou vpn_bridge.config.
• Downloads de apt.tar.gz, update.tar.gz ou amp.tar.gz a partir de 130[.]94[.]6[.]228.

Mitigação

A resposta deve separar contenção de erradicação. Ao identificar um host com sinais compatíveis, isole a máquina sem desligá-la imediatamente, preserve memória quando o processo ainda estiver ativo, colete árvores de processo, conexões, unidades systemd, arquivos em /var/tmp, /usr/sbin, /sbin e histórico de autenticação SSH. Revogue credenciais de contas de serviço usadas em SSH lateral e revise chaves autorizadas em todos os servidores alcançáveis a partir do host comprometido. Como o acesso inicial não foi determinado, servidores web e sistemas de borda relacionados ao ambiente devem entrar no escopo de investigação, com revisão de exploração recente, web shells, contas administrativas, logs de proxy reverso e alterações em binários de sistema.

Na camada de identidade e nuvem, bloqueie ou revise integrações não autorizadas com APIs de planilha, audite contas de serviço, chaves privadas, projetos de nuvem e tokens usados por workloads internos. O objetivo não é proibir todo uso de planilhas via API, mas restringir chamadas a identidades aprovadas, workloads conhecidos e origens esperadas. Para organizações que dependem de Google Workspace, crie detecções por processo de origem e por padrão de endpoint, porque a comunicação maliciosa ocorre em infraestrutura legítima. Em proxies e firewalls, regras de inspeção devem marcar processos desconhecidos que acessem endpoints de atualização de valores, limpeza de intervalo e leitura de célula com alta frequência.

Depois da contenção, remova serviços persistentes, binários e configurações somente após coleta forense suficiente. Faça rotação de credenciais expostas no host, incluindo chaves SSH, segredos de aplicações, tokens de banco de dados e credenciais de contas de serviço. Em ambientes de telecomunicações, valide acesso a bases de PII, registros de chamadas, sistemas de mensagens e componentes de interceptação legal; a investigação deve confirmar se houve leitura, cópia, compactação ou transferência de dados, ainda que a campanha analisada não tenha observado exfiltração direta de dados sensíveis. A validação final deve incluir varredura por hashes conhecidos, YARA para GRIDTIDE, hunting comportamental, revisão de tráfego histórico e monitoramento reforçado para nova infraestrutura do mesmo ator.

• Isolar hosts suspeitos, preservar evidências e coletar memória, processos, conexões, arquivos e unidades systemd antes da limpeza.
• Revogar credenciais de contas de serviço usadas em SSH e revisar authorized_keys, permissões sudo e acessos laterais recentes.
• Criar alertas para processos não navegadores acessando sheets.googleapis.com com batchClear, batchUpdate e leitura de A1 ou A2:A.
• Remover xapt.service, xapt, pmp, arquivos .cfg e componentes SoftEther somente após coleta forense e confirmação de escopo.
• Rotacionar segredos presentes no host comprometido e auditar sistemas de telecomunicações ou governamentais acessíveis a partir dele.