Campanha observada contra organizações usa mapeamento prévio, coleta de credenciais, interrupção de serviços e criptografia seletiva de estáções, armazenamento e recursos de rede.
| Componente | Ryuk, ransomware Windows com dropper contendo módulos de 32 e 64 bits, rotina de injeção de processo, criptografia de arquivos locais e enumeração de compartilhamentos de rede. |
| Vetor | Implantação manual após mapeamento de rede, intrusão prévia e coleta de credenciais; o contexto não descreve o vetor inicial de acesso. |
| Impacto | Criptografia de centenas de PCs, sistemas de armazenamento e data centers em empresas afetadas, com tentativa de parar processos, serviços, cópias de sombra e arquivos de backup. |
| Prioridade | Investigar sinais de implantação manual, isolar hosts com execução do Ryuk, preservar telemetria de identidade e endpoint, restaurar a partir de backups validados e revisar credenciais expostas. |
| Artefatos | Arquivos PUBLIC e UNIQUE_ID_DO_NOT_REMOVE, persistência em chave Run com valor svchos, uso de window.bat e marcador HERMES em arquivos criptografados. |
| Financeiro | Pagamentos observados variaram entre 15 BTC e 50 BTC, com arrecadação total indicada acima de US$ 640 mil no período descrito. |
Ryuk aparece no contexto como uma campanha de ransomware de baixa sofisticação individual, mas com execução operacional direcionada. A diferença central em relação a campanhas massivas está no modo de implantação: a atividade não é descrita como spam amplo nem como exploração automatizada por kit, e sim como uso sob medida depois de uma fase anterior de reconhecimento, invasão, mapeamento interno e coleta de credenciais. Esse ponto muda a prioridade defensiva, porque a presença do binário tende a representar uma etapa tardia de comprometimento, quando o operador já conhece ativos relevantes e tenta maximizar o impacto sobre sistemas críticos.
Em duas semanas de atividade observada, várias organizações foram atingidas em diferentes regiões. O dano técnico descrito envolve a criptografia de centenas de computadores, ambientes de armazenamento e data centers dentro de cada empresa infectada. A campanha também teve retorno financeiro relevante, com pedidos de resgate que variaram entre 15 BTC e 50 BTC e pagamentos que, no total indicado, ultrapassaram US$ 640 mil. A existência de duas versões de nota de resgate, uma mais elaborada e outra mais direta, sugere tratamento distinto entre vítimas ou fases operacionais diferentes, mas o contexto não prova a existência de dois grupos separados.
A análise técnica relaciona Ryuk a HERMES por similaridade de código e de fluxo criptográfico. A ligação mais importante não é uma atribuição definitiva, e sim a reutilização aparente de lógica: funções de criptografia com estrutura semelhante, marcador HERMES preservado em arquivos criptografados, exclusões de diretórios parecidas, criação de arquivos com finalidades equivalentes e uso de um script em lote com nome window.bat para ações destrutivas contra mecanismos de recuperação. O texto também menciona que HERMES foi associado anteriormente a operações atribuídas ao Lazarus Group, mas a conclusão defensiva deve permanecer limitada: Ryuk pode ter sido operado por quem tinha acesso ao código de HERMES, por operadores anteriores ou por outro ator que obteve a base de código.
Para equipes de segurança, o caso deve ser tratado como ransomware pós-comprometimento. O binário de criptografia é apenas a parte visível da cadeia. Antes dele, a organização precisa procurar autenticações incomuns, acesso administrativo indevido, movimentação por compartilhamentos, uso anômalo de ferramentas de administração e alterações em servidores de backup, bancos de dados e estáções com privilégios. A contenção não deve terminar na remoção do executável; ela exige entender quais contas permitiram a implantação, quais sistemas foram enumerados e quais backups ainda permanecem íntegros.
O dropper do Ryuk é descrito como simples. Ele carrega no próprio binário dois módulos do ransomware, um para 32 bits e outro para 64 bits. No início da execução, gera um nome aleatório de cinco letras usando srand e GetTickCount como base de aleatoriedade. Em sistemas Windows XP ou Windows 2000, tenta gravar o payload em um caminho sob Documents and Settings\Default User; em versões posteriores, usa users\Public. Se a criação do arquivo falhar, tenta gravar no próprio diretório usando o próprio nome com a letra V anexada ao final. Em seguida, verifica se o processo está sob Wow64 para escolher o payload compatível e inicia o ransomware gravado por meio de ShellExecuteW.
Depois de iniciado, o ransomware aguarda alguns segundos e verifica se recebeu argumento de linha de execução. Quando esse argumento existe, ele é tratado como caminho de arquivo a ser removido, o que no fluxo do dropper corresponde ao próprio dropper. Em seguida, o Ryuk tenta derrubar mais de 40 processos e interromper mais de 180 serviços. A lista inclui software de antivírus, bancos de dados, backup e edição de documentos. A função defensiva dessa etapa é clara: reduzir proteção ativa, bloquear arquivos abertos por aplicações de produtividade ou bancos de dados e degradar a capacidade de restauração antes da criptografia em larga escala.
A persistência é implementada por meio da chave Run do usuário atual, com o valor svchos, imitando visualmente nomenclatura de sistema sem corresponder ao nome legítimo. O comando operacional foi omitido aqui por segurança, mas o efeito é registrar o executável para inicialização em logon. Depois disso, o malware tenta elevar privilégios para SeDebugPrivilege, monta uma estrutura com nome de processos, PID e tipo de conta proprietária, e percorre processos em execução para tentar injeção. Ele evita nomes específicos listados no binário, como explorer.exe, csrss.exe e lsaas.exe, além de processos executados por NT AUTHORITY.
A técnica de injeção descrita é direta e tem fragilidades próprias. O Ryuk obtém um handle do processo alvo com OpenProcess, aloca memória com VirtualAllocEx, grava sua imagem virtual no espaço de endereçamento remoto e cria uma thread para executar a lógica injetada. A alocação espera uma base específica e não inclui relocação apropriada, o que pode causar falha quando o endereço solicitado não está disponível. Essa limitação reduz a robustez técnica, mas não diminui o risco operacional quando a implantação é manual e ocorre em máquinas escolhidas com antecedência pelo operador.
A rotina injetada concentra a criptografia. Ela começa descriptografando nomes de APIs com uma chave definida e comprimentos de strings armazenados em array, carregando dinamicamente as funções necessárias. Antes de prosseguir, tenta gravar um arquivo de teste no diretório Windows, uma ação que depende de privilégio administrativo. Se a gravação falhar, o malware espera e repete a tentativa cinco vezes; persistindo a falha, encerra a execução. Quando a gravação tem sucesso, cria dois arquivos em subpasta do Windows: PUBLIC, contendo chave pública RSA, e UNIQUE_ID_DO_NOT_REMOVE, contendo uma chave embutida usada no fluxo de criptografia.
O modelo criptográfico tem três níveis. No topo está um par de chaves RSA global controlado pelos operadores, cuja chave privada não fica exposta no sistema da vítima. O segundo nível é um par RSA por vítima, embutido na amostra, com a chave privada já criptografada pela chave global. O terceiro nível é uma chave AES por arquivo, gerada pela API CryptGenKey. Essa chave é exportada com CryptExportKey, protegida pela chave RSA de segundo nível e anexada ao arquivo criptografado. O desenho explica por que a recuperação depende do material criptográfico controlado pelo operador e por que reutilização de uma mesma amostra em múltiplas vítimas poderia criar fraqueza operacional, caso o mesmo par por vítima fosse reaproveitado.
A superfície exposta é composta por endpoints Windows, servidores com acesso a volumes compartilhados, ambientes de armazenamento montados e recursos de rede alcançáveis a partir dos hosts comprometidos. O Ryuk percorre unidades locais e compartilhamentos de rede, criptografando arquivos e diretórios que não correspondem a termos presentes em uma lista interna de exclusão. Entre os termos preservados aparecem Windows, Mozilla, Chrome, RecycleBin e Ahnlab. A preservação de navegadores pode manter o acesso da vítima à nota de resgate e a meios de pagamento, enquanto a exclusão relacionada a Ahnlab reforça a herança técnica observada em HERMES, sem provar por si só alvo geográfico ou autoria.
A enumeração de rede usa APIs Windows como WNetOpenEnum e WNetEnumResource. O malware aloca buffer, enumera recursos, trata contêineres de rede de forma recursiva e monta uma lista de nomes separados por ponto e vírgula para posterior criptografia. Esse comportamento é especialmente crítico em ambientes onde estáções administrativas ou servidores de aplicação possuem acesso amplo a compartilhamentos. Um único host com credenciais privilegiadas pode expor arquivos de equipes inteiras, repositórios de documentos, diretórios de bancos de dados exportados e áreas de backup acessíveis por SMB ou outro mecanismo apresentado ao Windows como recurso de rede.
O impacto também inclui sabotagem de recuperação. O contexto descreve criação de um arquivo em lote para apagar cópias de sombra e arquivos de backup; comandos prontos foram omitidos, mas a finalidade é impedir restauração simples pelo próprio sistema operacional. Como o Ryuk também tenta interromper serviços de backup e bancos de dados, a defesa precisa assumir que a criptografia pode ter sido precedida por ações para degradar snapshots, agentes de proteção e consistência de arquivos. Isso não confirma exfiltração de dados nem movimentação lateral em todos os casos, mas confirma risco de indisponibilidade ampla quando contas e hosts com acesso a armazenamento compartilhado são usados na implantação.
- Hosts Windows com privilégios suficientes para gravar no diretório Windows e manipular processos ficam em risco maior de execução completa.
- Compartilhamentos de rede acessíveis a partir de sistemas comprometidos podem ser enumerados e adicionados à rotina de criptografia.
- Serviços de antivírus, banco de dados, backup e edição de documentos aparecem como alvos de interrupção antes da criptografia.
- Backups expostos ao mesmo domínio, às mesmas credenciais ou aos mesmos caminhos montados podem ser afetados pela fase destrutiva.
A busca deve combinar telemetria de endpoint, identidade, armazenamento e rede. No endpoint, os sinais mais relevantes são criação de executáveis com nomes aleatórios curtos em caminhos públicos de usuário, execução subsequente por ShellExecuteW, remoção do dropper por argumento, criação dos arquivos PUBLIC e UNIQUE_ID_DO_NOT_REMOVE, registro de persistência com valor svchos e presença de window.bat. Também é importante procurar falhas repetidas de escrita no diretório Windows seguidas por encerramento do processo, pois esse padrão pode indicar tentativa de execução sem privilégio administrativo suficiente.
Na camada de processo, a defesa deve correlacionar tentativas de obtenção de SeDebugPrivilege, uso de OpenProcess, VirtualAllocEx, escrita em memória remota e criação de threads em processos de usuário que não deveriam receber código de ferramentas administrativas. A técnica descrita não é sofisticada, mas sua ocorrência perto de paradas massivas de serviços e de acessos a arquivos em alta escala é um forte indicador de ransomware em andamento. A telemetria deve observar também a sequência de encerramento de dezenas de processos e interrupção de centenas de serviços, principalmente quando envolver proteção de endpoint, bancos de dados, backup e suítes de documentos.
Em arquivos, a presença do marcador HERMES dentro de itens criptografados é um artefato relevante para triagem e agrupamento. Esse marcador não deve ser interpretado isoladamente como prova de autoria, mas pode ajudar a distinguir a família de ransomware e a relacionar amostras. Alterações em grande volume, renomeações ou gravações sucessivas em diretórios compartilhados, seguidas de falhas de abertura por usuários, devem ser investigadas com prioridade. Em servidores de arquivo, logs de acesso podem revelar qual conta e qual host originaram a maior parte das alterações, informação essencial para contenção de credenciais.
A investigação de identidade precisa voltar ao período anterior à execução do binário. Como o contexto descreve operações manuais com mapeamento e coleta de credenciais, procure logons administrativos fora de padrão, autenticações em múltiplos servidores em curto intervalo, acesso a consoles de backup, uso de contas com privilégios em estáções não administrativas e conexões para compartilhamentos que normalmente não são acessados por aquele usuário. A ausência de um vetor inicial no contexto impede concluir como o acesso começou; por isso, a caça deve reconstruir a cadeia a partir do primeiro uso suspeito de credenciais e do primeiro host que executou o dropper.
- Criação de
PUBLIC,UNIQUE_ID_DO_NOT_REMOVEewindow.batem caminhos incomuns ou subpastas de Windows. - Valor de persistência
svchosem chave Run do usuário atual. - Sequência concentrada de interrupção de serviços de backup, antivírus, banco de dados e documentos.
- Uso de APIs de enumeração de recursos de rede seguido por alto volume de gravação em compartilhamentos.
- Arquivos criptografados contendo marcador
HERMESe chave AES exportada anexada ao conteúdo. - Logons administrativos e acessos a compartilhamentos iniciados antes da primeira execução observada do ransomware.
A resposta deve começar pela contenção do escopo de execução, não pela negociação. Hosts com sinais de Ryuk precisam ser isolados da rede para impedir continuação da enumeração e da criptografia de recursos remotos. Contas usadas nesses hosts devem ser tratadas como potencialmente comprometidas, com revogação de sessões, redefinição de credenciais e revisão de privilégios. Como a implantação é descrita como manual, é provável que o operador tenha escolhido máquinas com acesso útil; portanto, a remoção de um único binário sem revogar credenciais pode permitir nova execução por outro caminho já estabelecido.
A preservação de evidências é crítica. Antes de reconstruir sistemas, colete logs de segurança Windows, eventos de criação de processo, registros de serviço, alertas de EDR, histórico de acesso a compartilhamentos, alterações em chaves Run e eventos de ferramentas de backup. Também preserve amostras dos arquivos PUBLIC, UNIQUE_ID_DO_NOT_REMOVE, do executável suspeito e de arquivos criptografados representativos. Esses artefatos permitem confirmar a família, medir extensão de impacto e entender se houve reutilização de amostra ou material criptográfico em mais de um host. O conteúdo não sustenta afirmar vazamento de dados; a análise deve separar indisponibilidade por criptografia de qualquer hipótese de exfiltração, que exigiria evidência própria.
Na recuperação, priorize controladores de domínio, servidores de backup, servidores de arquivo, bancos de dados e estáções administrativas. Backups devem ser validados fora do ambiente afetado, com verificação de integridade e data anterior à execução do ransomware. Cópias conectadas ao mesmo domínio ou acessíveis pelas mesmas credenciais não devem ser presumidas íntegras, porque o Ryuk tenta destruir cópias de sombra e arquivos de backup. Depois da restauração, monitore tentativas de reintrodução da persistência svchos, criação dos arquivos associados e novas enumerações de recursos de rede.
A redução de risco de recorrência passa por segmentação e privilégio mínimo. Contas administrativas não devem manter acesso permanente a estáções comuns e compartilhamentos amplos; servidores de backup precisam de isolamento, autenticação forte e credenciais separadas; estáções administrativas devem ser restritas e monitoradas; e compartilhamentos de rede devem limitar escrita por necessidade real. A detecção deve alertar para combinações de comportamento: parada de muitos serviços, acesso massivo a arquivos, enumeração recursiva de recursos, manipulação de cópias de sombra e persistência em Run. Em uma campanha como Ryuk, cada sinal isolado pode parecer administrativamente plausível, mas a sequência completa é incompatível com operação normal.
- Isolar hosts afetados e bloquear imediatamente credenciais usadas neles, inclusive sessões administrativas ativas.
- Coletar telemetria antes de reinstalação ou restauração, preservando executáveis, arquivos auxiliares e logs de identidade.
- Validar backups em ambiente separado e confirmar que snapshots, agentes e repositórios não foram afetados.
- Revisar privilégios de contas com acesso a compartilhamentos, bancos de dados, backup e servidores críticos.
- Adicionar detecções para
svchos,PUBLIC,UNIQUE_ID_DO_NOT_REMOVE,window.bat, enumeração de recursos de rede e paradas massivas de serviços. - Separar investigação de indisponibilidade por criptografia de qualquer hipótese de vazamento, exigindo evidência de saída de dados antes de classificar o incidente como exposição.
0 Comentários