A recuperação de ransomware falha antes de chegar aos dados

A base de tudo o que as organizações pensam saber sobre a sua capacidade de recuperação assenta numa confiança que os estudos não confirmam. Segundo o “Data Trust and Resilience Report 2026” da Veeam, que inquiriu mais de 900 responsáveis de IT, segurança e risco a nível mundial, 90% das organizações confiam na sua capacidade de recuperar de um ciberincidente. Menos de um em cada três recuperou efetivamente todos os dados afetados por um ataque de ransomware e 44% recuperou menos de 75%. Com base no estudo, a confiança na recuperação e a prova da recuperação são duas capacidades diferentes.

O desfasamento entre o que as organizações acreditam poder fazer e o que efetivamente conseguem fazer quando o pior acontece separa a preparação teórica da capacidade real de recuperação. Não é apenas uma questão de saber se as empresas têm backups, mas o que quebra depois disso: as dependências, os RTO nunca testados sob pressão real e a infraestrutura de identidade que tem de ser reconstruída antes de qualquer aplicação voltar a funcionar.

O ransomware já não é uma questão de malware

Para entender porque é que tantas recuperações falham, é preciso primeiro entender como o ransomware opera hoje, que tem menos a ver com ficheiros maliciosos. Segundo “Active Adversary Report 2026” da Sophos, que analisou 661 casos de resposta a incidentes e deteção e resposta geridas, o tempo médio de permanência de um atacante antes de ser detetado desceu para três dias. Dentro dessa janela, a velocidade é o dado mais preocupante, onde, depois de obter acesso inicial, um atacante demora, em média, apenas 3,4 horas a alcançar o servidor de Active Directory.

	Marcel Bornhöfft, Associate Field CISO na Sophos

Marcel Bornhöfft, Associate Field CISO na Sophos, explica que esta aceleração não resulta de novas técnicas, mas da execução mais rápida das que já são conhecidas. “Os atacantes não estão necessariamente a recorrer a um novo manual de ataque; estão a executar o manual já conhecido, mas muito mais depressa”, afirma, acrescentando que “o controlo da identidade pode dar a um atacante acesso a contas privilegiadas, sistemas críticos para o negócio e às mesmas ferramentas administrativas utilizadas pela própria equipa de IT da organização”. Os números indicam que 67% das causas-raiz identificados nos casos analisados pela Sophos estavam relacionadas com identidade e no “State of Ransomware 2026” (onde foram inquiridos 2.158 responsáveis de IT e cibersegurança) 79% dos ataques começaram através de uma abordagem baseada em identidade.

Bruno Castro, Fundador e CEO da VisionWare, descreve o mesmo fenómeno a partir da reconstrução pós-incidente. “A ideia de que o ciberataque só inicia quando os ficheiros foram encriptados é, muitas vezes, mal interpretada”, sendo que “esse é apenas o momento em que a intrusão se torna visível, tipicamente de forma violenta e ruidosa, para a organização”, diz. Bruno Castro nota ainda que este tempo de permanência tem vindo a comprimir-se de forma acentuada ao longo dos anos. “Há 20 anos, estaríamos a falar de meses; hoje, falamos, no máximo, de poucas horas”, acrescenta.

Paulo Vieira, Country Manager da Netskope em Portugal

Paulo Vieira, Country Manager da Netskope em Portugal, acrescenta a esta descrição a fase que raramente é vista antes de a encriptação se tornar visível: a exfiltração de dados. “O ponto cego mais comum é a exfiltração para dupla extorsão: os dados saem antes de qualquer ficheiro ser encriptado, muitas vezes para armazenamento cloud não sancionado (…), usando tráfego TLS que as organizações não inspecionam”, explica. Segundo Paulo Vieira, as equipas de segurança “tipicamente têm visibilidade sobre a rede on-prem e talvez sobre os SaaS corporativos oficiais, mas não sobre uploads para tenants pessoais dessas mesmas aplicações”, o que significa que, quando a encriptação se torna finalmente visível, os dados já saíram há muito.

Backup como primeiro alvo, não como último recurso

Se há um ponto em que praticamente todos os responsáveis convergem é de que a infraestrutura de backup deixou de ser um sistema secundário para se tornar num dos primeiros alvos de ataque. André Feijóo, Senior Account Executive da Cohesity Portugal, resume a lógica do lado do atacante: “não basta ter os dados protegidos e seguros, é preciso ser rápido a recuperá-los. Quando a arquitetura é antiga e recuperar significa duas ou três semanas de paragem, muitas empresas acabam por pagar mesmo tendo cópias válidas. O atacante sabe disso”. Segundo o “State of Ransomware 2026”, 66% das organizações cujos dados foram encriptados conseguiram recuperar através de backups, um valor que subiu 12 pontos percentuais face ao ano anterior, enquanto o custo médio de recuperação, excluindo resgates, aumentou 11% para 1,7 milhões de dólares.

Marcel Bornhöfft evita classificar a ideia de atacar backups como uma tática generalizada, sublinhando que “os dados habitualmente citados medem a forma como as organizações recuperam através de backups e não a frequência com que os atacantes tentam comprometer a infraestrutura de cópias de segurança”. Ainda assim, reconhece que, “quando os atacantes obtêm acesso privilegiado num ambiente com segmentação insuficiente, as consolas de backup, os snapshots e as plataformas de virtualização podem também ficar ao seu alcance”.

	Rui Oliveira, Security Solutions Specialist na Claranet Portugal

Rui Oliveira, Security Solutions Specialist na Claranet Portugal, confirma que este cenário já não é uma exceção e que “é um cenário mais frequente do que muitas organizações imaginam” e descreve dois padrões distintos. No primeiro, “a infraestrutura de backup está integrada no mesmo domínio, utiliza as mesmas credenciais administrativas e armazena os dados em recursos acessíveis a partir da rede de produção”. No segundo, mais preocupante, “nem é necessária qualquer encriptação”, uma vez que “os próprios repositórios são eliminados utilizando funcionalidades legítimas das plataformas”. Rui Oliveira acrescenta, ainda, que “a infraestrutura de backup não é tratada como um ativo crítico de segurança e partilha autenticação com a produção, fica fora dos ciclos de atualização e raramente beneficia do mesmo nível de monitorização que os restantes sistemas”.

Carlos Caldeira, Cybersecurity Manager e CISO na Oramix, partilha um caso concreto que ilustra esse padrão. Numa organização apoiada recentemente pela empresa, “o sistema de backup partilhava as credenciais de administração do domínio e, assim que essas credenciais foram comprometidas, os atacantes acederam também aos backups pela mesma via, através de movimento lateral”. O incidente levou a que a organização perdesse, ao mesmo tempo, “os dados e a única via de recuperação”. A equipa teve de reconstruir sistemas manualmente, durante semanas, com um custo muito superior ao que resultaria de um backup segregados da rede de produção.

RTO nunca testados sob pressão real

O tempo de recuperação objetivo, o número que as organizações comunicam à administração como garantia de resiliência, é, segundo os responsáveis, um dos pontos onde a distância entre teoria e prática mais se sente. Rui Oliveira recorda “um dos casos mais marcantes”, com “um RTO de 24 horas formalmente aprovado e comunicado à administração”, em que, “ao fim dessas 24 horas, ainda estávamos a preparar a infraestrutura necessária para iniciar a recuperação”, tudo porque “não tinha sido considerado o tempo necessário para validar que o ambiente estava efetivamente limpo antes de iniciar as reposições, nem o impacto real dos volumes de dados a transferir face à capacidade disponível de rede e armazenamento”.

Carlos Ferreira, Diretor Técnico na Prologin

Carlos Ferreira, Diretor Técnico na Prologin, descreve uma dinâmica semelhante: um cliente “acreditava conseguir recuperar toda a operação crítica em menos de oito horas”. O backup funcionava, mas “ninguém tinha considerado o tempo necessário para validar a infraestrutura, reconstruir serviços de identidade, testar aplicações e coordenar equipas de negócio”. Assim, diz Carlos Ferreira, “o recovery técnico foi relativamente rápido; o recovery operacional demorou vários dias”.

André Feijóo situa o mesmo problema em escala. “Um RTO de quatro horas medido num servidor é um RTO por servidor, não para 800”, nota, explicando que à escala real “o que limita não é o procedimento, é a arquitetura: a capacidade agregada, a rede e o destino da restauração”. O representante da Cohesity acrescenta um fator frequentemente esquecido nos exercícios de teste: “num incidente real não se restaura para o ambiente de origem. O ambiente está comprometido, pode estar retido para análise forense por exigência da seguradora e às vezes o próprio hardware é suspeito”.

A identidade como pré-requisito, não como mais um sistema a restaurar

	Carlos Caldeira, Cybersecurity Manager e CISO na Oramix

Antes de qualquer aplicação de negócio poder ser restaurada, é preciso reconstruir a infraestrutura de identidade e essa reconstrução raramente entra nas contas do RTO original. Carlos Caldeira descreve a sequência que a sua equipa segue. “O ponto de partida é sempre garantir que a infraestrutura de segurança e networking não foi comprometida. Só depois disso avançamos com a recuperação de sistemas. Começamos, habitualmente, pelo catálogo de utilizadores, como o Active Directory, e pela infraestrutura de DNS”, indica. Sobre o tempo que isso acrescenta, explica que “quando existe imutabilidade validada, falamos de poucas horas. Quando não existe nada disso, o processo pode prolongar-se por vários dias”.

Paulo Vieira traz para a equação a camada híbrida que liga a identidade on-premises e cloud. “A identidade federada cria uma dependência circular: o SSO para as aplicações SaaS depende muitas vezes do Active Directory on-prem, que pode estar encriptado ou comprometido, o que bloqueia o acesso às próprias ferramentas SaaS necessárias para coordenar a resposta”, afirma. Paulo Vieira insiste que restaurar dados é apenas metade do problema, até porque “restaurar cópias de segurança limpas é inútil se a infraestrutura de identidade e os canais de acesso continuarem comprometidos”. Assim, a reconstrução da confiança, com “revogação de tokens, rotação de chaves de encriptações e redefinição de permissões” é “frequentemente o verdadeiro gargalo da recuperação”.

André Feijóo, Senior Account Executive da Cohesity Portugal

André Feijóo indica que a maioria das organizações nunca testa este cenário. “A grande maioria das empresas nunca testou uma recuperação total do Active Directory e não tem ferramentas para o fazer de forma automatizada”. Quando o processo é manual, “sob pressão consome facilmente dias ou semanas – só essa fase pode ser mais longa do que o RTO que a empresa comunicou ao negócio”.

Dependências que só a análise forense revela

	Bruno Castro, Fundador e CEO da VisionWare

Bruno Castro descreve este processo de reconstrução como um exercício de comparar duas versões da mesma organização, onde “a documentação indica, por vezes, que determinados sistemas estão segmentados, que os acessos privilegiados são restritos ou que os backups estão isolados. E, mais tarde, a investigação revela contas com privilégios excessivos, redes de interligação entre ambientes, sistemas aparentemente isolados que continuam a comunicar com componentes críticas”. O representante da VisionWare resume que há uma “diferença entre a arquitetura que a organização pensa ter e a arquitetura que o atacante encontrou e acabou por decifrar”. Estas dependências, sublinha, “tornam-se evidentes quando reconstruímos o percurso do atacante”, nunca antes.

José Gonçalves, Solution Engineering Manager na Exclusive Networks Portugal, observa o mesmo padrão a partir de uma perspetiva transversal a vários clientes e setores. “As organizações têm backups e planos de Disaster Recovery, mas muitas vezes nunca testaram uma recuperação completa. Quando acontece um ransomware ou outro tipo de ataque grave, descobrem dependências que desconheciam, RTO que não são realistas e falta de clareza sobre o que recuperar primeiro”. A conclusão de José Gonçalves aponta para além da tecnologia, onde “o problema normalmente não é apenas recuperar os dados. É principalmente recuperar os serviços críticos, na ordem certa, dentro do tempo que o negócio consegue suportar”.

O que só se resolve antes do incidente

As políticas de retenção de backups, definidas normalmente para acomodar erros operacionais ou falhas técnicas, raramente foram pensadas para um adversário que já está dentro da rede há dias ou semanas antes de agir. André Feijóo, da Cohesity, identifica que “o padrão típico é uma retenção detalhada de duas a quatro semanas e, para trás disso, apenas cópias mensais com pouca granularidade. Só que o acesso inicial do atacante pode ser muito anterior”. Bruno Castro, da VisionWare, propõe uma forma diferente de colocar a questão, que desloca o foco da duração da retenção para a integridade da cópia: “a questão que a forense coloca não é apenas ‘quantos dias de backup temos?’. Deve ser, antes, ‘temos uma cópia comprovadamente anterior ao compromisso e que o atacante não conseguiu alterar ou eliminar’”.

Quando tudo parece crítico, a diferença entre uma recuperação organizada e uma recuperação caótica está numa decisão que devia ter sido tomada muito antes do incidente. Carlos Ferreira, da Prologin, descreve que “a decisão é tomada com base no impacto para o negócio, não na importância técnica dos sistemas. Começamos por identificar quais os processos que geram receita, suportam operações críticas ou cumprem requisitos legais. Depois trabalhamos para trás, restaurando as dependências necessárias”.

Importa, também, separar um teste para a checkbox com um teste verdadeiro. Carlos Ferreira explica que “um teste de checkbox valida apenas se os dados podem ser restaurados. Um teste eficaz valida se as organizações conseguem voltar a operar”. O representante da Prologin acrescenta que “se o teste não gerar desconforto nem descobrir problemas, provavelmente não foi suficientemente realista”.

O efeito NIS2

Com a NIS2 em vigor, a pergunta que os fornecedores ouvem dos clientes portugueses mudou, mas nem toda a gente mudou ao mesmo ritmo. José Gonçalves descreve que, “antes, a principal preocupação era garantir que existiam backups. Hoje, a pergunta é cada vez mais ‘se acontecer alguma coisa, conseguimos mesmo recuperar?’”. Rui Oliveira, da Claranet Portugal, confirma esta divisão em dois grupos. Nas organizações “onde existe envolvimento da administração, a NIS2 tem servido como catalisador para iniciativas concretas”, com pedidos de “exercícios de recuperação completos, testes de crise e validação de RTO”. No entanto, persiste “um conjunto significativo de organizações cuja principal preocupação é a componente documental e de conformidade”, ou seja, planos e políticas atualizados, “mas pouca evidência de que a capacidade de recuperação tenha sido efetivamente testada”.

Carlos Caldeira situa a mudança no tipo de prova que passou a ser exigida. “Mostrar que existem políticas e procedimentos sem demonstrar a sua aplicabilidade e evidências é, no mínimo, redutor”. Segundo o representante da Oramix, a NIS2 “impulsionou a que a resiliência não se demonstre apenas com documentação e sim através da capacidade comprovada de recuperar serviços críticos quando o pior cenário acontece”.

José Gonçalves, Solution Engineering Manager na Exclusive Networks Portugal

José Gonçalves acrescenta um dado que confirma o efeito prático desta pressão regulatória, onde, nas organizações que já sofreram um incidente grave, se observa uma “mudança clara de maturidade” e deixam de olhar apenas para a existência de backups e “começam a preocupar-se muito mais com a capacidade efetiva e a rapidez de recuperação”. No fundo, “passam de uma abordagem teórica de recuperação para uma abordagem operacional, testada e orientada à continuidade do negócio”.

É precisamente essa passagem de plano documentado para capacidade demonstrada que separa as organizações que sobrevivem a um ransomware das que apenas acreditavam estar preparadas. Os dados do “IT Resilience Survey 2026: Ransomware Recovery and Readiness” da Gartner confirmam que a maioria das organizações já implementou as ferramentas fundamentais: cerca de 70% utiliza software de backup com automação e 78% implementou, ou está a implementar, ambientes de recuperação isolados. Mas o mesmo estudo conclui que, apesar destes investimentos, muitas organizações continuam a não conseguir utilizar eficazmente essas capacidades quando mais precisam delas, normalmente por falta de estratégia integrada e de coordenação entre o IT e o negócio. É este o gap que a Veeam mediu em 90% contra 28%. A tecnologia, na maioria dos casos, já está presente. O que falta continua a ser aquilo que o checkbox não consegue certificar: a prova, sob pressão real, de que tudo funciona em conjunto.