This post was originally published here by Matthew Hosburgh.
In 2015, a targeted attack was discovered. Exposed by Cymmetria, the campaign was known as Patchwork. Their findings discovered that the campaign targeted “personnel working on military and political assignments, and specifically those working on issues relating to Southeast Asia and the South China Sea.” While that is not news to some, one notable action taken by the actor was an attempted connection to a discovered host via Remote Desktop Protocol (RDP). After failed brute force attempts, the attacker moved on to another target. This fact may seem insignificant, however, the RDP server itself was a decoy. These alerts provided an early warning and additional details on the behavior of the attacker.
RDP is Pretty Swell
Who hasn’t used RDP is probably the question I should ask. That’s because it’s leveraged by system administrators and users alike. Providing a means to teleport to another system’s Desktop, RDP is a staple when it comes to Windows hosts. Attacker’s know this and this is why finding an exposed 3389 port within an organization can lead to brute force attempts—if successful, it can be a pivot point for lateral movement. Sync’d administrative passwords can further make RDP a ripe target, especially when exposed to the Internet (see figure 1).
RDP is Just Read-Only, Right?
The casual administrator or user of RDP might have the thought that RDP is merely read-only (I held this view for years until I found the error of my ways); however, capabilities that exist, which may be lesser known, can turn a view only session into a means to exfiltrate data or stage malware for future actions. One of the lesser known “features” is the shared clipboard.
This permits the bi-directional sharing of the local and remote host’s clipboard. So what’s the problem with copying a little text back and forth? Couldn’t hurt, right? Well, what if I told you this also applies to files and really anything that you can apply copy-paste to? Compounding the issue is that this RDP traffic is typically encrypted, effectively creating an encrypted tunnel over the network—making it difficult to see what is happening from the network level. Files, passwords, malware all could be traversing the network, without an alert. It might be a good idea to discover when an adversary might be trying to RDP into a system, and in particular by means of brute forcing.
Brute Forcing and Password Guessing
In simple terms, brute forcing is the means to strong arm one’s way into a system by trying every combination possible. This is often noisy and detectable. In reality, a hybrid attack is the more practical means, where the attacker attempts passwords for a known or probable account. Because RDP utilizes Windows accounts (local or domain), the brute forcing is happening against the target account. Think of it the same as if the attacker were sitting at the keyboard of a system—just remotely. Back to the point of sync’d passwords. If an attacker were able to compromise credentials and those credentials were sync’d, moving laterally via RDP is a breeze.
Shouldn’t this not work?
If you’ve configured your servers, and specifically, a group policy to lock out accounts after a set number of invalid attempts, you’re well on your way to protecting your organization from this type of attack. Devoid of an account lockout policy, an attacker could hammer away at a system until they’re successful. Compounding the issue, failed RDP attempts could be noisy in your environment, but they could also point to a brute force attempt. So where can you start to look for these failures?
Logs to the Rescue!
One of the simplest forms to detect brute force attempts is to examine the Windows event logs. In particular, within a Windows 7/8/10 + environment, the event ID that is needed is 4625 (SANS has a great resource for identifying account access if you’re looking for more event IDs of value). This is the entry that will get us started in the hunt for brute force RDP attempts. Next, the logon type is required. Ranging from 2 – 11, RDP is classified as type 10 (RemoteInteractive). Within the description, a Failure Information section will sometimes indicate why the logon failed. According to Ultimate Windows Security, some of the observed reasons are:
What could point to brute forcing in particular is if the username does not exist. Additionally, if your domain or systems have a common (and hopefully), disabled account, logon attempts against that account could further indicate brute force attempts.
I See Brute Force Attempts + 1 Logon Success
Failed logons could indicate numerous things: old credentials in a script, mis-typed passwords, or even an active adversary. As a hunter these could be things that would be interesting; however, failed RDP logon attempts followed by an event 4624 (logon success) might be more valuable (and equally noisy). This could be a strong indicator that the brute forcing was successful. The question to ask if it was successful is: what type or permissions does the account possess? Is it a domain admin or standard user account? What happened after the account was compromised? Were additional remote sessions observed to other hosts in the environment?
Conclusion
RDP is a great tool for both attackers and administrators alike. From legitimate use to nefarious purposes, RDP is a ripe target for many attackers. Within a large organization, detecting brute force attempts could be difficult and it requires the environment to be prepped i.e. failed logon attempts must be audited for a failed logon event to be created. From a failed logon event ID, further information can be obtained such as the logon type. Type 10 indicates a remote interactive session, or RDP session. As a hunter looking for anomalous RDP logons from different or uncommon systems could serve as an early warning that something is awry. Numerous failed attempts followed by a successful logon could indicate a successful brute-force and could warrant further hunting.
Photo:Appthority
