Remote Desktop Services (or RDP, as most people call this service) is undoubtedly one of the most useful services that Windows administrators depend on. Introduced all the way back with Windows NT, Microsoft has been continually adding new features to Remote Desktop Protocol, with the current version 7.1.

One of the cool features Microsoft added initially with Windows Vista was Network Level Authentication (NLA). This new feature that must be supported by both the RDP client and server allows a client to go through the authentication process before connecting to the remote server. This has several benefits, the biggest one being that it requires fewer resources until the authentication process has successfully completed.

As I’ve been spending a lot of time analyzing Windows logs, I found that the introduction of NLA changed behavior of RDP servers regarding logs, due to the way it works. While the overall security level remains the same, consider this more a kind of a reminder on what to look for if you ever have to investigate a security incident concerning RDP connections.

So, before Windows 7 and Windows Server 2008, once we decided to use RDP to connect to a remote machine we fired up mstsc.exe, entered the name or IP address of the destination server and soon (or not so soon, depending on how fast or slow your connection is), the following screen welcomed us:

In this case the user can enter his/her credentials for the server to verify. In this case, the verification process is done by the target RDP server – behind the curtains, this server either contacted the domain controller or authenticated the user locally. In this case, an event 672 (for successful Kerberos authentication; event 4768 on Windows Vista/7/2008) or event 680 (4776) (in both successful and failed NTLM authentication) will be logged, following by a 528 or 529 (or 4624 and 4625 on Windows Vista/7/2008) event. In case of this event (528 or 529), its Logon Type value will show 10 which means RemoteInteractive or simply RDP.

All good in this case, since we can see the server that the user tried to connect to (the server requesting the authentication), and on the server we can see the source IP address of the user and his/her successful or unsuccessful connection attempt. If you are now collecting logs to a central log management server you can simply report or alert on brute force attempts on RDP.

However, with NLA things changed a bit. Since the authentication process has been changed, if the user now tries to login to a RDP server with his domain credentials, the mstsc.exe client will try to authenticate with the domain controller directly. If this attempt was unsuccessful it will result in a 675 event (pre-authentication failed), or 4771. This is as expected – if we haven’t supplied a valid username and password, the authentication will fail.

The problem I noticed here is lack of context: this event is same as any other authentication attempt in the domain. In other words, there is absolutely no way for an administrator monitoring logs to know if the user in question is trying to connect to a RDP server or just brute forcing accounts. Of course, this is not a security vulnerability since the domain controller will respect all implemented security controls such as account locking but there is a small lack of context which can help an attacker “hide” his true actions (accessing RDP).

So, to wrap this up – if you are monitoring your Windows logs don’t be surprised if suddenly you don’t see many (or any) 529/4625 events with Logon Type 10.

--
Bojan
INFIGO IS