Campanha de sete meses combinou e-mails falsificados, documentos com macro, exploração do MS Equation Editor, carregadores por DLL side-loading e variações de persistência para atingir entidades públicas.
| Componente | Campanha atribuída ao grupo Rancor contra entidades governamentais do Sudeste Asiático, com documentos maliciosos, macros, RTFs explorando MS Equation Editor, loaders e payloads PowerShell. |
| Vetor | E-mails de spear phishing aparentando origem em funcionários de ministérios, embaixadas ou entidades públicas, com remetente provavelmente falsificado e documentos isca sobre temas governamentais. |
| Impacto | Execução de código no endpoint da vítima, persistência por tarefas agendadas, download de estágios adicionais, comunicação com C2 e envio de informações básicas da máquina e resultados de execução. |
| Prioridade | Reforçar controles sobre documentos Office e RTF, bloquear execução indevida de macros e objetos ativos, caçar tarefas agendadas recorrentes e revisar telemetria de DLL side-loading e PowerShell. |
| Artefatos | A campanha usou arquivos como OneDriveApp.vbs, OneDriveApp.ps1, wsc_proxy.exe, wsc.dll, plugins nbf.plugin e nbs.plugin, além de loaders que chamavam a função exportada RunningThread. |
| IoCs | Exemplos citados incluem 45.125.65[.]76, www.chinhphumofa.esmtp[.]biz, www.microsoft.https443[.]org e 199.247.6[.]253, todos mantidos em formato defangado. |
O grupo Rancor conduziu uma campanha prolongada contra entidades governamentais do Sudeste Asiático, com atividade observada ao longo de mais de sete meses e foco em alvos de ministérios, embaixadas e organizações relacionadas ao setor público. A operação começou por spear phishing e se destacou menos pela novidade do vetor inicial e mais pela persistência operacional: dezenas de mensagens foram enviadas a funcionários ligados aos mesmos ministérios, os remetentes aparentavam pertencer a órgãos oficiais e os documentos usavam assuntos compatíveis com rotinas administrativas, cartas oficiais, comunicados, pesquisas e instruções internas.
A cadeia técnica mudou ao longo do tempo. Foram observadas oito grandes variações de táticas, técnicas e procedimentos, combinando métodos de entrega, mecanismos de persistência e payloads diferentes. Em algumas fases, documentos Office com macros acionavam código armazenado em metadados do arquivo; em outras, RTFs exploravam vulnerabilidades conhecidas no MS Equation Editor por meio do construtor 8.t. A operação também alternou entre instaladores MSI contendo PowerShell, arquivos JavaScript gravados localmente, carregadores DLL, DLL side-loading por executáveis legítimos e, em uma das ondas, uso de Cobalt Strike Beacon como segundo estágio.
O objetivo técnico confirmado era obter execução no sistema da vítima, manter recorrência por tarefa agendada, baixar novos componentes e enviar ao servidor de comando e controle informações básicas da máquina junto com resultados de execução. O material disponível não sustenta afirmar vazamento de dados específicos, movimentação lateral ou comprometimento de sistemas centrais; o impacto deve ser tratado como comprometimento de endpoint com capacidade de controle remoto e expansão por estágios adicionais, condicionado ao sucesso da cadeia de entrega e à disponibilidade dos servidores C2.
As primeiras amostras associadas à campanha, observadas em dezembro de 2018, usavam documentos com macro curta que executava conteúdo armazenado no campo Company das propriedades do documento. Esse conteúdo criava um arquivo VBScript no diretório temporário e registrava uma tarefa agendada com execução recorrente. O script, por sua vez, buscava um pacote MSI em infraestrutura controlada pelo operador e o executava por meio do instalador do Windows. O MSI citado foi criado com Advanced Installer, recurso que permitia encapsular um script PowerShell responsável por receber instruções do C2 e devolver resultados de execução com informações da máquina.
Em janeiro e março, a cadeia foi ajustada. O estágio MSI intermediário deixou de aparecer em algumas amostras, e a macro passou a conter um bloco codificado em Base64 que era decodificado e salvo como arquivo JavaScript. A criação da tarefa agendada era acionada a partir do campo Comments do documento. A operação tentava registrar a mesma tarefa com permissões diferentes, buscando aproveitar privilégios mais altos quando disponíveis. Os nomes de tarefa, arquivos e padrões de URL tentavam imitar atualizações do Google Chrome, uma escolha voltada a reduzir suspeita em revisões superficiais de endpoint e rede.
Outra fase introduziu documentos RTF criados com o construtor 8.t, explorando falhas conhecidas no MS Equation Editor. Ao abrir o documento, o exploit acionava a criação de arquivos como C:\Windows\tracing\OneDriveApp.vbs e C:\Windows\tracing\OneDriveApp.ps1. O PowerShell mantinha função semelhante à dos estágios anteriores: comunicação com C2, recebimento de instruções e devolução de resultados. As iscas e nomes de componentes variavam para se passar por aplicativos da Microsoft ou do Google, mas a lógica operacional continuava centrada em execução, persistência e comunicação remota.
A campanha também empregou DLL side-loading. Em uma cadeia, o RTF malicioso gravava wsc_proxy.exe e wsc.dll no diretório temporário. O executável wsc_proxy.exe era um binário legítimo da Avast, enquanto wsc.dll continha a carga maliciosa. Ao abusar da forma como um executável confiável carrega bibliotecas, o operador tentava executar o código dentro de um contexto com menor chance de inspeção comportamental. Em ondas posteriores, um executável legítimo da Bitdefender foi obtido de um repositório GitHub possivelmente criado para a campanha, enquanto a DLL maliciosa baixava e executava internamente os plugins nbf.plugin e nbs.plugin.
A superfície exposta era composta principalmente por estáções de trabalho de usuários governamentais que recebiam documentos por e-mail e tinham capacidade de abrir anexos Office ou RTF. A pré-condição mais importante era a interação do usuário com o documento isca, seguida da possibilidade de execução de macro, exploração de componente vulnerável do Office ou execução de objetos ativos. Ambientes com macros amplamente permitidas, versões do Office sem correções contra falhas do MS Equation Editor, execução pouco restrita de PowerShell e baixa visibilidade sobre tarefas agendadas ficavam mais suscetíveis à cadeia observada.
A segmentação da campanha indica foco em entidades públicas específicas, não distribuição oportunista em massa. A reutilização de TTPs entre múltiplas entidades ao mesmo tempo mostra que cada variação de cadeia não era necessariamente exclusiva de um único alvo. A campanha também apresentou relações de infraestrutura com domínios e endereços previamente associados ao Rancor, incluindo uso de DDNS via ChangeIP[.]com, domínios C2 defangados e resolução passiva conectando infraestrutura nova a atividade anterior do grupo.
A atribuição permaneceu baseada em sobreposições técnicas e indícios operacionais. Entre os pontos citados estão metadados de documentos, uso do construtor RTF 8.t, código PowerShell com função semelhante entre ondas, dupla tentativa de criação de tarefa agendada, loaders com a função exportada RunningThread, falsificação de remetentes governamentais e disponibilidade de servidores C2 em uma janela horária limitada. Também foram mencionados metadados em chinês, pausa de atividade em fevereiro de 2019 e conexão indireta com amostra relacionada a atividade conhecida como 1937CN, mas esses elementos devem ser tratados como suporte contextual, não como prova isolada de origem.
O conjunto de alvos e artefatos aponta para uma operação de espionagem com evolução incremental. O material recebido não descreve exploração de zero-day, roubo confirmado de bases de dados, comprometimento de credenciais específicas nem nomes de vítimas individuais. A análise defensiva deve, portanto, concentrar-se em endpoints que processaram documentos suspeitos, caminhos de persistência local, tráfego de saída para C2, execução anômala de PowerShell e relações entre anexos recebidos por e-mail e criação de arquivos no sistema.
- Estáções de trabalho de funcionários de ministérios, embaixadas e entidades públicas que abriram documentos isca recebidos por e-mail.
- Ambientes com macros permitidas, exploração possível de MS Equation Editor e execução não controlada de PowerShell ou scripts locais.
- Endpoints onde executáveis legítimos de fornecedores de segurança foram usados como hospedeiros para DLL side-loading.
- Infraestrutura de rede com comunicação de saída para domínios DDNS e C2 defangados associados à campanha.
A caça deve começar pela linha do tempo de e-mails recebidos por usuários governamentais, especialmente mensagens que aparentem vir de departamentos públicos, embaixadas ou órgãos relacionados, mas apresentem inconsistências de autenticação, cabeçalhos ou origem. Como os remetentes foram provavelmente falsificados, controles como SPF, DKIM e DMARC ajudam a reduzir o ruído inicial, mas a investigação precisa correlacionar anexos, abertura de documentos, criação de processos filhos e gravação de arquivos em diretórios temporários ou em C:\Windows\tracing.
No endpoint, os sinais mais relevantes incluem execução de scripts logo após abertura de documentos Office ou RTF, criação de tarefas agendadas com intervalo de poucos minutos, uso de nomes que tentam imitar atualizações de Chrome, Google, Microsoft ou OneDrive, e processos PowerShell iniciados a partir de macro, JavaScript, VBScript ou instalador MSI. A presença de arquivo JavaScript derivado de conteúdo Base64 em macro também é um indicador comportamental importante, mesmo quando o nome do arquivo varia.
Para DLL side-loading, a investigação deve revisar pares incomuns entre executável legítimo e DLL local no mesmo diretório, principalmente quando o executável for de fornecedor conhecido e tiver sido colocado fora do caminho esperado de instalação. Eventos de carregamento de biblioteca, hashes de binários, assinatura digital do executável e ausência de assinatura na DLL carregada podem ajudar a distinguir uso legítimo de abuso. Os nomes wsc_proxy.exe e wsc.dll devem ser tratados como exemplos de artefatos observados, não como lista completa.
Na rede, a defesa deve procurar padrões de comunicação periódica com servidores C2, conexões para domínios DDNS, tráfego que tente imitar atualizações de software e resolução de domínios associados a ChangeIP[.]com usados em conjunto com anexos suspeitos. Exemplos defangados relevantes incluem www.chinhphumofa.esmtp[.]biz, www.microsoft.https443[.]org, 45.125.65[.]76 e 199.247.6[.]253. Esses indicadores devem ser enriquecidos com datas, hosts envolvidos e evidências de execução local antes de qualquer conclusão operacional.
- Documentos Office com macros que leem campos de metadados como
CompanyouCommentspara acionar execução local. - RTFs criados com o construtor
8.te eventos de exploração do MS Equation Editor seguidos por criação de scripts. - Tarefas agendadas recorrentes, especialmente com execução em intervalo de aproximadamente dois minutos e nomes que simulam atualização de software.
- PowerShell recebendo instruções remotas e enviando informações básicas da máquina ou resultados de execução.
- Carregamento de DLL local por executável legítimo de Avast ou Bitdefender fora do fluxo normal de instalação.
- Presença dos artefatos
OneDriveApp.vbs,OneDriveApp.ps1,wsc.dll,nbf.pluginounbs.pluginem hosts investigados.
A resposta deve priorizar redução do vetor de entrada e contenção de endpoints já expostos. Em e-mail, é necessário aplicar autenticação de domínio, endurecer filtros de anexos e isolar documentos recebidos de remetentes externos que se façam passar por órgãos públicos. Em estáções de trabalho, macros devem ser bloqueadas por padrão quando vindas da Internet, documentos RTF devem passar por análise antes da entrega ao usuário e componentes antigos do Office, incluindo superfícies relacionadas ao MS Equation Editor, devem permanecer corrigidos ou desabilitados conforme a política corporativa.
No Windows, a execução de PowerShell, VBScript, JavaScript via Windows Script Host e instaladores MSI acionados por documentos deve ser controlada por política, telemetria e lista de permissões quando possível. Tarefas agendadas criadas por processos de Office, scripts ou diretórios temporários devem gerar alerta de alta prioridade. Como a campanha repetiu a criação de tarefa com permissões diferentes para tentar obter contexto mais privilegiado, a investigação deve revisar tanto o usuário interativo quanto execuções elevadas associadas ao mesmo nome de tarefa.
Para DLL side-loading, a mitigação exige controle de aplicativo, validação de assinatura, monitoramento de carregamento de bibliotecas e bloqueio de execução de binários legítimos quando copiados para diretórios não autorizados. Executáveis de fornecedores confiáveis não devem receber confiança irrestrita apenas pela assinatura; o contexto de execução, o caminho do arquivo, a DLL carregada e a cadeia de criação de processo precisam ser analisados em conjunto. Quando houver confirmação de execução, a contenção deve incluir isolamento do host, coleta de memória e disco, preservação de anexos e revisão de tráfego de saída no período da infecção.
A erradicação deve remover tarefas agendadas, scripts, DLLs e plugins associados, mas também validar se houve download de estágios adicionais indisponíveis no momento da análise. Como alguns C2 estavam inacessíveis durante parte da investigação, ausência de payload final não deve ser interpretada como ausência de comprometimento. A validação pós-contenção deve confirmar que não há novas tarefas recorrentes, processos PowerShell anômalos, comunicação com domínios DDNS suspeitos ou reaparecimento de documentos isca no fluxo de e-mail.
- Bloquear macros de documentos originados da Internet e submeter anexos Office e RTF a análise em sandbox antes da entrega.
- Corrigir ou desabilitar superfícies vulneráveis do Office relacionadas ao MS Equation Editor em estáções expostas.
- Alertar para tarefas agendadas criadas por Office,
wscript,cscript, JavaScript, MSI ou PowerShell com execução recorrente curta. - Monitorar PowerShell com registro de script block, criação de processo e conexões de rede, preservando evidências para resposta a incidente.
- Aplicar controle de aplicativo para impedir DLL side-loading a partir de diretórios temporários ou caminhos não autorizados.
- Isolar hosts com execução confirmada, coletar artefatos, revisar tráfego C2 defangado e validar ausência de persistência antes de retorno à produção.
0 Comentários