Ataques de ransomware contra MSPs: um guia de proteção e recuperação

Um terceiro está envolvido em 48% de todas as violações de dados hoje, um aumento de 60% em apenas um ano. ^[1] Para cada cliente em sua carteira, um provedor de serviços gerenciados (MSP) é um terceiro e, geralmente, aquele com o acesso mais privilegiado.

Um ataque de ransomware a um MSP é uma única intrusão que chega a todos os clientes de uma só vez. Em vez de invadir cinquenta empresas, o atacante compromete aquela que já detém acesso privilegiado às cinquenta e, então, usa esse acesso como um técnico usaria.

Como 83% das organizações sofreram pelo menos um ataque de ransomware nos últimos dois anos, evitar ransomware por completo já não é um plano realista. ^[2] Para um MSP, a pergunta em torno da qual vale a pena planejar não é se um ambiente de cliente será atingido, mas quantos serão atingidos ao mesmo tempo.

Este guia aborda por que grupos de ransomware miram MSPs, como atacantes se movem das ferramentas de gerenciamento de um MSP para as redes dos clientes, por que credenciais compartilhadas Backup podem desfazer o plano de recuperação de todos os clientes e como restaurar vários ambientes de uma só vez.

Principais conclusões

• Uma intrusão em um MSP pode entregar ransomware a todos os clientes de uma só vez, porque o acesso privilegiado que faz o serviço funcionar é o mesmo acesso que um atacante herda.

• Plataformas de monitoramento e gerenciamento remoto (RMM) são a rota de maior valor para entrada, porque um RMM mantém uma conexão permanente com cada rede de cliente que um atacante herda intacta.

• Credenciais de administrador compartilhadas Backup decidem o resultado de um ataque de ransomware a um MSP. O armazenamento Backup com Absolute Immutability é o que protege os dados Backup quando essas credenciais estão nas mãos de um atacante.

Por que grupos de ransomware miram MSPs

Grupos de ransomware miram MSPs não porque sejam mais fáceis de violar do que os clientes que protegem, mas porque uma única intrusão pode produzir muitas vítimas, e o acesso necessário para alcançá-las já está em vigor.

Há quatro aspectos dos MSPs que os tornam alvos de alto valor para agentes mal-intencionados.

• Uma intrusão, muitas vítimas: Em um ataque à cadeia de suprimentos de um MSP, o atacante alcança os alvos pretendidos por meio de um fornecedor em quem esses alvos já confiam. Comprometer um único MSP pode espalhar ransomware para dezenas ou centenas de ambientes a jusante, de modo que o esforço por vítima cai para uma fração do que um ataque direto custaria.

• As chaves vêm com o contrato: MSPs mantêm credenciais de alto privilégio em cada ambiente de cliente por design, porque a administração remota é o serviço pelo qual os clientes pagam. Um atacante que assume o controle dessas credenciais herda esse alcance sem precisar conquistá-lo.

• Um playbook serve para todos os clientes: As ferramentas, convenções de nomenclatura e baselines de segurança que um MSP aplica em toda a sua carteira são o que torna um grande parque eficiente de operar. Elas também tornam eficiente atacar, porque o reconhecimento feito uma vez tende a se aplicar em todos os lugares.

• Reguladores chegaram à mesma conclusão: A UE e o Reino Unido ambos incluíram provedores de serviços gerenciados na lei de cibersegurança como uma categoria distinta, em vez de tratá-los como empresas comuns. O raciocínio deles corresponde ao de um atacante: um MSP comprometido pode interromper muitas organizações de uma só vez.

• Sob a NIS2, o gerenciamento de serviços de TIC é um dos setores do Anexo I de alta criticidade, cobrindo provedores de serviços gerenciados e serviços de segurança gerenciados. ^[3] A classificação então segue a definição da UE de porte de empresa, de modo que MSPs com 250 ou mais funcionários, ou com faturamento acima de €50 milhões e um balanço acima de €43 milhões, contam como entidades essenciais. ^[4]

• O Reino Unido está indo na mesma direção. Seu Projeto de Lei de Cibersegurança e Resiliência ainda não é lei, mas, quando se tornar lei, criará uma categoria de provedores de serviços gerenciados relevantes e definirá o reporte de incidentes em 24 e 72 horas. ^[5]

Como atacantes entram em um MSP por meio do seu RMM

Todo MSP opera com duas plataformas. O software de monitoramento e gerenciamento remoto (RMM) dá aos técnicos uma conexão permanente com cada rede de cliente. O software de automação de serviços profissionais (PSA) mantém os chamados, contratos e registros de clientes que descrevem o que existe dentro dessas redes. O RMM é o alvo de maior valor porque não apenas descreve os ambientes dos clientes, como também os alcança.

Entrar nessa plataforma geralmente segue uma de duas rotas. A primeira é um servidor de gerenciamento deixado exposto à internet sem patches atuais, e explorar uma vulnerabilidade de software agora é o maior ponto único de partida para violações, com 31%. ^[1] A segunda é uma conta de técnico sem autenticação multifator, em que uma senha roubada basta por si só.

Qualquer uma das rotas termina no mesmo lugar. O atacante eleva privilégios dentro da plataforma e, então, distribui ransomware por meio dos próprios agentes do MSP, usando o mesmo mecanismo que os técnicos usam para implantar patches e scripts. Em um painel de monitoramento, essa distribuição parece uma atualização de software agendada, o que torna esses ataques tão difíceis de detectar.

Atores do DragonForce fizeram exatamente isso em 2025. Eles provavelmente encadearam três vulnerabilidades no SimpleHelp, a ferramenta de RMM que um MSP hospedava para seus clientes, e então usaram esse acesso para mapear as redes antes de implantar ransomware e roubar dados. ^[6]

A essa altura, o atacante detém direitos administrativos em todos os ambientes que o RMM alcança, incluindo os consoles que controlam os backups.

Um login de administrador roubado pode eliminar todos os backups dos clientes?

Em muitos MSPs, uma conta de administrador Backup controla os backups de todos os clientes, então as credenciais que um invasor rouba para se mover pelos ambientes dos clientes muitas vezes também governam o plano de recuperação de todos eles. Os MSPs acabam nesse cenário porque consoles compartilhados tornam econômico gerenciar mais de 50 clientes, e essa troca é um dos desafios de MSP Backup de operar muitos ambientes ao mesmo tempo.

Essa conta também é a rota para os backups de dados. Muitos MSPs operam um modelo híbrido, mantendo uma cópia local em cada site do cliente e uma cópia fora do site no próprio datacenter para atender à regra 3-2-1-1-0: três cópias, em duas mídias diferentes, uma fora do site, uma imutável e zero erros na verificação de restauração.

Quando um console controla ambos, um único login roubado pode alcançar os dois. Invasores caçam backups para bloquear a recuperação e forçar pagamentos de resgate e, sem eles, o resgate é a única saída. Um pilar do backup e recuperação de dados é manter backups imutáveis, o que significa que, durante uma janela de tempo predefinida, um Backup não pode ser alterado nem excluído.

Ainda assim, é preciso cuidado aqui, porque muitos sistemas que afirmam oferecer backups imutáveis têm exceções e brechas ocultas. A mais comum é uma configuração: o S3 Object Lock no modo governance permite que um usuário com permissões específicas de substituição remova o bloqueio, o que é exatamente o que uma conta de administrador Backup roubada fornece.

Uma solução para isso é Absolute Immutability, o que significa que nem mesmo o administrador mais privilegiado, ou um invasor com acesso ao armazenamento Backup, consegue modificar ou excluir dados. Esse nível de proteção de backup contra ransomware só pode ser alcançado com um sistema de armazenamento Backup que seja Seguro-by-Design, com Zero Access para executar ações destrutivas. Esse Zero Access também deve ser verificável por meio de testes de terceiros.

Entre líderes de TI, 93% dizem que o armazenamento Backup deve proteger backups mesmo quando invasores conhecem os segredos de TI de uma organização, enquanto apenas 16% dizem que seu armazenamento é absolutamente imutável. ^[2] Para um MSP, essa lacuna decide se a cópia imutável em uma configuração 3-2-1-1-0 sobrevive a um login roubado, para todos os clientes ao mesmo tempo.

Como recuperar vários clientes após um ataque de ransomware a um MSP

Se um ataque leva os backups de um cliente ou de todos eles é decidido principalmente pela arquitetura, não por quão bem o incidente é tratado. De qualquer forma, o trabalho parece o mesmo: muitos ambientes de clientes são restaurados ao mesmo tempo, por meio de um único pipeline, com cada cliente esperando ser o primeiro. O que muda é quanto resta para restaurar.

As organizações também estão recuperando menos do que costumavam: entre as atingidas por ransomware, apenas 39% recuperaram pelo menos 75% de seus dados em 2026, abaixo de 57% em 2024. ^[2]

Desconecte suas próprias ferramentas antes de tocar nos sistemas dos clientes

Desconecte primeiro as plataformas RMM e PSA, antes que qualquer trabalho de remediação comece nos sistemas dos clientes. Se o invasor ainda mantiver acesso ao mecanismo de implantação, sistemas limpos pela manhã podem ser criptografados novamente à tarde.

Isso significa desativar ferramentas de acesso remoto, encerrar sessões ativas, revogar tokens de API e chaves de integração e auditar a plataforma em busca de contas, scripts e tarefas agendadas que o invasor adicionou. Os sistemas dos clientes permanecem isolados até que se confirme que o plano de gerenciamento está limpo.

Confirme quais backups sobreviveram antes de prometer a alguém um cronograma

Com a plataforma contida, determine quais backups de clientes estão intactos, quais foram criptografados ou excluídos e até onde retrocede o último ponto de restauração limpo para cada um. Um cronograma de recuperação construído sobre backups que ninguém verificou é um palpite com datas anexadas.

Verifique cada ponto de restauração em relação à data do comprometimento inicial, em vez da data em que o ransomware foi executado. Invasores frequentemente mantêm acesso por dias ou semanas antes de acionar a criptografia, então um ponto de restauração dentro dessa janela pode reintroduzir o ponto de apoio.

Onde o armazenamento Backup é absolutamente imutável, esta etapa estabelece qual ponto de restauração usar. Onde não é, ela estabelece quanto foi perdido e, para alguns clientes, a resposta decide se a recuperação é uma opção.

Restaure na ordem que o contrato já define

Saber o que sobreviveu diz o que pode voltar a operar, mas não o que volta primeiro. Essa ordem deve ser definida com antecedência, por escrito, com base em fundamentos declarados: compromissos contratuais de Objetivo de Tempo de Recuperação (RTO), exposição regulatória e criticidade do negócio. Observe que o volume de ligações telefônicas após o evento não é um deles!.

Concordar com isso antes de um incidente tira a negociação do pior momento possível e dá aos gerentes de conta algo a que apontar quando trinta clientes fazem a mesma pergunta ao mesmo tempo. Um plano de resposta a ransomware documentado é onde essa ordem fica, junto com os papéis, caminhos de escalonamento e deveres de comunicação com o cliente que a acompanham.

Planeje a vazão de restauração, não o tempo de restauração por cliente

Saber a ordem não diz quanto tempo leva. Uma restauração que roda por uma hora em um cliente roda por dias em trinta, porque quando as cópias no local são perdidas, todos os clientes restauram do datacenter do MSP ao mesmo tempo, e a restrição passa a ser esse pipeline compartilhado, incluindo os links de saída para cada site do cliente, em vez de qualquer job individual. A vazão de restauração medida em todo o ambiente é o número que decide quanto tempo o incidente dura, e vale a pena testá-la antes de ser necessária.

Estratificação de armazenamento é o que move esse número. Em um repositório Backup scale-out Veeam, a camada de desempenho mantém dados recentes para restauração rápida, enquanto as camadas de capacidade e de arquivo carregam retenção mais longa a menor custo.

Manter backups recentes dos clientes em armazenamento de backup on-premises no site do cliente, na camada de desempenho, significa que as restaurações mais urgentes rodam na velocidade da rede local, de modo que a recuperação de dados após um ataque de ransomware não fica em fila atrás da cópia fora do site no data center do MSP, que é construída para retenção de longo prazo.

O relógio de reporte começa antes de a restauração terminar

As obrigações de reporte não esperam a restauração. Elas começam quando um MSP toma conhecimento do incidente, então, sob a NIS2, um alerta inicial vence dentro do primeiro dia e uma notificação mais completa dentro de três dias. ^[7] Ambos chegam enquanto as restaurações ainda estão em execução. O projeto de lei do Reino Unido segue o mesmo padrão em duas etapas. ^[5]

Restaurar os dados também não encerra o assunto. Operadores de ransomware frequentemente roubam dados antes de criptografá-los, então uma recuperação de ransomware limpa pode coexistir com uma violação reportável para o MSP e os clientes afetados. A assessoria jurídica e a seguradora cibernética devem ser incluídas na resposta no primeiro dia, não apenas quando os sistemas voltarem a ficar online.

Armazenamento Backup criado para a flexibilidade de MSP

MSPs precisam de armazenamento Backup que seja Simples de operar, resiliente contra ransomware e flexível o suficiente para suportar ambientes diversos de clientes, nos sites dos clientes e no próprio data center do MSP.

Soluções tradicionais frequentemente exigem hardening manual, dependem de ferramentas fragmentadas e forçam MSPs a modelos de precificação rígidos que desaceleram o crescimento.

Object First Ootbi torna os dados Veeam Seguro com Absolute Immutability, garantindo que ninguém, nem mesmo o administrador mais privilegiado ou um invasor com acesso ao armazenamento Backup, possa modificar ou excluir dados Backup.

A aplicação fica no próprio armazenamento, em vez de em política de software, portanto não pode ser desativada por credenciais, mudanças de configuração ou comandos remotos, e ações destrutivas são removidas totalmente da interface administrativa, em vez de serem controladas por permissões.

Para as falhas descritas acima, isso significa:

• Uma conta de administrador Backup roubada ainda pode fazer login e restaurar, que é o que a recuperação exige, mas não pode alterar nem excluir backups.

• Ransomware distribuído pelos próprios agentes do MSP pode gravar novos backups, mas não pode alterar o que já foi gravado, porque a imutabilidade se aplica no momento em que cada Backup é gravado.

• Um console alcançando ambas as cópias em uma configuração híbrida não consegue remover o bloqueio de nenhuma delas, porque a aplicação fica em cada appliance.

MSPs podem simplificar o gerenciamento de várias implantações com o utilitário de monitoramento baseado em nuvem Fleet Manager. Ao adquirir appliances, MSPs podem escolher entre preços por assinatura baseados em consumo e CapEx para se alinhar ao seu modelo de negócios.

Baixe o White paper para descobrir os desafios que os MSPs enfrentam e como o Object First entrega armazenamento de backup à prova de ransomware enquanto reduz a sobrecarga operacional.

Perguntas frequentes

Você deve pagar o resgate?

Pagar não garante chaves de descriptografia funcionais, e o dinheiro financia uma operação que atacará novamente. Um MSP com backups verificados e absolutamente imutáveis pode restaurar ambientes de clientes sem negociar, o que tira a questão de pauta.

Qual é a melhor proteção contra ransomware para MSPs?

O conjunto essencial é autenticação multifator nas plataformas RMM e PSA, aplicação rápida de patches em ferramentas de gerenciamento expostas à internet e credenciais e destinos de armazenamento separados para cada cliente. Tudo isso reduz a chance de uma violação, enquanto o armazenamento Backup com Absolute Immutability determina se um MSP consegue se recuperar de uma.

A NIS2 exige que MSPs sejam capazes de se recuperar de ransomware?

O Artigo 21 lista a continuidade de negócios, incluindo gerenciamento Backup e recuperação de desastres, entre as medidas de gestão de risco que entidades no escopo devem implementar, e a gestão de serviços de TIC aparece no Anexo I como um setor de alta criticidade. ^[3] A diretiva não nomeia uma tecnologia específica, então a obrigação é demonstrar que a recuperação realmente funciona, o que MSPs podem verificar em relação à lista completa de medidas de gestão de risco da NIS2.

Referências

[1] Verizon. "Vulnerability exploitation is top breach entry point, 2026 DBIR finds." 2026. https://www.verizon.com/about/news/breach-industry-wide-dbir-finds

[2] Omdia. "Recovery without Compromise: The Data-Backed Case for Backup Storage with Absolute Immutability." Research commissioned by Object First. 2026. https://objectfirst.com/recovery-without-compromise/

[3] European Parliament and Council. "Directive (EU) 2022/2555 (NIS2)." 2022. https://eur-lex.europa.eu/eli/dir/2022/2555/oj

[4] European Commission. "Commission Recommendation 2003/361/EC concerning the definition of micro, small and medium-sized enterprises." 2003. https://eur-lex.europa.eu/eli/reco/2003/361/oj

[5] UK Parliament. "Cyber Security and Resilience (Network and Information Systems) Bill, HL Bill 32 of 2026-27." 2026. https://bills.parliament.uk/bills/4035

[6] Sophos. "DragonForce actors target SimpleHelp vulnerabilities to attack MSP, customers." 2025. https://www.sophos.com/en-us/blog/dragonforce-actors-target-simplehelp-vulnerabilities-to-attack-msp-customers/

[7] European Parliament and Council. "Directive (EU) 2022/2555 (NIS2), Article 23." 2022. https://eur-lex.europa.eu/eli/dir/2022/2555/oj