Skip to content
Voltar ao BlogGuide

Ataques de força bruta em RDP — por que RDP-na-Internet é perigoso

Tenvo Editorial Team9 min de leitura
Ataques de força bruta em RDP — por que RDP-na-Internet é perigoso

Se você já abriu a porta 3389 no seu roteador porque "era mais fácil" — ou porque alguém pediu para habilitar Remote Desktop rapidamente — provavelmente sentiu a preocupação ao ver dezenas de falhas de login aparecerem do nada…

Se você já abriu a porta 3389 no seu roteador porque 'era mais fácil' — ou porque alguém pediu para habilitar Remote Desktop rapidamente — provavelmente já sentiu a preocupação quando esse servidor ou desktop começa a registrar dezenas de tentativas de login falhas do nada. A consequência é real: credenciais comprometidas, ransomware e longos ciclos de resposta a incidentes. Este guia explica por que um RDP exposto publicamente atrai ataques de força bruta e, mais importante, quais alternativas e mitigação práticas você deve usar em vez disso.

Por que expor RDP à Internet é uma ação de alto risco

Remote Desktop Protocol (RDP) é conveniente: a Microsoft o inclui no Windows, o cliente está integrado em outros sistemas e muitos administradores dependem dele para troubleshooting ad-hoc. Essa mesma ubiquidade o torna um alvo atraente. O protocolo normalmente escuta na porta TCP 3389 por padrão, o que facilita para atacantes encontrá-lo por meio de ferramentas de varredura em massa como Masscan ou ZMap. Uma vez descoberto, bots automatizados tentam listas de nomes de usuário e senhas até terem sucesso.

Existem dois problemas relacionados quando o RDP é diretamente acessível pela Internet:

  • Ataques por credenciais — força bruta e credential stuffing: atacantes usam senhas comuns, listas de credenciais vazadas e wordlists contra milhares de IPs em paralelo.
  • Risco de exploits/zero-day: hosts Windows mal configurados ou sem patch podem apresentar vulnerabilidades relacionadas ao RDP (por exemplo, CVE-2019-0708 "BlueKeep" afetou implementações antigas do RDP no Windows). Se o RDP estiver exposto, comprometimentos via exploit são possíveis além do abuso de credenciais.

Falando claramente: um servidor RDP na internet pública é um farol. Scripts e botnets o tratam como fruta ao alcance, e muitos comprometimentos começam com os mesmos passos laterais — login bem-sucedido, escalonamento e então ransomware ou roubo de dados.

Como atacantes executam ataques de força bruta contra RDP (visão geral)

Atacantes tipicamente combinam três estágios:

  1. Descoberta — varredura de faixas de IP em busca de serviços RDP respondendo na porta 3389 (ferramentas de scan são rápidas e commodity).
  2. Tentativas de autenticação — clientes automatizados tentam nomes de usuário e senhas. Usam dicionários, listas de credenciais vazadas e estratégias de credential stuffing. Ferramentas como Hydra, Ncrack ou frameworks personalizados de força bruta para RDP são frequentemente usadas; os atacantes distribuem a carga por proxies e VPNs para evitar bloqueios baseados em IP.
  3. Ação pós-autenticação — uma vez estabelecida a sessão, atacantes exploram manualmente a máquina ou executam scripts automatizados para instalar ransomware, criar persistência ou coletar credenciais para pivotar para outros sistemas.

Network Level Authentication (NLA) eleva a dificuldade porque exige credenciais antes que uma sessão RDP completa seja estabelecida, mas não é uma bala de prata: NLA ainda depende de credenciais de conta e pode ser contornada se uma conta for fraca, reutilizada ou já comprometida em outro lugar.

Sinais de que você está sendo alvo — o que observar agora

Detecção precoce importa. Aqui estão sinais concretos de que um ataque de força bruta contra RDP pode estar acontecendo com você:

  • Muitas entradas de falha de login em um curto período. No Windows, procure pelo Security Event ID 4625 (failed logon) e por entradas repetidas 4624 (successful logon) vindas de IPs de origem inesperados.
  • Bloqueios de conta incomuns ou timestamps estranhos para logins (logins fora do horário comercial vindos de faixas de IP estrangeiras).
  • Logs do firewall mostrando muitas tentativas de conexão TCP para a porta 3389 vindas de IPs distintos.
  • Novas contas administrativas locais, serviços inesperados instalados ou processos desconhecidos após um login bem-sucedido.

Verificações rápidas que você pode executar agora (PowerShell):

Test-NetConnection -ComputerName YOUR_HOSTNAME_OR_IP -Port 3389

E verifique logons falhos recentes com o Visualizador de Eventos, ou exporte eventos usando PowerShell/Get-WinEvent se estiver automatizando a detecção. Se você vir picos, presuma que atacantes estão caçando e aja imediatamente.

Medidas imediatas de contenção se você identificar atividade de força bruta

Se você descobrir tentativas ativas de força bruta ou suspeitar de um comprometimento, priorize contenção em vez de conveniência:

  1. Bloqueie o tráfego na firewall perimetral. Interrompa conexões de entrada para TCP/3389 na borda o quanto antes.
  2. Desabilite o RDP nas máquinas afetadas enquanto faz a triagem: System > Remote Settings > desmarque "Permitir conexões remotas" (Windows) — ou pare o serviço Remote Desktop Services para contenção de emergência de curto prazo.
  3. Redefina as credenciais das contas impactadas e de quaisquer contas que compartilhem senhas. Prefira passphrases longas e senhas únicas por conta.
  4. Habilite uma política de bloqueio de conta: por exemplo, bloqueie a conta após 5 tentativas falhas por 15 minutos. Isso é uma medida razoável de defesa em profundidade que desacelera ataques automatizados sem gerar muitas chamadas ao suporte.
  5. Verifique a máquina em busca de persistência: tarefas agendadas, novos autoruns, serviços suspeitos e indicadores conhecidos de ransomware. Se encontrar sinais de comprometimento, isole o host e siga seu playbook de resposta a incidentes.

Estas são ações de triagem — não corrigem causas raiz. Após a contenção, avance para remediação: aplicar patches, rotacionar credenciais e monitoramento pós-incidente.

Alternativas mais seguras a expor RDP diretamente (opções reais, prós e contras)

Se seu objetivo é administração remota segura ou trabalho remoto, há abordagens melhores do que abrir a porta 3389. Escolha aquela que corresponda à sua escala e modelo de ameaça.

1) VPN (site-to-site ou baseada em cliente) — mais simples para equipes pequenas/médias

Prós: o RDP fica acessível apenas por um túnel criptografado. Você pode limitar acesso via ACLs da VPN e centralizar autenticação. WireGuard e OpenVPN são escolhas comuns; OpenVPN é maduro, WireGuard é mais simples e rápido.

Contras: VPNs adicionam overhead de gerenciamento e exigem configuração segura do cliente e manejo de certificados/chaves. Se as credenciais da VPN forem fracas, você ainda terá uma superfície de ataque — combine VPN com MFA e monitoramento.

2) RDP Gateway / RD Web Access

Use o RD Gateway da Microsoft para encaminhar sessões RDP sobre TLS (tipicamente porta 443) e centralizar autenticação. O RD Gateway oferece melhor controle de políticas e se integra ao Azure AD em ambientes híbridos para MFA.

Prós: projetado para RDP, boa integração com autenticação do Windows e controle condicional de acesso.

Contras: adiciona infraestrutura para gerenciar e aplicar patches; má configuração ainda pode te expor. Para muitas equipes, uma VPN continua sendo mais simples.

3) Jump host ou bastion host (acesso gerenciado)

Implemente um bastion/jump host endurecido ao qual os administradores se conectem primeiro e, então, acessem as máquinas internas. Aplique MFA estrito e gravação de sessão no bastion; apenas o bastion precisa de IP público.

Prós: centraliza acesso e auditoria. Mais fácil monitorar e restringir do que vários endpoints expostos. Provedores cloud oferecem serviços gerenciados de bastion (Azure Bastion, AWS Systems Manager Session Manager) que eliminam portas de entrada inteiramente.

4) Software de acesso remoto (relay/self-hosted) — TeamViewer/AnyDesk/RustDesk/Tenvo

Ferramentas comerciais de acesso remoto usam NAT traversal e servidores de relay, então você não precisa abrir a porta 3389 no firewall. Elas costumam ser a forma mais rápida para usuários não técnicos obterem suporte remoto seguro. Dito isso, representam um modelo de confiança diferente: você confia no fornecedor ou na infraestrutura de relay.

Comparação honesta: TeamViewer e AnyDesk são muito polidos para suporte ao usuário final e gestão de sessão. São proprietários e gerenciados na nuvem, o que é aceitável para muitos casos de uso. Se você precisa evitar relays de terceiros ou quer controle total, opções self-hosted como RustDesk ou Tenvo são escolhas fortes — permitem evitar port forwarding mantendo a infraestrutura sob seu controle. Veja a página de download do Tenvo em /download para uma opção self-hosted e /pricing se precisar de relays hospedados ou suporte comercial.

Se quiser explorar abordagens que evitam port forwarding em detalhe, nosso guia sobre configurar acesso remoto sem port forwarding é útil: /remote-desktop-without-port-forwarding. Para recomendações mais amplas sobre segurança de desktop remoto, veja /remote-desktop-security.

Checklist prático de hardening — o que fazer a seguir (passo a passo)

Aqui está um checklist prático e priorizado que você pode aplicar a desktops e servidores. Mistura mudanças imediatas com melhorias de médio prazo.

  1. Feche a exposição: bloqueie TCP/3389 na firewall perimetral ou use listas de permissão de IP para que apenas faixas de IP confiáveis possam conectar.
  2. Se o RDP precisar permanecer acessível, habilite Network Level Authentication (NLA) e SSL/TLS para o gateway quando possível.
  3. Imponha políticas de senha fortes e use thresholds de bloqueio de conta (sugestão: bloqueio após 5 falhas, duração de 15 minutos — ajuste conforme seu ambiente).
  4. Habilite MFA para acesso remoto. Para máquinas ingressadas em domínio, integre Azure AD conditional access, ou use MFA de terceiros (Duo, Okta) na frente do seu gateway.
  5. Aplique patches prontamente. Mantenha o Windows atualizado — CVEs relacionados ao RDP antigos foram críticos e amplamente explorados.
  6. Use logging centralizado e alertas. Monitore Security Event IDs 4624/4625 e seus logs de firewall; crie um alerta para altas taxas de logon falho ou novos IPs acessando RDP.
  7. Use um jump host/bastion para trabalho administrativo e restrinja quem pode RDP diretamente para sistemas de produção.
  8. Prefira ferramentas de acesso remoto que evitam port-forwarding quando não for possível rodar uma VPN. Se você self-host, mantenha o relay ou servidor com patches e protegido por autenticação forte.
  9. Considere ferramentas automáticas de bloqueio e prevenção de intrusão para Windows como RdpGuard ou soluções nativas do seu stack de proteção de endpoint.
  10. Gerencie senhas de administradores locais com Microsoft LAPS ou uma solução de privileged access management (PAM) para evitar credenciais locais compartilhadas.

Qual opção você deve escolher — orientação rápida

Escolha com base no tamanho do ambiente, postura de segurança e capacidade administrativa:

  • Equipes pequenas / único administrador: use um app de acesso remoto confiável (relay ou self-hosted) ou uma VPN cliente. Ferramentas baseadas em relay são mais fáceis para usuários não técnicos; se quiser controle, use uma opção self-hosted como Tenvo e implante seu próprio relay.
  • Organizações médias: VPN site-to-site ou VPN cliente + MFA, combinado com um bastion para tarefas administrativas.
  • Grandes empresas: RD Gateway ou soluções de bastion gerenciadas na nuvem combinadas com conditional access e PAM para contas privilegiadas.

Uma observação honesta: se você precisa da experiência mais simples possível para familiares não técnicos, ferramentas comerciais como TeamViewer ou AnyDesk podem ser menos trabalhosas do que configurar VPNs. Elas têm trade-offs — conveniência vs. controle — e se isso é aceitável depende do seu modelo de ameaça e requisitos de conformidade.

Resumo e próximos passos imediatos

Ataques de força bruta a RDP são previsíveis e evitáveis. A melhor regra única: não exponha RDP diretamente à internet, a menos que tenha uma razão excelente e controles compensatórios (MFA, IPs de origem limitados, RD Gateway ou VPN, monitoramento estrito). Se um servidor RDP já está acessível pela internet, bloqueie-o agora e siga o checklist de hardening acima.

Se você quer uma maneira prática de evitar port-forwarding mantendo controle da sua infraestrutura, considere uma solução de acesso remoto self-hosted. Tenvo fornece um conector self-hosted e opções de relay — confira /download para testar e /pricing para planos de relay hospedados caso precise. E se estiver montando um plano de acesso remoto seguro, nossos guias relacionados podem ajudar: /remote-desktop-without-port-forwarding e /remote-desktop-security.

Não espere até ver aqueles picos 4625. Feche o buraco, escolha uma alternativa que caiba na sua escala (VPN, RD Gateway, bastion ou um app de acesso remoto controlado) e adicione MFA e monitoramento. Se quiser ajuda para selecionar e configurar a opção certa para seu ambiente, baixe o Tenvo em /download para experimentar uma abordagem self-hosted que evita expor RDP diretamente.

Baixe o Tenvo

Pronto para testar por conta própria?

Gratuito para 30 dispositivos, sem cartão de crédito. Configurado e conectado em dois minutos.