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 : 8155We 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 3389Therefore, when a user opens Remote Desktop Connection and enters only the server IP address:
10.10.10.50the 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:8155If DNS is used, the same format applies:
server01.contoso.local:81552. 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
testmay 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 – BlueKeepThis 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 → 8155can reduce the number of automated connection attempts from scanners that only probe the default RDP port.
For example, a bot that checks only:
TCP 3389may no longer detect the service.
However, an attacker performing a full TCP scan across:
1-65535can 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
KVMFor virtual machines:
VMware Console
vCenter Console
Hyper-V Console
Cloud ConsoleYou 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 SilentlyContinueAlternatively, use Command Prompt:
netstat -ano | findstr :8155If 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-TcpThe relevant value is:
PortNumberIts data type is:
REG_DWORDBy default, its decimal value is:
3389We will change this value to:
81557. Change the RDP Port to 8155 Using Registry Editor
Press:
Windows + Rand enter:
regeditOpen Registry Editor with administrative privileges.
Navigate to:
HKEY_LOCAL_MACHINE
└── SYSTEM
└── CurrentControlSet
└── Control
└── Terminal Server
└── WinStations
└── RDP-TcpLocate:
PortNumberDouble-click the value.
In the Edit DWORD (32-bit) Value window, select:
Base: DecimalThe current value should normally be:
3389Replace it with:
8155The final configuration should look like:
Value name : PortNumber
Value data : 8155
Base : DecimalClick 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).PortNumberA default installation will typically return:
3389Now change it to 8155:
Set-ItemProperty `
-Path $RDPPath `
-Name "PortNumber" `
-Value 8155Verify the new value:
(Get-ItemProperty $RDPPath).PortNumberExpected result:
81559. 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 /fTo verify the Registry value:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumberThis 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 AllowVerify 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 AllowTo 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/24use:
New-NetFirewallRule `
-DisplayName "Secure RDP TCP 8155" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 8155 `
-RemoteAddress 10.20.30.0/24 `
-Action AllowTo permit a single administrative workstation:
New-NetFirewallRule `
-DisplayName "Admin RDP TCP 8155" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 8155 `
-RemoteAddress 10.20.30.15 `
-Action AllowSource 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-ComputerBefore restarting a remotely managed server, verify the following:
PortNumber = 8155
TCP 8155 firewall rule exists
Alternative console access is availableYou can check the Remote Desktop Services state with:
Get-Service TermServiceRestarting 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 ListenAlternatively:
netstat -ano | findstr :8155A successful configuration may return something similar to:
TCP 0.0.0.0:8155 0.0.0.0:0 LISTENINGIf IPv6 is enabled, you may also see:
TCP [::]:8155 [::]:0 LISTENINGThis 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 :3389or PowerShell:
Get-NetTCPConnection -LocalPort 3389 -ErrorAction SilentlyContinueIf 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 8155A successful result should include:
ComputerName : 10.10.10.50
RemoteAddress : 10.10.10.50
RemotePort : 8155
TcpTestSucceeded : TrueThe most important field is:
TcpTestSucceeded : True17. Connect to RDP Using Port 8155
Press:
Windows + Rand enter:
mstscIn the Computer field, specify the IP address and port:
10.10.10.50:8155If using DNS:
server01.contoso.local:8155You can also launch the connection directly from Command Prompt:
mstsc /v:10.10.10.50:8155or:
mstsc /v:server01.contoso.local:8155Because 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:8155For example:
88.101.98.45:8155However, 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:8155The 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.50A simple port-forwarding rule may look conceptually like:
Public-IP:8155 → 192.168.10.50:8155If 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").PortNumberExpected result:
8155Check Remote Desktop Services:
Get-Service TermServiceVerify the listener:
Get-NetTCPConnection -LocalPort 8155 -State Listenor:
netstat -ano | findstr :8155Check firewall rules:
Get-NetFirewallRule |
Where-Object {$_.DisplayName -like "*8155*"}If another application is using the port:
netstat -ano | findstr :8155Note the PID from the output.
For example:
1234Then 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-RemoteConnectionManagerAlso review:
TerminalServices-LocalSessionManagerThese 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
└── Security22. 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-TcpThe relevant value is:
UserAuthenticationA value of:
1generally indicates that NLA is enabled.
Check it with PowerShell:
Get-ItemProperty `
"HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
-Name UserAuthenticationNLA 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 Servicesshould only be assigned to authorized users or security groups.
It can be managed under:
Computer Configuration
→ Windows Settings
→ Security Settings
→ Local Policies
→ User Rights AssignmentIn 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 Usersrather 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 PolicyImportant settings include:
Account lockout threshold
Account lockout duration
Reset account lockout counter afterValues 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 Serveruse:
Internet
|
v
VPN
|
v
Firewall
|
v
Management Network
|
v
Windows Server:8155In 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
|
+------ Server03This 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 ServerThis 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
+
MFAMFA can be implemented at different layers, such as:
VPN
RD Gateway
Identity Provider
Privileged Access ManagementIf 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 4624is associated with successful logon events.
Event ID 4625is 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 ALLOWthe 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).PortNumberCheck whether 8155 is currently in use:
Get-NetTCPConnection `
-LocalPort $NewRDPPort `
-ErrorAction SilentlyContinueChange the RDP port:
Set-ItemProperty `
-Path $RDPPath `
-Name "PortNumber" `
-Value $NewRDPPortAdd the TCP firewall rule:
New-NetFirewallRule `
-DisplayName "RDP TCP 8155" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 8155 `
-Action AllowAdd UDP if required:
New-NetFirewallRule `
-DisplayName "RDP UDP 8155" `
-Direction Inbound `
-Protocol UDP `
-LocalPort 8155 `
-Action AllowVerify the Registry value:
(Get-ItemProperty $RDPPath).PortNumberExpected result:
8155Restart the server during the appropriate maintenance window.
After reboot:
Get-NetTCPConnection -LocalPort 8155 -State ListenFrom another machine:
Test-NetConnection SERVER-IP -Port 8155Finally, connect using:
mstsc /v:SERVER-IP:815534. Example RDP 8155 Connection Scenario
Assume the Windows Server IP address is:
10.26.5.100and the RDP port is now:
8155Test the connection:
Test-NetConnection 10.26.5.100 -Port 8155A successful result may look like:
ComputerName : 10.26.5.100
RemoteAddress : 10.26.5.100
RemotePort : 8155
TcpTestSucceeded : TrueLaunch Remote Desktop:
mstsc /v:10.26.5.100:8155Or enter the following into the Remote Desktop Connection application:
10.26.5.100:8155Recommended RDP Security Checklist
After moving the RDP listener from 3389 to 8155, review the following security controls:
- Confirm that
PortNumberis 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
LISTENINGstate. - Test connectivity remotely with
Test-NetConnection. - Use the
SERVER-IP:8155format 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.
