Operação desativou projetos, contas e chamadas de API usados como canal de comando e controle por uma campanha de espionagem atribuída a um ator suspeito de vínculo com a China.
| Componente | Campanha UNC2814, backdoor GRIDTIDE, Google Sheets API, contas de serviço, servidores web e sistemas de borda comprometidos. |
| Vetor | O acesso inicial ainda está sob investigação; o histórico do ator inclui exploração e comprometimento de servidores web e sistemas de borda, seguido de uso de SSH, binários living-off-the-land e SaaS como C2. |
| Impacto | Pelo menos 53 organizações em 42 países foram comprometidas; há suspeita de infecções adicionais em mais de 20 países, com foco em governos internacionais e telecomunicações globais. |
| Prioridade | Revisar sistemas de borda, contas de serviço, persistência systemd, tráfego SaaS anômalo e uso não autorizado de SoftEther VPN Bridge em ambientes com exposição relevante. |
| Artefatos | Persistência observada em /etc/systemd/system/xapt.service, execução a partir de /usr/sbin/xapt e comunicação por células de planilhas via Google Sheets API. |
| Mitigação | A ação de interrupção encerrou projetos Google Cloud controlados pelo atacante, desativou infraestrutura conhecida, cortou contas controladas pelo ator e bloqueou chamadas de API usadas para C2. |
A campanha UNC2814 foi interrompida após a identificação de uma operação de espionagem cibernética que comprometeu pelo menos 53 organizações em 42 países. O ator é descrito como suspeito de vínculo com a China e vem sendo acompanhado desde 2017. A atividade se concentrou em governos internacionais e organizações globais de telecomunicações em regiões da África, Ásia e Américas, com suspeita de presença adicional em mais de 20 países. O escopo global e a duração provável de parte das intrusões indicam uma operação construída para acesso persistente e evasão prolongada, não para impacto destrutivo imediato.
O elemento técnico central da campanha é o GRIDTIDE, um backdoor em C que abusa da Google Sheets API como canal de comando e controle. Em vez de depender apenas de infraestrutura dedicada ou domínios evidentemente maliciosos, o malware usa chamadas a aplicações SaaS para misturar o tráfego operacional com comunicações aparentemente legítimas. Essa escolha dificulta a separação entre uso corporativo normal e atividade controlada por atacante, especialmente em organizações que permitem amplo acesso a serviços de produtividade em nuvem.
A operação de interrupção removeu projetos Google Cloud controlados pelo atacante, desativou infraestrutura conhecida do UNC2814, cortou o acesso a contas controladas pelo ator e bloqueou chamadas de API usadas para comando e controle. Também foram emitidas notificações formais às vítimas confirmadas. O dado mais importante para resposta defensiva é que a campanha combina comprometimento de borda, movimentação lateral por SSH, persistência em Linux, uso de binários nativos do sistema e abuso de SaaS confiável como canal de controle.
O acesso inicial ainda não foi confirmado, mas o histórico do grupo inclui exploração e comprometimento de servidores web e sistemas de borda. Esse detalhe é relevante porque appliances e serviços expostos à internet costumam operar fora da cobertura completa de EDR, têm ciclos de correção mais lentos e podem oferecer acesso direto a rotas internas. Em uma intrusão desse tipo, o comprometimento de um ponto de borda não precisa, por si só, gerar grande volume de telemetria de endpoint; o risco aumenta quando o sistema comprometido permite autenticação interna, execução de ferramentas administrativas ou pivô para servidores adjacentes.
Após o acesso, a atividade observada incluiu uso de conta de serviço para movimentação lateral via SSH. Esse padrão sugere tentativa de operar dentro de mecanismos administrativos já aceitos pelo ambiente, reduzindo a dependência de ferramentas externas ruidosas. A campanha também usou binários living-off-the-land para reconhecimento, elevação de privilégios e preparação de persistência. Para defesa, isso significa que a detecção não pode depender apenas de assinatura de malware: é necessário correlacionar autenticações, criação de serviços, execução incomum de utilitários do sistema e comunicação SaaS fora do padrão do host.
A persistência do GRIDTIDE foi observada por meio de um serviço em /etc/systemd/system/xapt.service. Depois de habilitado, o serviço iniciava uma nova instância do malware a partir de /usr/sbin/xapt. Esses artefatos devem ser tratados como indicadores de host relevantes para sistemas Linux, mas a análise não deve parar neles, porque nomes de arquivos e serviços podem ser alterados em novas tentativas de reconstituição da operação. A lógica defensiva precisa procurar criação recente de serviços systemd fora do padrão, binários em diretórios sensíveis com metadados inconsistentes e processos persistentes que mantenham comunicação regular com APIs SaaS.
O GRIDTIDE usa um mecanismo de consulta baseado em células de planilha. Células específicas recebem papéis no fluxo bidirecional de comunicação, permitindo consulta por comandos do operador e gravação de respostas de status. O backdoor oferece upload e download de arquivos, além de execução arbitrária de comandos shell. A descrição desses recursos confirma capacidade de controle remoto do host comprometido, mas o contexto não confirma exfiltração de dados durante a campanha. Há evidência de implantação em endpoints que continham informações pessoalmente identificáveis, o que é compatível com espionagem voltada ao monitoramento de pessoas de interesse, mas não autoriza concluir roubo de dados como fato observado.
A superfície exposta envolve três camadas principais: sistemas de borda e servidores web que podem ter sido usados no acesso inicial, hosts Linux onde o GRIDTIDE foi implantado e serviços SaaS usados como canal de comando e controle. Ambientes de telecomunicações e governo têm risco ampliado porque combinam grande superfície de rede, ativos legados, contas privilegiadas de operação e dados sensíveis sobre usuários, tráfego ou pessoas monitoradas. A presença de contas de serviço também amplia a dificuldade de resposta, pois autenticações automatizadas podem parecer parte de rotinas legítimas.
O uso de SoftEther VPN Bridge adiciona outra camada de exposição. A campanha empregou a ferramenta para estabelecer conexão criptografada de saída com endereço IP externo. O ponto defensivo não é tratar todo uso de SoftEther como malicioso, mas validar se há implantação autorizada, proprietário técnico, janela de mudança, destino externo esperado e justificativa operacional. Em ambientes onde a ferramenta não faz parte do padrão aprovado, a presença dela em servidor exposto, host sensível ou máquina com serviço systemd recém-criado deve elevar a prioridade de investigação.
- Organizações governamentais internacionais e empresas globais de telecomunicações aparecem como alvos centrais da campanha.
- Sistemas de borda e servidores web merecem revisão porque o acesso inicial ainda está sob investigação, mas o ator tem histórico de exploração desse tipo de ativo.
- Hosts Linux com serviços systemd desconhecidos, binários em
/usr/sbinsem cadeia de mudança validada e tráfego para APIs SaaS devem ser priorizados. - Contas de serviço com uso de SSH, autenticações fora de padrão e acesso a segmentos internos sensíveis devem passar por revisão de escopo e necessidade.
A caça deve começar pela correlação entre identidade, endpoint Linux e tráfego de saída. Em identidade, procure contas de serviço com autenticação SSH interativa ou uso fora de janelas esperadas. Em endpoint, examine criação ou modificação de unidades systemd, binários adicionados a diretórios administrativos e processos persistentes com pai incomum. Em rede, avalie fluxos de saída criptografados para destinos externos não documentados e volume anômalo de chamadas para APIs de planilhas a partir de servidores que não deveriam manipular documentos de produtividade.
A telemetria de SaaS é essencial porque o canal C2 foi projetado para parecer benigno. Chamadas repetitivas à Google Sheets API, padrões de consulta em intervalos regulares, acesso por contas sem relação funcional com planilhas e uso de projetos ou credenciais não reconhecidos devem ser investigados em conjunto com sinais de host. A existência de comunicação com SaaS não prova comprometimento, mas a combinação com persistência systemd, execução a partir de caminho administrativo e movimentação SSH por conta de serviço forma um encadeamento técnico forte.
Como não houve confirmação de exfiltração observada, a investigação de dados deve ser conduzida como validação de risco, não como conclusão automática. Em hosts com PII, revise acessos a arquivos, compressão ou preparação de grandes volumes, transferências incomuns e permissões locais. O objetivo é determinar se houve acesso, preparação ou tentativa de transferência, preservando a distinção entre capacidade do malware e impacto confirmado.
- Criação, habilitação ou alteração de serviços systemd com nomes não reconhecidos, especialmente próximos a atividade SSH incomum.
- Execução de binários em
/usr/sbinsem pacote, assinatura, inventário ou mudança administrativa correspondente. - Chamadas frequentes à Google Sheets API por servidores que não têm função documentada de automação com planilhas.
- Uso de SoftEther VPN Bridge sem aprovação, com conexão criptografada de saída para destino externo não previsto.
- Contas de serviço realizando SSH lateral, reconhecimento local ou ações administrativas fora de seu perfil normal.
A resposta deve priorizar contenção de identidade e persistência antes de reconstruções amplas. Contas de serviço usadas para SSH precisam ter chaves, credenciais e permissões revisadas, com rotação quando houver indício de uso indevido. Em seguida, remova persistências não autorizadas, preserve imagens e logs relevantes para análise forense e valide se há outros serviços systemd com padrões semelhantes. Como o ator pode tentar restabelecer presença, a correção deve incluir revisão de causas prováveis em sistemas de borda e servidores web, não apenas remoção do backdoor observado.
A mitigação de rede e SaaS exige inventário de integrações permitidas. Projetos, contas e tokens associados a APIs de produtividade devem ter proprietário, finalidade e escopo mínimos. Chamadas a APIs de planilhas vindas de servidores sem necessidade de negócio devem ser bloqueadas ou submetidas a aprovação explícita. Em ambientes com proxy, CASB ou logs de nuvem, crie detecções para padrões de polling repetitivo, contas desconhecidas e acessos a planilhas sem relação com fluxos corporativos normais.
Para sistemas de borda, a ação defensiva concreta é reduzir exposição, aplicar correções disponíveis, revisar configurações, remover serviços desnecessários e validar logs de autenticação e administração. Esses ativos devem receber monitoramento compatível com seu papel crítico, mesmo quando não suportam agentes tradicionais de endpoint. Quando a cobertura por EDR não for possível, compense com logs centralizados, integridade de arquivos, baseline de processos e alertas de mudança de configuração.
- Rotacionar credenciais de contas de serviço com uso SSH suspeito e reduzir permissões ao menor escopo operacional necessário.
- Remover serviços systemd e binários não autorizados somente após coleta forense suficiente para preservar linha do tempo e evidências.
- Revisar integrações com Google Sheets API, projetos de nuvem, contas técnicas e tokens que não tenham proprietário e finalidade documentados.
- Auditar SoftEther VPN Bridge e outras ferramentas de túnel para confirmar autorização, destino, processo dono e janela de instalação.
- Corrigir e endurecer servidores web e sistemas de borda, com validação específica de configurações, exposição pública e logs de exploração.
0 Comentários