Compromise Overview #
Recently, Okta Chief Security Officer Mr. David Bradbury released an article outlining their recent compromise. The article is linked in the bottom, and Mr. Bradbury does a fine job of giving a timeline of events as he understands them. Here is an even briefer version of events:
- January 20-21, 2022 –
- A security alert from an Okta third-party vendor (for customer support) initiates an incident response. Incident response process is followed, and events are escalated to a forensics company for analysis
- March 17, 2022 – Summary report issued from third-party customer support vendor
- March 22, 2022 –
- Hacker group, LAPSUS$, posts “proof” screenshot online.
- Complete report received from third-party support vendor.
Ignoring the odd timing of the proof screenshots and the final report (seems like the motivation to issue the complete report came from the bad press), the actual events seem to indicate no real threat of compromise of Okta’s data. That is great news, and I am pleased that Okta’s internal process were followed, and this event didn’t turn into another Target breach. If you’ll recall, Target suffered a significant breach that originated from weaknesses in one of their vendors’ processes. What we will focus on today, is the threat vector of the compromise. In this case, this compromise came about due to the unmonitored, or unrestricted use of Remote Desktop Protocol (RDP), a Window’s protocol that allows access to the target system over the internet.
RDP overview #
As Mr. Bradbury eloquently stated, unmonitored access with RDP is akin to allowing someone to sit down at your unlocked computer as you use the bathroom or go for a walk. Are you on a Windows computer? I’ll bet you have RDP active on your machine right now. Let’s check!
Click Start, type “RDP”, hit enter.
This is how you connect to another machine using RDP!
If the target computer is not securely configured, the bad guy is going to be attacking it. This is a common tactic for both scammers and hackers, and it is clear to see the appeal. It is a protocol that exists on most Windows machines and many administrators don’t bother shutting this attack vector down. Before we start looking for targets, let’s see how easy it is to shut off RDP (on Windows 10 in this example):
Click Start, type “remote settings”, toggle switch to “off”
If using Group/Local Policy, the most effective technique is to implement Multi-Factor Authentication (MFA) or setting the account lockout policy threshold to a low number of tries (3-5 is typical).
This is also easy to do!
Click Start, type
“Local Security Policy”
Go under “Account Policies ->, “Account Lockout Policy” ->, Double-Click on “Account lockout threshold, Set your threshold to the desired limit.
How do the Hackers do it? #
Some hackers use social engineering, pretending to be Microsoft support, or some other service, to trick people into allowing RDP connections. Other hackers use traditional hacking methodology. Since the bad guys know that there a bunch of machines out there with Windows RDP active and allowing connections, often it is only a matter of finding these vulnerable machines. Before we give it a try ourselves, is this common?
Observe the table to the right. This is a top ten list of intrusions in the United States of America. Numbers 1, 3, and 6 in this list are all Bruteforce attacks against RDP. In other words, the bad guys guess as many passwords as they can, as quick as they can manage, against RDP connections with the goal of getting lucky that a weak, or guessable, password is protecting the Windows machine.
Let’s try it ourselves! The following scanning activities are for educational purposes only and all sensitive information will be obfuscated.
Enumeration of Targets #
Since RDP uses port 3389 in most cases, a hacker can use active scanning techniques to find out if 3389 is in use on machine. This is possible using Nmap
nmap -v [hostname or IP address]
Below we’ve scanned a target, and we can see that in fact the target is using RDP. You can also scan large ranges of IPs or use a service like Shodan to show many web-facing machines.
Below is a quick summary of results from searching using Shodan.io. Using this simple query:
rdp product:”Remote Desktop Protocol” port:3389
There appear to be 4,476 potential victims enumerated with just a simple search! Digging into any of these results, we’re presented with public key information, as well as any other open ports that may be vulnerable.
Some of these results are honeypots, others are targets with no useful information to steal, but a motivated hacker will keep checking for easy targets until they are successful. Once a target is chosen, it is simply a matter of bruteforce attacking the RDP connection. This is illegal in all cases except where permission has been granted, but we’ll still show the steps.
Attacking the Target #
There are some good, very easy to use, tools that are useful in bruteforce attacking RDP. Crowbar is useful as it can bruteforce RDP using pre-populated username/password lists. All the attacker needs to do it install Crowbar (it’s free), grab some username/password lists (also free), and wait until they are successful.
./crowbar.py -b rdp -s [ip address] -U [username list] -C [password list]
Once successful, the hacker has access using your Windows machine.
The situation with Okta’s third-party customer service vendor reminds us that we should be setting up our machines with the least connectivity required to perform our duties. Furthermore, we should continue to monitor our vendors, and review our service agreements with them to gain reasonable assurance that they are managing their security appropriately. While RDP bruteforce attacks are extraordinarily common, we can protect against them by limiting the effectiveness of bruteforce attacks, or by shutting down remote connectivity altogether.
If you have any further questions about this type of attack vector, other threats, or how your organization can implement an effective information security program, please reach out to us!
Tyson A Savoretti CISSP, CISA, CEH, ECIH, SSCP, PCI-ISA, PenTest+, CySA+