SonicWall é alvo de ação judicial após falha que teria facilitado ataque de ransomware
A fornecedora de soluções de segurança SonicWall está no centro de uma disputa judicial nos Estados Unidos após ser acusada de contribuir diretamente para um grave incidente de ransomware. A empresa de tecnologia financeira Marquis, especializada em ferramentas de visualização de dados para bancos e cooperativas de crédito, entrou com um processo alegando que uma falha no serviço de backup em nuvem da SonicWall abriu caminho para a invasão de sua rede em 2025.
A ação foi protocolada no Tribunal Distrital dos EUA para o Distrito Leste do Texas e responsabiliza a SonicWall por uma suposta vulnerabilidade em suas APIs de backup de configuração de firewall. Segundo a queixa, criminosos cibernéticos conseguiram acessar arquivos altamente sensíveis de configuração de firewalls armazenados na nuvem da fornecedora, explorando um erro de código introduzido no início daquele ano.
Entre os dados extraídos, estariam “códigos de emergência” (scratch codes) usados para acesso administrativo de última instância. Essas credenciais funcionam, em termos práticos, como uma espécie de “chave mestra” para administradores que precisam entrar rapidamente em sistemas protegidos, inclusive quando métodos comuns de autenticação falham. No processo, a Marquis afirma que, ao permitir que esses códigos fossem obtidos por terceiros mal-intencionados, a SonicWall “entregou ao atacante as chaves para contornar a linha de defesa e entrar diretamente na rede interna”, justamente o perímetro que o firewall deveria proteger.
De posse das configurações detalhadas dos firewalls da Marquis, os invasores teriam sido capazes de mapear a arquitetura de rede, identificar pontos fracos e planejar um ataque de ransomware cirúrgico. Como resultado, as operações da fintech foram interrompidas, e dados pessoais e financeiros de centenas de milhares de pessoas foram acessados de forma não autorizada.
A Marquis atende centenas de instituições financeiras nos Estados Unidos, entre bancos e cooperativas de crédito. De acordo com as informações divulgadas pela própria empresa, os dados expostos incluem nomes completos, datas de nascimento, endereços, números de contas bancárias, dados de cartões de débito e crédito e números de Seguro Social. Trata-se de um conjunto de informações suficiente para possibilitar desde fraudes financeiras diretas até roubo de identidade em larga escala.
A linha do tempo do incidente também é um ponto central da ação judicial. A SonicWall tornou pública a ocorrência de uma violação em seu ambiente de backup em nuvem em 17 de setembro de 2025. Na ocasião, a companhia informou que acreditava que menos de 5% dos arquivos de backup de configuração de firewalls de clientes haviam sido exfiltrados. Porém, em outubro do mesmo ano, a empresa revisou esse posicionamento e admitiu que, na verdade, os arquivos de backup de todos os clientes haviam sido roubados no incidente.
A Marquis, por sua vez, começou a notificar formalmente os indivíduos afetados em dezembro de 2025, informando que sua própria rede havia sido comprometida meses antes, em agosto. No processo, a fintech argumenta que a origem do problema está em uma mudança de código efetuada em fevereiro de 2025 em uma das APIs da SonicWall. Essa modificação teria criado uma vulnerabilidade explorável, permitindo que atacantes acessassem arquivos de backup de configuração de firewalls “sem autenticação adequada”, apenas ao adivinhar números de série previsíveis associados aos dispositivos.
Em documentos apresentados às autoridades do estado do Texas, o incidente é descrito como de grande porte: pelo menos 400 mil pessoas em todo o território norte-americano teriam sido impactadas pela violação relacionada à Marquis. O caso ilustra como uma brecha em um único componente da cadeia de segurança – neste caso, o serviço de backup em nuvem do fornecedor – pode ter efeito cascata sobre diversos clientes corporativos e, por consequência, sobre centenas de milhares de cidadãos.
O papel crítico do backup em nuvem na segurança
O episódio também reacende o debate sobre a segurança de soluções em nuvem, em especial quando usadas para armazenar configurações sensíveis como as de firewalls, VPNs e outros equipamentos de segurança. Muitas empresas partem do princípio de que, ao contratar serviços de um grande fornecedor, estarão automaticamente protegidas por camadas avançadas de segurança. Entretanto, esse caso mostra que o modelo de responsabilidade compartilhada exige que clientes entendam claramente quais partes da proteção cabem ao provedor e quais exigem controles adicionais do próprio cliente.
Além disso, há um mito persistente no mercado de que, ao migrar para modelos Cloud ou SaaS, o backup estaria implicitamente garantido e sempre disponível em caso de falha ou ataque. A prática demonstra o oposto: ainda que exista redundância de infraestrutura, isso não significa, por si só, um plano robusto de backup e recuperação, tampouco garante que os dados de backup estejam isolados o suficiente para resistir a invasores que comprometam a camada de aplicação ou de API.
APIs como vetor de ataque
Um ponto particularmente sensível no processo é a acusação de que uma mudança de código em uma API da SonicWall teria permitido o acesso a backups sem autenticação adequada. As interfaces de programação de aplicações são hoje um dos principais alvos de criminosos. Vulnerabilidades como autenticação fraca, tokens mal gerenciados, validação insuficiente de parâmetros e previsibilidade em identificadores (como números de série ou IDs sequenciais) podem ser exploradas em ataques automatizados, capazes de varrer grandes faixas de endereços até encontrar combinações válidas.
Se a alegação da Marquis for confirmada, estaríamos diante de um exemplo clássico de falha de segurança em API: uso de identificadores previsíveis somado à ausência de uma checagem rigorosa de autenticação e autorização para acesso a dados extremamente sensíveis. Em um cenário ideal, backups de configuração de firewalls deveriam ser protegidos com autenticação forte, criptografia em repouso e em trânsito, controles de acesso granulares e monitoramento contínuo de tentativas suspeitas.
O que o caso ensina para outras empresas
Para organizações que dependem de fornecedores de segurança, o processo contra a SonicWall traz algumas lições importantes:
1. Auditoria de fornecedores: é fundamental revisar contratos, documentação técnica e práticas de segurança de cada provedor, principalmente aqueles que armazenam dados críticos ou gerenciam componentes de segurança da rede.
2. Segmentação de segredos: códigos de emergência, credenciais administrativas e chaves de acesso não devem ficar armazenados em locais acessíveis pelos mesmos mecanismos usados para configurações comuns. O princípio do menor privilégio vale não só para usuários, mas também para sistemas e rotinas de backup.
3. Defesa em profundidade: confiar exclusivamente no firewall ou em uma única solução é um risco. Monitoramento de comportamento de usuários e sistemas, detecção de anomalias de rede, segmentação interna e autenticação multifator reduzem o impacto caso uma camada seja comprometida.
4. Testes de invasão e análise de APIs: com o aumento da exposição de APIs, é essencial incluir esses componentes em testes de segurança periódicos, identificando vulnerabilidades como as alegadas no processo.
5. Planos de resposta a incidentes e comunicação: o desencontro inicial entre a estimativa de impacto divulgada pela SonicWall e o alcance real da violação mostra como a falta de visibilidade plena complica a gestão de crises. Ter processos maduros de resposta, investigação e comunicação é tão importante quanto a tecnologia em si.
Impacto para usuários finais e para o sistema financeiro
Para as pessoas físicas cujos dados foram expostos, a consequência imediata é o aumento do risco de golpes, abertura fraudulenta de contas, pedidos de crédito não autorizados e ataques de phishing altamente personalizados. Informações como número de Seguro Social, combinadas com dados bancários e de cartão, são extremamente valiosas no submundo digital.
No contexto do sistema financeiro, incidentes dessa natureza abalam a confiança não apenas na empresa diretamente atingida, mas em todo o ecossistema de prestação de serviços tecnológicos a bancos e cooperativas. Reguladores tendem a reforçar exigências de proteção de dados, notificação de incidentes e governança de terceiros, elevando a barra de conformidade para todo o setor.
A responsabilidade compartilhada em segurança
Um dos pontos que devem surgir na discussão jurídica é até onde vai a responsabilidade do fornecedor de segurança e onde começa a responsabilidade do cliente. Em muitos casos, o provedor é encarregado de proteger a infraestrutura base e a aplicação, enquanto o cliente deve controlar acessos, senhas, configurações e monitoramento interno. Quando a alegação envolve um defeito de projeto ou de implementação de uma API, a balança tende a pender para o lado do fornecedor, mas ainda assim tribunais costumam analisar se o cliente tomou medidas razoáveis adicionais para proteger seus ativos.
Para as empresas, a principal conclusão é que contratar um grande nome em segurança não elimina a necessidade de olhar criticamente para a arquitetura, exigir relatórios de auditoria, conduzir avaliações independentes e, quando possível, isolar ou criptografar informações sensíveis de forma que nem mesmo o fornecedor tenha acesso em texto puro.
A importância de revisão de código e governança de mudanças
Outro ponto sensível é o fato de a vulnerabilidade, segundo a ação, ter surgido após uma alteração de código em fevereiro de 2025. Isso remete à necessidade de processos robustos de desenvolvimento seguro, revisão de código independente, testes automatizados de segurança (como SAST e DAST) e governança rígida de mudanças em sistemas que lidam com dados críticos.
Cada modificação em APIs que controlam acesso a backups, credenciais ou configurações de segurança deveria passar por controles adicionais: revisões por especialistas em segurança, simulações de abuso de funcionalidades (abuse cases) e monitoramento mais intenso logo após o deploy, para flagrar comportamentos anômalos precocemente.
Como empresas podem se proteger em cenários similares
Diante de casos como o da Marquis, algumas medidas práticas podem ser adotadas por qualquer organização que use serviços em nuvem para backup de configurações de segurança:
– Criptografar configurações críticas com chaves próprias, mantidas em módulos seguros ou cofres de segredo, sem depender exclusivamente da criptografia nativa do provedor.
– Separar backups de credenciais e códigos sensíveis dos demais dados de configuração, com controles extras de acesso e monitoramento.
– Implementar monitoramento de atividades em APIs de fornecedores, por meio de logs detalhados e alertas para padrões suspeitos, como altos volumes de download de backups ou acessos de origens incomuns.
– Testar rotineiramente a restauração de backups, garantindo não apenas disponibilidade, mas também integridade e segurança do processo de recuperação.
– Negociar cláusulas contratuais claras de responsabilidade, notificação de incidentes e auditoria, para reduzir ambiguidade em caso de falhas.
Perspectivas para o desfecho do caso
O resultado da ação movida pela Marquis contra a SonicWall pode criar um precedente relevante para o mercado de cibersegurança. Se o tribunal entender que houve negligência na implementação da API ou na proteção dos backups, outros clientes afetados pela mesma violação podem se sentir encorajados a buscar compensação. Ao mesmo tempo, fornecedores tendem a investir ainda mais em processos de desenvolvimento seguro, certificações e transparência sobre sua postura de segurança.
Independentemente da decisão judicial, o episódio reforça uma mensagem importante: mesmo soluções projetadas para proteger organizações podem se tornar, se mal implementadas ou configuradas, o elo mais fraco da cadeia. Segurança, especialmente em ambientes em nuvem, exige vigilância constante, validação independente e uma visão realista de que nenhuma tecnologia é infalível.