Silver Dragon amplia operações com Cobalt Strike, phishing e C2 via Google Drive

Silver Dragon amplia operações com Cobalt Strike, phishing e C2 via Google Drive

Cluster alinhado à China combina exploração de servidores expostos, arquivos LNK, hijacking de AppDomain, serviços Windows adulterados e backdoor GearDoor contra organizações governamentais no Sudeste Asiático e na Europa.

ComponenteCampanhas atribuídas ao cluster Silver Dragon, com uso de Cobalt Strike, MonikerLoader, BamboLoader, SilverScreen, ferramenta SSH em .NET e backdoor GearDoor.
VetorExploração de servidores públicos vulneráveis em fases de acesso inicial e, em campanha mais recente, phishing com anexos LNK maliciosos que extraem payloads embutidos por meio de cmd.exe e PowerShell.
ImpactoExecução de beacons, persistência por serviços Windows, injeção em processos, captura de tela, execução remota de comandos, transferência de arquivos, comunicação por tunelamento DNS, SMB, HTTP e Google Drive.
PrioridadeInvestigar servidores expostos, estáções que executaram anexos LNK, criação anômala de serviços, alterações em diretórios do Windows, tráfego DNS de beaconing e uso incomum de Google Drive por processos não autorizados.
Artefatosdfsvc.exe.config, dfsvc.exe, tzsync.exe, ComponentModel.dll, MonikerLoader, BamboLoader, C:\Windows\Microsoft.NET\Framework64\v4.0.30319, C:\Windows\AppPatch, C:\Windows\System32\wbem, C:\Windows\Fonts, C:\Windows\Debug\wiatrace.bak.
MitigaçãoRevisar exposição de servidores, bloquear execução de anexos LNK não confiáveis, auditar serviços recriados, restringir abuso de PowerShell, monitorar AppDomain hijacking e controlar acesso corporativo a serviços de armazenamento em nuvem.
Resumo técnico

Silver Dragon é um cluster de atividade alinhado à China com sobreposição operacional com campanhas associadas anteriormente ao ecossistema de APT41. A atividade observada se concentra em organizações de alto valor, principalmente entidades governamentais no Sudeste Asiático, com presença adicional na Europa. O conjunto de técnicas combina comprometimento de servidores expostos, uso de arquivos compactados em fases pós-exploração, phishing com atalho LNK armado, carregadores personalizados e implantação recorrente de beacons Cobalt Strike como carga final. A atribuição deve ser tratada como avaliação de inteligência baseada em convergência de TTPs, infraestrutura, artefatos e cadeia de execução, não como identificação direta de operadores individuais.

As cadeias de infecção identificadas têm três caminhos principais. Dois deles parecem desenhados para uso depois que um invasor já obteve acesso a um ambiente, pois são entregues em arquivos RAR com scripts de instalação que posicionam DLLs, arquivos de configuração e shellcode em diretórios sensíveis do Windows. O terceiro caminho usa phishing e anexo LNK, com payloads embutidos no próprio arquivo de atalho. Em todos os caminhos descritos, o objetivo inicial é criar uma execução controlada em host Windows e levar o fluxo até Cobalt Strike; em fases posteriores, o grupo usa ferramentas próprias para captura de tela, movimentação operacional, execução remota e exfiltração por Google Drive.

A operação tem valor técnico para defesa porque mistura técnicas que costumam atravessar controles isolados. O uso de binários legítimos do Windows, serviços recriados, carregamento reflexivo em memória, ofuscação de strings, criptografia simples em estágios intermediários, tunelamento DNS e abuso de serviço de nuvem confiável reduz a visibilidade quando a organização depende apenas de antivírus ou de bloqueios por domínio. A resposta exige correlação entre endpoint, serviços Windows, criação de processos, alterações no Registro, diretórios do sistema, tráfego DNS, uso de nuvem e eventos de identidade.

Fluxo técnico

A primeira cadeia usa AppDomain hijacking, mapeada à técnica T1574.014. O arquivo compactado contém um script de instalação que copia o arquivo de configuração e DLLs para C:\Windows\Microsoft.NET\Framework64\v4.0.30319 e posiciona o shellcode em C:\Windows\AppPatch. O arquivo dfsvc.exe.config altera o ponto de entrada do AppDomain para que a execução do utilitário legítimo dfsvc.exe carregue MonikerLoader. O script remove e recria o serviço legítimo DfSvc para forçar nova execução do binário e acionar a cadeia maliciosa. Em variante semelhante, o mesmo princípio é aplicado sobre tzsync.exe, binário associado ao serviço de sincronização de fuso horário.

MonikerLoader é um carregador .NET com strings ofuscadas por uma rotina baseada em Brainfuck e nomes de classes e métodos escolhidos para parecerem legítimos. Sua função é ler ComponentModel.dll, descriptografar o conteúdo por uma rotina ADD-XOR simples e carregar o módulo de forma reflexiva na memória. Em variantes anteriores, o segundo estágio não ficava em arquivo: os dados criptografados eram buscados no Registro em HKLM\Software\Microsoft\Windows. O segundo estágio repete parte dos mecanismos de ofuscação, prepara persistência baseada em serviço, aloca memória com permissão de leitura, escrita e execução, copia o shellcode descriptografado e transfere a execução para o payload final, identificado como beacon Cobalt Strike.

A segunda cadeia usa BamboLoader, um binário x64 em C++ entregue em arquivo compactado junto com shellcode criptografado. Após extração e execução do script, a DLL do carregador costuma ser copiada para C:\Windows\System32\wbem, enquanto o shellcode criptografado é escrito em C:\Windows\Fonts. O script manipula serviços com reg.exe, interrompendo e removendo um serviço original antes de recriá-lo para executar a DLL no contexto de serviço. BamboLoader dificulta engenharia reversa com achatamento de fluxo de controle e inserção de código inútil. Em seguida, lê o payload do disco, descriptografa com RC4 usando chave embutida, descomprime com LZNT1 pela API RtlDecompressBuffer e injeta o resultado em um processo Windows, como taskhost.exe, criado como filho. A etapa injetada ainda aplica uma camada adicional de XOR de um byte antes da carga final.

A cadeia de phishing usa anexos LNK maliciosos e foi associada principalmente a alvos no Uzbequistão. O arquivo de atalho ultrapassa 1 MB porque contém payloads embutidos em sua estrutura. Ao ser aberto, o LNK inicia cmd.exe, que chama PowerShell. O código PowerShell localiza o próprio atalho malicioso com base no tamanho, lê seus bytes brutos, extrai componentes por intervalos fixos e grava os arquivos no diretório temporário antes de executá-los. O fluxo abre um documento isca para reduzir suspeita do usuário e executa em segundo plano um binário legítimo usado para sideload de BamboLoader.

Superfície afetada

A superfície primária inclui servidores Windows expostos à internet que apresentem vulnerabilidades exploráveis ou configuração fraca suficiente para permitir acesso inicial. As cadeias baseadas em arquivos RAR indicam execução manual ou semimanual após comprometimento, porque dependem de um script de instalação que posiciona arquivos em diretórios do sistema e manipula serviços. Ambientes em que contas administrativas são reutilizadas, servidores têm acesso lateral a estáções e logs de criação de serviço não são centralizados ficam mais expostos ao encadeamento de pós-exploração.

Estáções de trabalho entram na superfície quando usuários recebem e executam anexos LNK. O risco aumenta quando o ambiente permite execução de PowerShell iniciado por cmd.exe, não aplica controle de anexos vindos de e-mail e não inspeciona arquivos de atalho com tamanho incomum. O abuso de Google Drive por GearDoor amplia a superfície para controles de SaaS e proxy: a comunicação usa um serviço legítimo, com arquivos e extensões que representam tarefas, resultados e heartbeats, o que exige visibilidade sobre processos que acessam a nuvem, conta utilizada, volume de operações e padrões de nomeação.

As ferramentas pós-exploração ampliam o impacto além da execução inicial. SilverScreen, também observado como ComponentModel.dll, captura telas de todas as telas conectadas, registra a posição do cursor e usa comparação de miniaturas em escala de cinza para salvar imagens completas apenas quando há mudança visual relevante. O resultado é compactado com JPEG e GZIP e anexado a um arquivo local estruturado para coleta posterior. A ferramenta SSH em .NET, baseada em Renci.SshNet, aceita IP, porta, usuário e senha por argumentos de linha de comando e suporta execução de comandos, sessões TTY interativas e upload ou download de arquivos.

  • Servidores públicos Windows comprometidos e usados para entrega de arquivos RAR com scripts de instalação.
  • Hosts com alterações em DfSvc, serviços relacionados a dfsvc.exe ou abuso de tzsync.exe.
  • Estáções que abriram anexos LNK grandes e executaram cadeia cmd.exe para PowerShell.
  • Endpoints com DLLs ou payloads em C:\Windows\System32\wbem, C:\Windows\Fonts, C:\Windows\AppPatch ou C:\Windows\Microsoft.NET\Framework64\v4.0.30319.
  • Ambientes com tráfego DNS anômalo, beacons HTTP atrás de Cloudflare, comunicação SMB entre hosts internos e acesso incomum ao Google Drive.
Hunting e telemetria

A caça deve começar por criação e recriação de serviços Windows em servidores e estáções, especialmente quando o evento envolve reg.exe, scripts em lote, diretórios do sistema e DLLs recém-gravadas. A combinação de parada, exclusão e recriação de serviço em sequência curta é um sinal de alto valor, principalmente quando seguida por execução de dfsvc.exe, tzsync.exe ou processo filho incomum. Também vale correlacionar gravações de dfsvc.exe.config em diretórios do .NET com execução subsequente do serviço DfSvc, pois esse padrão é compatível com AppDomain hijacking usado para carregar MonikerLoader.

Para a cadeia de BamboLoader, procure criação de DLLs em C:\Windows\System32\wbem, arquivos criptografados ou binários incomuns em C:\Windows\Fonts, processos filhos como taskhost.exe iniciados por serviços recém-criados e alocação de memória executável seguida de injeção. A telemetria de EDR deve priorizar eventos de processo com relações pai-filho anômalas, chamadas de carregamento reflexivo, uso de RtlDecompressBuffer, escrita em regiões de memória com permissão executável e shellcode que aplica descriptografia adicional antes de beaconing.

Na cadeia de phishing, os sinais mais fortes são anexos LNK com tamanho incomum, abertura de cmd.exe a partir de um atalho, PowerShell lendo bytes brutos do próprio arquivo e gravação de múltiplos componentes no diretório temporário. A detecção deve correlacionar o e-mail recebido, o nome do anexo, o hash do arquivo, a execução do atalho, as linhas de comando de PowerShell e a criação de binários no perfil do usuário ou em %TEMP%. Como o documento isca pode ser aberto junto com a execução maliciosa, a presença de um arquivo aparentemente legítimo não deve encerrar a investigação.

A comunicação de Cobalt Strike foi observada principalmente por tunelamento DNS, com outras amostras usando HTTP e servidores protegidos por Cloudflare, além de comunicação SMB para outros hosts comprometidos no mesmo ambiente. Isso exige baseline de volume, periodicidade, entropia e tamanho de consultas DNS por host, inspeção de processos responsáveis pelo tráfego e correlação com execução recente de loaders. Para GearDoor, a busca deve focar processos .NET desconhecidos autenticando em Google Drive, criação de pastas com identificador derivado da máquina, arquivos com extensões .png, .cab, .rar, .7z, .pdf, .bak, .zip e .db sendo usados como canal de tarefa e resposta.

  • Escrita ou alteração de dfsvc.exe.config e execução subsequente de dfsvc.exe em servidores ou estáções fora do padrão operacional.
  • Uso de reg.exe para remover e recriar serviços pouco antes de DLLs serem executadas em contexto de serviço.
  • Arquivos LNK acima de 1 MB iniciando cmd.exe e PowerShell com leitura de bytes do próprio atalho.
  • DNS com padrão de beaconing, consultas de alta entropia ou volume periódico originado de processo que não deveria resolver domínios externos com frequência.
  • Acesso a Google Drive por processo não autorizado, seguido por criação, exclusão e troca de arquivos com extensões usadas como comandos ou resultados.
Mitigação

A resposta deve priorizar contenção dos sistemas com sinais de execução de loaders, não apenas bloqueio de domínios. Em hosts suspeitos, isole a máquina, colete memória quando possível, preserve logs de criação de processo, serviços, PowerShell, Registro, DNS, proxy e EDR, e copie artefatos nos diretórios citados antes de remover arquivos. Como a operação usa Cobalt Strike e comunicação lateral por SMB em algumas amostras, assuma que um host comprometido pode ter sido usado para pivotar para outros sistemas internos. Revise sessões administrativas, credenciais usadas no período, conexões SMB e execução remota entre máquinas.

A mitigação preventiva passa por reduzir exposição de servidores públicos, acelerar correção de vulnerabilidades exploráveis, segmentar redes, remover privilégios administrativos desnecessários e bloquear execução não controlada de scripts de instalação em diretórios do Windows. Para AppDomain hijacking, monitore arquivos .config ao lado de binários legítimos do .NET, restrinja escrita em diretórios de framework e alerte quando serviços legítimos forem recriados fora de janelas de manutenção. Para a cadeia de phishing, aplique bloqueio ou sandbox de anexos LNK, aumente inspeção de atalhos grandes e controle PowerShell com registro de bloco de script, modo restrito quando aplicável e regras de redução de superfície de ataque.

No tráfego de rede, trate tunelamento DNS como hipótese central. Configure detecção por periodicidade, comprimento de consulta, subdomínios de alta entropia, ausência de comportamento humano e divergência entre processo e padrão esperado. Para Google Drive, use CASB, proxy ou logs de API para restringir contas não autorizadas, controlar upload e download por processo e detectar padrões de extensões usadas por GearDoor. Em ambientes onde Google Drive é permitido, a política precisa diferenciar cliente oficial, navegador corporativo e binários desconhecidos em execução no endpoint.

Depois da erradicação, valide se não restaram serviços recriados, DLLs posicionadas nos diretórios usados pelos loaders, arquivos locais de captura de tela, tarefas de comando no Google Drive ou payloads de atualização como C:\Windows\Debug\wiatrace.bak. Rotacione credenciais usadas em servidores comprometidos, contas administrativas e credenciais observadas em linha de comando da ferramenta SSH. Refaça a análise de escopo com base em logs históricos de DNS, SMB, PowerShell e criação de serviço para identificar hosts que receberam o mesmo pacote, executaram payloads paralelos ou se comunicaram com os mesmos padrões de C2.

  • Isolar hosts com execução de MonikerLoader, BamboLoader, SilverScreen, GearDoor ou beacons Cobalt Strike antes de remover evidências.
  • Auditar serviços Windows removidos e recriados, especialmente quando associados a dfsvc.exe, tzsync.exe, DLLs em wbem ou payloads em Fonts.
  • Bloquear ou submeter anexos LNK a sandbox, com alerta para atalhos grandes que iniciam cmd.exe e PowerShell.
  • Restringir gravação em diretórios do sistema e monitorar arquivos .config usados para AppDomain hijacking.
  • Controlar acesso a Google Drive por processo, conta e volume, com alerta para troca de arquivos .cab, .rar, .7z, .pdf, .bak, .zip, .db e .png fora do uso corporativo esperado.

Postar um comentário

0 Comentários