A família combinava distribuição por kits de exploração e spam, painel para afiliados, comunicação C2 cifrada com RC4 e rotinas de criptografia baseadas em RSA-2048 e AES-256.
| Componente | Ransomware GandCrab, incluindo a primeira geração e a revisão chamada pela comunidade de GandCrab 2. |
| Vetor | Distribuição por kits de exploração Rig e GrandSoft, além de spam por e-mail, com operação baseada em afiliados. |
| Impacto | Mais de 50.000 vítimas foram infectadas, com estimativa de US$ 300 mil a US$ 600 mil em pagamentos de resgate. |
| Prioridade | Preservar evidências de endpoint e tráfego, identificar a variante pela extensão dos arquivos e buscar possibilidade de descriptografia antes de qualquer decisão operacional. |
| Versões | A primeira geração usava extensão GDCB; a revisão posterior passou a ser associada à extensão CRAB e corrigiu falhas presentes na implementação anterior. |
| Artefatos | Uso de mutex com dados derivados da máquina, coleta de informações do sistema, encerramento de processos, consulta DNS por processo separado e check-in HTTP com relatório cifrado. |
| Mitigação | Conter o host, preservar arquivos criptografados e identificadores da vítima, procurar chaves locais quando aplicável à primeira geração e validar ferramentas de descriptografia confiáveis. |
GandCrab representa uma operação de ransomware estruturada como serviço, com divisão clara entre criadores e afiliados. O malware surgiu em janeiro de 2018 e foi distribuído em escala por meio de kits de exploração e campanhas de spam. Os afiliados participantes repassavam entre 30% e 40% da receita de resgate ao operador principal e recebiam acesso a um painel web, suporte técnico e regras operacionais. Esse modelo permitiu que dezenas de afiliados executassem campanhas simultâneas, com mais de 80 participantes ativos e um afiliado responsável por mais de 700 amostras diferentes em um único mês.
A campanha observada afetou mais de 50.000 vítimas e acumulou uma estimativa de US$ 300 mil a US$ 600 mil em pagamentos. Os alvos descritos se concentravam principalmente na Escandinávia e em países de língua inglesa. O interesse técnico da família não está apenas no volume de infecções, mas na forma como a operação reagiu a uma quebra operacional: depois que uma ação coordenada envolvendo autoridades romenas, Bitdefender e Europol resultou em uma ferramenta gratuita de descriptografia, os operadores produziram uma revisão em menos de uma semana para recuperar a confiança criminosa na marca e corrigir problemas da primeira versão.
A ferramenta de descriptografia gratuita não dependia de uma quebra matemática do algoritmo de criptografia. O fator decisivo foi o acesso ao servidor mestre da operação, de onde foram recuperadas chaves privadas RSA usadas no processo de criptografia. Esse detalhe muda a leitura defensiva do caso: a criptografia do ransomware podia ser forte em teoria, mas a infraestrutura de gestão de chaves criou um ponto único de falha. Para equipes de resposta, o episódio reforça que a análise de ransomware precisa cobrir tanto o binário e a rotina de criptografia quanto o fluxo de geração, armazenamento, transmissão e recuperação das chaves.
O fluxo de execução do GandCrab era dividido em coleta inicial, comunicação com C2, criptografia dos arquivos e limpeza final. Logo no início, o malware alocava uma estrutura extensa para armazenar métricas e informações da máquina infectada. Entre os dados coletados estavam características da arquitetura do sistema por meio de GetNativeSystemInfo, além de informações usadas para derivar um identificador da vítima. Mesmo quando detectava layouts de teclado russos, comportamento que em outras famílias costuma acionar uma interrupção para evitar vítimas em determinadas regiões, o GandCrab registrava esse dado e continuava a execução.
O identificador de vítima, chamado internamente de Ransom ID, era derivado de parâmetros locais da máquina. O cálculo combinava o número de série do volume com um CRC32 baseado no próprio número de série e no nome do processador. Essa lógica tornava o identificador dependente de informações do host, não de um valor recebido externamente. O malware também criava um mutex com conteúdo variável, incluindo grupo do computador e identificador de resgate. Esse artefato é útil para hunting porque representa um marcador local da execução, embora seu valor exato dependa do ambiente infectado.
Depois da coleta, a família tentava encerrar processos que poderiam manter arquivos abertos e impedir escrita durante a criptografia. A técnica usava CreateToolhelp32Snapshot, Process32First e Process32Next para enumerar processos. A lista de processos mirados era semelhante à utilizada por Cerber, o que indica reutilização de conhecimento operacional entre famílias de ransomware. A finalidade defensiva desse detalhe é clara: encerramentos anormais de aplicações de produtividade, bancos de dados locais, clientes de e-mail ou outros programas que mantêm arquivos abertos podem aparecer pouco antes do pico de operações de escrita e renomeação de arquivos.
A rotina de criptografia usava RSA-2048 e AES-256. O malware gerava um par de chaves no host por meio da API criptográfica do Windows, começando por CryptAcquireContext e seguindo para CryptGenKey. Em seguida, exportava a chave pública e a chave privada com CryptExportKey. A implementação da primeira geração deixou uma falha relevante: ao não usar corretamente a opção associada a contexto não verificado, uma cópia da chave privada podia permanecer no repositório local de chaves. Essa condição não equivalia a um descriptografador universal para todos os casos, mas podia ajudar vítimas infectadas por GandCrab 1 em uma janela específica, especialmente quando arquivos tinham extensão GDCB e artefatos compatíveis apareciam em subpastas de %appdata%\Microsoft no período da infecção.
A comunicação C2 manteve desenho semelhante entre as duas gerações analisadas. As diferenças estavam nos domínios contatados e no grau de ofuscação aplicado à chave usada para proteger o tráfego. A primeira geração tentava resolver endereços C2 codificados no binário por meio de uma consulta DNS executada em processo separado. A resposta era devolvida ao processo principal por pipe criado com CreatePipe. Quando a resolução não produzia um endereço IP válido, o malware usava uma string de fallback sem valor operacional para a defesa. Quando a resolução funcionava, o binário montava uma requisição HTTP com um token de quatro dígitos, provavelmente ligado ao afiliado, e um relatório da vítima cifrado com RC4 e codificado em Base64.
O relatório de check-in continha parâmetros em formato semelhante a um corpo de requisição POST, com dados da vítima e material criptográfico sensível. Um ponto crítico é que a lógica incluía a chave privada no fluxo enviado, protegida apenas por RC4 com chave embutida ou derivada dentro do próprio executável. Essa proteção era uma barreira fraca contra análise, não um limite criptográfico robusto. Em ambientes nos quais registros completos de tráfego estivessem preservados, a combinação entre amostra, chave RC4 recuperável e logs do check-in poderia oferecer caminho para recuperação. Na prática, essa condição favorecia poucos casos, porque usuários e pequenas organizações raramente mantinham captura de tráfego detalhada no momento da infecção.
A superfície afetada incluía estáções Windows alcançadas por kits de exploração ou por mensagens de spam que entregavam a cadeia de infecção. O contexto não descreve uma exploração específica com CVE, versão de navegador ou aplicação vulnerável, portanto a exposição deve ser tratada como dependente do vetor de entrega observado em cada ambiente. A presença dos kits Rig e GrandSoft indica risco maior para estáções com navegação exposta a conteúdo malicioso e software cliente desatualizado, enquanto o vetor de e-mail amplia a superfície para usuários com anexos, links ou conteúdo malicioso processado fora de controles adequados.
A diferença entre GandCrab 1 e a revisão posterior é importante para resposta. A primeira geração foi associada a arquivos com extensão GDCB e continha a falha de contexto criptográfico que poderia deixar uma chave privada recuperável localmente em alguns cenários. A revisão chamada de GandCrab 2 pela comunidade foi associada à extensão CRAB e corrigiu falhas da implementação inicial, incluindo o problema que poderia permitir descriptografia ampla se explorado corretamente. Assim, identificar a variante não é apenas uma questão de nomenclatura; ela define o caminho de análise, a probabilidade de recuperação e os artefatos a preservar.
A operação também expôs superfície organizacional além dos endpoints. O painel de afiliados e o modelo de divisão de receita indicam que múltiplas campanhas podiam usar amostras diferentes, tokens distintos e infraestrutura variável sob a mesma família. Isso reduz a eficácia de controles baseados apenas em hash. Defesas precisam correlacionar comportamento de execução, encerramento de processos, criação de mutex, padrões de comunicação, extensões de arquivos, notas de resgate e anomalias de volume em operações de escrita.
- Estáções Windows expostas a spam ou navegação que aciona kits de exploração.
- Ambientes sem telemetria de endpoint suficiente para registrar encerramento de processos, criação de mutex e renomeação em massa de arquivos.
- Hosts infectados por GandCrab 1 com arquivos GDCB, nos quais artefatos locais de chave poderiam existir em circunstâncias específicas.
- Ambientes sem retenção de logs de proxy, DNS ou tráfego HTTP, reduzindo a chance de reconstruir o check-in inicial.
A investigação deve começar pela preservação do host e pelo congelamento do estado dos arquivos criptografados, identificadores de vítima e notas de resgate. Para GandCrab 1, a existência de arquivos com extensão GDCB e a presença de artefatos em subpastas de %appdata%\Microsoft criados no período da infecção são sinais relevantes. A busca não deve modificar a máquina antes da coleta, porque chaves locais, logs e metadados temporais podem ser necessários para validar uma possibilidade de recuperação.
No endpoint, sinais fortes incluem chamada de APIs de enumeração de processos seguida de encerramentos em série, geração de chaves via provedor criptográfico do Windows, alto volume de escrita em diretórios de usuário e criação de mutex com campos derivados da máquina. A sequência temporal importa: coleta de informações, encerramento de processos e início de criptografia formam uma cadeia comportamental mais confiável que um único evento isolado. Soluções EDR devem ser consultadas por árvores de processo nas quais um binário desconhecido cria processo auxiliar para resolução DNS, consome a saída por pipe e em seguida inicia comunicação HTTP.
Na rede, a defesa deve procurar padrões de resolução DNS incomuns iniciados por processos que não são navegadores ou serviços esperados, especialmente quando seguidos por requisições HTTP contendo parâmetros codificados ou blobs aparentando Base64. O uso de RC4 no conteúdo não torna a comunicação invisível; metadados como destino, frequência, processo originador, tamanho da requisição e proximidade temporal com atividade de criptografia ainda são úteis. Como o contexto não fornece domínios C2 concretos, a resposta deve se concentrar em comportamento, registros DNS, proxy, firewall e associação com hashes internos observados.
Em casos em que tráfego completo foi preservado, os registros do primeiro check-in podem ser mais valiosos que eventos posteriores. O relatório enviado ao C2 continha informações da vítima e material relacionado às chaves. A análise desse tráfego deve ser feita em ambiente forense controlado, sem executar amostras ou tentar contato com infraestrutura externa. O objetivo defensivo é reconstruir evidências já coletadas, não interagir com servidores maliciosos.
- Arquivos criptografados com extensão GDCB ou CRAB, usados para diferenciar famílias de artefatos e caminho de resposta.
- Criação de mutex com conteúdo derivado de grupo do computador e identificador de resgate.
- Chamadas a
CryptAcquireContext,CryptGenKeyeCryptExportKeypor processo suspeito antes de renomeação em massa de arquivos. - Encerramento sequencial de processos que poderiam bloquear acesso de escrita a arquivos.
- Processo auxiliar de resolução DNS com comunicação por pipe para o processo do malware.
- Requisições HTTP com conteúdo cifrado e codificado, próximas ao início da criptografia.
A resposta deve priorizar contenção e preservação. O host suspeito deve ser isolado da rede para interromper comunicação C2 e evitar novas ações do operador, mas evidências voláteis e artefatos de disco precisam ser preservados antes de limpeza agressiva. Em GandCrab, a identificação da variante é decisiva: arquivos GDCB apontam para a primeira geração e podem justificar busca forense por chaves locais; arquivos CRAB indicam revisão posterior com correções relevantes na implementação criptográfica.
Antes de qualquer restauração, equipes devem verificar a disponibilidade de ferramenta de descriptografia confiável compatível com a variante e com o identificador da vítima. Como a ferramenta gratuita citada no contexto dependia de chaves privadas recuperadas do servidor mestre, a validade do processo está ligada à correspondência correta entre vítima, chave e variante. Tentativas improvisadas de alteração de arquivos criptografados podem reduzir chance de recuperação; por isso, cópias preservadas dos dados afetados devem ser mantidas antes de testes.
No controle preventivo, a mitigação passa por reduzir a superfície de kits de exploração e spam. Isso inclui atualização de software cliente, bloqueio de conteúdo ativo desnecessário, filtragem de e-mail, detonação de anexos em sandbox, bloqueio de execução em diretórios de usuário e monitoramento de comportamento de criptografia. Como a operação usava afiliados e múltiplas amostras, listas estáticas de hash são insuficientes. Regras comportamentais, controle de aplicação, menor privilégio e backup offline com teste de restauração oferecem cobertura mais robusta.
A validação pós-incidente deve confirmar que não restaram processos, tarefas, binários ou artefatos associados à cadeia inicial. Embora o contexto descreva principalmente criptografia e comunicação C2, a investigação não deve assumir que o único dano foi a criptografia sem verificar logs de endpoint, proxy e identidade. Ao mesmo tempo, não há base para afirmar exfiltração de dados neste caso específico; a comunicação descrita envolve check-in e envio de relatório da vítima, não uma cadeia confirmada de roubo massivo de arquivos.
- Isolar hosts afetados e preservar imagem, logs, notas de resgate, extensões de arquivos e identificador da vítima.
- Distinguir GDCB de CRAB para orientar busca de artefatos locais e compatibilidade com descriptografia.
- Coletar logs DNS, proxy, firewall e EDR próximos ao primeiro horário de criptografia.
- Verificar ferramentas de descriptografia confiáveis antes de restauração ou reconstrução do sistema.
- Reforçar bloqueio de execução em diretórios graváveis pelo usuário e detecção de renomeação em massa.
- Testar restauração de backups offline e revisar retenção para evitar recuperação incompleta.
0 Comentários