Lock Down Your Management Ports Before Ransomware Does

RDP is ransomware's favourite door

Shodan shows close to five million devices with RDP exposed on port 3389 and millions more running SSH. Botnets cycle through credentials against these services around the clock. If you have a management port open to a broad network range, your logs already contain brute-force attempts.

Sophos's Active Adversary Report found RDP abuse in 90% of incident response cases in 2023, with external remote services (primarily RDP) as the initial access vector in 65% of cases. Not phishing (3.3%). Not zero-day exploits. Attackers find exposed or broadly accessible RDP, brute-force or buy stolen credentials, log in, and deploy ransomware. The entire kill chain starts with a firewall rule someone approved and forgot about. Note: by 2024, VPN exploitation surged as an initial access method, but RDP remains the dominant vector.

Each protocol has its own failure mode

RDP (TCP 3389) has a history of pre-auth remote code execution bugs (BlueKeep, CVE-2019-0708 being the most famous). Even fully patched, it's vulnerable to credential brute-forcing, pass-the-hash, and session hijacking. Without Network Level Authentication, the server presents a login screen to any connecting host, giving attackers an unlimited target for credential stuffing.

VNC (TCP 5900+) is worse. Many implementations ship with no authentication by default. Others use a single shared password with no username, no lockout, no MFA support. Traffic is unencrypted unless you tunnel it yourself. An attacker on the network path sees the full session: every screen, every keystroke.

WinRM (TCP 5985/5986) enables PowerShell remoting. Port 5985 is HTTP (cleartext). Port 5986 is HTTPS. WinRM over 5985 sends PowerShell commands and output across the wire unencrypted. If an attacker has any foothold on that segment, they capture admin commands and credentials without breaking anything.

SSH (TCP 22) is the most secure by default: encrypted, supports key-based auth, mature track record. The risk is tunnelling. A compromised SSH session becomes a gateway to reach databases, internal web applications, and anything else the firewall was supposed to protect.

Direct access vs. jump host architecture

The gap between a risky setup and a defensible one is architectural.

Direct access: the firewall allows a broad source range to reach the server. Every host in that range is a potential attack origin. One compromised machine gives the attacker a direct line to the management interface.

Jump host: the management port only accepts connections from a single, hardened bastion. Users authenticate through a VPN with MFA before reaching the jump host. The jump host logs every session. The firewall rule on the database server allows RDP from one IP. The attack surface drops from hundreds of potential sources to one purpose-built, monitored host.

Just-in-time access: stop leaving ports open 8,760 hours a year

Permanent firewall rules for management ports are the core problem. Even a well-scoped rule to a jump host means that port is reachable 24/7/365. JIT access fixes this.

How it works: An administrator requests access to a specific server. The system verifies their identity, checks approval (automated or manager-approved depending on sensitivity), opens the firewall rule for a defined window (2-4 hours is typical), and closes it automatically when the window expires.

What this buys you: If your management port is reachable for 4 hours instead of 8,760, that's a 99.95% reduction in exposure time. An attacker scanning your perimeter at 2 AM on a Saturday hits a closed port.

How to implement it:

• Azure: Azure AD Privileged Identity Management (PIM) paired with Azure Bastion and NSG rules. PIM handles the approval workflow; you script NSG rule creation/deletion on activation/deactivation.
• AWS: AWS Systems Manager Session Manager eliminates the need for open inbound ports entirely. Sessions route through the SSM agent. No security group rule needed for SSH or RDP at all.
• On-prem: CyberArk, BeyondTrust, or Hashicorp Boundary can manage JIT access workflows. If budget is tight, a scripted solution that opens a firewall rule via API on an approved ticket and closes it on a cron job gets you 80% of the value.

JIT pairs well with session recording. If you're opening a management port for a 4-hour window to a production database, record the session. You want a forensic trail that answers "what happened on that server Tuesday at 3 PM" with evidence, not guesswork.

The compliance angle (briefly)

PCI DSS, CIS Controls, and NIST all agree: management ports need restricted access, MFA, and encrypted tunnels. If you're exposing RDP from the internet or allowing management protocols from general-purpose user subnets, you're failing compliance before an auditor even shows up.

netbobr flags these patterns against specific compliance rules: PCI-NET-051 catches internet-facing RDP, PCI-NET-061 targets VNC exposure, and CIS-NET-040 flags admin protocols reachable from non-admin segments. But compliance is the floor, not the ceiling. The practical motivation is simpler: these rules get people ransomwared.

Building the architecture that holds up

Jump hosts and bastion hosts. Route every management connection through a dedicated bastion in its own network segment. Run minimal services on it. Log everything. When you need to audit who accessed what server and when, you look in one place.

VPN-gated access. Management ports should not be reachable without a VPN connection, including from internal networks. If your office Wi-Fi subnet can reach RDP on your domain controllers, you're one compromised laptop away from a domain takeover.

MFA everywhere. Require it at the VPN layer and again at the jump host. Stolen credentials are cheap. MFA is the single most effective control against credential-based attacks on management ports. For RDP, enforce Network Level Authentication so the user authenticates before the server creates a session.

Session recording on high-value targets. For production database servers, domain controllers, and anything in a regulated environment, capture the full management session.

Your 30-day plan

Week 1: Find the rules. Export your firewall ruleset. Search for ports 22, 3389, 5900, 5985, 5986. For each rule, document the source range, whether it's still needed, and who requested it. You will find rules nobody can explain, pointing at sources that no longer exist.

Week 2: Sort them. Three buckets: rules that can be deleted now (dead source or destination), rules that can be tightened to a specific jump host or management subnet, and rules that need architectural changes (bastion host deployment, JIT integration) before you can fix them.

Week 3: Kill the easy ones. Delete the dead rules. Tighten source ranges where the jump host exists but the rule was never updated. These changes affect zero legitimate users and shrink your attack surface immediately. Run your ruleset through netbobr to catch anything you missed.

Week 4: Plan the hard ones. Build a project plan for the rules that need bastion hosts, VPN changes, or JIT access mechanisms. These are not afternoon tasks. They are the changes that produce lasting improvement.

The cost of inaction

An overly broad rule allowing HTTP to a web server is a risk, but the web server was designed to handle untrusted connections. An overly broad rule allowing RDP to a database server gives an attacker a full interactive desktop session with whatever privileges the compromised account holds.

Every ransomware report tells the same story. Management ports are the front door. If your firewall rules leave it open wider than necessary, someone will try the handle. Reviewing those rules with netbobr takes less time than recovering from what follows.