🚀 A CloudSEK se torna a primeira empresa de segurança cibernética de origem indiana a receber investimentos da Estado dos EUA fundo
Leia mais

Em 15 de janeiro de 2026, os pesquisadores do CloudSEK detectaram o novo programa de afiliação relacionado à Gunra. O Gunra é um Ransomware-as-a-Service (RaaS) que foi visto ativo pela primeira vez em maio de 2025, mas o programa de afiliação foi lançado recentemente em um fórum da Dark Web em janeiro de 2026.
Aproveitando as operações estratégicas de Inteligência Humana (HUMINT), a equipe de pesquisa se infiltrou com sucesso no programa de afiliados da Gunra. Isso permitiu que os pesquisadores obtivessem as credenciais do painel RaaS e uma amostra ao vivo de ransomware para uma análise técnica abrangente.
O Gunra é uma operação sofisticada de ransomware voltada principalmente para sistemas Windows. Ele apresenta um painel de gerenciamento de afiliados completo, parâmetros de ataque configuráveis e recursos avançados de criptografia. O malware usa algoritmos criptográficos fortes e criptografa arquivos seletivamente, empregando exclusões inteligentes de caminhos para maximizar os danos e, ao mesmo tempo, garantir que o sistema permaneça operacional durante o processo de pagamento do resgate.
Grupo Gunra: uma operação profissional de ransomware como serviço (RaaS)
O Grupo Gunra administra um sofisticado modelo de negócios de Ransomware-as-a-Service (RaaS), utilizando um extenso programa de afiliados. Sua operação foi projetada para atrair cibercriminosos com motivação financeira que buscam ferramentas de ransomware prontas.
Principais detalhes operacionais:
O grupo reduz significativamente a barreira de entrada de agentes de ameaças menos sofisticados, oferecendo suporte abrangente aos afiliados. Esse suporte inclui documentação detalhada, um painel de gerenciamento fácil de usar e criadores de ransomware personalizáveis, facilitando a execução de ataques de ransomware.
Para apreciar plenamente o escopo das operações do Grupo Gunra, é crucial analisar seu alcance global e suas tendências recentes de atividade.
Distribuição global de vítimas
O mapa a seguir ilustra a distribuição mundial das vítimas alvo das afiliadas do Grupo Gunra. Esse visual destaca as principais regiões de foco e o amplo impacto internacional da operação de RaaS.

Cronograma de atividades operacionais (maio de 2025 a janeiro de 2026)
O gráfico abaixo fornece um resumo do ritmo operacional do Grupo Gunra nos últimos nove meses. Analisar a frequência e o tipo de suas atividades, incluindo recrutamento de novos afiliados, implantações bem-sucedidas de ransomware e frequência de comunicação na dark web, é essencial para entender sua trajetória de crescimento atual e seus períodos de pico de atividade.

Nossa análise começou com um anúncio no Ramp Forum da Dark Web, onde pesquisadores da CloudSEK identificaram um Ransomware como serviço (RaaS) programa de afiliados. A postagem destacou os principais recursos da oferta:

Uma operação direcionada de Inteligência Humana (HUMINT) foi lançada para engajar o agente da ameaça por meio do Tox ID fornecido. Utilizando uma engenharia social cuidadosa para estabelecer credibilidade na comunidade cibercriminosa, nossos pesquisadores conseguiram o seguinte:


Essa variante de ransomware de nível profissional emprega um sofisticado sistema de criptografia híbrida projetado para maximizar o impacto. Após a execução, o malware criptografa com eficiência os arquivos em todas as unidades acessíveis, inicializando seus threads de trabalho e identificando os arquivos-alvo com base nas listas de exclusão internas.
O processo de criptografia depende de uma arquitetura robusta:
Essa metodologia torna a recuperação de arquivos criptograficamente inviável sem a chave privada RSA correspondente dos atacantes.
O malware foi projetado para ser furtivo e confiável, operando totalmente offline durante a fase de criptografia. Todos os componentes necessários — incluindo a chave pública RSA-4096, listas de exclusão para diretórios e extensões de arquivos e uma nota de resgate pré-escrita com um endereço de serviço oculto do Tor — estão embutidos no binário. Essa abordagem off-line ignora os sistemas de detecção baseados em rede e garante a funcionalidade mesmo em ambientes isolados ou altamente seguros.

Após a execução, o binário do ransomware é carregado pelo carregador do Windows, e o controle é transferido para o função de início (0x1400014b0). Essa função primeiro estabelece o ambiente de execução antes de chamar a rotina de configuração principal em 0x1400015F1, onde o malware se prepara para o ataque.
O fase de configuração carrega o incorporado, formatado em PEM Chave pública RSA-4096. Essa chave é fundamental para o modelo de criptografia híbrida: enquanto o Algoritmo ChaCha20 criptografa os arquivos da vítima, a chave RSA é usada para proteger as próprias chaves ChaCha20. Isso garante que somente os invasores que possuem a chave privada correspondente possam descriptografar os dados.
Durante a configuração, o malware também define seu escopo operacional:
Finalmente, a fase de preparação termina com a inicialização de um conjunto de fios para dois trabalhadores e a preparação do BCryptGen Aleatório interface, que é essencial para gerar as chaves aleatórias criptograficamente seguras e não necessárias para o processo de criptografia.


Uma vez configurado, o ransomware inicia seu processo de busca de arquivos usando a função # #0x140002369 ##, um alterador de diretório recursivo. Essa função verifica sistematicamente o armazenamento da vítima, começando pela unidade A e passando pela Z, tentando acessar cada unidade e percorrer sua árvore de diretórios.
O malware emprega uma lógica de filtragem ao descobrir arquivos e pastas. Ele ignora os diretórios do sistema, como ## (C:\\ Windows, C:\\ Arquivos de Programas, C:\\ Arquivos de Programas (x86)) ##, para evitar perder tempo com arquivos não essenciais que não obrigarão a vítima a pagar. Para arquivos que passam por essa exclusão de diretório, o malware compara suas extensões com uma segunda lista de exclusão contendo tipos essenciais para o sistema, como (##.exe, .dll e .sys##). Arquivos com extensões de dados do usuário (por exemplo, documentos, bancos de dados, imagens, arquivos) são aprovados e adicionados a uma fila de trabalho centralizada para que os segmentos de criptografia sejam processados.



Para garantir que não haja dois arquivos iguais (e para tornar a recuperação um pesadelo total), o ransomware cria novas criptomoedas para cada arquivo usando as APIs BCrypt padrão do Windows. Especificamente, # #sub\\ _140005320## chamadas BCryptGen Aleatório (# #0x1400070F0 ##) para criar uma chave ChaCha20 exclusiva de 32 bytes (256 bits) e uma chave nonce de 12 bytes (96 bits) para cada arquivo.
A codificação real de arquivos é feita pela função # #0x140003765 ##, que usa a cifra de fluxo ChaCha20. Confirmamos isso porque detectamos as constantes mágicas clássicas do ChaCha20, a “expansão k de 32 bytes”, nos endereços # #0x140003776 e 0x140003794##. Para maior velocidade, ele processa arquivos em blocos de 1 MB. O trabalho pesado da mixagem do ChaCha20 acontece na função de um quarto de rodada # #0x140003710 ##, que inclui os movimentos característicos de rotação à esquerda (ROL) nas contagens de bits 16, 12, 8 e 7. Ele funciona por 20 rodadas, exatamente como a especificação ChaCha20 exige (10 iterações de loop com 2 pares de rodadas), terminando com o XOR final para transformar o texto simples em texto cifrado usando o keystream.
Depois que o ChaCha20 faz seu trabalho nos dados do arquivo, o ransomware protege as próprias chaves com a criptografia RSA-4096, gerenciada pela função # #0x140004936 ##. Essa função criptografa um pacote de chaves (tem cerca de 256 bytes) contendo a chave ChaCha20 de 32 bytes, a nonce de 12 bytes, além de algumas informações extras, tudo usando uma chave pública RSA incorporada. O texto cifrado RSA resultante, que tem cerca de 512 bytes, é inserido no final do arquivo criptografado ou armazenado em um arquivo.keystore separado nomeado com um hash SHA-256 do nome do arquivo original.


A fase final do ransomware envolve a limpeza pós-criptografia. Depois que os threads de trabalho concluem suas tarefas de criptografia, o código de gerenciamento de threads garante que todas as operações sejam concluídas, evitando a execução incompleta, o que prejudicaria a perspectiva do invasor.
A nota de resgate, localizada no endereço # #0x140012020 ##, serve como conjunto de instruções para a vítima. Ele os direciona a acessar o portal de pagamento por meio da rede Tor usando o URL do Onion, o ID do cliente e a senha fornecidos na nota.
Após a conclusão da criptografia de arquivos e da implantação da nota de resgate, o malware realiza uma limpeza final: desligando o pool de threads, zerando a memória confidencial (incluindo chaves de criptografia) e saindo de forma limpa.

O malware emprega um sofisticado algoritmo de seleção de arquivos, implementado na função 0x140001903. Esse mecanismo prioriza dados de alto valor e, ao mesmo tempo, garante que o sistema operacional da vítima permaneça funcional.
Estratégia de exclusão: O algoritmo primeiro extrai a extensão do arquivo usando strrchr para localizar o último ponto. Em seguida, ele executa uma comparação sem distinção entre maiúsculas e minúsculas com uma lista de exclusão (localizada em 0x140012780). Essa lista contém especificamente quatorze extensões de arquivo essenciais para o sistema:
[# #Exe, Dell, Sys, Com, Pif, Bat, Msi, Scr, Drv, Cxd, Mui, Cpl, Fon, ini##]
Os arquivos correspondentes a qualquer uma dessas extensões são imediatamente ignorados para preservar a operabilidade do sistema.
Estratégia de segmentação:
Todos os outros tipos de arquivo são direcionados para criptografia. Isso inclui dados valiosos do usuário, como:
Além disso, o malware evita criptografar sua própria nota de resgate (# #R3ADM3 .txt##) e quaisquer arquivos já marcados com a extensão ##.ENCRT##, evitando a recriptografia redundante. Essa abordagem direcionada maximiza o impacto nos dados da vítima, garantindo simultaneamente que ela possa acessar a nota de resgate e prosseguir com o pagamento.

O ransomware implementa uma arquitetura de pool de threads com threads de trabalho que processam arquivos em paralelo. A função # #0x140005500 ## gerencia o pool de threads, implementando um padrão produtor-consumidor em que as rotinas de enumeração de arquivos adicionam caminhos a uma fila compartilhada e os threads de trabalho extraem tarefas para processamento. A configuração padrão usa dois threads de trabalho, embora isso pareça configurável.
Esse processamento paralelo permite que o ransomware criptografe vários arquivos simultaneamente, sobrepondo a computação criptográfica às operações de E/S de disco. Enquanto um thread executa operações de criptografia ChaCha20 em um arquivo grande, outro pode estar lendo um arquivo diferente ou gravando dados criptografados. Combinada com o desempenho excepcional do ChaCha20, essa arquitetura permite que o malware criptografe sistemas de arquivos inteiros em minutos, em vez de horas.

O ransomware emprega um sofisticado sistema de armazenamento de chaves de modo duplo que depende de um componente criptográfico SHA-256 integrado. Esse componente, especificamente das funções 0x14000513A a 0x1400052C0, é usado exclusivamente para gerar nomes de arquivos exclusivos para os pacotes de chaves.
Em seu modo operacional de armazenamento de chaves separado, o malware precisa de um método confiável para vincular arquivos criptografados aos arquivos de armazenamento de chaves correspondentes. Em vez de usar o nome de arquivo original, potencialmente problemático (devido a caracteres especiais ou limitações de comprimento), o ransomware calcula o hash SHA-256 do nome do arquivo original. Esse hash é então convertido em uma string hexadecimal de 64 caracteres, que forma o nome do arquivo de armazenamento de chaves padronizado: {sha256_hash} .keystore.
A implementação do SHA-256 segue estritamente a especificação padrão. O processo envolve a função 0x14000513A para inicializar o contexto de hash com valores padrão (por exemplo, H0=0x6A09E667), 0x140005182 para processar dados em blocos de 64 bytes e 0x1400051D9 para as etapas de finalização e preenchimento. A transformação do núcleo é tratada pela função de compressão de 64 rodadas 0x140004F40, que usa constantes K padrão e operações sigma. Finalmente, a função 0x1400052C0 converte a saída de hash binário no formato de string hexadecimal necessário.
Essa abordagem criptográfica oferece vários benefícios: um tamanho de nome de arquivo consistente, independentemente do nome original, prevenção de problemas relacionados a caracteres especiais, exclusividade criptográfica para evitar colisões de nomes de arquivos e um processo de geração determinística que permite que o mecanismo de descriptografia localize com segurança o arquivo de armazenamento de chaves correto ao recalcular o mesmo hash.


Depois de concluir a análise estática inicial, os pesquisadores do CloudSEK transferiram a amostra para um ambiente de VM controlado e isolado para análise dinâmica. Esse estágio permitiu que a equipe observasse o “Locker” em ação, monitorando seu comportamento em tempo de execução, interações com o sistema e processos de criptografia à medida que eles se desenrolavam em tempo real.

Imediatamente após a execução, o ransomware gerou threads de trabalho e iniciou a enumeração de sistemas de arquivos de alto volume. Os registros do ProCmon mostram acesso sequencial rápido em várias letras de unidade, confirmando a rotina de varredura recursiva da unidade descrita no fluxo de execução estática.
Principais observações de tempo de execução:
O comportamento demonstra uma taxa de transferência otimizada consistente com uma arquitetura multisegmentada de produtor-consumidor.

A execução dinâmica confirma que o mecanismo de criptografia híbrida é acionado por arquivo. As capturas do ProcMon mostram um padrão de repetição:
Esse padrão é consistente em centenas de arquivos em segundos, demonstrando a vantagem de desempenho e a execução paralela do ChaCha20.
Além disso, arquivos de armazenamento de chaves são gerados quando o ransomware opera em modo de armazenamento de chaves separado. Eles aparecem como: ## {hash de 64 caracteres hexadecimais} .keystore##
Esses arquivos são criados no mesmo diretório do arquivo criptografado correspondente.

Depois que a criptografia é concluída em um diretório, o ransomware grava uma nota de resgate chamada R3ADM3.txt. O ProcMon captura um padrão determinístico:

Nenhuma solicitação de DNS, tráfego HTTP ou evento de criação de soquete foi observado durante a execução. O ransomware executa criptografia completa sem exigir conectividade de comando e controle, reforçando sua resiliência contra as defesas de isolamento da rede.
A interação com o portal Tor é conduzida pela vítima e ocorre somente após a criptografia, por meio de instruções na nota de resgate.
O ecossistema de ransomware prova que o número de agentes de ameaças sofisticados que possuem a habilidade de criar um armário do zero é pequeno, portanto, vemos alguma semelhança com outros armários ativos devido ao legado do código-fonte vazado do conti: