N-able N-central: zero-day expõe o risco do RMM do seu MSP

O N-able N-central, uma das ferramentas de gestão remota mais usadas por empresas de TI terceirizada, virou alvo de um zero-day explorado poucas horas depois da publicação do código de ataque. Em 12 de novembro de 2026, 21 servidores foram invadidos e passaram a minerar criptomoeda, e 19 deles já rodavam a correção mais recente. Neste post eu explico o que aconteceu, o que perguntar ao seu fornecedor de TI hoje e como blindar o console que tem a chave de todos os seus computadores.

TL;DR (atualizado em 15/11/2026)

• O 4EverAble2Shell é uma cadeia de exploração publicada em 12/11 que dá acesso root sem login ao servidor do N-able N-central quando a Legacy API está ligada.
• Em menos de 9 horas, pelo menos 21 servidores reais foram comprometidos com um minerador de Monero. 19 deles estavam no Hotfix 2 (build 2026.4.1.26), a correção que a N-able lançou em 10/11.
• Até a manhã de 15/11 não havia correção confirmada para essa cadeia. A orientação do fabricante é manter a Legacy API desligada e procurar indícios de invasão desde 8/11.
• Se a sua empresa terceiriza TI, o risco não é só do fornecedor: o RMM dele tem permissão de administrador em todas as suas máquinas.
• Há perguntas objetivas para fazer ao seu MSP ainda esta semana, e controles que você pode exigir em contrato.

O que aconteceu com o N-able N-central em novembro de 2026

O N-able N-central é um RMM (Remote Monitoring and Management, ou monitoramento e gestão remota): o painel que a empresa de TI terceirizada usa para instalar atualizações, rodar scripts, acessar telas e inventariar os computadores dos clientes. Um único servidor N-able N-central costuma controlar centenas ou milhares de máquinas de dezenas de empresas diferentes.

A sequência dos fatos, segundo o FAQ técnico da Tenable e a cobertura do BleepingComputer:

Data (2026)	O que aconteceu
9/11	Um pesquisador publica no GitHub o pacote Able2Shell, com 33 supostas vulnerabilidades e código de prova de conceito. A N-able tira o N-central hospedado do ar e pede que clientes on-premises desliguem seus servidores.
10/11	Sai o Hotfix 2 (build 2026.4.1.26), corrigindo sete CVEs, duas delas com nota 9,3 no CVSS v4. O controle remoto nativo é desativado temporariamente.
12/11, 03h58 UTC	O mesmo pesquisador publica duas novas cadeias, 4EverAble2Shell (servidor) e Agent2Shell (agentes Windows), que funcionariam mesmo com o Hotfix 2.
12/11, 09h16 UTC	Primeira tentativa armada de ataque registrada pela Huntback.
12/11, 12h50 UTC	O pool de mineração do atacante mostra 21 servidores N-central ativos minerando Monero.
13/11	A N-able publica indicadores de comprometimento para servidores com Legacy API ligada.
14/11	O Hotfix 3 segue em validação, sem data confirmada.

Os servidores N-able N-central invadidos estavam nos Estados Unidos (9), na África do Sul (4), no Canadá (4) e no Reino Unido, Alemanha, França e Suécia (1 cada), segundo o relatório da Huntback. Nenhum no Brasil, até onde se sabe. Isso não significa que não haja servidor brasileiro vulnerável: significa só que o atacante, desta vez, quis minerar e não sequestrar.

Como funciona o 4EverAble2Shell, sem jargão

A cadeia tem quatro passos, e vale entender cada um porque eles mostram onde a defesa falhou.

1. Requisição sem login. O atacante manda uma mensagem SOAP malformada para o endereço /dms/services/ServerUI, que pertence à Legacy API. Ela explora uma falha do Apache Axis (CVE-2026-90436) e executa um comando como o usuário de serviço nable.
2. Escalada para root. Um script em Python abusa de um utilitário interno do próprio N-central e de um link simbólico para alterar um script que roda como root.
3. Download do payload. Já como root, o servidor baixa um script de um IP externo.
4. Persistência. Instala o minerador XMRig limitado a cerca de metade dos núcleos, cria um serviço xvd.service no systemd, entrada no cron e um vigia que relança o processo se alguém matar.

O detalhe que importa para quem contrata TI: o minerador foi a única carga vista até agora, mas quem tem root no servidor do RMM tem, em tese, a capacidade de mandar comandos para todas as máquinas gerenciadas. Minerar é o cenário barulhento e barato. O cenário caro é o mesmo acesso usado para distribuir ransomware para todos os clientes do MSP de uma vez.

A pegadinha da Legacy API do N-able N-central

A N-able afirma que, no N-able N-central atual, a Legacy API vem desligada por padrão e que o N-central hospedado não é afetado por essa cadeia de servidor. O pesquisador também diz que ela só funciona com a Legacy API ativa. Só que a Huntback não confirmou se as 21 vítimas tinham essa opção ligada. Na prática, é comum ela ter sido ativada anos atrás para uma integração antiga e nunca mais desligada. Configuração padrão não é configuração atual.

Por que “estar atualizado” não salvou 19 de 21 servidores

Este é o dado que mais me incomoda no caso, porque derruba a resposta padrão de qualquer fornecedor: “estamos com tudo atualizado”. Os 19 servidores no Hotfix 2 estavam atualizados. Fizeram o que o fabricante mandou, dois dias antes. Mesmo assim caíram em horas.

O motivo é simples. O patch fecha falhas conhecidas. Um zero-day é, por definição, uma falha para a qual ainda não existe correção. Entre a publicação do código de ataque e a chegada do conserto, a única defesa é reduzir a superfície: o que não está exposto não é explorado.

Eu vejo esse padrão há anos administrando servidores Linux de clientes, de AVAs Moodle a sistemas de gestão. Quando escrevi sobre gestão de patches depois do PHP2Shell, a lição foi a mesma: atualizar rápido é obrigatório, mas não basta. O que salvou os ambientes que eu cuidava foi o painel administrativo não estar aberto para a internet.

O histórico do N-able N-central também pesa. Antes deste episódio, a CISA (agência de cibersegurança dos EUA) já tinha incluído cinco falhas do N-central no seu catálogo de vulnerabilidades exploradas: duas em agosto de 2025 e três entre agosto e setembro de 2026. Não é um raio que caiu uma vez. É uma ferramenta que, como todo RMM popular, está permanentemente na mira.

O risco real do RMM para quem terceiriza TI

Se a sua empresa tem 20, 80 ou 300 computadores e um fornecedor externo cuida deles, quase certamente existe um agente de RMM instalado em cada máquina. Pode ser o N-able N-central, o N-sight, o NinjaOne, o Datto, o ConnectWise, o Kaseya ou outro. Todos funcionam do mesmo jeito: um agente com privilégio de administrador que obedece a um servidor central.

Isso cria três riscos que o dono da empresa raramente enxerga:

• Ponto único de falha compartilhado. Você não é atacado diretamente. O atacante invade o painel do MSP e chega a você junto com todos os outros clientes dele.
• Privilégio máximo por padrão. O agente roda como SYSTEM no Windows ou root no Linux. Qualquer comando que sair do console vale como se fosse do administrador local.
• Visibilidade zero do seu lado. Você não vê os logs do console, não sabe quem do fornecedor tem acesso, nem se o servidor dele está exposto.

No artigo sobre ransomware em pequenas empresas eu listei o acesso remoto como uma das primeiras portas a fechar. O RMM é o acesso remoto mais poderoso que existe na sua rede, e na maioria dos contratos que já li ele aparece em uma linha só, sem nenhuma exigência de segurança.

É esse tipo de ponto cego que a gente mapeia na consultoria de diagnóstico técnico da Agathas Web: não para trocar o seu fornecedor, mas para você saber exatamente qual é o tamanho do risco que está terceirizando.

O que perguntar ao seu MSP sobre o N-able N-central hoje

Não precisa ser técnico para fazer estas perguntas. Precisa só exigir resposta por escrito.

Sobre o incidente

1. Vocês usam o N-able N-central ou outro produto da N-able? Se sim, é hospedado pela N-able ou instalado no servidor de vocês (on-premises)?
2. Em que build está o servidor N-able N-central e quando foi atualizado? A resposta mínima aceitável hoje é 2026.4.1.26 (Hotfix 2) e um plano para o Hotfix 3.
3. A Legacy API está desligada? Quem conferiu e quando? Peça um print da tela de configuração.
4. Agentes e probes foram atualizados? A N-able orienta atualizar os agentes antes das probes, porque probe nova não conversa com agente antigo.
5. Vocês procuraram os indicadores de comprometimento desde 8/11? Os principais são requisições ao caminho /dms/services/ServerUI, o serviço xvd.service e a pasta /tmp/.xvd.

Sobre a operação do dia a dia

1. O console do RMM fica acessível pela internet aberta ou só por VPN, túnel ou lista de IPs?
2. Todo técnico entra com MFA resistente a phishing (chave de segurança ou passkey), e não só código por SMS?
3. Quantas pessoas do fornecedor têm acesso ao console com permissão sobre os meus computadores? Existe conta compartilhada?
4. Os logs do console são guardados por quanto tempo, e eu posso pedir o relatório de quem acessou minhas máquinas?
5. Se o servidor de vocês for comprometido, em quanto tempo eu fico sabendo?

Resposta vaga para a pergunta 10 é sinal de alerta. Pela Resolução CD/ANPD nº 15/2024, a sua empresa, como controladora dos dados, tem prazo de três dias úteis para comunicar à ANPD um incidente de segurança com risco relevante aos titulares. Se o fornecedor demorar uma semana para avisar, quem descumpre o prazo é você.

Como isolar o console de RMM: os controles que importam

Estes controles valem para o N-able N-central e para qualquer outro RMM. Estão em ordem de impacto por esforço.

Controle	O que bloqueia	Esforço	Custo típico
Console fora da internet aberta (VPN, túnel com autenticação ou allowlist de IP)	Exploração em massa sem login, como o 4EverAble2Shell	Médio	Baixo: VPN e túneis gratuitos ou já incluídos no firewall
Desligar API legada e integrações sem uso	Cadeias que dependem de endpoints antigos	Baixo	Zero
MFA com chave ou passkey para todo técnico	Roubo de senha e phishing	Baixo	Chaves físicas a partir de cerca de R$ 200 por pessoa
Contas nominais, sem login compartilhado	Falta de rastreabilidade	Baixo	Zero
Monitoramento de processos e conexões no servidor do RMM	Persistência e minerador silencioso	Médio	Varia com a ferramenta de EDR
Segmentação: o RMM não alcança servidores críticos sem aprovação	Movimento lateral em massa	Alto	Horas de projeto de rede

Allowlist de IP e túnel: como fazemos aqui

Nos servidores que administro, nenhum painel administrativo responde para a internet inteira. O acesso passa por um túnel autenticado ou por uma lista de IPs liberados, e o resto do mundo recebe conexão recusada. É a mesma lógica do checklist de hardening de servidor Linux: se o painel não aparece numa varredura, a varredura em massa que começou às 8h30 UTC do dia 12 nunca chega até ele.

A armadilha é a exceção temporária. Alguém libera o console para um técnico em viagem, ninguém remove a regra, e seis meses depois o painel está exposto de novo. Allowlist precisa de revisão mensal com nome e data em cada linha.

Monitoramento que pega minerador

Minerador é barulhento se alguém olhar: uso de CPU estável em 50% sem motivo, conexões de saída para portas de pool e um serviço novo no systemd. Um alerta simples de CPU e de serviço novo já teria denunciado as 21 vítimas no mesmo dia.

Quando NÃO vale a pena entrar em pânico (e quando vale)

Nem todo cliente de MSP precisa trocar de fornecedor amanhã. Pela informação pública até agora:

• Se o seu fornecedor usa o N-able N-central hospedado pela fabricante, a cadeia de servidor 4EverAble2Shell não afeta o servidor, segundo o fabricante. Ainda assim os agentes e probes nas suas máquinas precisam estar atualizados.
• Se o fornecedor usa outro RMM, este incidente específico não te atinge. Mas as perguntas da seção anterior continuam valendo, porque o próximo pode ser com a ferramenta dele.
• Se o fornecedor usa o N-able N-central on-premises com a Legacy API ligada e não sabe responder se olhou os indicadores, aí sim é caso de pedir uma investigação formal, trocar senhas de contas administrativas e verificar as máquinas.

O erro que vejo com mais frequência é a reação exagerada: desinstalar o agente de todas as máquinas no impulso. Sem agente, ninguém instala as atualizações de segurança do Windows nem do navegador na semana seguinte, e o risco sobe em vez de cair. Decisão de remover RMM se toma com inventário e plano, não no susto.

Contrato, LGPD e responsabilidade: o que exigir por escrito

O incidente do N-able N-central é um bom pretexto para revisar o contrato com o fornecedor de TI. A maioria que eu leio fala de prazo de atendimento e preço por máquina, e nada sobre segurança do próprio fornecedor.

Itens que recomendo incluir:

• Lista das ferramentas de acesso remoto usadas no seu ambiente, com o nome do produto e o modelo (hospedado ou próprio).
• Compromisso de MFA para todo acesso ao console e de contas nominais por técnico.
• Prazo de notificação de incidente curto, como 24 horas, compatível com os três dias úteis que você tem perante a ANPD.
• Prazo para aplicar correções críticas de ferramentas que tocam seu ambiente, com registro de quando foram aplicadas.
• Direito a relatório de acessos às suas máquinas, sob demanda.
• Desligamento limpo: ao fim do contrato, remoção comprovada dos agentes e das credenciais.

Nada disso é exótico. São as mesmas exigências que fazemos para quem toca a API oficial do WhatsApp de um cliente: token de usuário de sistema com permissão mínima, acesso nominal, registro de quem mexeu. Quando a ferramenta tem poder sobre o negócio inteiro, o contrato precisa refletir isso. Eu tratei raciocínio parecido para outro tipo de acesso privilegiado no post sobre segurança de agentes de IA: quanto mais autonomia a ferramenta tem, mais estreito precisa ser o que ela alcança.

Como a Agathas Web resolve isso

A Agathas Web não revende RMM nem é MSP de suporte a estações. Por isso conseguimos olhar para o seu fornecedor sem conflito de interesse. O que fazemos é diagnóstico técnico independente, conduzido por mim, com mais de 15 anos operando servidores Linux, hospedagem gerenciada, Moodle e integrações em produção.

Na consultoria da Agathas Web, um diagnóstico focado em acesso remoto e terceirização de TI inclui:

• Inventário de acessos privilegiados: quais agentes de RMM, ferramentas de acesso remoto e contas de fornecedor existem nas suas máquinas e servidores.
• Revisão das respostas do seu MSP às perguntas deste post, com parecer sobre o que é aceitável e o que não é.
• Checagem de exposição: se painéis, portas de gestão e serviços seus aparecem na internet aberta.
• Revisão de contrato e LGPD: cláusulas de notificação, prazos de correção e responsabilidade em incidente.
• Relatório com prioridades: o que corrigir esta semana, este mês e no próximo trimestre, com estimativa de esforço.

Como funciona: uma conversa inicial gratuita para entender o ambiente, acesso de leitura combinado com você e com o fornecedor atual, análise e reunião de entrega do relatório. Você decide o que fazer com ele, inclusive executar tudo com o time ou o MSP que já tem. Para contratar, é só agendar o diagnóstico pela página de consultoria.

Conclusão: a ferramenta do seu fornecedor também é sua superfície de ataque

O caso do N-able N-central mostra três coisas ao mesmo tempo. Código de ataque público vira exploração em horas, não em semanas. Patch em dia não protege contra o que ainda não foi corrigido. E a ferramenta que o fornecedor de TI usa para cuidar da sua empresa é, também, a forma mais rápida de alguém chegar nela.

O próximo passo é prático: mande as dez perguntas deste post para o seu MSP hoje e peça as respostas por escrito até sexta. Se as respostas vierem vagas, ou se você não souber avaliar o que voltou, fale com a gente na consultoria e a gente analisa com você.

Fontes principais: FAQ da Tenable sobre Able2Shell, reportagem do BleepingComputer de 12/11/2026 e relatório técnico da Huntback. Como a situação está mudando dia a dia, confira a página de status da N-able antes de agir.