How are hacker bots figuring out user and port for RDC connection?

I've got some serious security concerns. Our office has Remote Desktop Access configured, but we are not using the standard 3389 port. Each user is assigned a specific port in a range, e.g. 12345-12354 (not the real ports). These ports are then forwarded to port 3389 on the specific user's workstation. The router is Linux using iptables. Here's the problem. Some hacker(s) have figured this out and have been trying to break in. In the logfile I have (abridged):
[2018/03/07 07:28:45.080884, 2] authentication for user [HPRS/user] FAILED with error NT_STATUS_WRONG_PASSWORD, port: 12345, IP:
[2018/03/07 07:28:46.741469, 2] authentication for user [HPRS/user] FAILED with error NT_STATUS_ACCOUNT_LOCKED_OUT, port: 12345, IP:

IP: 77.72.83    Attempted Remote Desktop port accesses: 124
address:        45 REYNOLDS WALK
country:        GB

Open in new window

The first line occurs 15 times before the lockout policy kicks in. The second line occurs another 100+ times as the bot continues to try despite now being locked out. An additional script (like fail2ban) examines these messages and will block this IP long-term, not just for the lockout duration. The perpetrator in this case is allegedly from Great Britain, but we had one yesterday from the Netherlands, and in the past from other places.

Now, I can see how they might guess the target server and user because these are components of the users' email addresses. And I suppose I can see how they might guess port number by scanning ports and looking for  RDC signatures on the various ports (note that we also have 3 Linux workstations on this port range and no attempts have been made on those yet. I'm guessing because a scan of those ports does not return an RDC signature).

The puzzling and alarming bit to me is how they are guessing the correct forwarded port for a given user? They're not trying user 'jane' on all the possible RDC ports. Rather, they're trying user 'jane' on her specifically assigned port for her workstation.

How is this possible? If this user connects from home, is this connection not secure by the RDC protocol? Can someone "see" user ID and port? What else might it be?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

MarkAuthor Commented:
That link suggests changing the default port, which I've done. One of the responders says, "RDP is not secure. Your password is set encrypted, but all other traffic is sent in the clear." Hmmm, this post is from 2007 so maybe it's old? This Microsoft link says, "By default, RD Session Host sessions use native RDP encryption", suggesting to me that the connection is encrypted. Thoughts?

Yes, local Windows firewalls are enabled (controlled by Active Directory server), but of course RDP port is opened.

Whether or not the RDP connection is encrypted, any ideas on how they would be able to correlate a user ID with the correct re-mapped port to that user's workstation?

more info:

This particular user has not logged into her workstation from home for several months ... hmmm
btanExec ConsultantCommented:
1) The listening port for RDP can be changed as uou have done so and these are recorded in the registry - provided the bots or attacker has admin rights. If your user are default admin then getting into the machine to check such port will be easier. User should not be using admin accounts
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp.

Although this change port approach is helpful, it is security by obscurity which is not the most reliable security approach.

2) In fact, you should not allow even RDP ro be accessible from Internet. Minimally a RDP gateway to front those rdp client.

It provides a way to tightly restrict access to Remote Desktop ports while supporting remote connections through a single "Gateway" server. When using an RD Gateway server, all Remote Desktop services on your desktop and workstations should be restricted to only allow access only from the RD Gateway. The RD Gateway server listens for Remote Desktop requests over HTTPS (port 443), and connects the client to the Remote Desktop service on the target machine.

If using an RD Gateway is not feasible, you can add an extra layer of authentication and encryption by tunneling your Remote Desktop sessions through IPSec or SSH. IPSec is built-in to all Windows operating systems.

By enforcing the use of a RDP gateway, you also get a third level of auditing that is easier to read than combing through the domain controller logins, and is separate from the target machine so is not subject to tampering.

3) Use of 2FA for remote login. RDP Gateways do provide a simple mechanism for controlling authentication via two factor certificate based smartcards. Other two factor approaches need another approach at the Remote Desktop host itself e.g. YubiKey, RSA.

4) Actually they should be some form of health check. Such as use of Network Access Protection(NAP) with an RD Gateway. That is beyond the discussion.
The 7 Worst Nightmares of a Sysadmin

Fear not! To defend your business’ IT systems we’re going to shine a light on the seven most sinister terrors that haunt sysadmins. That way you can be sure there’s nothing in your stack waiting to go bump in the night.

Either do what btan mentioned or you use a VPN.
Jonny BTech (CEO)Commented:
Remote Desktop Protocol (Remote Desktop)  should really never be port forward on any port out of a firewall onto the internet.  That particular protocol is not secure at all and is constantly being compromised by hackers.  Several years ago, I took over support for a small doctors offices that had a similar configuration as you mentioned.  I could set there a watch the constant attacks coming in and trying to logon which not only put a major strain on the server slowing it down but would only be a matter of time before it was breached and have logon ability.  

The best way I have found to still use Remote Desktop, was to implement VPN connections into the offices.  This not only adds another layer of security, but will make all the traffic in these connections secure from prying eyes.  

There was even a way to breach an administrator account in a domain with only having standard user permission if they were logged in.  I would have to check with a few people to see if that is still possible or has been patched to prevent that ability.

So I would suggest that you try to work to enable vpns so you have a much more secure connection.  Also if you use admin accounts via Remote desktop connections, that you log out as soon as you are done working so you don't have to worry about a standard user gaining administer access.
Many years ago, remapping the port worked out just fine.  However, too many people figured out that trick, so they're now fingerprinting other ports to find rdp.  It's no longer feasible to remap rdp ports, because it's a well known obfuscation trick.
btanExec ConsultantCommented:
At best is dont go for RDP but if needed VPN (with NAC) and 2FA for login. That will increase deterrence to unauthorized access.
btanExec ConsultantCommented:
for author advice
You can also try an RDP Gateway.
btanExec ConsultantCommented:
for author advice
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Remote Access

From novice to tech pro — start learning today.