A Beget, uma das maiores provedoras russas de hospedagem, domínios e serviços de nuvem, vive o tipo de incidente que costuma aparecer em apresentações de segurança como cenário extemo. Um invasor obteve acesso à camada de gerenciamento da infraestrutura, acionou malware preparado para apagar dados e transformou uma operação com milhares de clientes em uma corrida para reconstruir servidores, serviços e vínculos que antes pareciam parte permanente da paisagem digital.
O ataque começou na madrugada de 2 de novembro. A empresa identificou a atividade maliciosa pouco depois de os scripts destrutivos entraem em ação e desconectou os servidores da rede para tentar impedir que o dano se espalhasse ainda mais. A resposta rápida conteve parte do desastre, mas não evitou a perda de dados na infraestrutura de nuvem. Ambientes de VPS, armazenamento S3 e Kubernetes foram atingidos, assim como configurações de CDN e endereços IP.
Quando o backup desaparece junto
O trecho mais desconfortável do caso não está apenas na queda dos serviços. As imagens binárias usadas como backup integral dos servidores VPS foram perdidas. Cópias em nível de arquivo sobreviveram somente para parte dos clientes, e associar cada conjunto recuperado à conta correta virou outro trabalho técnico. Em outras palavras: havia backup, mas uma parcela dele estava dentro do mesmo raio de destruição operacional.
Essa é a diferença entre possuir cópias e ter uma estratégia de recuperação. Um backup realmente útil precisa estar isolado das credenciais, do plano de controle e dos riscos que ameaçam o ambiente principal. Se um atacante alcança a administração da nuvem e consegue apagar produção e cópias com o mesmo movimento, a empresa não tinha duas linhas de defesa. Tinha duas gavetas no mesmo armário.
A Beget afirmou não ter encontrado evidências de download ou alteração deliberada de dados de clientes. O ataque parece ter sido destrutivo, não uma operação de espionagem ou extorsão. Isso reduz um tipo de risco, mas não suaviza a realidade para quem perdeu uma máquina virtual, um banco gerenciado ou objetos guardados no S3. Dado apagado continua apagado, ainda que ninguém o tenha roubado antes.
O que deveria existir fora da nuvem principal
- cópias imutáveis ou protegidas por credenciais independentes;
- exportações regulares de bancos em formato restaurável;
- configurações de DNS, rede, CDN e infraestrutura como código;
- teste real de restauração, não apenas relatório de “backup concluído”;
- um plano para reconstruir serviços em outro provedor.
Reconstruir com o inimigo talvez ainda dentro
A empresa decidiu tratar cada parte da infraestrutura como potencialmente comprometida. É uma postura lenta, cara e correta. Religar servidores apenas porque eles respondem ao ping seria a receita ideal para restaurar também acessos persistentes, scripts escondidos e configurações manipuladas. Por isso, cerca de mil servidores precisam passar por verificação manual antes de retornar à operação.
Serviços de hospedagem compartilhada e servidores dedicados foram recuperados gradualmente, mas a nuvem exige uma reconstrução mais profunda. Não basta instalar um hipervisor novo. É necessário recriar a cadeia de gestão, restaurar redes, reconstituir relações entre contas e recursos, validar backups sobreviventes e provar que o ambiente limpo não está conectado a uma raiz ainda comprometida.
Para clientes, o caso também lembra uma verdade pouco simpática: terceirizar infraestrutura não terceiriza responsabilidade. A provedora deve oferecer segurança e disponibilidade, mas o dono da aplicação continua responsável por saber como recuperá-la. Quem mantém código, banco, arquivos e DNS presos ao mesmo fornecedor pode descobrir, em uma madrugada ruim, que comprou conveniência demais e independência de menos.
Nuvem não é sinônimo de invulnerabilidade
O ataque à Beget é uma aula brutal sobre concentração de risco. Não há indicação de que todos os clientes tenham perdido tudo, e a recuperação continua, mas a destruição de ambientes de nuvem e de backups integrais mostra por que redundância precisa atravessar fronteiras administrativas. Uma cópia no mesmo plano de controle é confortável até o dia em que o plano de controle vira a arma. A empresa merece crédito pela transparência operacional e pela decisão de reconstruir com cautela; o desastre, porém, continua sendo um lembrete caro de que recuperação precisa ser projetada antes do incêndio, não durante a fumaça.
