Plano de Resposta a Ransomware: Guia para Empresas Portuguesas

Na noite de 25 de dezembro de 2025, o LockBit 5.0 cifrou os sistemas de pelo menos duas organizações portuguesas enquanto o país estava em festa. O deadline de pagamento foi fixado para 15 de janeiro de 2026. Os dados já estavam publicados na plataforma de leaks antes de qualquer negociação. O timing foi deliberado — atacar quando as equipas de IT estão ausentes é uma táctica de maximização de dano bem documentada.

O relatório Hiscox 2025 indica que 54% das PMEs portuguesas foram alvo de ciberataques. O CNCS regista um aumento significativo de incidentes. E o Decreto-Lei n.º 125/2025 (NIS2) exige agora que as entidades abrangidas tenham um plano de resposta a incidentes documentado e testado — com prazos de notificação ao CNCS que começam nas 24 horas após detecção.

Este guia é estruturado como um plano operacional real — não uma política genérica. Cobre as cinco fases de resposta a ransomware com procedimentos concretos, tempos de execução e responsáveis, adaptado ao contexto regulatório português.

1. Como funciona um ataque de ransomware moderno

O ransomware moderno não é um vírus que entra e cifra imediatamente. É uma campanha multi-fase que pode durar dias ou semanas antes da cifragem. Perceber as fases do ataque é essencial para entender onde a detecção precoce é possível — e onde não é.

Fase	O que acontece	Janela de detecção
1. Acesso inicial	Phishing com credenciais, RDP exposto, VPN vulnerável, credencial comprada em fórum	Alta (MFA, EDR)
2. Persistência	Instalação de backdoor, criação de conta admin, registo de serviço malicioso	Média (EDR, audit log)
3. Reconhecimento interno	Mapeamento de rede, identificação de Domain Controllers, servidores de backup, dados críticos	Média (SIEM, comportamental)
4. Exfiltração de dados	Cópia de dados para servidor externo (dupla extorsão) — pode durar dias	Baixa (tráfego DNS/HTTPS)
5. Destruição de backups	Eliminação de Shadow Copies, destruição de backups locais, desactivação de agentes de backup	Baixa (crítica detectar aqui)
6. Cifragem e nota de resgate	Payload executado — cifragem massiva, nota de resgate, sistemas inacessíveis	Demasiado tarde

2. Antes do ataque — preparação obrigatória

A capacidade de resposta a um ransomware é determinada quase inteiramente pelo que foi feito antes do ataque. Uma organização sem preparação prévia perde, em média, 3 a 5 vezes mais tempo e dinheiro na recuperação do que uma organização preparada.

2.1 Backups — a linha de defesa mais crítica

Requisito	Implementação recomendada
Regra 3-2-1-1	3 cópias, 2 suportes diferentes, 1 offsite, 1 offline ou imutável
Isolamento do backup	O servidor de backup nunca deve ser acessível via RDP ou SMB da rede de utilizadores. Rede separada ou VLAN dedicada
Backup imutável em cloud	Azure Backup com Soft Delete activado (14 dias mínimo) ou Acronis Cloud com imutabilidade — não apagável mesmo com credenciais comprometidas
Frequência	Dados críticos: backup a cada 4h ou menos. Servidores: diário. Ficheiros de utilizadores: diário com retenção de 30 dias
Teste de restauro	Testar restauro completo pelo menos trimestralmente. Um backup nunca testado não é um backup — é uma esperança

2.2 Documentação prévia essencial

• Lista de contactos de emergência em papel: responsável IT, gestor de topo, advogado, seguradora, MSP externo, CNCS (linha de emergência: 213 303 190)
• Diagrama de rede actualizado: todos os segmentos, servidores, switches — essencial para contenção rápida
• Inventário de activos críticos: quais os sistemas cuja paragem tem impacto imediato no negócio
• Credenciais de emergência em cofre físico: passwords de administrador local, de switches, de consolas de backup — fora do ambiente AD (que pode estar comprometido)
• Contrato com empresa de resposta a incidentes (DFIR): ter o número pré-estabelecido evita perder horas a procurar ajuda em crise

2.3 Controlos preventivos mínimos

• MFA activado em todos os acessos remotos (VPN, RDP, M365) — ver artigo Conditional Access
• RDP não exposto directamente à internet — sempre via VPN ou Azure Bastion
• EDR activo em todos os endpoints — ver artigo Defender for Business
• Shadow Copies activadas nas workstations (Windows) e servidores
• Segmentação de rede — servidores, utilizadores e backups em VLANs separadas
• Patches críticos aplicados em 72 horas após publicação

3. Fase 1 — Detecção e Contenção Imediata (0–2 horas)

Sinais de detecção mais comuns

• Ficheiros com extensão desconhecida ou nota de resgate (README.txt, DECRYPT_INSTRUCTIONS.html)
• Alerta do EDR (Defender, Acronis, etc.) de comportamento suspeito em massa
• Utilizadores a reportar que não conseguem abrir ficheiros
• Pico de actividade de disco ou CPU em vários sistemas simultaneamente
• Shadow Copies eliminadas (alerta nos event logs: Event ID 524 e 1098)
• Serviços de backup parados ou agentes desinstalados

Acções imediatas de contenção

Ordem	Acção	Responsável
1	Activar o plano de incidente — notificar o responsável de cibersegurança e o gestor de topo imediatamente	Quem detecta
2	NÃO DESLIGAR os sistemas afectados (ainda) — preservar evidências em memória RAM; documentar o estado antes de qualquer acção	IT / DFIR
3	Isolar imediatamente os sistemas comprometidos da rede — desligar cabos de rede ou desactivar porta no switch. Se for workstation única: desactivar a NIC. Se for segmento mais amplo: desactivar VLAN no switch	IT
4	Isolar o servidor de backup da rede produtiva (se ainda não estiver isolado) — desligar acesso de rede imediatamente	IT
5	Revogar todas as sessões activas no Microsoft 365 (Entra ID → Utilizadores → Revogar sessões) e repor passwords de contas administrativas	IT
6	Bloquear o acesso VPN e RDP externamente no firewall — impedir que o atacante mantenha acesso remoto	IT / Network
7	Fotografar ou registar em vídeo os ecrãs com a nota de resgate e os ficheiros afectados — documentação para investigação e seguradora	IT
8	Comunicar internamente — instruir todos os utilizadores a não abrirem emails ou ficheiros até nova ordem; não partilhar informação sobre o ataque externamente sem autorização da gestão	Gestão / IT

4. Fase 2 — Avaliação do Âmbito (2–8 horas)

Com a contenção imediata feita, o passo seguinte é perceber exactamente o que foi afectado — e o que não foi. Esta avaliação é também o que alimenta o relatório de incidente para o CNCS.

Perguntas a responder na avaliação

• Que sistemas estão cifrados? — inventário por categorias (servidores, workstations, NAS)
• Que sistemas ainda estão limpos? — identificar o perímetro seguro para operação mínima
• Qual foi o vector de entrada inicial? — phishing, credencial comprometida, RDP, vulnerabilidade?
• Quando começou o ataque? — rever logs de EDR, event logs do Windows (Security, System)
• Houve exfiltração de dados? — rever logs de tráfego de rede, DNS queries, uploads de grande volume
• Os backups estão intactos? — verificar estado dos backups cloud e offline
• O Active Directory está comprometido? — se o DC foi afectado, toda a infraestrutura on-premises está comprometida

Identificar a variante de ransomware

Identificar a família de ransomware ajuda a perceber se existe decryptor gratuito disponível, qual o modo de operação esperado (ex: prazo de pagamento), e se há IOCs (Indicators of Compromise) publicados que ajudem a identificar persistência.

• ID Ransomware (id-ransomware.malwarehunterteam.com) — upload da nota de resgate ou de um ficheiro cifrado para identificação
• No More Ransom (nomoreransom.org) — projecto conjunto da Europol com decryptors gratuitos para variantes conhecidas
• Verificar a extensão dos ficheiros cifrados e o nome da nota de resgate — geralmente identificativos da família

5. Fase 3 — Notificação ao CNCS (NIS2)

Um ataque de ransomware que afecte sistemas de rede ou informação de uma entidade abrangida é, por definição, um incidente significativo nos termos do DL 125/2025. Os prazos de notificação são:

Prazo	O que comunicar
24 horas após detecção	Alerta inicial: Notificação de que o incidente ocorreu. Inclui: data/hora de detecção, natureza do incidente (ransomware), sistemas afectados, impacto preliminar estimado. Não é necessário ter toda a informação — a obrigação é comunicar dentro do prazo mesmo com informação incompleta
72 horas após detecção	Relatório intermédio: Avaliação actualizada do impacto, vector de ataque identificado (se conhecido), medidas de contenção implementadas, estado dos sistemas críticos, estimativa de tempo de recuperação
30 dias após resolução	Relatório final: Análise completa — causa raiz, cronologia do ataque, sistemas afectados, dados comprometidos (incluindo dados pessoais para CNPD), medidas correctivas implementadas, lições aprendidas. Ver artigo Relatório de Incidente NIS2 — template

Contactos CNCS para notificação

Linha de apoio	213 303 190 (horário de expediente)
Email	[email protected]
Portal de notificação	cncs.gov.pt — plataforma electrónica de notificação de incidentes (em implementação)

6. Fase 4 — Erradicação e Remediação (Horas 8–72)

Antes de restaurar qualquer sistema, é necessário garantir que o ransomware e todos os seus mecanismos de persistência foram completamente removidos. Restaurar para um ambiente ainda comprometido resulta numa segunda cifração.

1. Análise forense dos sistemas comprometidos (se houver capacidade interna ou DFIR contratado) — identificar IOCs, backdoors, contas criadas pelo atacante, mecanismos de persistência (tarefas agendadas, serviços, chaves de registo)
2. Redefinir TODAS as passwords do Active Directory — começar pelo krbtgt (duas vezes, com 10h de intervalo), depois Domain Admins, depois todos os utilizadores. Se o DC estiver comprometido, considerar reconstrução do AD
3. Revogar todos os tokens e certificados suspeitos — incluindo tokens OAuth no M365, certificados de serviço
4. Eliminar contas criadas pelo atacante — rever AD Users e Computers e Entra ID para contas não reconhecidas
5. Remover mecanismos de persistência — tarefas agendadas, serviços Windows, chaves de Run no registo, extensões de browser maliciosas
6. Reinstalar sistemas operativos comprometidos a partir de imagem limpa — não tentar “limpar” sistemas cifrados, reconstruir de raiz é mais seguro e mais rápido
7. Aplicar todos os patches pendentes antes de reconectar à rede
8. Rever e revogar acessos de terceiros (MSPs, fornecedores com acesso remoto)

7. Fase 5 — Recuperação e Regresso à Operação (Dias 3–30)

Sequência de recuperação recomendada

Passo	Acção	Critério de conclusão
1	Validar integridade dos backups — verificar hashes e fazer restauro de teste antes de usar em produção	Restauro de teste bem-sucedido
2	Reconstruir infraestrutura core — Domain Controllers, servidores de ficheiros críticos, sistemas de email	AD funcional, email operacional
3	Restaurar dados dos backups validados — começar pelos dados mais críticos ao negócio	Dados críticos acessíveis
4	Validar segurança antes de reconectar — scanning de vulnerabilidades, verificação de EDR activo, confirmação de patches	Zero vulnerabilidades críticas
5	Reconectar sistemas à rede de forma faseada — começar por um segmento de teste antes de libertar tudo	Sem reinfecção em 24h de monitorização
6	Monitorização intensiva durante 30 dias — alertas EDR ao nível máximo, revisão diária de logs, threat hunting activo	30 dias sem novo incidente

8. Pagar ou não pagar o resgate

Esta é a decisão mais difícil de um incidente de ransomware. Não existe uma resposta universalmente correcta. Os factores a considerar:

Factor	Consideração
Backups disponíveis	Se tens backups válidos e testados, pagar raramente faz sentido. O custo de recuperação é quase sempre inferior ao resgate
Tempo de recuperação	Se a recuperação técnica demora mais do que a organização aguenta sem operar, o pagamento pode ser considerado como opção de continuidade de negócio
Dados críticos sem backup	Se há dados sem backup alternativo e críticos para a sobrevivência do negócio, o decryptor pode ser necessário. Ponderar com advogado
Garantia de decryptor	Aproximadamente 20% das organizações que pagam não recebem um decryptor funcional. Não há garantias reais
Dados já exfiltrados	O pagamento não garante que os dados exfiltrados sejam apagados — muitos grupos vendem os dados independentemente do pagamento
Implicações legais e regulatórias	Pagar a grupos sancionados internacionalmente pode ter implicações legais. Consultar advogado especializado antes de qualquer pagamento

9. Checklist dos Primeiros 60 Minutos

Imprimir e guardar em papel junto ao servidor ou na gaveta do responsável IT. Quando o ransomware actua, os sistemas de documentação digital podem estar inacessíveis.

#	Acção	Feito?
1	Confirmar que é ransomware (extensão de ficheiros, nota de resgate visível)	☐
2	Fotografar ecrã com nota de resgate e ficheiros afectados	☐
3	Notificar responsável de cibersegurança e gestor de topo por telefone	☐
4	Desligar cabo de rede dos sistemas afectados (não desligar energia ainda)	☐
5	Isolar servidor de backup da rede (desligar cabo ou porta de switch)	☐
6	Bloquear acesso VPN e RDP no firewall	☐
7	Revogar todas as sessões activas no Entra ID / M365	☐
8	Repor password de todas as contas administrativas do AD	☐
9	Verificar estado dos backups cloud — aceder via portal isolado	☐
10	Instruir todos os utilizadores a pararem de trabalhar e não abrirem ficheiros (via telefone ou mensagem externa)	☐
11	Notificar o CNCS ([email protected] / 213 303 190) — prazo de 24h desde detecção	☐
12	Contactar empresa DFIR externa se não houver capacidade interna de resposta	☐

10. Pós-incidente — lições aprendidas

Um incidente de ransomware, por mais custoso que seja, é também a análise de segurança mais completa que uma organização pode fazer — paga a um custo muito elevado. Não desperdiçar as lições:

• Sessão de lições aprendidas (post-mortem) com toda a equipa de resposta — dentro de 2 semanas após resolução
• Identificar a causa raiz — qual o ponto de entrada inicial? Que controlo falharia?
• Actualizar o plano de resposta com base no que funcionou e no que não funcionou
• Testar o plano actualizado num exercício tabletop dentro de 60 dias
• Elaborar o relatório final para o CNCS (prazo: 30 dias após resolução) — ver artigo Relatório de Incidente NIS2
• Comunicar à seguradora se houver apólice de cyber seguro — a maioria tem prazo de reporte máximo de 72h
• Avaliar se a classificação da organização na NIS2 implica reporte adicional a autoridades sectoriais (ANACOM, Banco de Portugal, etc.)