Wiper: como proteger backups e recuperar sistemas após um ataque

Um wiper muda a prioridade de resposta a incidentes: em vez de negociar para recuperar arquivos, a equipe precisa conter a destruição e restaurar sistemas confiáveis. Segundo o Sapo.pt, a ESET identificou um ataque desse tipo contra uma empresa industrial ucraniana, atribuído ao grupo de ciberespionagem FrostyNeighbor. O caso mostra por que acesso remoto comprometido, dados sem cópias isoladas e uma recuperação não testada podem transformar uma intrusão em uma interrupção operacional grave.

O que se sabe sobre o ataque à empresa industrial ucraniana

A investigação da ESET analisou atividades de grupos de ciberespionagem entre abril e setembro de 2026. Segundo os pesquisadores, operações de grupos alinhados com a Bielorrússia demonstram uma aproximação crescente dos objetivos estratégicos russos na Ucrânia. Isso descreve um alinhamento observado pelos investigadores; não significa, por si só, que cada grupo opere sob comando direto de um Estado.

O alvo foi uma empresa industrial ucraniana cuja identidade não foi divulgada. A organização poderá ter um papel importante no setor de transportes do país, mas essa possibilidade não foi confirmada publicamente. A ESET atribuiu o ataque ao FrostyNeighbor, grupo conhecido por operações de ciberespionagem.

Durante a intrusão, os atacantes utilizaram ferramentas de acesso e controle remoto. Mais tarde, implantaram um wiper, malware projetado para apagar dados. Essa sequência importa: a destruição costuma ser o estágio visível de uma invasão que pode ter começado antes, com roubo de credenciais, acesso remoto indevido ou movimentação entre sistemas.

Wiper e ransomware: a diferença que muda a resposta

Ransomware costuma cifrar arquivos ou bloquear sistemas para exigir pagamento. Um wiper tem como objetivo principal destruir dados e pode deixar computadores ou servidores inutilizáveis. Embora alguns ataques misturem técnicas ou tentem parecer ransomware, pagar não é uma estratégia confiável para recuperar informações apagadas por um wiper.

Na prática, a distinção muda o plano de recuperação. Diante de ransomware, a equipe ainda pode investigar se existe uma chave de descriptografia ou uma ferramenta legítima de recuperação. Diante de um wiper, a prioridade é conter a propagação, preservar evidências e reconstruir os sistemas a partir de fontes conhecidas como íntegras.

Também não basta restaurar arquivos. Se o atacante ainda controla uma conta administrativa, um servidor de identidade ou uma ferramenta de gerenciamento remoto, ele pode voltar a comprometer o ambiente depois da recuperação. Por isso, restauração sem investigação da causa raiz pode apenas reiniciar o ciclo.

Por que o acesso remoto é um ponto crítico

Ferramentas de administração remota são comuns em empresas de tecnologia e indústria. Elas permitem manutenção, suporte e operação distribuída. O problema não é simplesmente usar acesso remoto, mas deixar contas privilegiadas expostas, sem autenticação multifator, com permissões excessivas ou sem registro centralizado de atividades.

Na minha avaliação, a defesa precisa considerar o caminho completo do acesso: quem pode entrar, de onde, com qual dispositivo, em quais sistemas e com que nível de privilégio. Uma ferramenta legítima pode ser usada de forma maliciosa se uma conta autorizada for roubada. Bloquear apenas nomes de programas conhecidos não resolve esse cenário.

Em ambientes industriais, há uma complicação adicional: nem todo equipamento pode ser atualizado ou reiniciado imediatamente. Sistemas de tecnologia operacional (OT) podem ter requisitos de disponibilidade e compatibilidade diferentes dos computadores corporativos. A segmentação entre TI e OT, com regras explícitas de comunicação, reduz o risco de uma invasão em uma rede alcançar equipamentos críticos.

Na Prática: como preparar uma recuperação contra wipers

Eu organizaria a preparação em etapas verificáveis. O objetivo não é prometer que um ataque será evitado, mas reduzir o alcance da destruição e demonstrar que a empresa consegue voltar a operar com sistemas confiáveis.

Mapeie os ativos essenciais. Registre servidores, serviços de identidade, estações administrativas, sistemas de produção, dependências e responsáveis. Sem esse inventário, a equipe pode restaurar arquivos e esquecer o serviço necessário para usá-los.
Separe as cópias de segurança. Mantenha backups com proteção contra alteração ou exclusão pelo mesmo usuário que administra os sistemas de produção. Uma cópia sempre conectada e acessível com credenciais comprometidas pode ser destruída junto com os originais.
Teste a restauração, não só a execução do backup. Faça exercícios que recuperem sistemas completos e validem dados, permissões, configurações e dependências. Uma tarefa de backup concluída sem erro não prova que a restauração funcionará.
Reduza privilégios e proteja o acesso remoto. Use autenticação multifator, contas administrativas separadas, acesso condicionado e registros centralizados. Revise contas antigas, chaves e serviços que já não têm um responsável claro.
Prepare uma sequência de resposta. Defina quem pode isolar segmentos, revogar credenciais, preservar evidências e autorizar a recuperação. Em um incidente, decisões improvisadas aumentam o tempo de indisponibilidade e podem apagar informações úteis à investigação.
Valide antes de reconectar. Reinstale sistemas a partir de imagens confiáveis, altere credenciais potencialmente expostas e monitore o ambiente restaurado. Só então reintroduza máquinas em segmentos de produção.

Uma verificação simples de integridade pode ajudar a detectar arquivos alterados, removidos ou adicionados em um diretório monitorado. O exemplo abaixo cria um manifesto SHA-256 na primeira execução e compara os arquivos com esse manifesto nas execuções seguintes:

import hashlib
import json
import sys
from pathlib import Path

ROOT = Path(sys.argv[1]).resolve() if len(sys.argv) > 1 else Path(".").resolve()
MANIFEST = Path(sys.argv[2]).resolve() if len(sys.argv) > 2 else ROOT.parent / "integrity.json"

def sha256(path):
    digest = hashlib.sha256()
    with path.open("rb") as file:
        for chunk in iter(lambda: file.read(1024 * 1024), b""):
            digest.update(chunk)
    return digest.hexdigest()

def snapshot():
    result = {}
    for path in ROOT.rglob("*"):
        if path.is_file() and not path.is_symlink() and path.resolve() != MANIFEST:
            result[str(path.relative_to(ROOT))] = sha256(path)
    return result

current = snapshot()

if not MANIFEST.exists():
    MANIFEST.write_text(json.dumps(current, indent=2), encoding="utf-8")
    print(f"Manifesto criado: {MANIFEST}")
    raise SystemExit(0)

baseline = json.loads(MANIFEST.read_text(encoding="utf-8"))
for name in sorted(baseline.keys() - current.keys()):
    print(f"REMOVIDO: {name}")
for name in sorted(current.keys() - baseline.keys()):
    print(f"NOVO: {name}")
for name in sorted(baseline.keys() & current.keys()):
    if baseline[name] != current[name]:
        print(f"ALTERADO: {name}")

Salve como integrity_check.py e execute, por exemplo, com python integrity_check.py /srv/documentos /var/backups/integrity.json. Na primeira execução, o programa cria o manifesto; depois, aponta diferenças. Para que essa verificação tenha valor, guarde o manifesto fora do diretório monitorado e proteja-o contra alterações. Se o atacante puder modificar tanto os arquivos quanto a referência de comparação, o resultado deixa de ser confiável.

Esse script é uma demonstração defensiva, não um sistema de monitoramento corporativo. Ele não impede alterações, não identifica o autor e não substitui logs, EDR, backups imutáveis ou uma solução de integridade com alertas. Também pode consumir bastante tempo em diretórios grandes. O ponto é mostrar uma ideia básica: integridade só pode ser verificada contra uma referência protegida.

Erros comuns ao se defender de malware destrutivo

Confiar em um único backup online. Se as credenciais de produção também permitem apagar as cópias, o isolamento é apenas aparente. Use controles de retenção, contas separadas e testes de recuperação.
Confundir alerta de antivírus com plano de recuperação. Ferramentas de detecção ajudam a identificar atividade suspeita, mas não garantem que os dados estarão recuperáveis nem que a infraestrutura voltará a funcionar.
Restaurar antes de conter o acesso comprometido. Recolocar máquinas na rede sem revogar sessões, credenciais e mecanismos de acesso suspeitos pode permitir uma nova intrusão.
Tratar TI e OT como se tivessem os mesmos requisitos. Aplicar atualizações ou isolar equipamentos industriais sem avaliar impacto operacional pode causar indisponibilidade. A resposta precisa ser planejada com as equipes responsáveis pelos processos físicos.
Considerar o teste de backup como teste de desastre. Restaurar um arquivo isolado não valida a recuperação de identidade, aplicações, configurações e serviços interdependentes.
Ignorar ferramentas legítimas de administração. Bloquear um executável específico não resolve o uso indevido de credenciais válidas. Revise privilégios, origem das conexões e comportamento das contas.

O que esse incidente significa para quem desenvolve software

Desenvolvedores também operam sistemas que podem ser alvos: ambientes de CI/CD, registros de pacotes, repositórios, servidores de build e contas de nuvem. Uma conta comprometida nesses serviços pode afetar não só o código, mas também artefatos, segredos e processos de implantação.

Eu evitaria guardar credenciais permanentes em arquivos de configuração ou conceder permissões amplas a pipelines. Prefira segredos gerenciados, credenciais temporárias quando disponíveis, revisão de permissões e logs de auditoria. Separe o ambiente de build do de produção para que um incidente em uma camada não dê acesso automático a todas as outras.

Também vale manter um caminho de recuperação para repositórios e artefatos importantes. Código versionado não é necessariamente um backup se a conta que controla a organização puder apagar o histórico e as cópias. Para sistemas críticos, documente como reconstruir o ambiente, valide dependências e registre quais imagens e artefatos são considerados confiáveis.

FAQ: dúvidas de desenvolvedores sobre wipers

Um wiper pode ser confundido com ransomware?

Sim. Os dois podem deixar arquivos inacessíveis, mas o objetivo central é diferente: ransomware busca extorsão; wipers são projetados para destruir dados. Um pedido de resgate não prova que os dados possam ser recuperados mediante pagamento.

Um backup comum protege contra um wiper?

Não necessariamente. Se o backup estiver conectado e puder ser apagado com as mesmas credenciais da produção, também pode ser atingido. Cópias isoladas ou protegidas contra alteração, somadas a testes de restauração, oferecem uma defesa mais sólida.

Como saber se a restauração é segura?

Investigue a causa do incidente, contenha acessos comprometidos, reconstrua sistemas a partir de fontes confiáveis e valide serviços antes de reconectar. A equipe de resposta deve confirmar que não há mecanismos de acesso persistentes conhecidos no ambiente recuperado.

O script de hash do exemplo detecta um ataque em tempo real?

Não. Ele compara arquivos com um manifesto quando é executado. Para alertas contínuos, use monitoramento apropriado, centralização de logs e controles de segurança. O manifesto também precisa ficar protegido e fora do alcance de quem pode alterar os arquivos monitorados.

O caso descrito pelo Sapo.pt reforça uma lição prática: defesa contra wipers depende tanto de limitar o acesso quanto de conseguir reconstruir o ambiente. Para equipes de desenvolvimento e infraestrutura, isso significa revisar privilégios, proteger pipelines e testar a recuperação antes de precisar dela.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.