Uma empresa de serviços com operação nacional ficou sem acesso ao seu ERP, servidor de arquivos e sistema de atendimento em uma manhã de segunda-feira. Em menos de uma hora, telas com pedido de resgate substituíram documentos, planilhas e aplicativos críticos. Este caso real de recuperação de ransomware mostra que a capacidade de voltar a operar não depende apenas de ter backups. Depende de saber se eles estão íntegros, isolados, acessíveis e inseridos em um plano de resposta que funcione sob pressão.
Os dados que identificariam a organização foram preservados por confidencialidade, mas o incidente e a estratégia de recuperação refletem uma situação real atendida em ambiente corporativo brasileiro. O resultado não foi fruto de sorte: foi consequência de decisões técnicas tomadas antes do ataque e de uma execução disciplinada durante a crise.
O incidente: quando a indisponibilidade vira risco de negócio
A empresa possuía cerca de 180 usuários, unidades em três estados e uma operação fortemente dependente de sistemas centralizados. O ERP registrava pedidos, faturamento e estoque. O servidor de arquivos concentrava contratos, documentos financeiros e informações de projetos. O acesso remoto era utilizado por equipes comerciais e administrativas.
O ponto inicial foi uma credencial de acesso remoto comprometida. O invasor obteve acesso a uma conta com permissões elevadas, movimentou-se pela rede e passou alguns dias reconhecendo servidores, compartilhamentos e rotinas de backup. Esse intervalo é comum em ataques de ransomware direcionados: antes de criptografar, o grupo procura ampliar privilégios e identificar os ativos que podem tornar a interrupção mais cara para a vítima.
Na madrugada do ataque, ferramentas administrativas legítimas foram usadas para distribuir a criptografia. Servidores virtuais, compartilhamentos de rede e estações de trabalho começaram a ficar inacessíveis. O antivírus existente bloqueou parte da atividade, mas a combinação de credenciais válidas e execução por ferramentas autorizadas reduziu a capacidade de contenção automática.
Às 7h12, o primeiro chamado chegou ao suporte. Às 7h19, o monitoramento identificou aumento anormal de alterações de arquivos e indisponibilidade de serviços. Às 7h27, a equipe classificou o evento como incidente crítico e acionou o procedimento de resposta.
As primeiras decisões evitaram uma perda maior
Em um ataque dessa natureza, tentar restaurar imediatamente ou reiniciar servidores sem critério pode destruir evidências, propagar a ameaça e contaminar cópias recuperadas. A prioridade inicial não é colocar tudo no ar a qualquer custo. É interromper a propagação, entender o escopo e preservar uma rota segura de retorno.
A resposta começou com o isolamento dos segmentos afetados, a suspensão temporária de acessos remotos e a revogação das sessões de usuários privilegiados. As contas administrativas tiveram as credenciais redefinidas a partir de uma estação segura. Também foram bloqueados os mecanismos de comunicação que poderiam permitir ao invasor manter persistência ou disparar uma nova criptografia.
Em paralelo, a equipe separou os ativos em três grupos: sistemas claramente comprometidos, sistemas sob suspeita e serviços sem evidência de comprometimento. Essa classificação evitou dois erros recorrentes: desligar componentes que poderiam apoiar a investigação e manter conectados ativos que poderiam disseminar o ataque.
A diretoria recebeu atualizações objetivas sobre impacto, medidas em curso, prazo estimado e critérios para retomada. Esse ponto teve peso operacional. Quando a comunicação é vaga, áreas comerciais, financeiras e de atendimento criam soluções paralelas, usam dispositivos não autorizados ou tentam contornar controles. Durante uma recuperação, disciplina operacional também é segurança.
O backup existia, mas precisava ser confiável
A empresa realizava backups diários, porém a pergunta central não era se havia cópias. Era se havia cópias recuperáveis. O ambiente contava com retenção em repositório protegido contra alteração e exclusão por um período definido, além de cópias mantidas fora do domínio principal. Isso impediu que a criptografia comprometesse todos os pontos de restauração.
A equipe analisou os registros das tarefas de backup, verificou a última execução bem-sucedida e selecionou pontos anteriores à movimentação lateral identificada. Depois, os backups foram validados em uma área isolada. Não bastava restaurar arquivos: era preciso confirmar a inicialização das máquinas virtuais, a consistência dos bancos de dados e a ausência de indicadores do ataque no ambiente recuperado.
Esse processo levou mais tempo do que uma restauração simples, mas reduziu o risco de recolocar o invasor dentro da operação. Em recuperação de ransomware, velocidade sem validação pode gerar uma segunda indisponibilidade ainda mais difícil de administrar.
Caso real de recuperação de ransomware: a retomada em etapas
A restauração não ocorreu de uma única vez. A empresa definiu a ordem conforme o impacto no negócio. Primeiro, foram recuperados os serviços de identidade e autenticação em ambiente segregado, seguidos pelos bancos de dados necessários ao ERP. Depois vieram o ERP, a integração de faturamento e os serviços de arquivos prioritários para as áreas financeira e de atendimento.
A recuperação total dos serviços essenciais levou aproximadamente 18 horas a partir da identificação do incidente. Algumas estações de trabalho foram reconfiguradas ou reconstruídas nos dois dias seguintes, e arquivos não críticos foram restaurados gradualmente. A operação não ficou ilesa: houve atraso no processamento de pedidos e esforço adicional das equipes. Ainda assim, a empresa evitou uma paralisação prolongada, não pagou resgate e não perdeu a base principal de dados corporativos.
A decisão de não negociar só foi viável porque existia uma alternativa comprovada. Pagar não garante chave funcional, não elimina cópias mantidas pelo criminoso e não corrige a falha que abriu caminho para o ataque. Em determinados cenários, organizações sem backup válido podem avaliar essa opção sob orientação jurídica, de seguros e de resposta a incidentes. Mas ela continua sendo uma decisão de alto risco, não uma estratégia de recuperação.
O que mudou depois do incidente
A recuperação foi acompanhada de uma revisão completa da arquitetura e dos processos. As contas administrativas passaram a seguir segregação de funções, autenticação multifator e controle mais rígido de privilégios. O acesso remoto foi revisto, com regras de origem, autenticação reforçada e monitoramento de comportamento.
Os backups ganharam testes regulares de restauração, indicadores de sucesso que não se limitam ao término da tarefa e cópias em camadas distintas. A organização também estabeleceu objetivos formais de recuperação. O RPO define quanto dado a empresa aceita perder em caso de incidente. O RTO define quanto tempo um serviço pode ficar indisponível. Sem esses parâmetros, a discussão sobre backup tende a ser técnica demais e pouco aderente ao impacto financeiro real.
Foi implementada ainda uma rotina de monitoramento contínuo para identificar tentativas de elevação de privilégio, alterações em massa de arquivos, uso anormal de ferramentas administrativas e falhas de backup. Nenhuma solução isolada elimina ransomware. A redução de risco vem da combinação entre proteção de endpoint, segmentação de rede, gestão de identidades, cópias imutáveis, monitoramento e resposta humana qualificada.
O que gestores devem cobrar antes de um ataque
A principal lição deste caso é direta: backup sem teste é uma expectativa, não uma garantia. Para uma operação que depende de dados e sistemas, a diretoria precisa saber quais serviços são críticos, em quanto tempo devem voltar, qual a perda de dados aceitável e quem toma decisões durante uma crise.
Também é necessário verificar se a infraestrutura permite isolamento rápido. Uma rede sem segmentação, credenciais administrativas compartilhadas e acesso remoto exposto amplia o raio de impacto. Da mesma forma, backups acessíveis com as mesmas credenciais do ambiente produtivo podem se tornar apenas mais um alvo para o atacante.
A maturidade não está em prometer que nenhum incidente ocorrerá. Está em reduzir a superfície de ataque, detectar sinais antes da criptografia e recuperar a operação com método quando a prevenção falhar. Para empresas com equipe interna enxuta ou ambiente complexo, um parceiro de serviços gerenciados pode assumir o monitoramento, os testes de recuperação e a evolução dos controles sem transferir a responsabilidade estratégica do negócio.
A TI Sec trabalha essa preparação como parte da continuidade operacional: diagnóstico do ambiente, definição de prioridades, proteção em camadas, backup imutável e gestão contínua. O melhor momento para descobrir se sua empresa consegue restaurar o ERP, os arquivos e os acessos críticos não é depois de receber uma nota de resgate. É em um teste controlado, com metas de recuperação que façam sentido para a operação.
