Remote Desktop Protocol (RDP) is a Microsoft technology that allows administrators and users to connect remotely to Windows systems through a graphical desktop interface. It is widely used for server administration, troubleshooting, application management, and day-to-day infrastructure operations.

By default, Windows Remote Desktop Services listens on TCP port 3389. Modern Windows versions can also use UDP to improve RDP performance. Because TCP 3389 is universally associated with RDP, Internet-facing systems listening on this port are frequently discovered by automated scanners, bots, and malicious actors.

One common hardening step is therefore to change the default RDP port to a non-standard port.

In this guide, we will change:

Default RDP Port : 3389
New RDP Port     : 8155

We will also configure Windows Defender Firewall, verify that the new port is listening correctly, test connectivity, and review additional security measures that should be implemented alongside the port change.

Important: Changing the RDP port from 3389 to 8155 does not make RDP secure by itself. It can reduce noise from automated scanners that target the default port, but a complete port scan can still discover RDP on port 8155. RDP should ideally be protected with VPN access, firewall restrictions, Network Level Authentication, MFA, patch management, and proper access controls.

1. Why Does RDP Use Port 3389?

When Remote Desktop is enabled on a Windows system, Remote Desktop Services listens on port:

TCP 3389

Therefore, when a user opens Remote Desktop Connection and enters only the server IP address:

10.10.10.50

the RDP client automatically attempts to connect to TCP 3389.

After changing the RDP port to 8155, the port must be explicitly included in the connection address:

10.10.10.50:8155

If DNS is used, the same format applies:

server01.contoso.local:8155

2. Why Is an Internet-Exposed RDP Service Risky?

Using port 3389 is not a vulnerability by itself. The main risk appears when RDP is directly exposed to the Internet without proper restrictions.

Internet-connected systems are constantly scanned by automated tools and malicious infrastructure looking for open services.

Common tools and platforms that can identify exposed RDP services include:

• Nmap
• Masscan
• Internet-wide scanners
• Automated botnets
• Search engines for exposed services
• Password-attack frameworks

Once an accessible RDP service is discovered, attackers may attempt several techniques.

Brute-Force Attacks

An attacker can repeatedly test username and password combinations against an exposed RDP service.

Accounts such as:

administrator
admin
support
user
test

may attract additional attention because they are commonly used account names.

Password Spraying

Instead of testing many passwords against a single account, password spraying attempts a small number of common passwords across many accounts.

This approach may help attackers avoid aggressive account lockout policies.

Exploitation of Unpatched Systems

Historically, vulnerabilities have also affected Remote Desktop Services.

A well-known example is:

CVE-2019-0708 – BlueKeep

This is why changing the RDP port must never be considered a substitute for patch management.

3. What Does Changing RDP from 3389 to 8155 Actually Achieve?

Changing:

3389 → 8155

can reduce the number of automated connection attempts from scanners that only probe the default RDP port.

For example, a bot that checks only:

TCP 3389

may no longer detect the service.

However, an attacker performing a full TCP scan across:

1-65535

can still identify that port 8155 is open and determine that RDP is running on it.

Therefore, changing the RDP port should be considered an additional hardening measure rather than a primary security control.

Its practical benefits may include:

• Reducing automated attacks against TCP 3389
• Reducing unnecessary failed logon events
• Reducing log noise
• Preventing simplistic bots from immediately discovering RDP
• Making basic Internet-wide scanning slightly less effective

It does not replace a firewall, VPN, MFA, patching, or access-control policy.

4. Before Changing the RDP Port

Changing the RDP listener directly affects remote connectivity.

If you are performing the change through an active RDP session, an incorrect Registry or firewall configuration may prevent you from reconnecting to the server.

Before starting, make sure you have an alternative management method whenever possible.

For physical servers, this could include:

iLO
iDRAC
IPMI
KVM

For virtual machines:

VMware Console
vCenter Console
Hyper-V Console
Cloud Console

You should also verify that port 8155 is not already being used by another application.

For production servers, the change should preferably be performed during an approved maintenance window.

5. Check Whether Port 8155 Is Already in Use

Before assigning port 8155 to Remote Desktop Services, verify that another service is not already listening on it.

Using PowerShell:

Get-NetTCPConnection -LocalPort 8155 -ErrorAction SilentlyContinue

Alternatively, use Command Prompt:

netstat -ano | findstr :8155

If no output is returned, there is probably no active TCP listener on port 8155 at that moment.

For production systems, you should also confirm that the port has not been reserved or assigned to another application that may start later.

6. Where Is the RDP Port Stored in the Windows Registry?

The RDP listener configuration is stored under the following Registry path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

The relevant value is:

PortNumber

Its data type is:

REG_DWORD

By default, its decimal value is:

3389

We will change this value to:

8155

7. Change the RDP Port to 8155 Using Registry Editor

Press:

Windows + R

and enter:

regedit

Open Registry Editor with administrative privileges.

Navigate to:

HKEY_LOCAL_MACHINE
   └── SYSTEM
       └── CurrentControlSet
           └── Control
               └── Terminal Server
                   └── WinStations
                       └── RDP-Tcp

Locate:

PortNumber

Double-click the value.

In the Edit DWORD (32-bit) Value window, select:

Base: Decimal

The current value should normally be:

3389

Replace it with:

8155

The final configuration should look like:

Value name : PortNumber
Value data : 8155
Base       : Decimal

Click OK to save the change.

8. Change the RDP Port to 8155 Using PowerShell

The same operation can be performed more efficiently with PowerShell.

Open PowerShell as Administrator.

First, define the Registry path:

$RDPPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp"

Check the current RDP port:

(Get-ItemProperty $RDPPath).PortNumber

A default installation will typically return:

3389

Now change it to 8155:

Set-ItemProperty `
-Path $RDPPath `
-Name "PortNumber" `
-Value 8155

Verify the new value:

(Get-ItemProperty $RDPPath).PortNumber

Expected result:

8155

9. Change the RDP Port Using Command Prompt

You can also modify the Registry directly from an elevated Command Prompt.

Run:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber /t REG_DWORD /d 8155 /f

To verify the Registry value:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber

This method can be useful in scripted deployments or automated server configuration processes.

10. Create a Windows Defender Firewall Rule for TCP 8155

Changing the Registry value is not enough.

Windows Defender Firewall must also allow inbound connections to the new RDP port.

Create the TCP rule with PowerShell:

New-NetFirewallRule `
-DisplayName "RDP TCP 8155" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 8155 `
-Action Allow

Verify the rule:

Get-NetFirewallRule -DisplayName "RDP TCP 8155"

Without this inbound rule, Remote Desktop Services may be listening on 8155 while remote clients are still unable to connect.

11. Add a UDP 8155 Rule When Required

Modern RDP implementations can use UDP alongside TCP to improve connection performance and responsiveness.

If UDP transport is allowed in your environment, create a corresponding rule:

New-NetFirewallRule `
-DisplayName "RDP UDP 8155" `
-Direction Inbound `
-Protocol UDP `
-LocalPort 8155 `
-Action Allow

To display the related rules:

Get-NetFirewallRule |
Where-Object {$_.DisplayName -like "*RDP*8155*"}

For standard RDP server connectivity, the critical firewall configuration is the inbound rule.

A dedicated outbound rule for port 8155 is normally unnecessary unless your organization uses restrictive outbound firewall policies.

12. Restrict RDP 8155 to Specific IP Addresses

Allowing port 8155 from every source is less secure than limiting access to known administration networks.

For example, to allow only:

10.20.30.0/24

use:

New-NetFirewallRule `
-DisplayName "Secure RDP TCP 8155" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 8155 `
-RemoteAddress 10.20.30.0/24 `
-Action Allow

To permit a single administrative workstation:

New-NetFirewallRule `
-DisplayName "Admin RDP TCP 8155" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 8155 `
-RemoteAddress 10.20.30.15 `
-Action Allow

Source IP restrictions provide considerably more protection than simply changing the port number.

13. Apply the New RDP Listener Configuration

The Remote Desktop Services listener must reload its configuration before the port change becomes active.

For production systems, restarting the server during a maintenance window is generally the safest approach.

Using PowerShell:

Restart-Computer

Before restarting a remotely managed server, verify the following:

PortNumber = 8155
TCP 8155 firewall rule exists
Alternative console access is available

You can check the Remote Desktop Services state with:

Get-Service TermService

Restarting Remote Desktop Services directly may interrupt active RDP sessions, so it should be handled carefully.

14. Verify That RDP Is Listening on Port 8155

After the server restarts, confirm that Remote Desktop Services is listening on the new port.

Use PowerShell:

Get-NetTCPConnection -LocalPort 8155 -State Listen

Alternatively:

netstat -ano | findstr :8155

A successful configuration may return something similar to:

TCP    0.0.0.0:8155       0.0.0.0:0       LISTENING

If IPv6 is enabled, you may also see:

TCP    [::]:8155          [::]:0          LISTENING

This confirms that a service is actively listening on TCP 8155.

15. Verify That RDP Is No Longer Listening on 3389

After confirming that port 8155 is active, also check whether port 3389 is still listening.

Using Command Prompt:

netstat -ano | findstr :3389

or PowerShell:

Get-NetTCPConnection -LocalPort 3389 -ErrorAction SilentlyContinue

If Remote Desktop Services successfully switched to 8155, the old RDP listener should no longer be present on TCP 3389.

If something is still listening on 3389, investigate which process owns the port.

16. Test Port 8155 from Another Windows Computer

A local LISTENING state does not guarantee that the port is reachable across the network.

Traffic may still be blocked by:

• Windows Defender Firewall
• Network firewalls
• VLAN ACLs
• Routers
• VPN policies
• NAT devices
• IPS/IDS systems
• Cloud security groups
• Network security groups

From another Windows computer, run:

Test-NetConnection 10.10.10.50 -Port 8155

A successful result should include:

ComputerName     : 10.10.10.50
RemoteAddress    : 10.10.10.50
RemotePort       : 8155
TcpTestSucceeded : True

The most important field is:

TcpTestSucceeded : True

17. Connect to RDP Using Port 8155

Press:

Windows + R

and enter:

mstsc

In the Computer field, specify the IP address and port:

10.10.10.50:8155

If using DNS:

server01.contoso.local:8155

You can also launch the connection directly from Command Prompt:

mstsc /v:10.10.10.50:8155

or:

mstsc /v:server01.contoso.local:8155

Because 8155 is not the default RDP port, the port number must be included.

18. Connecting Through a Public IP Address

If the server is reachable through a public IP, the client would technically connect using:

PUBLIC-IP:8155

For example:

88.101.98.45:8155

However, exposing RDP directly to the Internet is generally not recommended.

A safer design is:

Internet
   |
   v
VPN
   |
   v
Firewall
   |
   v
Internal Network
   |
   v
Windows Server:8155

The user first establishes a VPN session and then connects to the internal RDP service.

19. NAT Configuration for Port 8155

If the Windows Server is behind a router or firewall performing Network Address Translation, the NAT configuration must also allow the new port.

For example:

Public IP
   |
   | TCP 8155
   v
Firewall / NAT
   |
   | TCP 8155
   v
192.168.10.50

A simple port-forwarding rule may look conceptually like:

Public-IP:8155 → 192.168.10.50:8155

If possible, however, avoid publishing RDP directly through NAT.

Using VPN or Remote Desktop Gateway is a better security architecture.

20. Troubleshooting RDP After the Port Change

If the new connection does not work, begin by verifying the Registry value:

(Get-ItemProperty `
"HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp").PortNumber

Expected result:

8155

Check Remote Desktop Services:

Get-Service TermService

Verify the listener:

Get-NetTCPConnection -LocalPort 8155 -State Listen

or:

netstat -ano | findstr :8155

Check firewall rules:

Get-NetFirewallRule |
Where-Object {$_.DisplayName -like "*8155*"}

If another application is using the port:

netstat -ano | findstr :8155

Note the PID from the output.

For example:

1234

Then identify the process:

tasklist /FI "PID eq 1234"

This can help detect a port conflict.

21. Use Event Viewer for RDP Troubleshooting

Event Viewer can provide valuable information when the RDP listener appears healthy but connections still fail.

Review:

Applications and Services Logs
   └── Microsoft
       └── Windows
           └── TerminalServices-RemoteConnectionManager

Also review:

TerminalServices-LocalSessionManager

These logs can help identify:

• Connection failures
• Authentication problems
• Session creation issues
• Remote Desktop Services errors

The Windows Security log can also be useful:

Windows Logs
   └── Security

22. Enable Network Level Authentication

Network Level Authentication, commonly known as NLA, is an important part of a secure RDP configuration.

With NLA enabled, the user must authenticate before a complete graphical RDP session is created.

This reduces unnecessary session creation and limits part of the Remote Desktop attack surface.

The setting can be checked under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

The relevant value is:

UserAuthentication

A value of:

1

generally indicates that NLA is enabled.

Check it with PowerShell:

Get-ItemProperty `
"HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
-Name UserAuthentication

NLA should normally remain enabled unless there is a specific compatibility requirement that has been properly assessed.

23. Use Secure TLS Configuration

The security of Remote Desktop connections is not determined by the port number alone.

Encryption and certificate configuration are also important.

Windows Server systems should:

• Remain fully patched
• Avoid obsolete cryptographic protocols where possible
• Use modern TLS configurations supported by the operating system
• Use trusted certificates where appropriate
• Follow organization-wide cryptographic policies

In enterprise environments, cryptographic and Remote Desktop policies should preferably be managed centrally through Group Policy.

24. Restrict Which Users Can Use RDP

Remote Desktop access should not automatically be granted to every user.

The Windows user right:

Allow log on through Remote Desktop Services

should only be assigned to authorized users or security groups.

It can be managed under:

Computer Configuration
→ Windows Settings
→ Security Settings
→ Local Policies
→ User Rights Assignment

In Active Directory environments, using dedicated security groups is generally easier to manage than assigning permissions to individual user accounts.

25. Use the Remote Desktop Users Group

Users who need Remote Desktop access should, where appropriate, be assigned through:

Remote Desktop Users

rather than being made local administrators solely to allow RDP access.

Giving unnecessary administrative permissions violates the principle of least privilege.

The goal should be to provide users with exactly the permissions required for their tasks and no more.

26. Configure Account Lockout Policies

Password-based RDP attacks can be partially mitigated with properly designed account lockout policies.

These settings are available under:

Computer Configuration
→ Windows Settings
→ Security Settings
→ Account Policies
→ Account Lockout Policy

Important settings include:

Account lockout threshold
Account lockout duration
Reset account lockout counter after

Values should be selected according to the organization’s security policy.

Lockout settings should not be made unnecessarily aggressive, because attackers may otherwise intentionally trigger account lockouts and cause a denial-of-service condition for legitimate users.

27. Prefer VPN Instead of Direct Internet Exposure

A much stronger improvement than changing the RDP port is to avoid exposing RDP directly to the Internet.

Instead of:

Internet
   |
TCP 8155
   |
Windows Server

use:

Internet
   |
   v
VPN
   |
   v
Firewall
   |
   v
Management Network
   |
   v
Windows Server:8155

In this design, the RDP service is reachable only after the user has authenticated to the VPN.

This greatly reduces Internet-based exposure.

28. Use Remote Desktop Gateway in Enterprise Environments

Organizations with many Windows servers should avoid publishing every individual server’s RDP port externally.

Remote Desktop Gateway provides a centralized RDP access point.

A typical architecture is:

Internet
   |
   v
Remote Desktop Gateway
   |
   +------ Server01
   |
   +------ Server02
   |
   +------ Server03

This architecture provides a better foundation for:

• Centralized access control
• Logging
• Authentication policies
• Connection auditing
• Security policy enforcement

It is significantly easier to manage than exposing multiple RDP listeners directly.

29. Use a Bastion Host or Jump Server

Critical infrastructure should ideally not be accessed directly from standard user workstations.

Instead, administrators can first connect to a hardened management system.

For example:

Administrator
      |
      v
VPN
      |
      v
Bastion / Jump Server
      |
      +------ Domain Controller
      |
      +------ Database Server
      |
      +------ Application Server

This centralizes privileged access and simplifies monitoring.

A bastion or jump-server architecture is especially valuable for highly privileged systems.

30. Add Multi-Factor Authentication

Username and password alone may not provide sufficient protection for privileged remote access.

Where possible, Remote Desktop access should be protected by:

Username
   +
Password
   +
MFA

MFA can be implemented at different layers, such as:

VPN
RD Gateway
Identity Provider
Privileged Access Management

If a password is compromised, an additional authentication factor significantly reduces the likelihood of successful unauthorized access.

31. Monitor RDP Authentication Events

Remote access should be monitored, not merely enabled.

Windows Security logs can provide information about successful and failed logon attempts.

For example:

Event ID 4624

is associated with successful logon events.

Event ID 4625

is associated with failed logon events.

These Event IDs are not exclusive to RDP, so the Logon Type, source information, and Terminal Services logs should be evaluated together when investigating Remote Desktop activity.

Organizations using a SIEM platform can forward these logs centrally and generate alerts for:

• Large numbers of failed logins
• Unusual source systems
• Unexpected administrative sessions
• Connections outside normal working hours
• Repeated authentication failures
• Suspicious privileged-user activity

32. Review Old TCP 3389 Firewall Rules

After successfully moving RDP to port 8155, review existing firewall rules that still permit TCP 3389.

For example, if the server still has both:

TCP 3389   ALLOW
TCP 8155   ALLOW

the intended benefit of the port migration may be reduced.

However, do not blindly delete built-in Remote Desktop firewall rules.

In enterprise environments, firewall rules may be created or restored by Group Policy.

Review the existing configuration and organizational policies before removing or disabling rules.

33. Complete PowerShell Example for RDP Port 8155

The following commands summarize the main configuration steps.

Define the new port and Registry path:

$NewRDPPort = 8155
$RDPPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp"

Check the current port:

(Get-ItemProperty $RDPPath).PortNumber

Check whether 8155 is currently in use:

Get-NetTCPConnection `
-LocalPort $NewRDPPort `
-ErrorAction SilentlyContinue

Change the RDP port:

Set-ItemProperty `
-Path $RDPPath `
-Name "PortNumber" `
-Value $NewRDPPort

Add the TCP firewall rule:

New-NetFirewallRule `
-DisplayName "RDP TCP 8155" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 8155 `
-Action Allow

Add UDP if required:

New-NetFirewallRule `
-DisplayName "RDP UDP 8155" `
-Direction Inbound `
-Protocol UDP `
-LocalPort 8155 `
-Action Allow

Verify the Registry value:

(Get-ItemProperty $RDPPath).PortNumber

Expected result:

8155

Restart the server during the appropriate maintenance window.

After reboot:

Get-NetTCPConnection -LocalPort 8155 -State Listen

From another machine:

Test-NetConnection SERVER-IP -Port 8155

Finally, connect using:

mstsc /v:SERVER-IP:8155

34. Example RDP 8155 Connection Scenario

Assume the Windows Server IP address is:

10.26.5.100

and the RDP port is now:

8155

Test the connection:

Test-NetConnection 10.26.5.100 -Port 8155

A successful result may look like:

ComputerName     : 10.26.5.100
RemoteAddress    : 10.26.5.100
RemotePort       : 8155
TcpTestSucceeded : True

Launch Remote Desktop:

mstsc /v:10.26.5.100:8155

Or enter the following into the Remote Desktop Connection application:

10.26.5.100:8155

Recommended RDP Security Checklist

After moving the RDP listener from 3389 to 8155, review the following security controls:

• Confirm that PortNumber is set to 8155.
• Create an inbound Windows Defender Firewall rule for TCP 8155.
• Add UDP 8155 only where required.
• Verify that 8155 is not used by another service.
• Confirm that the RDP listener is in the LISTENING state.
• Test connectivity remotely with Test-NetConnection.
• Use the SERVER-IP:8155 format for connections.
• Review unnecessary TCP 3389 firewall rules.
• Enable Network Level Authentication.
• Restrict RDP access to authorized users and groups.
• Follow least-privilege principles.
• Apply an appropriate account lockout policy.
• Use MFA where possible.
• Restrict firewall access by source IP or management network.
• Prefer VPN or RD Gateway instead of direct Internet exposure.
• Consider a bastion host or jump server for privileged systems.
• Keep Windows fully patched.
• Monitor RDP and Windows Security logs.
• Forward authentication logs to a centralized SIEM where available.