O tráfego de comando e controle do SHEETCREEP vai para sheets.googleapis.com sobre HTTPS em IPs do Google. No nível de rede, é indistinguível de um funcionário editando uma planilha. Na Tech86, analisamos essa campanha porque ela representa o limite atual da evasão de C2 — e por que a detecção precisa acontecer no endpoint.
A campanha Sheet Attack e a descoberta
Segundo a Zscaler, o SHEETCREEP foi observado a partir de setembro de 2025, com divulgação pública em janeiro de 2026 durante a campanha "Sheet Attack" contra o governo indiano. Em junho de 2026, a Securonix publicou análise de uma variante evoluída e acessou a planilha de C2 ativa — com 91 abas. Esse número circulou como "91 vítimas", mas o breakdown real, segundo a análise da Securonix da planilha de C2, conta outra história: 28 abas eram sandboxes automatizadas, 17 eram labs de pesquisadores de segurança, 17 eram alvos reais potenciais (apenas 1 de alta confiança), 16 estavam vazias (provavelmente bloqueadas por AV), 3 de categorias diversas, 1 aba default, 1 VM de análise e 8 com atividade indeterminada. Dizer "91 vítimas" sem esse breakdown é enganoso.
A atribuição é de confiança moderada. A Zscaler avalia que pode ser um novo grupo APT vinculado ao Paquistão ou um subgrupo do APT36 (Transparent Tribe). Os indicadores apontam nessa direção — vitimologia focada no governo indiano, operação a partir do Paquistão, abuso de nuvem consistente com ElizaRAT e campanhas anteriores como a Operation FlightNight — mas há diferenças: novas técnicas de evasão (Geo-IP, User-Agent), tooling diferente e metadados PDF distintos.
O mecanismo: uma planilha como painel de C2
O SHEETCREEP é um RAT leve em C# com aproximadamente 20 KB. Cada vítima recebe uma aba dedicada na planilha com formato username-hostname-4charhash. A Coluna A recebe comandos do operador em Base64. A Coluna B armazena a saída dos comandos em Base64. A Coluna C registra timestamps. O RAT consulta a planilha a cada 3 segundos via Sheets API v4 sobre HTTPS. A autenticação usa uma conta de serviço (service account) do GCP com chave RSA-2048 embutida no binário para gerar JWTs OAuth2.
É elegante na simplicidade. O operador escreve comandos em uma célula, o RAT lê, executa e escreve o resultado na célula adjacente. Tudo trafega pela API do Google, sobre HTTPS, para IPs do Google. Nenhum servidor dedicado. Nenhum domínio suspeito. Nenhuma infraestrutura própria.
Duas variantes, duas gerações operacionais
A variante original, documentada pela Zscaler, usava criptografia TripleDES ECB, executava comandos via cmd.exe oculto e mantinha a configuração em texto plano. A variante evoluída, identificada pela Securonix, introduziu ofuscação XOR com chave "discrete", PowerShell runspace in-process (sem processo powershell.exe filho) e autenticação via service account do GCP.
A evolução é significativa. TripleDES ECB para XOR com chave embutida no código não é melhoria criptográfica — é pragmatismo operacional: XOR é mais difícil de detectar por análise de assinatura estática, enquanto TripleDES exige referências a System.Security.Cryptography que são indicadores óbvios. PowerShell in-process elimina o artefato mais óbvio: um processo powershell.exe filho. A service account do GCP substitui credenciais de usuário, reduzindo o risco de revogação. Cada mudança fecha uma janela de detecção.
A Zscaler também encontrou indicadores de código gerado por IA no SHEETCREEP. Se confirmado, isso representa um marco: um APT sul-asiático usando IA para gerar código de malware operacional.
O desafio de detecção que muda o paradigma
Todo tráfego C2 do SHEETCREEP vai para sheets.googleapis.com sobre HTTPS em IPs do Google (AS15169). No nível de rede, é indistinguível de tráfego legítimo do Google Workspace. Sua empresa provavelmente permite esse tráfego. Seu firewall não bloqueia. Seu IDS não detecta. Seu SIEM não alerta.
A detecção precisa focar no endpoint. Processos não-browser fazendo conexões sustentadas a APIs do Google são o primeiro sinal. Tarefas agendadas anômalas — como WindowsVaultSyncService com descrição "Windows Edge Core Update Task Machine Discord Update" — são o segundo. Caminhos de arquivo suspeitos como %LOCALAPPDATA%\Microsoft\Vault\vaultsvc.exe com atributos Hidden+System são o terceiro. Autenticação OAuth2 de service account originada de binários fora de contexto corporativo é o quarto.
O anti-forense agrava o problema. Se o RAT detecta ferramentas de análise como dnSpy, Wireshark ou Network Monitor, ele força uma reinicialização via Restart-Computer -Force. O carregador de carga (dropper) se auto-deleta e substitui por um PDF decoy. O binário recebe atributos Hidden+System. Isso significa que a janela de análise é curta e o investigador precisa de proteção antes de iniciar a análise.
Contexto histórico: evolução, não novidade
Google Sheets como C2 não é novo. O GC2-sheet apareceu em 2021. O google_RAT também em 2021. A APT41 usou GC2 em 2022, conforme documentado pelo Google TAG em 2023. O que é novo no SHEETCREEP é a adoção por um APT sul-asiático com melhorias operacionais: autenticação via service account, abas dedicadas por vítima, ofuscação XOR, PowerShell in-process e anti-forense agressivo.
A tendência é clara. Ameaças avançadas estão migrando para infraestrutura de SaaS legítima como canal C2. O tráfego é permitido por padrão. A infraestrutura é gratuita ou barata. A detecção no nível de rede é quase impossível. O foco precisa estar no endpoint.
Por que EDR é a resposta
Na Tech86, a campanha SHEETCREEP reforça o que defendemos há tempo: a detecção de C2 baseada em infraestrutura de SaaS legítima precisa acontecer no endpoint. Nosso EDR monitora processos não-browser fazendo conexões sustentadas a APIs de SaaS, detecta tarefas agendadas com descrições anômalas, identifica binários em caminhos suspeitos com atributos de ocultação e correlaciona autenticação OAuth2 fora de contexto.
Quando o C2 se esconde no tráfego legítimo do Google Workspace, a rede não vê. O endpoint vê. E o EDR é a ferramenta que transforma o que o endpoint vê em ação de resposta.
O atacante evoluiu. Sua detecção precisa estar onde o atacante não pode se esconder: no processo, no binário, no comportamento do endpoint.