Ghostwriter usa iscas do Prometheus contra órgãos governamentais da Ucrânia

Ghostwriter usa iscas do Prometheus contra órgãos governamentais da Ucrânia

Campanha atribuída ao Ghostwriter usa contas comprometidas, anexos PDF e arquivos JavaScript para coletar dados de sistemas Windows e preparar execução de código adicional.

ComponenteFluxo de phishing contra entidades governamentais da Ucrânia, usando iscas relacionadas à plataforma ucraniana de aprendizagem on-line Prometheus e componentes JavaScript identificados como OYSTERFRESH, OYSTERBLUES e OYSTERSHUCK.
VetorE-mails de phishing enviados a partir de contas comprometidas contêm um anexo PDF com link que leva ao download de um arquivo ZIP; dentro dele há um arquivo JavaScript executado no Windows.
ImpactoO payload coleta nome do computador, conta de usuário, versão do sistema operacional, horário da última inicialização e lista de processos em execução, envia os dados por requisição HTTP POST a um servidor de comando e controle e aguarda código JavaScript adicional executado com eval().
PrioridadeRestringir a execução de wscript.exe para contas de usuário padrão, revisar exposição a anexos e links em mensagens recebidas de contas confiáveis comprometidas e caçar execuções de JavaScript originadas de ZIPs baixados por fluxo de phishing.
ArtefatosOYSTERFRESH exibe documento isca e grava OYSTERBLUES ofuscado e criptografado no Registro do Windows; OYSTERSHUCK baixa e executa a rotina responsável por decodificar OYSTERBLUES.
AtribuiçãoA atividade é vinculada ao ator Ghostwriter, também conhecido como UAC-0057 e UNC1151, alinhado à Bielorrússia, com atividade observada desde a primavera de 2026.
Resumo técnico

Uma campanha vinculada ao Ghostwriter está usando temas associados ao Prometheus, plataforma ucraniana de aprendizagem on-line, para atingir organizações governamentais da Ucrânia. O fluxo observado combina engenharia social, abuso de contas de e-mail comprometidas e execução de JavaScript no Windows. A escolha de contas previamente comprometidas aumenta a credibilidade do contato inicial, porque a mensagem pode chegar de um remetente que já possui histórico, reputação ou relação operacional com o destinatário. O uso do Prometheus como isca também reduz a fricção social: em vez de depender de um tema genérico, a mensagem explora um serviço reconhecível no contexto ucraniano e conduz a vítima por etapas que parecem compatíveis com acesso a material de treinamento ou documento administrativo.

A cadeia começa com uma mensagem de phishing endereçada a entidades governamentais. O anexo PDF não carrega o componente principal por si só; ele funciona como etapa intermediária, contendo um link que leva ao download de um arquivo ZIP. Dentro do ZIP há um arquivo JavaScript. Quando executado, esse arquivo, identificado como OYSTERFRESH, apresenta um documento isca para distrair o usuário e, em paralelo, grava um payload ofuscado e criptografado chamado OYSTERBLUES no Registro do Windows. O fluxo ainda baixa e inicia OYSTERSHUCK, componente usado para decodificar OYSTERBLUES. Essa separação entre isca visual, armazenamento no Registro e decodificação por componente auxiliar dificulta a análise superficial baseada apenas no PDF ou no arquivo ZIP inicial.

O objetivo técnico confirmado no contexto é reconhecimento e preparação para execução adicional. OYSTERBLUES coleta dados do host, incluindo nome do computador, conta de usuário, versão do sistema operacional, horário da última inicialização e processos em execução. Essas informações são enviadas a um servidor de comando e controle por requisição HTTP POST. Depois disso, o componente aguarda resposta com código JavaScript de próximo estágio, executado com a função eval(). O payload final é avaliado como Cobalt Strike, ferramenta de simulação adversária amplamente abusada em atividades pós-exploração. O contexto não confirma movimentação lateral, roubo de dados ou persistência de longo prazo nesta cadeia específica; a leitura defensiva deve se concentrar no vetor de phishing, na execução de script, no armazenamento no Registro e na comunicação HTTP de comando e controle.

Fluxo técnico

O encadeamento técnico se apoia em uma transição controlada entre formatos comuns: e-mail, PDF, link, ZIP e JavaScript. O PDF age como ponte, não como exploit de leitor de documentos. O risco operacional surge quando o usuário interage com o link e baixa o ZIP. Essa escolha contorna parte das defesas que tratam o PDF como documento relativamente benigno, deslocando a execução para um script externo. Em ambientes Windows, a execução de arquivos JavaScript por mecanismos associados a wscript.exe pode permitir que código rode fora do navegador, com acesso a recursos locais compatíveis com o contexto do usuário. Por isso, a cadeia depende menos de exploração de vulnerabilidade e mais de execução induzida por engenharia social.

Depois da execução, OYSTERFRESH tem uma dupla função. A primeira é manter a experiência aparente do usuário ao exibir um documento isca. A segunda é preparar o payload real, escrevendo OYSTERBLUES no Registro do Windows em forma ofuscada e criptografada. Esse armazenamento desloca parte do conteúdo malicioso para uma área de configuração do sistema, o que pode reduzir a visibilidade para controles que analisam apenas arquivos recém-baixados. Em seguida, OYSTERSHUCK é baixado e lançado para decodificar OYSTERBLUES. A divisão em componentes favorece modularidade: o arquivo inicial não precisa conter tudo em claro, e a lógica de decodificação pode ser separada do artefato entregue por e-mail.

OYSTERBLUES executa reconhecimento local antes de qualquer próximo estágio. Nome do computador e conta de usuário ajudam a identificar o papel do host e o contexto de privilégio. A versão do sistema operacional pode orientar compatibilidade de payloads posteriores. O horário da última inicialização pode indicar estabilidade do sistema, reinicializações recentes ou possível janela de atividade do usuário. A lista de processos em execução permite inferir ferramentas de segurança, aplicações administrativas, clientes de comunicação e softwares corporativos presentes no endpoint. Após essa coleta, o envio por HTTP POST ao servidor de comando e controle cria um ponto claro de hunting em proxy, EDR, firewall de saída e telemetria de rede.

A etapa de resposta do servidor é crítica porque o malware aguarda código JavaScript adicional e o executa por eval(). Essa escolha permite que a lógica posterior seja fornecida dinamicamente, sem estar presente no artefato inicial analisado. O contexto informa que o payload final é avaliado como Cobalt Strike, mas não fornece configuração, endereço de infraestrutura, perfil de comunicação, hash ou beacon específico. Portanto, defesas não devem depender de IoCs ausentes. A abordagem mais robusta é detectar o comportamento: JavaScript originado de arquivo compactado, gravação de conteúdo codificado no Registro, execução de decodificador auxiliar, requisição HTTP POST após coleta de inventário local e uso de eval() para próximo estágio.

Superfície afetada

A superfície descrita é composta por entidades governamentais da Ucrânia que recebem mensagens de e-mail potencialmente enviadas por contas comprometidas. O uso de contas já comprometidas muda a prioridade de filtragem, porque reputação de remetente e familiaridade do domínio podem ser insuficientes para bloquear a mensagem. O conteúdo temático ligado ao Prometheus aumenta a chance de interação por usuários que reconheçam a plataforma. A superfície endpoint envolve estáções Windows capazes de abrir o PDF, acessar o link, baixar o ZIP e executar o JavaScript contido nele. O componente defensivo mais sensível é a permissão de execução de scripts para usuários padrão.

A campanha está ativa desde a primavera de 2026, conforme o material analisado, e usa uma cadeia que não depende de CVE, versão vulnerável ou exploração remota explícita. Isso desloca o controle para políticas de execução, inspeção de anexos, isolamento de navegação e monitoramento de comportamento. Organizações com permissões amplas para execução de wscript.exe, baixa inspeção de arquivos compactados ou pouca correlação entre e-mail e endpoint ficam mais expostas. Também há risco aumentado quando controles de e-mail confiam excessivamente em remetentes internos ou parceiros sem verificar sinais de comprometimento da conta de origem.

  • Entidades governamentais ucranianas que recebem mensagens com temas relacionados ao Prometheus.
  • Contas de e-mail comprometidas usadas como origem de phishing e como mecanismo de credibilidade social.
  • Endpoints Windows onde usuários padrão conseguem executar arquivos JavaScript por wscript.exe.
  • Fluxos em que um anexo PDF pode conduzir a link externo, download de ZIP e execução manual do conteúdo compactado.
  • Ambientes sem bloqueio ou alerta para gravação de payload ofuscado no Registro do Windows por processo de script.
Hunting e telemetria

A investigação deve começar pela correlação entre e-mail, download e execução. O primeiro conjunto de sinais envolve mensagens recebidas de contas legítimas ou previamente confiáveis, com anexo PDF e tema associado ao Prometheus. Em seguida, equipes devem verificar cliques em links dentro desses PDFs e downloads subsequentes de arquivos ZIP. No endpoint, a trilha mais relevante é a execução de JavaScript extraído de ZIP, especialmente quando acionada por wscript.exe ou outro mecanismo de script do Windows a partir de diretórios de usuário, pasta de downloads ou caminho temporário. Essa sequência é mais forte do que qualquer indicador isolado.

Na camada de host, o comportamento de OYSTERFRESH sugere buscas por processos de script que exibem um documento isca e, no mesmo intervalo, escrevem conteúdo codificado ou criptografado no Registro do Windows. O contexto não fornece chaves específicas do Registro, portanto a detecção deve observar padrões: gravações incomuns feitas por intérpretes de script, valores com alta entropia, dados ofuscados e criação de conteúdo logo antes de execução de outro componente. A presença de OYSTERSHUCK deve ser tratada como um estágio de decodificação; a telemetria útil inclui criação de processo, download de arquivo auxiliar, leitura do valor gravado no Registro e execução subsequente de payload decodificado.

Na rede, o ponto confirmado é a requisição HTTP POST para comando e controle após coleta de informações do sistema. Como não há domínio, IP, URI ou cabeçalho no contexto, a caça deve se apoiar em anomalias comportamentais: processo de script iniciando conexão HTTP externa, tráfego logo após enumeração de processos, corpo de requisição contendo metadados do host e resposta que pareça carregar código JavaScript. Em EDR, a chamada a eval() para executar código recebido dinamicamente é um sinal de alto valor quando aparece no mesmo encadeamento de processos iniciado por arquivo JavaScript vindo de ZIP.

  • E-mails com anexo PDF e link externo recebidos de contas comprometidas ou inesperadamente confiáveis.
  • Download de arquivo ZIP iniciado a partir de link contido em PDF relacionado ao Prometheus.
  • Execução de arquivo JavaScript por wscript.exe em diretórios de usuário, downloads ou caminhos temporários.
  • Processos de script gravando valores ofuscados ou criptografados no Registro do Windows.
  • Requisição HTTP POST feita por processo de script após coleta de nome do computador, usuário, versão do sistema operacional e lista de processos.
  • Uso de eval() para executar JavaScript recebido como próximo estágio.
  • Indícios de carga posterior compatível com Cobalt Strike, sem assumir configuração ou infraestrutura não informada.
Mitigação

A mitigação principal é reduzir a capacidade de execução de scripts fora de fluxos administrativos controlados. A recomendação explícita no contexto é restringir a execução de wscript.exe para contas de usuário padrão. Essa medida corta uma parte central da cadeia, porque o arquivo JavaScript entregue no ZIP depende da execução local para iniciar OYSTERFRESH. A restrição deve ser aplicada com validação de impacto operacional, exceções mínimas e monitoramento de tentativas bloqueadas. Quando a organização ainda precisa de Windows Script Host para rotinas legítimas, o controle deve separar contas administrativas, estáções de gestão e usuários finais, evitando que qualquer usuário de escritório possa executar scripts recebidos por e-mail.

A resposta também precisa tratar a origem do phishing. Como a campanha usa contas comprometidas, filtros baseados apenas em confiança histórica do remetente são insuficientes. Equipes devem reforçar análise de anexos PDF com links, inspecionar destinos de URL, desmontar arquivos ZIP em sandbox e bloquear execução direta de conteúdo compactado quando possível. Treinamento de usuário ajuda apenas se estiver conectado a controles técnicos: mensagens com PDF que conduzem a ZIP e JavaScript devem ser tratadas como padrão de alto risco, especialmente quando o tema tenta se passar por material de aprendizagem, documentação interna ou comunicação administrativa.

Em incidentes suspeitos, a ordem de resposta deve preservar evidências de e-mail, proxy, endpoint e Registro. O host deve ser isolado quando houver execução confirmada do JavaScript, gravação de payload codificado no Registro ou comunicação HTTP POST anômala. Em seguida, é necessário coletar a árvore de processos, arquivos baixados, valores de Registro modificados, histórico de navegação relacionado ao PDF e registros de rede. Como o componente aguarda código dinâmico e o payload final é avaliado como Cobalt Strike, a contenção não deve terminar na remoção do arquivo ZIP; é preciso verificar execução posterior, conexões persistentes e qualquer artefato lançado após a resposta do servidor de comando e controle.

  • Bloquear ou restringir wscript.exe para contas de usuário padrão e alertar tentativas de execução bloqueadas.
  • Impedir execução direta de JavaScript extraído de ZIPs recebidos por e-mail ou baixados a partir de links em PDFs.
  • Inspecionar PDFs com links externos e correlacionar clique, download de ZIP e criação de processo no endpoint.
  • Monitorar gravações no Registro feitas por processos de script, principalmente valores ofuscados, criptografados ou de alta entropia.
  • Isolar endpoints com execução confirmada de OYSTERFRESH, indícios de OYSTERBLUES no Registro ou download de OYSTERSHUCK.
  • Revisar contas de e-mail usadas como remetentes na campanha, tratando-as como possivelmente comprometidas e exigindo redefinição de credenciais e validação de sessões.
  • Caçar requisições HTTP POST originadas de processos de script e respostas contendo código JavaScript para execução dinâmica.

Postar um comentário

0 Comentários