Falha no MikroTik RouterOS está sendo explorada agora: sem senha, atacante ganha shell no roteador e toma a rede

Introdução

A MikroTik (fabricante de equipamentos de rede) confirmou no dia 03/09/2026 a existência de uma vulnerabilidade crítica no RouterOS (sistema operacional dos roteadores MikroTik) — e a exploração ativa já começou. O fabricante liberou correções em todas as linhas de versão — 7.25 beta 3, 7.24.2 stable, 7.23.4 long-term e 6.49.21 long-term — mas omitiu deliberadamente os detalhes técnicos do advisory inicial, com o objetivo declarado de dar tempo aos administradores para atualizar antes que a falha fosse engenharia reversa a partir da divulgação pública. A estratégia não segurou a onda: usuários e pesquisadores reconstruíram a mecânica do ataque por conta própria em fóruns, e o relato de exploração em campo não demorou a aparecer.

O que se sabe até agora é grave: um atacante remoto, sem autenticação alguma — nem senha, nem chave SSH — consegue um shell direto no dispositivo e, a partir dele, acesso à rede inteira. O CERT Letônia (equipe de resposta a incidentes da Letônia) emitiu alerta público corroborando o aumento acentuado de atividade contra roteadores MikroTik.

Contexto: por que isso importa no Brasil

O impacto no Brasil é potencialmente enorme. MikroTik domina o mercado de roteadores de provedores regionais de internet e de pequenas e médias empresas: são equipamentos baratos, flexíveis e onipresentes — inclusive em milhares de residências. Um roteador comprometido não é apenas um aparelho invadido: é o ponto de passagem de todo o tráfego da rede. Com shell no RouterOS, o atacante pode redirecionar DNS, interceptar tráfego, alterar regras de firewall, instalar backdoors persistentes e usar o equipamento como pivô para atacar outros dispositivos da LAN — sem falar no risco de o próprio ISP ser usado como infraestrutura de ataques maiores.

A própria MikroTik afirma que "a maioria das configurações não está em risco" e que, para usuários domésticos comuns, não há risco imediato — mas o CERT Letônia pede que organizações e usuários domésticos atualizem imediatamente. A diferença de tom reflete o que os pesquisadores já constataram: o risco é real quando o SSH está acessível pela internet ou por uma rede não confiável, cenário comum em ISPs e empresas.

O que se sabe sobre a falha

A MikroTik não divulgou CVE nem detalhes técnicos — e esta é a nota honesta que precisa ficar registrada: a vulnerabilidade ainda não tem CVE publicado e a mecânica do ataque foi reconstruída pela comunidade, a partir de análise do advisory, de discussões no fórum oficial e de relatos de comprometimento real. O que se sabe com razoável segurança:

• O bug vive numa biblioteca núcleo compartilhada por vários serviços do RouterOS — o que significa que qualquer serviço construído sobre essa base pode servir de porta de entrada, não apenas o SSH;
• A reconstrução da comunidade aponta que a falha está ligada ao SSH e concede a qualquer atacante remoto não autenticado acesso direto a um shell no dispositivo, funcione ele com autenticação por senha ou por chave SSH (método de login por par de chaves criptográficas);
• Não há roubo de credencial nem interação do usuário envolvidos: se o SSH está exposto, o roteador é vulnerável até receber o patch.

Por se tratar de reconstrução comunitária e não de divulgação oficial, o detalhamento abaixo deve ser lido com essa ressalva em mente — mas as evidências de exploração em campo já são consistentes com esse modelo.

Cadeia de ataque: do SSH exposto à rede comprometida

O comprometimento observado segue um fluxo em cinco etapas, começando pela exposição do serviço SSH na internet até o controle da rede local. Abaixo apresentamos o diagrama da cadeia de ataque e detalhamos cada etapa em seguida.

SSH exposto na internet

O primeiro passo é a exposição: roteadores com o serviço SSH (porta 22) acessível pela internet ou por redes não confiáveis. Em ISPs e empresas é comum encontrar equipamentos com gerência remota aberta — muitas vezes configurada para facilitar o suporte técnico e nunca revogada. Ferramentas de varredura como o Shodan (motor de busca de dispositivos expostos na internet) tornam trivial localizar essa superfície em escala global.

Exploração sem autenticação

Em seguida vem a exploração da falha na biblioteca núcleo: segundo a reconstrução da comunidade, o atacante envia uma sequência específica ao serviço SSH e obtém execução sem apresentar nenhuma credencial — nem senha, nem chave. Não há brute force nem roubo de credenciais: a falha é na camada de autenticação do próprio serviço. É essa característica que torna o cenário tão perigoso — qualquer equipamento com SSH exposto é alvo viável, inclusive roteadores com senhas fortes.

Shell direto e conta rogue

Com o shell no RouterOS, o atacante tem controle total do sistema operacional do roteador. O padrão observado em campo é a criação de uma conta administrativa reserva (conta rogue) para manter acesso persistente e limpo, sem scripts visíveis na configuração. No relato que circulou na comunidade, a conta criada recebeu permissões de escrita (write) e de política (policy) — as mais altas do sistema.

Acesso à rede

Por fim, com a conta rogue e o shell persistente, o roteador vira uma porta aberta para a rede: o atacante pode redirecionar DNS, interceptar tráfego, alterar regras de firewall e usar o equipamento como pivô para alcançar outros dispositivos da LAN e, no caso de ISPs, a infraestrutura do provedor.

Evidências de exploração ativa

O caso mais citado até agora veio do Reddit, relatado por um administrador que identificou o comprometimento em 02/09/2026, por volta das 08:00 UTC: uma conta não autorizada chamada "ops" foi criada por outra conta rogue de nome "0", com permissões de escrita e política, e o acesso foi rastreado até uma conexão SSH vinda do IP 82.192.72.4. O administrador notou que a conta parecia servir apenas para login e que nenhum script malicioso estava visível na configuração — mas a suspeita de comprometimento mais profundo, invisível para o próprio RouterOS, levou a equipe a recorrer ao netinstall (ferramenta oficial de instalação e reinstalação completa de dispositivos MikroTik) para garantir que os equipamentos estivessem limpos.

O caso ilustra o problema central: um roteador comprometido pode não apresentar nenhum sinal óbvio na configuração, e o atacante pode permanecer silencioso usando a conta reserva para acessos futuros.

A detecção pós-upgrade: o status "Flagged"

A MikroTik adicionou ao RouterOS um mecanismo de detecção justamente para esse cenário. Após a atualização, o sistema operacional inspeciona toda a configuração na inicialização e, se encontrar sinais de adulteração não autorizada, marca o dispositivo com o status "Flagged" e registra uma entrada crítica no log do sistema.

Dispositivos nesse estado sofrem restrições operacionais: fica bloqueada a criação de novas entradas no scheduler (agendador de tarefas do RouterOS) e a configuração de SOCKS proxy, PPTP, L2TP, IPsec, proxy e SMB — protocolos e serviços comumente abusados por atacantes — até que um administrador faça uma auditoria manual. A orientação oficial é direta: se o dispositivo aparecer como "Flagged", assuma que foi comprometido, audite cada linha da configuração, roteie todas as senhas e só então limpe o status.

A ressalva vale para todos, inclusive para quem não viu o "Flagged": a MikroTik e os pesquisadores recomendam revisar manualmente a configuração — usuários, scripts e tarefas agendadas desconhecidos — após a atualização, porque alguns vestígios de comprometimento podem não disparar a detecção automática.

Como se proteger

Atualize imediatamente para uma versão corrigida. Este é o passo inadiável: 7.25 beta 3, 7.24.2 stable, 7.23.4 long-term ou 6.49.21 long-term — na tela "Check for updates" do próprio RouterOS, ou via CLI:

# Verifica se há atualização disponível
/system package update check-for-updates
# Instala a versão corrigida
/system package update install

Tire a gerência da internet. Nunca exponha SSH nem WinBox (aplicativo de gerência dos roteadores MikroTik) diretamente na internet. Acesse a gerência apenas por uma rede de administração confiável ou via VPN, restrinja os endereços IP de origem permitidos e prefira autenticação por chave SSH — embora, nesta falha, nem isso proteja: a única defesa real contra a exploração é o patch.

Audite a configuração linha a linha. Após atualizar, revise usuários, scripts, tarefas agendadas e regras de firewall procurando qualquer coisa que você não reconheça. Cheque o log por entradas críticas de "Flagged" e liste os usuários do sistema:

# Lista todos os usuários do RouterOS
/user print

Varra e monitore a frota. Use o nmap para mapear quais equipamentos da sua rede têm SSH aberto e o Shodan para descobrir dispositivos MikroTik expostos antes que os atacantes o façam. Para monitoramento contínuo, um SIEM como o Wazuh ajuda a correlacionar eventos de autenticação, novas contas e mudanças de configuração nos equipamentos.

Em caso de comprometimento, reinstale. Se houver qualquer sinal de conta desconhecida, status "Flagged" ou configuração adulterada, assuma o pior: reinstale o dispositivo via netinstall para eliminar qualquer persistência invisível, troque todas as senhas e chaves (do roteador e dos sistemas que ele protege) e só então recoloque o equipamento em produção.

Conclusão

A falha do RouterOS combina os três ingredientes de uma crise de segurança: uma vulnerabilidade crítica explorável sem autenticação, uma base de dispositivos gigantesca — com presença massiva em ISPs e residências brasileiras — e exploração ativa confirmada em campo antes mesmo da divulgação oficial dos detalhes. O fabricante agiu rápido ao liberar correções em todas as linhas de versão, e o mecanismo de detecção "Flagged" é um diferencial útil — mas a lição permanece: roteador é infraestrutura crítica, e gerência exposta na internet é uma porta que mais cedo ou mais tarde será testada. Atualizar, auditar e tirar a gerência da internet são as três ações que separam um incidente contido de uma rede tomada.

Perguntas frequentes

Fontes e leituras adicionais

• Cyber Security News — Hackers Exploiting MikroTik RouterOS Vulnerability in the Wild to Gain Complete Network Access — 06/09/2026
• MikroTik — September 2026 vulnerability — 03/09/2026
• CERT.LV — Uzbrucēji pastiprināti cenšas kompromitēt MikroTik maršrutētājus — 04/09/2026
• Reddit r/mikrotik — Relato de conta rogue "ops" criada via SSH em RouterOS — 02/09/2026