A recuperação após ransomware não começa pela promessa de uma chave. Ela começa por contenção, preservação, identificação da variante e escolha do caminho técnico: backup limpo, decryptor público, snapshots, dados originais ainda recuperáveis ou reconstrução de arquivos parcialmente cifrados.
O que é ransomware?
Para a SECURITY, a intenção desta página é recuperação de dados. Análise forense, resposta ao incidente e descriptografia são meios de chegar aos dados, não promessas de quebrar criptografia moderna sem chave.
Guia completo de recuperação de dados após ransomware
10 ações nas primeiras horas de um ataque de ransomware
Quatro caminhos técnicos para recuperar dados sem depender primeiro do pagamento
1. Backup limpo
É a rota preferencial quando existe recovery point confiável anterior ao comprometimento. Restore deve ocorrer em ambiente limpo e testado.
2. Decryptor público
Algumas famílias/versões possuem ferramentas gratuitas publicadas por pesquisadores e pelo No More Ransom.
3. Dados originais / versões
Arquivos deletados, snapshots, Shadow Copies, object versions ou blocos ainda não sobrescritos podem ser fontes de recovery.
4. Criptografia parcial
Algumas famílias cifram apenas partes de arquivos grandes. Regiões intactas podem permitir extração parcial ou reconstrução estrutural, dependendo do formato.
Nenhum desses caminhos é garantido. Em criptografia forte sem chave, sem backup, sem versões e sem regiões aproveitáveis, os dados podem ser irrecuperáveis.
Identificar a família é útil, mas a versão específica é o que determina a chance de descriptografia
O No More Ransom mantém uma biblioteca de decryption tools para famílias compatíveis. Isso não significa que toda amostra de uma família pode ser descriptografada: mudanças de versão, key handling e implementation bugs alteram a viabilidade.
No More Ransom
Primeira fonte pública recomendada para procurar decryptor compatível.
Ransom note
Nome, extensão, contact details e victim ID ajudam na identificação.
Arquivo de amostra
Compare cópia criptografada e, se houver, versão original conhecida em ambiente controlado.
Malware sample
Quando disponível, análise segura pode identificar algoritmo e comportamento. Não execute amostras em produção.
O No More Ransom orienta remover o malware antes de executar a solução de decryption. Em recuperação crítica, preserve a mídia e rode ferramentas sobre cópias sempre que possível.
Backup limpo, imutável e testado é a fonte de recuperação mais previsível
CISA recomenda backups offline e testes regulares de restauração. Microsoft recomenda cópias imutáveis e independentes, além de restore drills, porque sucesso do backup não prova que o restore funciona.
Offline / off-site
Fora do alcance das credenciais e do storage de produção.
Imutável
Proteção contra exclusão e alteração pelo atacante.
Restore testado
Recovery point precisa ser validado antes de confiar nele para retorno à produção.
Clean environment
Restaure em infraestrutura limpa para reduzir risco de reinfecção.
Arquivos grandes podem ter regiões intactas, mas isso não significa recuperação garantida
CISA documenta Play ransomware usando criptografia intermitente. A Microsoft documenta ransomware em 2026 com modos que cifram apenas percentuais distribuídos de arquivos grandes. Essa estratégia acelera o ataque a VMDKs, bancos e archives.
VM disk
VMDK/VHDX pode manter grandes regiões não cifradas, mas estruturas críticas podem ter sido atingidas.
Database
Páginas ou data regions podem sobreviver, porém consistency precisa ser validada no engine.
Archive
ZIP/7z e outros containers podem depender de headers/central directory e reagir de forma diferente.
Media / files
Alguns formatos toleram danos locais melhor que outros.
A SECURITY evita percentuais universais de recuperação porque a cobertura de cifragem, o offset e o formato do arquivo mudam entre famílias e incidentes.
Servidores atacados concentram várias camadas de recuperação no mesmo incidente
Windows Server
NTFS/ReFS, VSS, SQL, file shares, Active Directory e backups podem ser atingidos.
VMware ESXi
VMDK, VMX, snapshots e VMFS podem ser criptografados ou ficar inacessíveis.
Hyper-V
VHDX/AVHDX, CSV, ReFS/NTFS e checkpoints entram na análise.
Proxmox
QCOW2, ZFS, LVM-thin, Ceph e backups podem ser afetados.
Storage/SAN
Pool, LUN, snapshots, UNMAP e RAID podem influenciar o recovery.
Banco de dados
MDF/NDF/LDF, DBF, IBD, WAL/binlogs e dumps precisam de validação específica.
Ransomware em VMware: VMFS, VMDK, snapshots e storage subjacente
Algumas famílias atacam diretamente ESXi e desligam VMs antes de cifrar VMDKs. CISA documenta Play ransomware mirando extensões VMware e usando criptografia intermitente.
VMDK parcial
Grandes virtual disks podem conter regiões não cifradas, dependendo da variante.
VMFS
Não crie um novo datastore sobre a mesma LUN quando os dados precisam ser recuperados.
Snapshots
Deltas que sobreviveram podem conter estados úteis, mas dependem da chain.
RAID/SAN
Se o storage também falhou, a camada física vem antes do VMDK.
VHDX/AVHDX criptografados exigem preservar a cadeia antes de merge ou repair
Em Hyper-V, o ransomware pode atingir VHDX, AVHDX, CSV, backup shares e o filesystem do host. A recuperação precisa separar disk image, checkpoint chain e storage.
VHDX
Estruturas internas e regiões de dados podem ter cobertura de cifragem diferente.
AVHDX
Checkpoints podem conter alterações não presentes no base VHDX.
CSV
ReFS/NTFS e storage abaixo do CSV podem ser fontes adicionais de problema ou recovery.
Backup/Replica
Uma cópia secundária limpa pode ser mais segura que repair direto na origem.
Proxmox atacado: o backend real define o caminho de recuperação
QCOW2 é apenas uma possibilidade. Proxmox pode usar ZFS, LVM-thin, Ceph RBD, NFS ou storage externo. Não recrie pool, thin volume ou cluster antes de preservar o backend.
ZFS
Snapshots e zvols podem conter pontos não afetados se sobreviveram ao ataque.
LVM-thin
Thin metadata e volumes precisam ser preservados antes de repair.
Ceph
RBD snapshots/trash e object states podem oferecer caminhos conforme o incidente.
QCOW2
Backing chains e imagem base precisam ser preservadas.
QNAP, Synology e Asustor: RAID/pool, filesystem, snapshots e originais deletados
Famílias como Qlocker, DeadBolt e eCh0raix ficaram historicamente associadas a ataques em NAS. O caminho de recovery depende de RAID/SHR/ZFS, EXT4/Btrfs, snapshots, versões e do que aconteceu com os arquivos originais.
QNAP
Qlocker/DeadBolt são exemplos históricos. Não assuma que toda variante atual possui o mesmo caminho de recovery.
Synology
SHR/Btrfs snapshots e eCh0raix aparecem em históricos de incidentes.
Asustor
Volumes, snapshots e backups precisam ser avaliados conforme modelo e filesystem.
TRIM / UNMAP
SSD/thin pools podem reduzir a janela para originais deletados.
LUN deletada, snapshot removido ou pool corrompido após ataque
Storage corporativo adiciona mais uma camada entre RAID e os dados. O ransomware ou o atacante pode remover snapshots, apagar LUNs ou atingir o host que monta o volume.
Pool
Metadata de alocação e RAID/storage layout precisam ser preservados.
LUN
Excluir/recriar LUN pode substituir metadata; não faça isso por tentativa.
Snapshot
Snapshots de storage sobreviventes podem ser fontes valiosas.
UNMAP
Thin storage pode liberar blocos e reduzir a possibilidade de recuperar dados deletados.
SQL Server, Oracle, MySQL e PostgreSQL precisam de validação além do arquivo
Algumas famílias usam partial encryption em arquivos grandes, o que pode deixar regiões de dados intactas. Porém, recuperar bytes não garante consistency do banco.
| Engine | Arquivos comuns | Recovery | Validação |
|---|---|---|---|
| SQL Server | MDF/NDF/LDF/BAK | páginas/regiões intactas, backup | DBCC/engine em cópia |
| Oracle | DBF, control files, redo | datafiles/backups/redo | Oracle em ambiente isolado |
| MySQL | IBD/ibdata/binlog | tablespaces/logs/backups | engine e schema |
| PostgreSQL | data directory/WAL | base backup/WAL/files | cluster de teste |
Recuperar originais deletados depende do comportamento real do storage
HD mecânico
Blocos deletados podem permanecer até serem sobrescritos por novas gravações.
SSD
TRIM e garbage collection podem reduzir a disponibilidade de blocos liberados.
Filesystem
NTFS, ReFS, EXT, APFS e outros têm comportamentos diferentes após delete.
Uso posterior
Continuar gravando no mesmo volume pode sobrescrever justamente os dados que seriam recuperáveis.
Não é correto afirmar que todo ransomware necessariamente cria um arquivo novo e deleta o original. A técnica de cifragem varia por família. O diagnóstico precisa verificar o que realmente aconteceu.
Ransomware não substitui o problema físico: RAID ainda precisa estar coerente
RAID 1 / 10
Mirror, sem paridade
RAID 5
Paridade P
RAID 6
Paridade P + Q
NAS / Storage
Pool/LUN antes dos dados
Se o ataque ocorre num ambiente que já possuía discos degradados, rebuild interrompido ou storage com falha, a recuperação de ransomware pode exigir primeiro reconstrução do array. Caio Bruno F. Garcia é associado a RAID Low Level e análise com WinHex em casos de extrema complexidade.
Ransomware pode ser incidente de segurança mesmo sem vazamento confirmado
A ANPD define incidente de segurança como evento adverso confirmado que compromete confidencialidade, integridade, disponibilidade ou autenticidade de dados pessoais. Ransomware é citado como exemplo.
Disponibilidade
Indisponibilidade prolongada de sistemas com dados pessoais pode causar risco relevante.
Exfiltração
Se houve cópia/publicação, também existe impacto de confidencialidade.
Comunicação
Controladores sujeitos à LGPD devem avaliar se o incidente confirmado envolve dados pessoais e pode gerar risco ou dano relevante.
Documentação
Preservar logs, timeline e medidas adotadas ajuda a demonstrar resposta e mitigação.
Como funciona a recuperação remota para todo o Brasil
Como a SECURITY conduz um projeto de recuperação após ransomware
Se a falha física também está presente, podem entrar PC-3000, Data Extractor, DeepSpar e procedimentos em sala limpa ISO-5 quando necessários.
Caio Bruno F. Garcia, WinHex e RAID Low Level em incidentes de extrema complexidade
WinHex pode auxiliar inspeção de LUNs, RAID, VMFS, VMDK/VHDX, filesystems e regiões cifradas versus intactas quando o caso exige análise abaixo das ferramentas do sistema operacional.
RAID / LUN
Validar ordem, stripe, parity, offsets e estrutura física.
VMs
Comparar blocos e signatures em VMDK/VHDX/QCOW2.
Partial encryption
Mapear regiões cifradas e intactas em cópias de trabalho.
Filesystem / DB
Localizar estruturas e páginas que sobreviveram.
Principais plataformas encontradas em recuperação de ransomware
Vídeos da SECURITY sobre RAID, VMs e banco de dados
O vídeo complementa este artigo quando ransomware atinge uma infraestrutura com RAID, VMs e bancos em várias camadas.
Cenários técnicos de recuperação após ransomware
VMware ESXi com VMDKs parcialmente criptografados
Preservar datastore/VMDKs, mapear a cobertura de cifragem e extrair VMs/dados em cópias sem recriar VMFS.
QNAP/Synology com RAID íntegro e snapshots apagados
Preservar discos e pool, procurar versões sobreviventes e avaliar originais deletados antes de novas escritas.
Windows Server + SQL + backup repository criptografado
Separar recovery point limpo, datafiles parcialmente afetados e infraestrutura comprometida antes do restore.
Hyper-V com VHDX/AVHDX e CSV afetados
Preservar chain e volume, identificar o que foi cifrado e validar aplicações em ambiente isolado.
SAN com LUN deletada durante o incidente
Interromper novas alocações, preservar pool/LUN metadata e reconstruir camadas antes de VMs/databases.
FAQ sobre recuperação de dados após ransomware
O que é ransomware?
Ransomware é malware de extorsão que pode criptografar dados, bloquear sistemas e, em muitos ataques modernos, também exfiltrar informações antes da criptografia. A recuperação depende da variante, do storage, dos backups, dos snapshots, da extensão do dano e das ações executadas depois do incidente.
É possível recuperar dados de ransomware sem pagar resgate?
Em alguns casos, sim. Os caminhos técnicos incluem backup limpo, descriptografador público compatível, snapshots ou versões não afetadas, recuperação de dados originais ainda não sobrescritos e extração de regiões intactas quando a família usa criptografia parcial. Nenhum caminho é garantido para toda variante.
Pagar o resgate garante que os dados voltarão?
Não. O FBI declara que não apoia o pagamento porque ele não garante a devolução dos dados e incentiva novas atividades criminosas. Uma avaliação técnica deve ocorrer antes de tratar pagamento como solução de recuperação.
Qual é a primeira ação após identificar ransomware?
Isole imediatamente os sistemas afetados da rede e impeça propagação para shares, backups e outros hosts. Em seguida, preserve evidências, identifique o escopo e proteja backups limpos. A decisão de desligar ou manter um equipamento ligado depende do cenário técnico e da resposta a incidentes.
Devo desligar o servidor imediatamente?
Não existe uma regra universal. A CISA orienta isolamento imediato e, em certos cenários, recomenda desligar dispositivos afetados que ainda não foram completamente corrompidos para conter o dano. Porém, desligar também elimina memória volátil e evidências. Em incidentes corporativos, a decisão deve considerar propagação ativa, risco de novas escritas, TRIM/UNMAP, preservação forense e orientação de resposta a incidentes.
Devo rodar antivírus ou EDR logo após o ataque?
Ferramentas de segurança são importantes para conter e entender o incidente, mas limpeza e quarentena podem alterar evidências. Quando os dados são críticos, preserve logs, imagens e arquivos relevantes antes de executar ações que modifiquem a única cópia. O No More Ransom recomenda remover o malware antes de usar um decryptor.
Devo formatar o servidor ou reinstalar o sistema?
Não antes de preservar os dados e avaliar a recuperação. Formatar, recriar volumes, datastores, pools ou LUNs pode sobrescrever estruturas e blocos que ainda seriam úteis.
Como identificar a variante do ransomware?
A variante pode ser inferida por extensão dos arquivos, ransom note, artefatos do malware, indicadores de compromisso e serviços de identificação. Use outro dispositivo limpo para pesquisa e nunca execute amostras suspeitas em produção.
O que é No More Ransom?
No More Ransom é uma iniciativa internacional que disponibiliza ferramentas públicas de descriptografia para famílias compatíveis. A existência de uma ferramenta depende da variante e da versão específica do ransomware.
Posso usar um descriptografador gratuito diretamente nos arquivos originais?
É melhor trabalhar sobre cópias. O próprio No More Ransom orienta remover o malware antes de usar o decryptor. Em dados críticos, preserve os originais para permitir uma segunda abordagem se a ferramenta falhar.
Backup também pode ser criptografado pelo ransomware?
Sim. Ataques frequentemente procuram backups acessíveis pela mesma rede ou credenciais. CISA e Microsoft recomendam backups offline, isolados ou imutáveis e testes periódicos de restauração.
Snapshot é backup contra ransomware?
Não por definição. Snapshots podem estar no mesmo storage ou sob a mesma administração e também ser apagados ou criptografados. Eles podem ser úteis se sobreviveram intactos, mas backup independente é a proteção mais robusta.
O que é dupla extorsão?
É o modelo em que os atacantes exfiltram dados antes de criptografar e ameaçam publicar as informações além de bloquear a disponibilidade. Nesse caso, recuperação de dados e resposta ao incidente precisam tratar confidencialidade e disponibilidade separadamente.
Ransomware pode criptografar apenas parte de arquivos grandes?
Sim. Algumas famílias usam criptografia intermitente ou parcial para ganhar velocidade. CISA documenta Play ransomware usando criptografia intermitente e a Microsoft documenta famílias que cifram percentuais ou blocos distribuídos de arquivos grandes.
Criptografia parcial significa recuperação garantida?
Não. Regiões intactas podem existir, mas recuperar um arquivo funcional depende de quais estruturas foram atingidas. Bancos, VMs e arquivos compactados podem falhar mesmo com grande quantidade de bytes não cifrados.
É possível recuperar VMDK criptografado?
Pode existir viabilidade quando a criptografia é parcial, existem snapshots, backup ou blocos originais ainda acessíveis. O trabalho precisa considerar VMFS, VMDK base, deltas, guest filesystem e storage subjacente.
É possível recuperar VHDX ou AVHDX após ransomware?
Pode existir viabilidade dependendo da cobertura da criptografia e da integridade da cadeia Hyper-V. Preserve VHDX, AVHDX e o volume do host antes de merge, repair ou restore.
Proxmox e ZFS atacados por ransomware podem ser recuperados?
Pode existir viabilidade conforme o estado do pool, zvols, LVM-thin, QCOW2, Ceph, snapshots e backups. Preserve o backend e não recrie pools ou volumes antes de avaliar.
NAS QNAP ou Synology atacado pode ter recuperação?
Pode. A análise considera RAID/pool, filesystem, snapshots, versões, arquivos ainda intactos e possíveis dados originais deletados. O comportamento de TRIM/UNMAP e o tipo de storage influenciam muito a viabilidade.
O que são Qlocker, DeadBolt e eCh0raix?
São famílias historicamente associadas a ataques contra NAS, especialmente QNAP e Synology em determinados períodos. A estratégia de recuperação deve ser definida pela variante e pelo estado real dos dados, não apenas pelo nome do ataque.
TRIM e UNMAP podem afetar a recuperação?
Sim. Em SSDs, thin storage, NAS e SAN, TRIM/UNMAP pode informar ao dispositivo que determinados blocos foram liberados. Isso pode reduzir a possibilidade de recuperar dados deletados, dependendo da implementação e do tempo decorrido.
HD é diferente de SSD na recuperação pós-ransomware?
Sim. Em HD, blocos de arquivos deletados podem permanecer até sobrescrita. Em SSD, TRIM e garbage collection podem reduzir rapidamente a disponibilidade de blocos deletados. O resultado depende do filesystem, controladora e comportamento do dispositivo.
É possível recuperar banco SQL Server criptografado?
Pode existir viabilidade dependendo do que foi cifrado. MDF/NDF/LDF parcialmente afetados podem conter páginas intactas, mas recuperar bytes não é o mesmo que garantir consistência do banco. A validação deve ocorrer no nível da aplicação.
Oracle, MySQL e PostgreSQL também podem ser recuperados?
Podem existir caminhos de recuperação conforme os datafiles, logs, tablespaces, WAL/binlogs, backups e cobertura da criptografia. Cada engine exige validação específica.
Ransomware pode apagar Shadow Copies?
Sim. Diversas famílias tentam remover mecanismos de recuperação do Windows, inclusive Volume Shadow Copies. Se alguma shadow copy ou snapshot sobreviveu intacta, ela pode se tornar uma fonte de recuperação.
É possível recuperar arquivos originais deletados pelo ransomware?
Em alguns ataques, o malware cria uma versão criptografada e remove o original, ou substitui o conteúdo por outra versão. A recuperação de originais depende do método usado, do filesystem, de TRIM/UNMAP e de quanto o storage foi reutilizado.
Posso renomear a extensão do arquivo criptografado para abrir?
Não. A extensão é apenas um nome. Se o conteúdo foi criptografado, renomear não restaura a estrutura original.
Devo reiniciar um servidor após ransomware?
Não use reboot como tentativa automática. Alguns incidentes exigem contenção imediata; outros precisam preservar evidência volátil. Documente o estado e siga uma decisão coordenada de resposta e recuperação.
Como recuperar ransomware em VMware ESXi?
Primeiro preserve storage e VMDKs. Depois se avalia VMFS, snapshot chain, padrão de criptografia e guest filesystem. Se o RAID ou SAN falhou, a camada física vem antes do VMDK.
Como recuperar ransomware em Hyper-V?
Preserve VHDX/AVHDX, CSV/ReFS/NTFS e logs. Não execute merge, CHKDSK ou restore desordenadamente sobre a única cópia antes de entender a cadeia.
Como recuperar ransomware em NAS?
Preserve o conjunto RAID/pool, filesystem, snapshots e arquivos criptografados. A recuperação pode combinar reconstrução do array, versões intactas, undelete e análise de criptografia parcial.
Como recuperar ransomware em storage SAN?
Preserve LUNs, pool metadata e snapshots. Evite formatar, recriar LUNs ou executar UNMAP/TRIM desnecessário. O recovery pode envolver RAID, pool, LUN, VMFS e VMs em múltiplas camadas.
O ransomware pode ser um incidente de LGPD?
Sim. A ANPD reconhece ransomware como exemplo de incidente de segurança. Se o incidente confirmado envolver dados pessoais e puder gerar risco ou dano relevante aos titulares, o controlador deve avaliar as obrigações de comunicação à ANPD e aos titulares conforme a LGPD e as regras vigentes.
Ransomware sem exfiltração precisa ser avaliado pela LGPD?
Sim, porque disponibilidade e integridade também fazem parte da segurança de dados pessoais. A ANPD afirma que incidentes não se limitam a vazamento; indisponibilidade prolongada pode gerar risco relevante.
É possível recuperar ransomware remotamente?
Sim, em muitos casos lógicos. Se o storage está estável e acessível, a triagem pode começar remotamente com logs, arquivos de amostra, VMs, bancos e snapshots. Falhas físicas ou storage instável podem exigir envio de mídias.
Preciso levar o servidor ou NAS inteiro?
Na maioria dos casos lógicos, não. Logs, imagens, VMDKs/VHDXs, dumps, arquivos e cópias de volume podem ser suficientes. Em falha física, normalmente enviam-se as mídias necessárias, preservando ordem e seriais.
Quanto custa recuperar dados de ransomware?
O custo depende do volume, variante, quantidade de servidores/VMs, RAID, NAS/SAN, bancos, backups, criptografia e intervenções anteriores. Não existe preço único sem diagnóstico.
Quanto tempo leva?
Depende da escala e do caminho técnico. Restaurar backup limpo é diferente de reconstruir RAID, recuperar VMFS, analisar criptografia parcial ou validar bancos de dados.
A SECURITY atende ransomware em todo o Brasil?
Sim. Casos lógicos compatíveis podem começar por recuperação remota para todo o Brasil. Quando há falha física, a SECURITY orienta o envio das mídias necessárias.
Sem necessidade de levar o equipamento em muitos casos
Remoto
Logs, amostras, VMs, bancos e imagens podem ser analisados por sessão segura.
Mídias físicas
Se HDD/SSD/RAID falha, enviam-se as mídias afetadas.
Servidor completo
Normalmente não é necessário em falha lógica.
Todo o Brasil
Triagem lógica pode começar independentemente da localização.
Alphaville, São Paulo e Campinas quando o caso exige laboratório
Alameda Rio Negro, 1030, Conj. 206
Barueri, SP, CEP 06454-000
(11) 98570-8000
Rua Frei Caneca, 1380, Conj. 11
São Paulo, SP, CEP 01307-002
(11) 98570-8000
Rua José Paulino, 1399, Andar 10
Campinas, SP, CEP 13013-001
(19) 99971-7987
Caio Bruno F. Garcia
Especialista em Recuperação de Dados e liderança técnica e estratégica da SECURITY. Atua desde 2005 e, em incidentes de ransomware de alta complexidade, relaciona servidores, VMs, NAS, storage e bancos às camadas de RAID Low Level e análise hexadecimal com WinHex, além de PC-3000 e Data Extractor quando existe falha física.
Ransomware por dentro: contenção, storage, criptografia e caminhos de recuperação
1. Ransomware
Malware de extorsão que pode combinar criptografia, indisponibilidade e exfiltração.
2. Double extortion
Dados podem ser roubados antes da criptografia.
3. Isolamento
Primeira prioridade é interromper propagação para outros sistemas e backups.
4. Power decision
Não existe regra universal; propagação, RAM e novas escritas precisam ser ponderadas.
5. Preservação
Ransom note, logs, samples e cópias precisam ser preservados.
6. Backup offline
CISA recomenda backups offline e testes de restore.
7. Backup imutável
Microsoft recomenda cópias que não possam ser apagadas ou alteradas pelo atacante.
8. Restore drill
Backup sucesso não garante restore sucesso.
9. Clean environment
Restore deve ocorrer em ambiente limpo, não na infraestrutura ainda comprometida.
10. No More Ransom
Mantém decryptors públicos para famílias compatíveis.
11. Decryptor
Deve ser usado sobre cópias quando os dados são críticos.
12. Strong encryption
Sem chave, falha de implementação ou outra fonte, AES/RSA moderno pode ser impraticável de quebrar.
13. Intermittent encryption
Algumas famílias cifram partes de arquivos grandes para acelerar o ataque.
14. Play ransomware
CISA documenta criptografia intermitente e alvo a extensões VMware.
15. The Gentlemen
Microsoft documentou em 2026 modos que cifram percentuais distribuídos de arquivos grandes.
16. Deleted originals
Alguns workflows deixam originais recuperáveis até sobrescrita/TRIM, outros sobrescrevem in-place.
17. TRIM
Pode reduzir a disponibilidade de blocos liberados em SSDs.
18. UNMAP
Pode liberar blocos em thin storage/SAN.
19. Shadow Copies
Podem ser removidas por famílias que tentam impedir recovery.
20. Snapshots
Podem ajudar se sobreviveram, mas não são backup independente.
21. VMware
VMFS, VMDK, snapshots e RAID/storage formam camadas.
22. Hyper-V
VHDX/AVHDX, CSV e storage formam camadas.
23. Proxmox
ZFS/LVM-thin/Ceph/QCOW2 definem o backend real.
24. NAS
RAID/SHR/ZFS, EXT4/Btrfs e snapshots entram na recuperação.
25. Qlocker
Família histórica associada a QNAP; estratégia depende da variante e dos dados restantes.
26. DeadBolt
Família histórica em NAS; não existe uma regra única para todas as versões.
27. eCh0raix
Família historicamente ligada a QNAP/Synology.
28. SAN
Pool, LUN, snapshots e RAID podem sobreviver de formas diferentes.
29. LUN deletion
Recriar LUN pode sobrescrever metadata e blocos.
30. VMFS
Não criar novo datastore sobre LUN a recuperar.
31. VMDK
Partial encryption pode deixar regiões intactas, mas recovery depende das estruturas atingidas.
32. VHDX
Preserve VHDX/AVHDX antes de merge/repair.
33. SQL Server
MDF/NDF/LDF precisam de validação no engine.
34. Oracle
DBF/control/redo e backups precisam de validação própria.
35. MySQL
IBD/ibdata/binlogs podem oferecer fontes distintas.
36. PostgreSQL
Base backup, data directory e WAL têm papéis diferentes.
37. PC / HD
Blocos deletados podem sobreviver até sobrescrita.
38. PC / SSD
TRIM/garbage collection podem reduzir rapidamente a janela.
39. RAID
Ransomware não elimina a necessidade de reconstruir array quando o storage está degradado.
40. RAID 5
Paridade simples.
41. RAID 6
Dupla paridade.
42. RAID Low Level
Ordem, stripe, parity, offsets e metadata.
43. PC-3000
Usado quando mídia suportada apresenta falha física/firmware.
44. Sala limpa ISO-5
Usada quando HDD mecânico exige procedimento físico.
45. WinHex
Auxilia análise de blocos e estruturas; não quebra criptografia moderna sem chave.
46. FBI
Não apoia pagar resgate e alerta que pagamento não garante os dados.
47. ANPD
Ransomware é exemplo de incidente de segurança com dados pessoais.
48. LGPD
Disponibilidade, integridade e confidencialidade entram na avaliação de risco.
49. Remote recovery
Casos lógicos estáveis podem começar remotamente.
50. Second opinion
Tentativas anteriores precisam ser documentadas antes de novas ações.
51. Matriz técnica de decisão
| Sintoma | Camada | Prioridade | Evitar |
|---|---|---|---|
| Criptografia ainda ativa | incidente | isolar e conter | manter shares expostos |
| Backup limpo | recovery point | validar e restaurar em clean env | restore na rede comprometida |
| Decryptor disponível | variant-specific | preservar originals e testar cópia | rodar no único original |
| VMs parcialmente cifradas | VMDK/VHDX/QCOW2 | mapear coverage | repair direto no source |
| NAS/storage | RAID/pool/filesystem | preservar disks/pool | initialize/recreate |
| Database cifrado | application | copiar datafiles/logs | attach/repair desordenado |
| RAID degradado | camada física | diagnosticar/clonar | rebuild repetido |
| Incidente LGPD | governança | documentar e avaliar risco | perder logs/timeline |
52. Conclusão técnica
Recuperar dados após ransomware é um problema de múltiplas camadas. O melhor caminho pode ser backup, decryptor, snapshot, original deletado, partial encryption ou reconstrução de storage. O fator comum é preservar antes de escrever e validar em ambiente limpo. Em muitos casos lógicos, a triagem pode começar remotamente em qualquer região do Brasil.
Referências utilizadas para validar este guia
- CISA StopRansomware Guide
- FBI: Ransomware e orientação sobre pagamento
- No More Ransom: decryption tools
- Microsoft: backup and recovery plan for ransomware
- Microsoft: ransomware-resilient backup architecture
- CISA: Play ransomware e intermittent encryption
- Microsoft Security: partial encryption em ransomware
- ANPD: comunicação de incidente de segurança
- X-Ways: WinHex
