Campanhas ligadas ao Paquistão miram entidades governamentais da Índia com backdoors e C2 em serviços legítimos

Campanhas ligadas ao Paquistão miram entidades governamentais da Índia com backdoors e C2 em serviços legítimos

Gopher Strike e Sheet Attack combinam phishing, geofencing, abuso de GitHub, Google Sheets, Firebase e Microsoft Graph para controlar hosts Windows e furtar documentos em alvos indianos.

ComponenteDuas campanhas contra entidades governamentais indianas, chamadas Gopher Strike e Sheet Attack, com backdoors GOGITTER, GITSHELLPAD, GOSHELL, SHEETCREEP, FIREPOWER e MAILCREEP.
VetorPhishing com PDFs, falsa atualização do Adobe Acrobat Reader DC, arquivos ISO ou ZIP entregues apenas a usuários Windows com endereços IP da Índia e arquivos LNK disfarçados de documento.
ImpactoPersistência por tarefa agendada, execução remota de comandos, uso de repositórios privados do GitHub e serviços Google e Microsoft como C2, entrega de Cobalt Strike Beacon e furto condicionado de documentos.
PrioridadeCaçar acessos anômalos a GitHub, Google Sheets, Firebase e Microsoft Graph a partir de estáções Windows de usuários-alvo, revisar execuções de LNK, ISO e VBScript e bloquear artefatos defangados associados.
ArtefatosGOGITTER cria VBScript em C:\Users\Public\Downloads, C:\Users\Public\Pictures e %APPDATA%; GITSHELLPAD usa command.txt e result.txt em repositórios privados.
IoCsExemplos defangados citados no contexto incluem github[.]com/jaishankai/sockv6 e adobe-acrobat[.]in; a campanha também usa serviços legítimos como canais de controle.
Resumo técnico

Entidades governamentais da Índia foram alvo de duas operações de ameaça que apresentam sobreposição tática com atividade associada ao ecossistema APT36, mas a atribuição descrita no contexto permanece em confiança média para um subgrupo novo ou para outro grupo alinhado ao Paquistão operando em paralelo. As campanhas receberam os nomes Gopher Strike e Sheet Attack e foram identificadas em setembro de 2025. O ponto comum entre elas é a tentativa de reduzir a visibilidade de segurança usando iscas documentais, validações no lado do servidor e canais de comando e controle apoiados em plataformas legítimas amplamente permitidas em ambientes corporativos.

Gopher Strike usa phishing com documentos PDF que exibem uma imagem borrada e uma janela falsa de atualização do Adobe Acrobat Reader DC. A interação com o botão de instalação aciona a entrega de um arquivo ISO apenas quando a requisição parte de endereço IP localizado na Índia e o User-Agent indica Windows. Esse filtro por geografia e plataforma limita a exposição do payload a sandboxes genéricas, crawlers e ferramentas automatizadas que não reproduzem o perfil esperado do alvo. Dentro da cadeia, o downloader GOGITTER, escrito em Golang, prepara VBScript, consulta servidores C2 em intervalos curtos, estabelece persistência com tarefa agendada e baixa um arquivo ZIP de um repositório privado do GitHub quando o artefato esperado não está presente no host.

Sheet Attack segue outra linha de abuso de infraestrutura confiável. A campanha usa PDFs e arquivos LNK para instalar backdoors leves que se comunicam por Google Sheets, Firebase Realtime Database e Microsoft Graph API. Os componentes descritos incluem SHEETCREEP, FIREPOWER e MAILCREEP, além de um ladrão de documentos baseado em PowerShell. O uso de serviços de nuvem legítimos complica a inspeção puramente baseada em reputação de domínio, porque o tráfego pode se misturar a fluxos normais de produtividade, colaboração e integração. A presença de erros em comandos servidos pelo canal de Google Sheets também sugere, como hipótese técnica, operação manual em alguns momentos da campanha.

Fluxo técnico

Na Gopher Strike, a etapa inicial depende da persuasão do usuário para abrir um PDF e aceitar uma suposta atualização necessária para visualizar o conteúdo. O servidor que hospeda a próxima etapa valida se o cliente está dentro da população de interesse, usando origem geográfica indiana e identificação de Windows no User-Agent. Quando as condições são atendidas, o alvo recebe um ISO contendo o payload. Essa combinação reduz a taxa de coleta por análise automatizada e permite que a infraestrutura entregue artefatos diferentes ou nenhum artefato a observadores fora do recorte operacional.

O downloader GOGITTER grava ou valida a presença de um arquivo VBScript em três locais de usuário: C:\Users\Public\Downloads, C:\Users\Public\Pictures e %APPDATA%. O script consulta comandos VBScript em dois servidores C2 pré-configurados a cada 30 segundos. A persistência é configurada por uma tarefa agendada que executa o script aproximadamente a cada 50 minutos. O mesmo componente procura adobe_update.zip nas mesmas pastas e, caso o arquivo não exista, obtém o arquivo de um repositório privado no GitHub associado a uma conta criada em 7 de junho de 2025. Após a obtenção bem-sucedida, a cadeia realiza uma requisição HTTP GET para adobe-acrobat[.]in, interpretada no contexto como possível sinalização de infecção concluída.

O ZIP baixado contém edgehost.exe, identificado como GITSHELLPAD, um backdoor leve em Golang que usa repositórios privados controlados pelo operador como canal de C2. O componente consulta command.txt em intervalos de 15 segundos, executa instruções recebidas, grava resultados em result.txt e envia a resposta de volta ao repositório por requisição HTTP PUT. Depois da execução, o arquivo de comando é removido do repositório. O contexto também descreve a obtenção posterior de arquivos RAR por cURL após acesso ao host, contendo utilitários para coleta de informações do sistema e o loader GOSHELL, usado para entregar Cobalt Strike Beacon após múltiplas camadas de decodificação. Esses utilitários são apagados após o uso.

GOSHELL incorpora duas propriedades relevantes para defesa. A primeira é o aumento artificial do tamanho do binário para cerca de 1 GB por inserção de bytes sem função no overlay do PE, técnica que pode pressionar limites de análise, varredura e armazenamento de produtos de segurança. A segunda é a execução condicionada a nomes específicos de host, comparados contra uma lista embutida. Esse comportamento reduz a utilidade de análise dinâmica em ambientes que não replicam o identificador do alvo e pode fazer o binário aparentar inatividade fora das máquinas pretendidas.

Na Sheet Attack, a cadeia também aplica validação por geografia e User-Agent para entregar um ZIP malicioso apenas a usuários Windows na Índia. O arquivo contém um LNK que se apresenta como documento e dispara a instalação do SHEETCREEP. Esse backdoor em C# usa Google Sheets como C2 para obter comandos executados por comando operacional omitido. Campanhas mais recentes descritas no contexto migraram de SHEETCREEP para LNKs que distribuem FIREPOWER, um backdoor em PowerShell que usa Firebase Realtime Database como C2 e também atua como condutor para um ladrão de documentos em PowerShell e para MAILCREEP em alvos selecionados. MAILCREEP é escrito em Golang e usa Microsoft Graph API para C2 e manipulação de e-mails.

Superfície afetada

A superfície primária é composta por usuários e estáções Windows dentro de entidades governamentais indianas que recebem documentos por e-mail e têm permissão para montar ISOs, abrir LNKs, executar scripts ou acessar serviços de nuvem comuns. O contexto não descreve exploração de vulnerabilidade específica, CVE ou comprometimento de servidor exposto à internet. O risco descrito depende de interação com iscas documentais, entrega seletiva por perfil de cliente e execução local dos artefatos baixados. Portanto, a avaliação defensiva deve se concentrar em fluxo de e-mail, comportamento de endpoint, execução de scripts, criação de tarefas agendadas e tráfego de saída para plataformas legítimas usadas de forma abusiva.

O uso de GitHub, Google Sheets, Firebase e Microsoft Graph amplia a superfície de detecção para além de domínios claramente maliciosos. Ambientes que permitem esses serviços sem inspeção contextual podem registrar as comunicações como tráfego comum de desenvolvedores, colaboração, banco de dados em tempo real ou integração com e-mail. A proteção precisa distinguir uso corporativo esperado de padrões de automação, consulta periódica, escrita de arquivos de resultado, acesso a repositórios privados desconhecidos e manipulação de mensagens fora do perfil normal do usuário ou da estáção.

  • Estáções Windows de usuários governamentais indianos que recebem PDFs por e-mail e podem interagir com falsas atualizações ou arquivos LNK.
  • Contas e endpoints com acesso permitido a GitHub, Google Sheets, Firebase Realtime Database e Microsoft Graph API.
  • Hosts onde surgem VBScript em diretórios públicos ou %APPDATA%, arquivos ISO recentes, ZIPs associados a atualização falsa e tarefas agendadas recorrentes.
  • Ambientes onde binários grandes em formato PE, como GOSHELL inflado artificialmente, não são analisados por limite de tamanho.
Hunting e telemetria

A caça deve começar por eventos de e-mail e endpoint que mostrem abertura de PDFs seguida por download de ISO ou ZIP, montagem de imagem de disco, execução de LNK e criação de scripts. Em Windows, eventos de criação de processo devem correlacionar leitores de PDF, exploradores de arquivos, interpretadores de script, PowerShell, comando operacional omitido e binários recém-extraídos de diretórios de usuário. A criação de tarefa agendada que referencia VBScript nos caminhos citados é um sinal de alta fidelidade quando ocorre em máquinas que não têm automações legítimas semelhantes.

Na camada de rede e proxy, a telemetria deve procurar requisições periódicas para repositórios privados ou caminhos de API associados a GitHub, acessos programáticos a Google Sheets, Firebase e Microsoft Graph, além de conexões para domínios defangados mencionados no contexto. Como esses serviços podem ser legítimos, a detecção precisa combinar destino, frequência, agente de usuário, processo de origem e identidade do usuário. Um padrão de consulta a cada 15 ou 30 segundos, escrita de arquivos de resultado, acesso a recursos desconhecidos e tráfego originado de processos fora do conjunto corporativo esperado deve receber prioridade.

Em hosts possivelmente comprometidos, os artefatos mais relevantes são a presença de adobe_update.zip, edgehost.exe, command.txt, result.txt, scripts VBScript nos diretórios indicados e arquivos RAR baixados após a etapa inicial. A investigação também deve revisar eventos de limpeza de ferramentas, porque o contexto descreve remoção dos utilitários após uso. Ausência dos arquivos não elimina comprometimento se houver registros de execução, downloads, tarefas agendadas, conexões de saída e criação temporária de artefatos no histórico de EDR, Sysmon, proxy, DNS, PowerShell e logs de identidade.

  • PDF aberto seguido por download seletivo de ISO ou ZIP, montagem de imagem de disco e execução de LNK em estáção Windows.
  • Criação de tarefa agendada apontando para VBScript em C:\Users\Public\Downloads, C:\Users\Public\Pictures ou %APPDATA%.
  • Acessos periódicos e automatizados a GitHub privado, Google Sheets, Firebase Realtime Database ou Microsoft Graph API por processos incomuns.
  • Requisições para adobe-acrobat[.]in ou para o repositório defangado github[.]com/jaishankai/sockv6, quando compatíveis com a janela temporal da atividade.
  • Binários Golang recém-criados, executáveis PE anormalmente grandes e execução condicionada por nome de host.
Mitigação

A resposta deve tratar a atividade como intrusão por phishing com execução de malware e C2 sobre serviços legítimos. A primeira ação é isolar endpoints com sinais de ISO, LNK, VBScript, tarefas agendadas suspeitas ou comunicação periódica com os canais descritos. Em seguida, é necessário preservar artefatos e telemetria antes da limpeza, incluindo histórico de processos, linha de comando registrada por EDR, eventos de tarefa agendada, cache de downloads, registros de proxy, DNS, PowerShell e acessos a APIs de nuvem. A contenção deve bloquear os indicadores defangados conhecidos e, principalmente, restringir padrões de abuso de GitHub, Google Sheets, Firebase e Microsoft Graph a identidades e aplicações aprovadas.

A correção estrutural envolve reduzir a execução de conteúdo ativo vindo de documentos, limitar montagem de ISO por usuários sem necessidade, controlar execução de LNK fora de locais confiáveis e aplicar regras de redução de superfície para scripts e PowerShell. Em ambientes com alto risco, anexos que simulam atualização de software devem ser detonados em sandbox com perfil geográfico e de cliente representativo, porque a campanha usa checagens no lado do servidor para evitar análise automatizada genérica. Controles de egress também precisam considerar comportamento, não apenas reputação: serviços legítimos devem ser permitidos com escopo, identidade, inspeção e alertas de anomalia.

Para erradicação, remova tarefas agendadas maliciosas, scripts, ZIPs, binários extraídos, LNKs e arquivos temporários somente após coleta forense suficiente. Revise documentos recentes acessados pelo usuário e permissões de e-mail quando houver indício de MAILCREEP ou abuso da Microsoft Graph API. Quando o ladrão de documentos em PowerShell for suspeito, avalie quais diretórios e extensões foram acessados, mas evite presumir vazamento sem telemetria que comprove coleta ou saída de dados. Após limpeza, valide que não há nova criação de command.txt, result.txt, chamadas recorrentes aos canais de C2 ou recriação de tarefas agendadas.

  • Isolar máquinas com execução de ISO, LNK, VBScript, edgehost.exe, adobe_update.zip ou tarefas agendadas desconhecidas.
  • Bloquear ou revisar acessos anômalos a GitHub privado, Google Sheets, Firebase Realtime Database e Microsoft Graph API a partir de endpoints de usuário.
  • Aplicar controles para impedir montagem de ISO e execução de LNK e scripts de diretórios de download, públicos e %APPDATA% quando não houver necessidade operacional.
  • Coletar telemetria antes da remoção de artefatos, incluindo processos, tarefas agendadas, PowerShell, DNS, proxy, EDR e logs de identidade.
  • Revisar permissões de aplicações e tokens associados à Microsoft Graph API se houver sinais de MAILCREEP ou manipulação de e-mail.

Postar um comentário

0 Comentários