Yurei reutiliza código aberto de ransomware em ataques de dupla extorsão

Família escrita em Go deriva do Prince-Ransomware, criptografa arquivos com extensão .Yurei, mantém símbolos no binário e falha ao remover cópias de sombra do Windows.

Componente	Ransomware Yurei, derivado do projeto aberto Prince-Ransomware e implementado em Go.
Vetor	Comprometimento prévio do ambiente seguido de execução do binário, enumeração de unidades locais e de rede e criptografia concorrente por unidade.
Impacto	Criptografia de arquivos com extensão .Yurei, extorsão por ameaça de vazamento de dados e negociação por página .onion com token de acesso.
Prioridade	Preservar evidências, isolar hosts afetados, verificar VSS, validar restauração por cópias de sombra e investigar exfiltração antes de reconectar sistemas.
Artefatos	Nota _README_Yurei.txt, extensão .Yurei, separador || no conteúdo criptografado, módulos filewalker, encryption e configuration, caminho local D:\satanlockv2\* em amostras analisadas.
Criptografia	Uso de ChaCha20 por arquivo, com chave e nonce aleatórios protegidos por ECIES usando chave pública do operador.
Limitação técnica	Ausência de rotina para excluir Shadow Copies do Windows, o que pode permitir recuperação parcial quando VSS está habilitado e íntegro.
Atribuição	Indícios operacionais apontam para possível origem no Marrocos, mas a confiança é baixa e não há confirmação suficiente para atribuição conclusiva.

Resumo técnico

Yurei é uma operação recente de ransomware que combina criptografia de arquivos com pressão por vazamento de dados. O grupo apareceu com uma vítima inicial no setor de fabricação de alimentos no Sri Lanka e, nos primeiros dias de atividade observada, adicionou organizações na Índia e na Nigéria ao seu site de vazamento. O modelo segue a lógica de dupla extorsão: primeiro o ambiente é comprometido e os arquivos são cifrados; depois, os operadores usam uma página em rede de anonimato para negociar pagamento, suposta descriptografia e não publicação de informações corporativas copiadas durante a intrusão.

A amostra descrita no material técnico é escrita em Go e preserva símbolos, nomes de módulos e funções no binário final. Esse detalhe reduz a dificuldade de engenharia reversa e expõe que a base de código vem majoritariamente do Prince-Ransomware, um projeto de ransomware disponibilizado publicamente e depois reaproveitado por outros operadores. Os nomes filewalker, encryption e configuration permanecem alinhados ao projeto original, e a lógica de alteração de papel de parede também mantém estrutura compatível com essa linhagem. A diferença mais relevante observada é operacional: Yurei altera a enumeração e criptografia de unidades para usar goroutines, permitindo processar drives em paralelo, e adiciona uma rotina para monitorar novas unidades de rede após a fase inicial de criptografia.

A operação expõe dois riscos distintos. O primeiro é técnico e imediato: perda de disponibilidade por criptografia de arquivos em estáções e servidores alcançados pelo malware. O segundo é de confidencialidade: mesmo quando há possibilidade de recuperação por cópias de sombra ou backups, a ameaça de publicação de dados pode sustentar a extorsão. Por isso, a resposta não deve se limitar a restaurar arquivos; é necessário determinar o caminho de intrusão, validar se houve exfiltração, revisar credenciais usadas no ambiente comprometido e preservar artefatos antes de qualquer limpeza agressiva.

Fluxo técnico

O binário percorre unidades disponíveis, seleciona arquivos para criptografia e grava o resultado com a extensão .Yurei. Para cada arquivo, a rotina gera uma chave ChaCha20 e um nonce aleatórios, cifra o conteúdo e protege esses parâmetros por ECIES com a chave pública controlada pelo operador. O arquivo final armazena a chave cifrada, o nonce cifrado e o conteúdo cifrado separados por ||. Esse formato é útil para hunting em disco porque cria um padrão estrutural além da extensão, embora a presença isolada de || não seja suficiente para confirmar infecção sem correlação com nome de arquivo, nota de resgate, execução do processo e alterações em massa.

A nota de resgate é gravada como _README_Yurei.txt e orienta a vítima a acessar uma página .onion com token de acesso para negociação. O texto promete uma ferramenta de descriptografia e um relatório sobre vulnerabilidades exploradas após pagamento, enquadrando a cobrança como se houvesse uma entrega técnica adicional. Essa promessa não muda a natureza do incidente: o ambiente já deve ser tratado como comprometido, com possível acesso interativo prévio, movimentação lateral, coleta de dados e uso de credenciais válidas ou roubadas. A presença do token na nota deve ser preservada como evidência, mas não deve ser usada em máquinas corporativas sem isolamento e decisão formal de resposta a incidente.

A rotina de papel de parede herdada tenta baixar Wallpaper.png para %TEMP% por PowerShell e depois compilar uma montagem .NET para chamar SystemParametersInfo com SPI_SETDESKWALLPAPER. No caso observado, o endereço remoto para download não foi fornecido, fazendo o comando falhar. Em seguida, a tentativa de definir um arquivo inexistente como papel de parede faz o Windows cair para um fundo sólido, frequentemente preto. Esse comportamento é importante porque pode aparecer nos logs como execução de PowerShell aparentemente quebrada, criação ou tentativa de uso de Wallpaper.png em diretório temporário e atividade .NET fora de fluxo administrativo normal.

A modificação de concorrência torna a execução mais agressiva sobre múltiplas unidades. Em vez de processar tudo de forma serial, o malware usa goroutines para criptografar drives de maneira simultânea. Após terminar a fase inicial, entra em uma rotina que observa novas unidades de rede e as adiciona à fila. Isso amplia o impacto em ambientes Windows com compartilhamentos montados, mapeamentos persistentes e sessões de usuário com acesso amplo a file servers. O alcance real ainda depende das permissões do processo, das credenciais ativas na sessão comprometida e dos controles de acesso nos compartilhamentos.

Superfície afetada

A superfície principal são hosts Windows nos quais o binário é executado com acesso a arquivos locais e unidades de rede. Como o fluxo depende das permissões efetivas do usuário ou serviço que executa o malware, estáções de trabalho com drives mapeados e contas com acesso amplo a pastas corporativas podem servir como ponto de amplificação. Servidores de arquivos, diretórios de engenharia, áreas financeiras, repositórios documentais e compartilhamentos operacionais ficam mais expostos quando não há segmentação por função, quando permissões herdadas foram acumuladas ao longo do tempo ou quando contas privilegiadas são usadas para tarefas de rotina.

A ausência de remoção de Shadow Copies é uma limitação operacional relevante. Ransomwares mais maduros costumam executar comandos ou APIs para apagar snapshots do Volume Shadow Copy Service, reduzir opções de recuperação local e forçar negociação. Yurei não inclui essa capacidade no comportamento descrito, então sistemas com VSS habilitado, snapshots recentes e volumes íntegros podem permitir restauração parcial. Essa possibilidade não elimina o incidente, porque dados podem ter sido copiados antes da criptografia e porque snapshots também podem estar desatualizados, incompletos ou inacessíveis em servidores já impactados.

Os artefatos de desenvolvimento sugerem reaproveitamento quase direto do Prince-Ransomware. A presença de símbolos, nomes de módulos preservados e caminhos como D:\satanlockv2\* indica baixa maturidade de empacotamento e possível relação técnica com amostras de SatanLockv2, também associadas à mesma base aberta. Esses pontos devem ser usados com cautela: são fortes para agrupamento de amostras e criação de detecções, mas insuficientes sozinhos para atribuição de identidade real ou geolocalização definitiva do operador.

• Hosts Windows com execução do binário Yurei e permissão de escrita sobre arquivos locais ou compartilhados.
• Unidades de rede montadas, inclusive compartilhamentos SMB acessíveis pela sessão comprometida.
• Ambientes com backups apenas online ou compartilhamentos de backup graváveis pelo mesmo contexto de usuário.
• Sistemas com VSS desabilitado, snapshots antigos ou políticas de retenção insuficientes para recuperação operacional.
• Organizações listadas em blog de vazamento, onde o risco de confidencialidade precisa ser avaliado separadamente da restauração de arquivos.

Hunting e telemetria

A busca deve combinar sinais em endpoint, disco, identidade, rede e armazenamento. Em endpoint, procure criação em massa de arquivos com extensão .Yurei, escrita de _README_Yurei.txt em múltiplos diretórios, aumento abrupto de operações de renomeação e escrita sequencial, além de processos Go desconhecidos executando a partir de diretórios temporários, perfis de usuário, downloads ou caminhos não administrados. Se houver EDR com telemetria de módulo e linha de comando, priorize processos que iniciem PowerShell para baixar Wallpaper.png em %TEMP% ou que invoquem compilação .NET para alterar papel de parede.

Em file servers, análise picos de escrita por uma única conta, principalmente quando várias árvores de diretório recebem arquivos .Yurei em curto intervalo. Eventos de acesso SMB, auditoria de objeto e logs de NAS podem revelar qual host originou a escrita. Essa identificação é crítica para contenção porque o processo pode continuar monitorando novas unidades de rede e cifrar compartilhamentos recém-conectados. Também é necessário revisar sessões ativas e tokens de acesso associados ao host inicial, pois a criptografia em rede costuma refletir as permissões da conta comprometida.

A telemetria de ameaça deve incluir os indicadores estruturais, não apenas nomes. O separador || no arquivo cifrado, a combinação de _README_Yurei.txt com extensão .Yurei, os módulos preservados filewalker, encryption e configuration, e caminhos de build contendo D:\satanlockv2\* ajudam a diferenciar Yurei de famílias não relacionadas. Ainda assim, não substituem hash, assinatura comportamental e correlação temporal. Como não há hash ou endereço de infraestrutura confirmado no contexto técnico recebido, qualquer regra de detecção deve ser escrita como comportamento ou artefato observável, sem inventar IoCs estáticos.

• Criação de _README_Yurei.txt em várias pastas durante a mesma janela temporal.
• Grande volume de arquivos renomeados ou regravados com extensão .Yurei.
• Execução de PowerShell tentando manipular Wallpaper.png em %TEMP%.
• Chamadas ou compilação .NET relacionadas a SystemParametersInfo e SPI_SETDESKWALLPAPER.
• Processos desconhecidos com comportamento de criptografia concorrente sobre várias unidades.
• Padrão de conteúdo com chave cifrada, nonce cifrado e dados cifrados separados por ||.
• Acesso SMB anômalo de uma estáção comum para múltiplos compartilhamentos em sequência.
• Presença de strings ou símbolos como filewalker, encryption, configuration e D:\satanlockv2\* em amostras coletadas.

Mitigação

A primeira medida é conter sem destruir evidências. Desconecte hosts afetados da rede, preserve memória quando possível, colete binários suspeitos, notas de resgate, listas de processos, conexões, tarefas agendadas, serviços recém-criados e logs de autenticação. Em file servers, identifique o host de origem das escritas e bloqueie sessões associadas. Revogue ou desabilite temporariamente contas envolvidas até concluir a análise de credenciais, principalmente se elas tiverem acesso a compartilhamentos amplos, administração local ou serviços críticos.

A recuperação deve separar disponibilidade de confidencialidade. Para disponibilidade, valide Shadow Copies antes de reinstalar sistemas ou limpar volumes, porque Yurei não remove VSS no comportamento descrito. Se snapshots íntegros existirem, teste restauração em ambiente isolado, confirme ausência de binários persistentes e compare amostras restauradas com backups offline. Para confidencialidade, trate a ocorrência como possível exfiltração: revise proxy, DNS, firewall, EDR, logs de transferência, compactadores, ferramentas de sincronização e acessos a repositórios documentais. A restauração de arquivos não encerra o caso se dados sensíveis foram acessados ou copiados.

A prevenção depende de reduzir o efeito de uma execução bem-sucedida. Mantenha backups offline ou imutáveis, VSS habilitado onde fizer sentido operacional, privilégios mínimos em compartilhamentos, segmentação de servidores de arquivos e bloqueio de execução em diretórios graváveis por usuário. Como a base do malware deriva de projeto aberto, controles comportamentais são mais resistentes do que IoCs fixos: detecções por renomeação em massa, escrita cifrada, nota de resgate, varredura de unidades e execução suspeita de PowerShell capturam variações menores sem depender de uma única amostra.

• Isolar endpoints com criptografia ativa e bloquear sessões SMB originadas desses hosts.
• Preservar _README_Yurei.txt, amostras do binário, eventos de PowerShell, logs de autenticação e registros de escrita em file servers.
• Verificar Shadow Copies e backups offline antes de apagar volumes ou reinstalar sistemas.
• Rotacionar senhas e revogar tokens de contas usadas em hosts afetados, começando por contas com acesso a compartilhamentos e administração.
• Auditar permissões em unidades de rede e remover acesso amplo que não seja necessário para a função do usuário.
• Criar detecções para extensão .Yurei, nota _README_Yurei.txt, separador || em arquivos recém-criados e strings preservadas no binário.
• Investigar possível exfiltração com logs de rede, proxy, DNS, EDR e repositórios de arquivos antes de declarar contenção completa.
• Testar restauração em ambiente isolado e validar integridade dos dados recuperados antes de retornar sistemas à produção.