Especialidades
tecnologia para trazer seus dados de volta!
Descriptografar MS SQL Server
Equipe especializada para descriptografar banco de dados afetados por ransomware.
- Mais de 25 anos de experiência
- Presente em 7 países
- Suporte multilíngue
ATENDIMENTOS EM TODO O MUNDO
CASES DE ATAQUE LOCKBIT
CASES DE ATAQUE BLACK CAT
CASES DE ATAQUE HIVE LEAKS
CASES DE ATAQUE AKIRA
VALOR SALVO SEM NEGOCIAÇÃO COM HACKERS
* dados até 2025
Recuperar MS SQL Server encriptados por ransomware
O MS SQL Server é um dos sistemas gerenciadores de banco de dados mais utilizados no mundo corporativo, armazenando informações críticas para o funcionamento de empresas dos mais diversos segmentos.
Em razão disso, ataques cibernéticos como ransomware têm se tornado cada vez mais frequentes, bloqueando o acesso aos bancos de dados através de criptografias complexas e solicitando valores elevados para devolução das informações.
Além do ransomware, incidentes internos, erros humanos, falhas técnicas ou problemas de segurança podem causar o bloqueio ou criptografia dos dados, deixando as empresas sem acesso a informações vitais para suas operações diárias.
O serviço especializado da Digital Recovery para descriptografar MS SQL Server utiliza técnicas avançadas, incluindo ferramentas proprietárias e processos validados por inúmeros casos de sucesso. Atuamos rapidamente para restabelecer o acesso aos dados críticos do seu negócio.
Entre as principais causas para a criptografia ou bloqueio de bases MS SQL Server estão ataques ransomware direcionados, vulnerabilidades não corrigidas no sistema operacional ou no próprio banco de dados, erros em políticas de segurança e má gestão de senhas e credenciais internas.
A contratação do nosso serviço garante benefícios imediatos, incluindo a recuperação ágil dos dados bloqueados, redução de perdas financeiras e operacionais.
Por que a Digital Recovery?
A Digital Recovery é reconhecida internacionalmente pela excelência na recuperação e descriptografia de dados críticos. Contamos com ferramentas exclusivas, desenvolvidas internamente, capazes de lidar com todas as variantes de ransomware que afetam bases de dados MS SQL Server, incluindo aquelas mais recentes e complexas.
Nossa equipe técnica é composta por profissionais altamente qualificados e experientes em recuperação de bancos de dados criptografados, garantindo a aplicação das melhores práticas e o sucesso do processo em tempo recorde.
Entendemos a urgência das situações críticas enfrentadas por nossos clientes. Por isso, oferecemos atendimento emergencial 24/7, com início imediato após a contratação, garantindo o menor tempo possível de indisponibilidade.
Garantimos total confidencialidade e segurança das informações durante todo o processo. Nossa metodologia é segura e não invasiva, cumprindo rigorosamente as normas internacionais de proteção e privacidade de dados.
Com atuação global, a Digital Recovery é capaz de prestar suporte remoto eficiente e seguro, independentemente da localização da sua empresa.
Estamos sempre online pelo WhatsApp
Caso prefira o formulário como forma de contato, preencha e retornaremos em breve.
Experiências do cliente
O que nossos clientes dizem sobre nós
Cliente desde 2017
Respostas dos nossos especialistas
Nosso SQL Server foi atingido por ransomware e nenhum backup funcional está disponível. O banco ainda pode ser recuperado?
Em determinados casos, sim. A ausência de um backup restaurável elimina a solução convencional, mas não permite concluir automaticamente que o conteúdo do SQL Server foi perdido.
Um ambiente pode envolver MDF, NDF e LDF, vários filegroups, FILESTREAM, backups full/differential/log, Availability Groups, snapshots e diferentes camadas de storage. Cada uma dessas fontes precisa ser considerada antes de estabelecer o cenário real.
Além disso, “SQL Server criptografado” pode significar situações muito diferentes: arquivos modificados pelo ransomware, database excluído, volume inacessível, corrupção de páginas ou simplesmente uma instância que não consegue iniciar o processo normal de recovery.
Por isso, a Digital Recovery trata primeiro o incidente como um problema técnico a ser diagnosticado. Somente depois dessa análise é possível estimar se existe possibilidade de recuperação integral, parcial ou se o dano é tecnicamente inviável.
O que devemos preservar antes de tentar colocar o SQL Server novamente em produção?
Preserve primeiro os dados e evidências que não podem ser recriados. A infraestrutura pode ser reconstruída posteriormente.
Em um incidente SQL Server, isso normalmente significa manter cópias dos:
- MDF, NDF e LDF;
- BAKs, differential e transaction log backups;
- certificados e chaves de TDE/backup encryption;
- FILESTREAM containers;
- discos ou volumes da VM;
- snapshots;
- réplicas Always On;
- storage relacionado;
- SQL Server ERRORLOG e erros observados.
Evite sobrescrever o servidor ou o volume crítico simplesmente para instalar rapidamente uma nova instância.
Também é importante registrar o que já foi feito depois do ataque: attach, restore, DBCC, exclusão/recriação de logs, movimentação dos arquivos ou outras intervenções. Essas ações podem modificar o cenário que será posteriormente analisado.
O banco ficou SUSPECT ou RECOVERY_PENDING depois do ataque. Esses estados significam que os dados foram perdidos?
Não. SUSPECT e RECOVERY_PENDING indicam problemas diferentes e nenhum deles, isoladamente, equivale a perda total dos dados.
Segundo a Microsoft, RECOVERY_PENDING significa que o SQL Server encontrou um problema relacionado a recursos durante o recovery; os arquivos podem estar ausentes ou existir outra condição impedindo a inicialização. SUSPECT, por outro lado, indica que ao menos o primary filegroup pode estar danificado e que o database não conseguiu ser recuperado durante o startup.
Portanto, o estado exibido no SSMS deve ser interpretado junto com o SQL Server ERRORLOG, condition dos arquivos e storage.
Um database em SUSPECT após ransomware merece análise de integridade, mas não deve ser automaticamente submetido a procedimentos destrutivos simplesmente para fazê-lo aparecer como ONLINE.
O DBCC CHECKDB encontrou erros. Devemos executar REPAIR_ALLOW_DATA_LOSS para colocar o banco online rapidamente?
Não como primeira medida. REPAIR_ALLOW_DATA_LOSS deve ser tratado como último recurso, especialmente quando o database é a única cópia disponível.
O DBCC CHECKDB é extremamente útil para identificar problemas de consistência física e lógica. O risco surge ao transformar diagnóstico em reparo destrutivo.
A Microsoft alerta expressamente que REPAIR_ALLOW_DATA_LOSS pode deallocar páginas, linhas ou outras estruturas para restabelecer consistência, resultando efetivamente em perda de dados. A recomendação primária continua sendo restaurar uma cópia íntegra quando ela existe.
Em ransomware, onde justamente pode não haver um bom backup, preservar a condição original torna-se ainda mais importante.
Se CHECKDB já foi executado, guarde o resultado. Antes de aplicar uma opção de repair sobre a única cópia, preserve fisicamente os arquivos relevantes.
O recovery model SIMPLE, FULL ou BULK_LOGGED muda as possibilidades depois de um ransomware?
Sim. O recovery model determina como o transaction log é administrado e quais tipos de restauração o SQL Server permite.
Existem três modelos: SIMPLE, FULL e BULK_LOGGED. Em FULL, uma sequência adequada de full/differential/log backups pode permitir recuperação até um ponto específico no tempo. Em SIMPLE, normalmente o alcance fica limitado aos backups de database disponíveis. BULK_LOGGED possui características próprias para operações minimamente logadas.
Essa informação é especialmente importante após ransomware.
Duas empresas podem possuir exatamente a mesma versão do SQL Server e ter sido atacadas pelo mesmo grupo, mas apresentar opções completamente diferentes porque uma mantinha uma cadeia de transaction logs e a outra não.
Por isso, informe o recovery model de cada database prioritário durante a análise, quando essa informação estiver disponível.
O servidor caiu antes do último backup de log. As transações mais recentes ainda podem ter alguma chance de recuperação?
Depende principalmente da condição atual do transaction log e do recovery model utilizado.
Em databases FULL ou BULK_LOGGED, existe o conceito de tail of the log: registros de transações ainda não incluídos no último log backup. Em situações convencionais de falha, um tail-log backup pode preservar essas transações antes do início do restore.
Depois de ransomware, porém, o LDF também pode ter sido criptografado, truncado, removido ou tornado inacessível junto com os datafiles.
Isso muda completamente a situação.
Por essa razão, não exclua ou recrie automaticamente o transaction log apenas porque o database não consegue subir. Se o objetivo é recuperar o estado mais recente possível, o LDF e todos os .trn existentes podem ser elementos relevantes da análise.
Temos Always On Availability Groups. Uma réplica secundária pode evitar a recuperação do banco atingido?
Possivelmente. Antes de reparar o primary database, verifique cuidadosamente o estado de todas as réplicas secundárias.
Always On Availability Groups mantém cópias de databases em réplicas diferentes. Os transaction log records do primary são enviados às secondary replicas, onde são hardened e posteriormente aplicados aos datafiles.
Uma secondary replica saudável e suficientemente atual pode, portanto, representar uma fonte muito melhor do que um database primário danificado.
Mas há duas ressalvas importantes.
Primeiro, um problema no nível do database nem sempre provoca failover automático. A Microsoft destaca que perda de datafile ou corrupção de transaction log não necessariamente dispara failover sem configurações específicas.
Segundo, é preciso verificar se o atacante também alcançou a réplica secundária antes de promovê-la ou reutilizá-la.
Os arquivos BAK existem, mas RESTORE ou VERIFYONLY falham. Isso significa que precisamos abandonar o backup?
Não necessariamente. Primeiro é preciso entender por que o SQL Server não aceita aquele backup.
O SQL Server possui comandos como RESTORE HEADERONLY, FILELISTONLY e VERIFYONLY para inspecionar e verificar backup sets. VERIFYONLY confirma se o backup set está completo e se todo o backup é legível, mas não executa um restore nem valida completamente a estrutura interna dos dados.
Após ransomware, um BAK pode apresentar:
- corrupção;
- parte ausente de um striped backup;
- criptografia externa;
- problemas anteriores ao ataque;
- cadeia incompleta;
- dependência de certificado;
- dano no dispositivo onde estava armazenado.
Portanto, registre a mensagem de erro exata e preserve o arquivo.
O banco utilizava TDE ou backup encryption e o servidor original foi perdido. Quais certificados e chaves precisamos preservar?
Preserve tudo relacionado à criptografia legítima do SQL Server. Isso pode ser tão importante quanto preservar o próprio database.
Transparent Data Encryption e ransomware não são a mesma coisa.
Em TDE, a Database Encryption Key é protegida por um certificado ou mecanismo correspondente. Backups de databases protegidos por TDE também permanecem criptografados e exigem o certificado necessário durante um restore em outra instância. A Microsoft alerta que perder esse material pode tornar o backup inutilizável.
Backup encryption também pode utilizar certificado ou asymmetric key próprio; sem o encryptor correto, aquele backup não poderá ser restaurado normalmente.
Depois de ransomware, preserve certificates, private keys, passwords, master keys e qualquer documentação relacionada antes de formatar ou descartar o antigo servidor SQL.
Apenas alguns filegroups ou arquivos do database foram afetados. É necessário recuperar o banco inteiro de uma vez?
Não em todos os cenários. SQL Server possui mecanismos de recuperação em nível de files e filegroups, dependendo da arquitetura e do recovery model do database.
Databases grandes podem ser distribuídos entre primary e secondary filegroups. Em ambientes adequadamente configurados, o SQL Server inclusive suporta piecemeal restore, permitindo que diferentes partes do database sejam restauradas em etapas.
Isso é particularmente relevante quando um sistema possui vários terabytes e somente determinados conjuntos de dados são críticos para a retomada da operação.
Porém, uma função nativa de restore não deve ser confundida com recuperação de um filegroup criptografado pelo ransomware. Ela pressupõe que existam fontes válidas para restaurá-lo.
Depois do incidente, vale mapear quais filegroups existem, quais arquivos pertencem a cada um e quais aplicações dependem deles antes de assumir que todo o database possui exatamente o mesmo estado.
Últimos insights dos nossos especialistas
The Gentlemen Ransomware: como funciona e como recuperar os dados
O The Gentlemen ransomware está entre as operações de ransomware que mais cresceram desde o segundo semestre de 2025. Diferentemente de campanhas automatizadas que atacam
Ransomware Qilin: como funciona e como recuperar os dados
O ransomware Qilin está entre as operações de ransomware mais ativas e estruturadas do mercado. Também conhecido inicialmente como Agenda, o grupo atua por meio
Por que enviar o dispositivo para diagnóstico?
Quando um HD, SSD, servidor, sistema RAID, NAS, cartão de memória ou outro dispositivo apresenta uma falha, é natural querer recuperar os arquivos o mais
O que você precisa saber
O banco utiliza FILESTREAM. Os arquivos externos precisam ser tratados separadamente após ransomware?
Sim. Um database com FILESTREAM não deve ser analisado olhando apenas para MDF, NDF e LDF.
FILESTREAM permite que dados varbinary(max) sejam armazenados no filesystem em um container associado ao database. Isso cria uma dependência adicional entre a estrutura SQL Server e dados localizados fora dos datafiles tradicionais.
Há ainda uma particularidade importante: a Microsoft informa que TDE não criptografa os dados FILESTREAM, mesmo quando Transparent Data Encryption está ativado no database.
Portanto, em um ataque de ransomware, o impacto sobre datafiles e sobre o FILESTREAM container pode ser diferente.
Se a aplicação armazenava documentos, imagens ou outros objetos por FILESTREAM, preserve também esses diretórios e informe sua localização. Recuperar apenas o MDF pode não representar recuperação completa da aplicação.
Reconstruímos a instância SQL Server e restauramos os databases, mas a aplicação ainda não funciona. O que pode estar faltando?
Um database funcional não significa necessariamente uma instância SQL Server funcional para a aplicação.
Objetos importantes podem existir fora do database recuperado. Dependendo da versão e da arquitetura, isso pode incluir:
- logins;
- SQL Server Agent jobs;
- linked servers;
- credentials;
- endpoints;
- configurações da instância;
- integrações externas.
A Microsoft destaca que Always On Availability Groups tradicionalmente fornece proteção no nível do database, não de todos os objetos da instância. Em SQL Server 2022 e posteriores, contained availability groups ampliam a possibilidade de administrar determinados metadados, mas isso depende de como o ambiente foi configurado.
Por isso, a validação após recuperação deve incluir não só DBCC CHECKDB ou acesso às tabelas, mas também a capacidade da aplicação de autenticar, executar jobs e utilizar suas dependências.
O database foi excluído ou o RAID, SAN, NAS ou volume onde ele estava também foi comprometido. Por onde começar?
Quando a camada de storage também está danificada, não é suficiente analisar somente o SQL Server.
Erros de I/O como 823 e 824 mostram bem essa relação. A Microsoft associa o erro 823 frequentemente a problemas no subsistema de storage, filesystem, hardware ou drivers, enquanto o erro 824 indica uma inconsistência lógica detectada durante leitura. Ambos podem ameaçar a integridade do database.
Depois de ransomware, isso pode envolver:
SQL Server: MDF, NDF, LDF e backups.
Filesystem/volume: NTFS, ReFS ou outra camada.
Infraestrutura: RAID, SAN, NAS, datastore, VHDX/VMDK ou discos físicos.
Se arquivos foram excluídos, novas gravações no mesmo storage também podem alterar a situação.
A Digital Recovery pode avaliar banco e armazenamento como partes do mesmo incidente quando essa dependência existe.
De que dependem realmente as chances de recuperação de um ambiente SQL Server afetado por ransomware?
O nome do ransomware é apenas uma das informações; o estado técnico do ambiente é muito mais importante.
Entre os fatores que mais alteram o cenário estão:
- quais databases foram atingidos;
- estado de MDF/NDF/LDF;
- recovery model;
- transaction log disponível;
- full/differential/log backups;
- Always On replicas;
- TDE e certificados;
- FILESTREAM;
- corruption de páginas;
- arquivos excluídos;
- storage subjacente;
- ações realizadas depois do ataque.
Até erros aparentemente semelhantes podem ter causas diferentes. RECOVERY_PENDING, SUSPECT, erros 823/824, CHECKDB failures e simples ausência de um datafile não representam o mesmo problema.
Além disso, ransomwares podem utilizar parâmetros e padrões distintos conforme o tamanho e tipo dos arquivos.
Por isso, percentuais genéricos de recuperação têm pouco valor sem um diagnóstico real.
Sem decryptor, devemos partir diretamente para o pagamento do resgate?
Não é tecnicamente correto assumir que a ausência de um decryptor significa automaticamente que negociar com o atacante é a única alternativa.
Descriptografia e recuperação profissional de dados são caminhos diferentes.
Um decryptor tenta reverter a criptografia usando a chave adequada ou outra condição aplicável à variante.
Uma análise de recuperação avalia o que aconteceu concretamente com databases, backups, transaction logs, replicas e storage e determina se existe alguma alternativa técnica.
Em alguns casos, essa alternativa pode existir. Em outros, o dano pode tornar a recuperação parcial ou inviável.
Mesmo quando o atacante fornece uma ferramenta, ainda podem restar corrupção, arquivos excluídos, backups danificados ou problemas de consistência do database.
Por isso, quando o SQL Server é essencial para a empresa, vale conhecer tecnicamente o cenário antes de tratar qualquer opção como inevitável.
Qilin, Pay2Key, Akira, DragonForce, LockBit, INC Ransom e Mimic afetam SQL Server da mesma maneira?
Não. E não é correto afirmar que todas essas famílias possuem um comportamento específico e idêntico contra Microsoft SQL Server.
Qilin permaneceu como uma das operações mais ativas no segundo trimestre de 2026, enquanto DragonForce também apresentou forte atividade. Akira continua ativo no ecossistema Windows, e INC Ransom mantém recursos de criptografia e movimentação em ambientes corporativos. Pay2Key, por sua vez, foi observado como serviço RaaS construído sobre Mimic.
Para SQL Server especificamente, vale acrescentar The Gentlemen à página: a Microsoft documentou em maio de 2026 que o ransomware tenta interromper explicitamente serviços MSSQLSERVER, MSSQL*, SQLSERVERAGENT e instâncias SQL Express antes da criptografia.
Ainda assim, a família não determina sozinha a recuperabilidade.
Quando o DBA ou MSP consegue resolver o incidente e quando passa a ser um caso de recuperação profissional de dados?
Enquanto existe uma fonte íntegra para restaurar, o trabalho deve permanecer no fluxo normal de administração e disaster recovery.
DBAs e MSPs são essenciais para:
- restaurar BAKs;
- aplicar transaction logs;
- promover Availability Group replicas;
- reconstruir instâncias;
- validar bancos;
- reconectar aplicações;
- reforçar segurança depois do incidente.
SQL Server possui recursos robustos para tudo isso.
A mudança acontece quando a matéria-prima necessária para o restore também foi comprometida: MDF/NDF/LDF criptografados, BAKs que não restauram, replicas inutilizáveis, files excluídos ou storage danificado.
Nesse ponto, repetir comandos administrativos não resolve necessariamente o problema e algumas opções de repair podem inclusive causar perda adicional. A Microsoft classifica REPAIR_ALLOW_DATA_LOSS como último recurso.
A Digital Recovery atua nessa camada especializada, idealmente em cooperação com o DBA ou MSP do cliente.
Como funciona um projeto de recuperação de SQL Server com a Digital Recovery e qual é o papel do Tracer?
O processo é dividido em análise técnica e recuperação, porque não é responsável cotar ou prometer resultado antes de conhecer o dano.
Etapa 1 — Análise técnica
O primeiro passo é entrar em contato por telefone com a Digital Recovery. Normalmente são levantados:
- versão/edição do SQL Server;
- databases e tamanhos;
- arquivos MDF/NDF/LDF;
- recovery model;
- backups disponíveis;
- Always On;
- TDE;
- FILESTREAM;
- storage;
- ransomware;
- erros apresentados;
- bancos e aplicações prioritários.
Conforme o incidente, a análise pode envolver arquivos específicos, cópias de storage ou acesso remoto apropriado.
Ao final, o cliente recebe uma avaliação das possibilidades identificadas e uma proposta comercial para a recuperação.
Etapa 2 — Recuperação
Após a contratação, o projeto segue o cenário técnico encontrado.
Entre os recursos especializados utilizados pela Digital Recovery está o Tracer, sua tecnologia proprietária voltada à análise e recuperação de ambientes digitais comprometidos por ransomware.
O prazo só pode ser estimado com responsabilidade depois da análise.
