SonicWall é alvo de ação judicial após falha em backup em nuvem facilitar ataque de ransomware
A fintech norte‑americana Marquis, especializada em análise e visualização de dados para instituições financeiras, abriu um processo contra a fornecedora de soluções de segurança SonicWall, alegando que uma falha grave no serviço de backup em nuvem da empresa criou o caminho para um ataque de ransomware que paralisou suas operações e expôs dados sensíveis de centenas de milhares de pessoas. A ação foi protocolada no Tribunal Distrital dos EUA para o Distrito Leste do Texas.
Segundo a petição, criminosos digitais conseguiram acessar arquivos confidenciais de configuração de firewalls armazenados na nuvem da SonicWall. Entre as informações exfiltradas estavam os chamados “códigos de emergência” (scratch codes), credenciais especiais usadas para acesso administrativo em situações críticas. Na prática, esses códigos funcionam como chaves-mestras para contornar mecanismos de autenticação tradicionais em cenários de suporte ou recuperação.
No documento, a Marquis afirma que a fornecedora de segurança acabou se tornando o elo fraco da proteção: ao permitir que esses códigos fossem obtidos a partir do backup em nuvem, a SonicWall teria fornecido aos invasores “as chaves do cofre”. O texto sustenta que a empresa de segurança “permitiu que um ator de ameaça obtivesse as chaves para contornar essa linha de defesa e entrar diretamente na rede interna da Marquis, exatamente o que o firewall deveria impedir”.
Com posse dos arquivos de configuração e dos códigos de emergência, os atacantes teriam estudado em detalhes a arquitetura de defesa, regras de acesso e segmentação de rede, o que facilitou o planejamento e a execução do ataque. Assim, conseguiram lançar um ransomware que interrompeu serviços da Marquis e, ao mesmo tempo, extraiu grandes volumes de informações sigilosas pertencentes a clientes de bancos e cooperativas de crédito atendidos pela fintech.
O impacto do incidente foi significativo. A Marquis informou que os dados comprometidos incluem nomes completos, datas de nascimento, endereços, números de contas bancárias, informações de cartões de débito e crédito e números de Seguro Social – combinação de dados suficiente para permitir fraudes financeiras, roubo de identidade e uso indevido de crédito em larga escala. Por isso, a escala do dano não se limita à interrupção temporária dos serviços da empresa, mas se prolonga no tempo, afetando diretamente a privacidade e a segurança financeira das vítimas.
A SonicWall tornou pública a violação em 17 de setembro de 2025. Inicialmente, afirmou que menos de 5% dos arquivos de backup de configuração de firewalls de clientes teriam sido exfiltrados. Porém, cerca de um mês depois, já em outubro, a empresa voltou atrás e revisou essa estimativa, reconhecendo que, na realidade, todos os clientes tiveram seus arquivos de backup de firewall roubados no incidente. Essa mudança de narrativa é um dos pontos explorados pela acusação, que levanta dúvidas sobre a forma como o incidente foi inicialmente avaliado e comunicado.
A Marquis, por sua vez, começou a avisar as pessoas afetadas em dezembro de 2025, após concluir que o ataque à sua própria rede havia ocorrido em agosto do mesmo ano. O intervalo de tempo entre a intrusão, a confirmação do impacto e a notificação às vítimas tende a ser um componente importante tanto para a análise regulatória quanto para a avaliação de danos na esfera cível, já que, quanto mais tarde os indivíduos são informados, maior o período em que permanecem expostos a fraudes sem saber.
O processo detalha ainda a origem técnica da falha. De acordo com a queixa, uma mudança de código feita pela SonicWall em fevereiro de 2025 em uma de suas APIs teria “criado uma vulnerabilidade explorável”. Essa alteração, afirma a petição, possibilitou que invasores acessassem arquivos de backup de configuração “sem autenticação adequada”, apenas explorando números de série previsíveis dos firewalls. Ou seja, bastaria ao atacante adivinhar ou gerar esses identificadores para obter acesso a dados altamente sensíveis de várias organizações.
Registros do incidente junto ao procurador‑geral do Texas indicam que pelo menos 400 mil pessoas em todo o território dos Estados Unidos foram afetadas. Considerando que a Marquis atende instituições financeiras de diferentes portes, o número de organizações impactadas indiretamente pode ser ainda maior, já que cada registro comprometido está associado a um cliente final de banco ou cooperativa de crédito.
Além do embate jurídico, o caso levanta uma questão central para empresas de todos os portes: até que ponto confiar que soluções em nuvem, especialmente de segurança, estão devidamente protegidas e segmentadas? Ao que tudo indica, os invasores não atacaram diretamente a infraestrutura interna da Marquis no primeiro momento, mas sim a camada de serviços do fornecedor de segurança. Isso caracteriza um típico ataque à cadeia de suprimentos (supply chain), em que o comprometimento de um provedor abre portas para atingir várias organizações de uma só vez.
Outro ponto sensível é a forma como backups são tratados em ambientes Cloud/SaaS. Há uma percepção generalizada de que, por estarem na nuvem, dados e configurações estão automaticamente protegidos, redundantes e, por consequência, seguros. O caso da SonicWall evidencia o contrário: backups podem se transformar em um alvo estratégico, já que costumam concentrar configurações, chaves e dados históricos em um único repositório. Se esse repositório não tiver controles de autenticação e autorização robustos, torna‑se um ponto de falha catastrófico.
A presença de “códigos de emergência” em arquivos acessíveis via API também levanta discussões sobre práticas de engenharia de produto. Em ambientes sensíveis, credenciais desse tipo deveriam ser separadas de backups regulares, armazenadas em cofres de segredos dedicados, com camadas adicionais de criptografia e autenticação multifator, além de políticas rígidas de acesso privilegiado. Misturar esses elementos críticos com dados de configuração comuns aumenta a superfície de ataque e o potencial de dano em caso de vazamento.
Do ponto de vista regulatório, o incidente pressiona por maior transparência e responsabilidade contratual em serviços de segurança gerenciados. Quando uma organização terceiriza uma camada essencial de proteção, como firewalls e seus backups em nuvem, espera que requisitos mínimos de segurança estejam implicados no contrato. Falhas como autenticação insuficiente em APIs, uso de identificadores previsíveis e subestimação inicial do incidente podem ser interpretadas como negligência, sobretudo em setores sob forte regulação, como o financeiro.
Para empresas que dependem de fornecedores de segurança, o caso funciona como um alerta para revisar contratos, níveis de serviço (SLAs) e exigências de auditoria técnica. Não basta contratar uma marca reconhecida: é necessário estabelecer mecanismos formais de verificação, testes de penetração independentes, revisões de arquitetura e planos claros de resposta a incidentes envolvendo terceiros. Em alguns cenários, pode fazer sentido manter uma camada adicional de criptografia própria sobre dados armazenados em serviços de terceiros, de forma que o provedor não tenha acesso pleno ao conteúdo.
Do lado da gestão de risco, o episódio reforça a necessidade de desenhar estratégias que considerem explicitamente o comprometimento de fornecedores de segurança. Planos de continuidade de negócios e de resposta a incidentes devem contemplar cenários em que chaves, configurações e segredos associados a equipamentos de segurança possam ser roubados. Isso inclui prever rotação rápida de credenciais, substituição de chaves, revisão forçada de configurações e, quando possível, mecanismos de detecção de uso anômalo de códigos de emergência ou acessos administrativos.
O incidente também expõe uma tensão recorrente entre usabilidade e segurança. Códigos de emergência e acessos administrativos simplificados costumam ser criados para agilizar suporte e recuperação em momentos críticos. Porém, se não forem tratados como ativos de altíssimo risco, podem se transformar em atalhos privilegiados para invasores. Organizações e fornecedores precisam reavaliar até que ponto esses “atalhos” são indispensáveis e, quando forem, de que forma podem ser protegidos com múltiplas camadas de controle.
Para o usuário final – o titular dos dados expostos – o caso é mais um lembrete de que, mesmo quando seus dados estão sob a guarda de instituições financeiras tradicionais, há toda uma cadeia de terceiros manuseando essas informações. Quanto mais complexa a cadeia tecnológica, maior a importância de regras claras de proteção, notificação ágil em caso de violação e medidas de mitigação, como monitoramento de crédito, alertas de fraude e possibilidade de contestação facilitada de transações suspeitas.
Em síntese, o processo movido pela Marquis contra a SonicWall vai além de um embate específico entre cliente e fornecedor. Ele evidencia fragilidades estruturais em como o mercado lida com backups em nuvem, APIs expostas, credenciais privilegiadas e gestão de risco de terceiros. Independentemente do desfecho judicial, o caso tende a servir de referência para futuras discussões sobre responsabilidade compartilhada, boas práticas de arquitetura de segurança em nuvem e a necessidade de tratar dados de backup – especialmente de segurança – com o mesmo rigor (ou até mais) aplicado aos ambientes de produção.