Ransomware em PME: o que muda na sua infraestrutura

Empresa de médio porte tende a se achar alvo pequeno demais para ataque direcionado. A premissa está certa e a conclusão está errada: a maior parte do ransomware que atinge PME não é direcionado. É oportunista — varredura automatizada procurando credencial fraca, serviço exposto e software desatualizado, sem saber nem se importar com quem está do outro lado.

Isso muda o que faz diferença na defesa. Não é sofisticação; é fechar as portas óbvias e garantir que a cópia de segurança sobreviva ao ataque que atingiu tudo o mais.

Como ele entra, na prática

Os vetores que dominam os relatos, em ordem de frequência:

• Credencial válida. Senha reutilizada, vazada em outro serviço, ou adivinhada por força bruta em um acesso remoto exposto. É o caminho mais comum, e o que menos depende de falha técnica.
• Serviço de acesso remoto aberto à internet. Área de trabalho remota, compartilhamento de arquivos e painéis administrativos publicados sem restrição.
• Software desatualizado com falha conhecida e exploração pública disponível.
• Anexo ou macro em estação de trabalho, que depois alcança os servidores pela rede interna.

Repare que os três primeiros são problemas de infraestrutura, não de usuário. E os três têm correção conhecida: autenticação forte, não expor o que não precisa estar exposto, e manter o que está exposto atualizado.

O passo que decide o desfecho

Aqui está a parte que quase toda cobertura do assunto trata de leve. Ransomware moderno não começa criptografando. Ele começa procurando o backup.

O raciocínio de quem ataca é simples: uma vítima com cópia funcional restaura e não paga. Então o primeiro alvo é a cópia, e ela costuma ser fácil de alcançar, porque foi montada assumindo que o risco era falha de hardware.

Os arranjos que caem junto:

• Disco externo montado permanentemente. Aparece como pasta e é criptografado como qualquer outra.
• Compartilhamento de rede acessível pelo servidor. Mesma coisa.
• Bucket com credencial que também apaga. Se a chave que o servidor usa tem permissão de exclusão, quem comprometeu o servidor tem também.
• Snapshot na mesma conta, com o mesmo acesso administrativo comprometido.

O denominador comum: a cópia estava ao alcance de quem comprometeu o original. É a diferença entre ter backup e ter backup que sobrevive.

Cópia que não pode ser apagada

A correção é dar à cópia externa duas propriedades que a separam do ambiente principal.

Credencial de escrita sem exclusão. A chave que o servidor usa para enviar backup deve poder criar objeto e não poder removê-lo nem sobrescrevê-lo. A limpeza de arquivos antigos passa a ser política do bucket, executada pelo próprio armazenamento, e não comando do servidor.

Retenção que impede remoção, quando disponível. Objeto com prazo mínimo não pode ser apagado nem por quem tem credencial administrativa, até o prazo vencer.

# O teste que vale: com a credencial do servidor,
# tentar apagar precisa FALHAR
aws s3 rm s3://backups-empresa/teste.txt --profile backup-servidor

Se esse comando funcionar, a sua cópia externa não é externa — é apenas mais um lugar dentro do mesmo perímetro.

E vale reforçar o que o artigo sobre testar restauração já defende: cópia que nunca foi restaurada é suposição. No cenário de ransomware isso pesa ainda mais, porque a restauração acontece sob pressão, com o negócio parado.

Reduzir o alcance de uma credencial

Se o vetor mais comum é credencial válida, o objetivo é que uma credencial comprometida alcance pouco.

• Segundo fator no acesso administrativo. Senha vazada deixa de ser suficiente.
• Nada de conta compartilhada. Sem saber quem entrou, a investigação fica inviável — assunto do artigo sobre usuários, grupos e sudo.
• Acesso remoto atrás de VPN. Painel e área de trabalho remota deixam de existir para a internet, como no artigo sobre WireGuard.
• Segmentação entre máquinas. O servidor de aplicação não precisa alcançar o de arquivos, nem o de backup. Regra de saída restritiva contém a movimentação lateral, que é como um servidor comprometido vira todos comprometidos.
• Serviço com usuário próprio e sem privilégio, para que uma falha na aplicação não vire controle da máquina.

Nenhuma dessas medidas impede a entrada. Todas reduzem o que acontece depois — e é aí que se ganha ou se perde.

O que detecta a tempo

Criptografar todo o conteúdo produz sinais peculiares, diferentes da operação normal:

• Escrita massiva e sustentada, muito acima do padrão do horário.
• Muitos arquivos alterados em pouco tempo, em diretórios que normalmente mudam pouco.
• Uso de CPU alto e constante, por criptografia.
• Acesso administrativo em horário atípico.

O primeiro é o mais fácil de acompanhar e o mais confiável. Um alerta de escrita anômala em disco pode dar meia hora de vantagem, e meia hora é a diferença entre perder uma pasta e perder tudo. As ferramentas para medir isso são as mesmas do artigo sobre IO lento — o que muda é o motivo de estar olhando.

Vale também acompanhar o volume enviado ao bucket: uma queda súbita significa que o backup parou, e backup que para em silêncio é o pior tipo de falha.

O plano de resposta, que cabe numa página

No momento do incidente, ninguém pesquisa o que fazer. O que existe escrito é o que será feito.

Isolar antes de investigar. Desconectar da rede as máquinas afetadas. Não desligar — a memória pode conter informação útil, e desligar às vezes aciona rotinas do próprio malware.

Não mexer nas cópias. Nenhum acesso ao backup a partir de máquina possivelmente comprometida, sob risco de contaminar a única saída.

Preservar evidência. Log, imagem de disco, horários. Serve para a investigação e para a comunicação obrigatória.

Avaliar a obrigação legal. Vazamento de dado pessoal tem prazo e destinatários definidos pela LGPD, e ransomware moderno costuma exfiltrar antes de criptografar — ou seja, é vazamento além de indisponibilidade. Vale ter isso mapeado antes, como discutido no artigo sobre CLOUD Act e conformidade.

Restaurar em ambiente novo. Máquina limpa, não a comprometida. Provisionar VPS nova leva cerca de um minuto, e é bem mais seguro que confiar na limpeza de um sistema invadido.

Trocar todas as credenciais depois, sem exceção.

Sobre pagar: além de não haver garantia de recuperação, o pagamento financia a operação e não resolve o vazamento — o dado já saiu. A decisão é do negócio e do jurídico, mas ela precisa ser tomada com essa informação, e não no desespero.

O que fazer nesta semana

Cinco medidas, todas viáveis em poucos dias, em ordem de retorno:

• Teste apagar o backup com a credencial do servidor. Se conseguir, corrija hoje.
• Liste o que está exposto à internet e desligue o que não precisa estar.
• Ative segundo fator em todo acesso administrativo.
• Faça uma restauração completa cronometrada, do zero, em máquina nova.
• Escreva o plano de resposta em uma página e deixe onde ele possa ser lido sem depender da infraestrutura que estará fora.

Nenhuma dessas exige ferramenta nova ou orçamento. E a primeira, sozinha, é o que separa uma semana ruim de uma empresa que não volta.

A conversa que precede tudo isso

Vale registrar o ponto que costuma travar a implementação dentro das empresas: o tema chega ao time técnico como pedido de ferramenta — "precisamos de um antivírus melhor", "vamos contratar uma solução de proteção".

Ferramenta ajuda. Mas nenhuma delas altera as três variáveis que decidem o desfecho: o que está exposto à internet, o alcance de uma credencial comprometida, e se a cópia de segurança sobrevive ao ataque.

Essas três são decisões de arquitetura, custam pouco dinheiro e bastante disciplina. Uma empresa com backup imutável testado, acesso administrativo atrás de VPN com segundo fator e segmentação entre servidores tem um incidente ruim e volta em horas. Uma empresa sem isso, com o melhor antivírus do mercado, pode não voltar.

Quando o assunto surgir, vale reposicionar a pergunta: em vez de "qual produto nos protege?", perguntar "se a máquina X for comprometida amanhã, o que o atacante alcança, e quanto tempo levamos para voltar?". A resposta a essa segunda pergunta mostra sozinha onde investir — e costuma apontar para itens que já estão ao alcance da equipe, sem contrato novo.

Por que a estação de trabalho entra nessa conta

Um último ponto que costuma ficar fora do escopo de quem cuida de servidor: boa parte dos casos começa em um computador de escritório e chega à infraestrutura pelo compartilhamento de rede ou pela credencial salva no navegador.

Isso significa que duas medidas do lado do servidor têm efeito desproporcional. A primeira é não montar compartilhamento de rede com permissão de escrita em máquina de usuário comum, quando o conteúdo não precisa ser alterado por ela. A segunda é não guardar credencial de acesso administrativo em navegador nem em arquivo de configuração da estação — que é justamente o que o primeiro estágio do ataque procura.

Não é preciso assumir a gestão dos computadores da empresa para reduzir esse caminho. Basta desenhar a infraestrutura supondo que uma estação será comprometida em algum momento, e garantir que isso não entregue o ambiente inteiro.