Especialidades
tecnologia para trazer seus dados de volta!
Descriptografar SAP
Equipe especializada para recuperar dados encriptados 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 SAP encriptado por ransomware
A descriptografia de ambientes SAP é uma solução especializada projetada para recuperar sistemas SAP encriptados por ataques ransomware, restaurando de maneira ágil e segura todas as funcionalidades e dados comprometidos.
Ambientes SAP são alvos especialmente atrativos para criminosos digitais devido ao seu papel estratégico nas operações empresariais, armazenando desde informações financeiras confidenciais até dados pessoais e de fornecedores críticos para o funcionamento da organização.
Por isso, ataques ransomware a esses ambientes podem causar impactos operacionais devastadores, resultando em paralisação total ou parcial das atividades, perdas financeiras significativas e danos irreversíveis à imagem e reputação da empresa.
Entre as causas mais comuns da encriptação por ransomware dos sistemas SAP estão:
- Exploração de vulnerabilidades: Falhas de segurança não corrigidas, seja por ausência de patches ou atualizações pendentes, permitem que invasores explorem pontos fracos no ambiente SAP.
- Phishing e engenharia social: Ataques direcionados através de e-mails maliciosos ou manipulação direta de usuários, levando ao comprometimento das credenciais e acessos privilegiados ao ambiente SAP.
- Credenciais comprometidas: Roubo ou exposição de credenciais de usuários privilegiados que possibilitam o acesso não autorizado e instalação de ransomware diretamente no sistema SAP.
Quando um ataque de ransomware afeta o ambiente SAP, a rapidez da recuperação é crítica para minimizar prejuízos e restaurar rapidamente as operações.
A Digital Recovery atua com processos altamente especializados e tecnologias próprias desenvolvidas especificamente para a descriptografar ransomware em ambientes SAP afetados.
Por que a Digital Recovery?
A Digital Recovery é especializada na recuperação e descriptografia de ransomware, combinando tecnologia exclusiva e equipes altamente especializadas para garantir resultados rápidos e seguros. Nossa empresa investe continuamente no desenvolvimento de soluções próprias, permitindo lidar com os mais diversos tipos de ransomware com agilidade e eficiência comprovadas.
Contamos com uma equipe formada por profissionais experientes em segurança cibernética e em ambientes SAP, garantindo que cada etapa do processo de recuperação seja realizada com máxima precisão técnica. Nossos especialistas estão disponíveis 24 horas por dia, prontos para oferecer atendimento imediato e personalizado, reduzindo significativamente o tempo de indisponibilidade dos seus sistemas críticos.
Além disso, asseguramos rigorosos padrões de segurança e confidencialidade durante todo o processo, protegendo integralmente as informações sensíveis da sua empresa. A reputação da Digital Recovery é respaldada por inúmeros casos bem-sucedidos ao redor do mundo, demonstrando nossa capacidade de solucionar com eficiência situações complexas envolvendo ambientes SAP encriptados.
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 ambiente SAP foi criptografado e não existe backup funcional. Ainda há possibilidade de recuperar os dados?
Em determinados casos, sim, mas primeiro é preciso determinar qual camada do ambiente SAP contém os dados afetados.
“SAP criptografado” pode significar um database SAP HANA comprometido, uma VM de Application Server, volumes de dados, backups, storage ou vários desses componentes simultaneamente.
Em sistemas ABAP, a arquitetura separa a camada de aplicação da camada de banco de dados. A própria SAP documenta que um sistema ABAP pode possuir vários Application Servers e um database central onde ficam dados empresariais, programas e configurações.
Por isso, a perda do servidor que executava a aplicação não equivale automaticamente à perda dos dados empresariais.
Quando o restore normal não funciona, é necessário analisar database, backups, réplicas e storage antes de determinar se existe uma alternativa técnica.
Antes de falar em recuperação, por que precisamos saber se o ambiente é S/4HANA, ECC, NetWeaver ou outro sistema SAP?
Porque SAP identifica um ecossistema de aplicações, e não uma única tecnologia de armazenamento que possa ser recuperada da mesma maneira em todos os casos.
Em um ambiente SAP, é necessário identificar pelo menos:
- produto e versão;
- SID;
- banco de dados;
- sistema operacional;
- Application Servers;
- ASCS;
- virtualização;
- storage;
- estratégia de backup;
- alta disponibilidade.
A arquitetura do SAP NetWeaver AS ABAP, por exemplo, possui camada de aplicação com uma ou mais instâncias, uma instância ASCS para serviços centrais e uma camada de database separada.
Consequentemente, um incidente em SAP S/4HANA + HANA é tecnicamente diferente de um sistema legado no qual o SAP utiliza outro SGBD.
A identificação correta da arquitetura evita tratar “SAP recovery” como se fosse um único procedimento universal.
Os Application Servers foram criptografados, mas o banco continua íntegro. Perdemos os dados do SAP?
Não necessariamente. Os Application Servers executam a lógica da aplicação, enquanto grande parte dos dados essenciais do sistema permanece no database.
Em um sistema ABAP, os Application Servers executam processos de diálogo, background, update e spool e se comunicam com o banco central. A SAP documenta inclusive que código ABAP, dados administrativos, Customizing e dados dos usuários estão vinculados à camada de database.
Assim, se o ransomware destruiu uma VM de Application Server, mas o database permaneceu íntegro, pode fazer mais sentido reconstruir a camada de aplicação do que tentar recuperar integralmente a antiga VM.
Porém, antes de descartá-la, é preciso verificar se existiam nela arquivos, interfaces, perfis, certificados, customizações ou outros componentes sem outra cópia.
Recuperar os dados SAP e reconstruir os servidores SAP são objetivos relacionados, mas diferentes.
Em SAP HANA, qual é a importância dos data volumes e log volumes depois de um ataque?
Eles são componentes centrais da persistência do SAP HANA e precisam ser avaliados em conjunto.
Embora o HANA seja um database in-memory, seus dados persistentes são mantidos em data volumes. Periodicamente, savepoints gravam no disco as alterações existentes em memória. Ao mesmo tempo, alterações persistentes são registradas como redo entries nos log volumes.
Após uma interrupção normal, o HANA pode carregar o último savepoint disponível e utilizar os redo logs para avançar o database até um estado mais recente.
Um ransomware, entretanto, pode atingir essas duas estruturas de maneiras diferentes.
Por isso, se o HANA não inicia, não se deve concluir simplesmente que “a memória foi perdida”. É necessário verificar data volumes, log volumes, backups e storage para entender quais estados consistentes ainda existem.
Temos um data backup do HANA, mas alguns log backups foram perdidos. Até que ponto o sistema pode ser recuperado?
A disponibilidade dos log backups pode determinar até qual momento o SAP HANA consegue avançar durante uma recuperação.
O HANA permite recuperação para o estado mais recente ou para um ponto específico no tempo utilizando a combinação apropriada de data backup, delta backups e log backups. Antes de iniciar, a própria plataforma pode verificar se os backups necessários estão disponíveis.
Se existem lacunas nos logs necessários, determinados pontos de recuperação podem não estar disponíveis.
Isso significa que é importante preservar:
- complete data backups;
- differential/incremental backups
- existentes;
- log backups;
- log area;
- snapshots;
- backup catalog.
Também não se deve apagar logs aparentemente antigos antes de compreender a cadeia.
Em uma empresa que perdeu várias horas ou dias de transações após ransomware, a diferença entre “temos um full backup” e “temos full + sequência de logs” pode ser operacionalmente enorme.
Os backups via Backint e o repositório do software de backup também foram criptografados. O que ainda deve ser preservado?
Preserve tanto os componentes SAP HANA quanto tudo o que pertence à integração com o software de backup.
Backint é a interface do SAP HANA para integração com ferramentas de backup de terceiros. Data backups, log backups e backup catalog podem ser enviados através dela para o sistema externo de proteção.
Em um incidente, portanto, devem ser inventariados:
- backups nativos existentes;
- backups enviados via Backint;
- repositório da solução de terceiros;
- parameter files;
- backup catalog;
- backup.log;
- backint.log;
- snapshots ou cópias secundárias.
Os arquivos backup.log e backint.log registram informações importantes sobre as operações realizadas e podem auxiliar a entender o que existia antes do ataque.
Um repositório que não restaura pelo software convencional não deve ser automaticamente descartado.
O backup catalog do SAP HANA foi perdido ou corrompido. Os backups existentes deixam de ter utilidade?
Não necessariamente. A perda do backup catalog cria limitações, mas não significa automaticamente que todos os data backups perderam valor.
O backup catalog contém o histórico das operações de backup e ajuda o HANA a determinar quais backups podem ser utilizados em uma recuperação. System database e cada tenant database possuem seus próprios catalogs.
A própria SAP documenta, porém, que é possível realizar determinadas recuperações sem o backup catalog, desde que sejam conhecidas informações como tipo de backup, localização e prefixo.
Há uma limitação importante: sem o catalog, não é possível realizar normalmente uma recuperação point-in-time; a recuperação fica restrita a um data backup específico.
Portanto, depois de ransomware, preserve os backups mesmo que o catalog tenha desaparecido. Catalog perdido e backup perdido são problemas distintos.
Temos SAP HANA System Replication e o secondary parece intacto. Ele pode evitar uma recuperação complexa?
Pode ser a melhor fonte disponível, por isso deve ser examinado antes de reparar ou sobrescrever o primary afetado.
SAP HANA System Replication mantém um sistema secundário destinado a assumir a função do primary em determinados cenários de indisponibilidade.
Em ambientes multitenant, entretanto, a replicação é feita no nível do sistema inteiro: system database e tenant databases participam da replicação, e um takeover não ocorre individualmente para apenas um tenant.
Depois de ransomware, é importante verificar:
- estado do secondary;
- última sincronização;
- se o atacante alcançou o site secundário;
- condição dos tenants;
- estado da replicação;
- alterações executadas antes do incidente.
Não promova ou reinicialize automaticamente o secondary apenas porque o primary não inicia.
Uma réplica saudável pode evitar uma recuperação de dados complexa; uma réplica comprometida pode simplesmente reproduzir parte do problema.
Em um HANA multitenant, podemos recuperar apenas um tenant database afetado?
O SAP HANA possui mecanismos específicos de recuperação de tenant databases, mas é preciso respeitar a relação entre tenant e system database.
A documentação atual da SAP prevê a recuperação de um tenant a partir de um complete data backup e indica que a operação é iniciada através do system database.
Isso torna importante identificar durante um incidente:
- quais tenants foram atingidos;
- quais permanecem funcionais;
- backups de cada tenant;
- backup do SYSTEMDB;
- backup catalogs;
- prioridade operacional de cada tenant.
A existência de múltiplos tenants não significa que todos sofreram exatamente o mesmo dano.
Ao mesmo tempo, não é correto tratar cada tenant como um servidor totalmente independente: determinadas operações administrativas e de recuperação dependem do SYSTEMDB.
Esse cenário merece análise específica antes de uma restauração global de todo o ambiente HANA.
O ransomware atingiu ASCS, Application Servers ou perfis SAP, mas o database está disponível. Precisamos recuperar tudo dos discos antigos?
Não necessariamente. Alguns componentes de infraestrutura podem ser reconstruídos, enquanto os dados empresariais precisam ser preservados.
Em AS ABAP, um sistema possui uma ou mais instâncias de Application Server e uma instância ASCS, que reúne serviços centrais como Message Server e Enqueue Server.
Depois de ransomware, a equipe precisa diferenciar:
Dados insubstituíveis — database, documentos, interfaces, customizações sem cópia.
Infraestrutura reconstruível — binaries e determinados servidores que podem ser reinstalados de forma compatível.
Mesmo quando reconstruir é mais eficiente, preserve previamente informações sobre SID, instance numbers, perfis, mounts, certificados, interfaces e configuração.
O objetivo não deve ser necessariamente “recuperar byte por byte todos os servidores antigos”, mas reconstruir uma plataforma íntegra ao redor dos dados efetivamente recuperados.
Ú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
Nosso SAP não usa HANA como banco. A recuperação muda se o backend for Oracle, SQL Server ou outra tecnologia?
Sim. A tecnologia de database subjacente muda profundamente o processo técnico de recuperação.
A arquitetura tradicional do SAP NetWeaver abstrai parte das diferenças entre bancos na camada de aplicação, mas o database continua sendo uma plataforma própria, com mecanismos específicos de storage, backup e recovery. A documentação SAP descreve inclusive interfaces específicas por plataforma de banco. Por exemplo:
SAP HANA → data/log volumes, savepoints, Backint, System Replication.
Oracle → datafiles, control files, redo, RMAN.
Microsoft SQL Server → MDF/NDF/LDF, transaction logs, BAK e recovery models.
Não existe um método técnico único aplicável a todo sistema SAP.
O SAP e o HANA estavam virtualizados ou sobre SAN/RAID e essa infraestrutura também foi atingida. Onde deve começar a análise?
Quando a infraestrutura subjacente foi comprometida, é preciso analisar simultaneamente aplicação, database e storage.
Em SAP HANA, data e log volumes representam a persistência do database. Se esses volumes estavam sobre SAN, RAID, LUNs, discos virtuais ou outra camada que sofreu exclusões ou corrupção, o problema deixa de ser exclusivamente do HANA.
Preserve quando aplicável:
- VMDK/VHDX;
- LUNs;
- configuração RAID;
- discos;
- volumes HANA;
- snapshots;
- datastores;
- data/log paths;
- backups remanescentes.
Se arquivos ou volumes foram excluídos, novas gravações no mesmo storage podem alterar o cenário.
A Digital Recovery pode avaliar as diferentes camadas quando a indisponibilidade SAP é consequência de um problema de dados que começa abaixo da aplicação.
Financeiro, produção ou logística precisam voltar primeiro. É possível priorizar processos críticos na recuperação do SAP?
Sim. A prioridade empresarial deve orientar a análise, embora módulos SAP não sejam necessariamente conjuntos de arquivos independentes.
Em um incidente grave, pode ser mais importante restabelecer rapidamente:
- faturamento;
- financeiro;
- produção;
- estoque;
- logística;
- compras;
- folha;
- determinada company code ou operação crítica.
Porém, em sistemas ABAP, aplicações diferentes utilizam o mesmo database central e podem compartilhar tabelas, Customizing, master data e serviços da plataforma. A arquitetura da SAP centraliza tanto dados empresariais quanto código e informações administrativas no database.
Portanto, “priorizar FI” não significa necessariamente extrair isoladamente alguns arquivos chamados FI.
A prioridade ajuda a definir o que precisa ser validado primeiro e qual estado do sistema representa valor operacional, enquanto a recuperação técnica continua respeitando dependências entre os componentes.
Existe relação real entre ransomware e vulnerabilidades do SAP NetWeaver, como CVE-2025-31324?
Sim. Nesse caso existe uma relação pública e documentada, mas o vetor de entrada não determina sozinho a recuperabilidade dos dados.
A CISA classifica CVE-2025-31324, no SAP NetWeaver Visual Composer, como vulnerabilidade explorada ativamente e marca explicitamente seu uso conhecido em campanhas de ransomware. A falha permite upload de arquivos sem autenticação e pode levar a comprometimento do servidor.
Pesquisadores também relacionaram infraestrutura associada ao Qilin à exploração da vulnerabilidade, além de observações envolvendo BianLian e RansomEXX.
Qilin, DragonForce, Akira, LockBit e INC também permanecem operações relevantes em 2026. Pay2Key continua sendo observado como RaaS baseado no ecossistema Mimic.
Mesmo assim, grupo atacante e dano final são informações distintas.
De que dependem realmente as chances de recuperar um ambiente SAP depois de ransomware?
Da combinação entre arquitetura, estado dos dados e fontes alternativas existentes — e não apenas do nome do ransomware.
Entre os fatores relevantes estão:
- SAP S/4HANA, ECC ou outra arquitetura;
- HANA ou outro database;
- condição dos data/log volumes;
- backups;
- backup catalog;
- Backint;
- System Replication;
- tenants;
- máquinas virtuais;
- storage;
- arquivos excluídos;
- ações executadas após o incidente.
Em HANA, por exemplo, savepoints e redo logs possuem funções diferentes, enquanto recovery para determinados momentos depende da disponibilidade de backups e logs apropriados.
O mesmo ransomware pode utilizar configurações diferentes entre vítimas, e afiliados podem executar procedimentos distintos.
Por isso, nenhuma taxa genérica de sucesso seria tecnicamente adequada. A situação precisa ser determinada a partir do ambiente real.
Não existe decryptor para o ataque. Devemos considerar o pagamento do resgate como única opção?
Não. A ausência de um decryptor e a impossibilidade de recuperação profissional não são sinônimos.
Um decryptor procura desfazer diretamente a criptografia utilizando uma chave aplicável ao ransomware.
Uma avaliação de recuperação responde a outra pergunta: o que permanece tecnicamente utilizável no database, backups, réplicas e storage?
Em SAP, isso é especialmente relevante porque podem existir fontes independentes:
- HANA System Replication;
- data backups;
- log backups;
- Backint;
- storage snapshots;
- outro database server;
- máquinas ou volumes preservados.
Nenhuma dessas fontes garante sucesso, mas elas precisam ser analisadas antes de concluir que só existe uma alternativa.
Da mesma forma, uma ferramenta fornecida pelo atacante não resolve necessariamente arquivos excluídos, storage danificado ou inconsistências do database.
A decisão sobre resgate deve permanecer separada da análise técnica de recuperação.
Quando SAP Basis, DBA ou MSP conseguem resolver o incidente e quando é necessária recuperação profissional de dados?
Enquanto existe uma fonte íntegra que os mecanismos normais conseguem restaurar, o caso continua sendo principalmente disaster recovery e reconstrução de infraestrutura.
Equipes SAP Basis, DBAs e MSPs são fundamentais para:
- reconstruir Application Servers;
- configurar ASCS;
- administrar HANA;
- executar recovery nativo;
- promover System Replication;
- restaurar backups;
- validar transações e integrações.
SAP HANA possui procedimentos próprios para recuperar databases utilizando data backups, log backups, snapshots e Backint.
A situação muda quando essas próprias fontes foram criptografadas, excluídas ou danificadas.
Se data volumes, backup repositories, VMs ou storage já não funcionam pelos procedimentos normais, passa a existir um problema de recuperação de dados.
A Digital Recovery atua nessa camada, enquanto Basis/DBA continuam essenciais para validar e colocar o sistema reconstruído novamente em produção.
Como funciona a recuperação de SAP com a Digital Recovery e onde entra o Tracer?
O processo começa pelo mapeamento técnico do ambiente e é dividido em análise e recuperação.
Etapa 1 — Análise técnica
O primeiro contato deve ser feito por telefone.
Normalmente são levantados:
- produto e release SAP;
- HANA ou outro database;
- SID e arquitetura;
- tamanho do database;
- data/log volumes;
- backups e Backint;
- System Replication;
- virtualização/storage;
- ransomware identificado;
- sistemas e processos prioritários;
- ações já realizadas.
Conforme o cenário, arquivos, mídias, storage ou acesso remoto apropriado podem ser utilizados para a análise.
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 trabalho segue o cenário encontrado.
A Digital Recovery utiliza, entre seus recursos especializados, o Tracer, tecnologia proprietária aplicada à análise e recuperação de ambientes digitais afetados por ransomware, incluindo SAP e SAP HANA.
Uma estimativa responsável de prazo só é possível depois da análise.
