For many years, abuse of Remote Desktop Protection (RDP) has been the most common root cause of all ransomware events. At the moment one of the most common attacks against VMs in Azure/ AWS or other clouds is based on the RDP brute-force attack.

Last year I published a blog about monitoring RDP attacks. This blog is focussing on more in-depth information; what happens after 24+ hours of open RDP ports and what is visible in Defender – Sentinel – Defender for Cloud.

T-Pot is added to this blog for some additional background information around honeypots and the most common malicious activity part of a new T-Pot instance including containers.

In part 2 of this blog, I’ll talk about what happened when the machine was online with the username: Administrator and password: 123456 in Microsoft Defender for Endpoint.

RDP attack most frequent attack?

Now you may think, securing RDP is a default measure – based on Shodan there are currently more than 4.46M RDP ports (3389) exposed to the public internet. Attackers use automated systems to scan frequently the internet for open ports which are available with only username and password protection.

There is absolutely no reason to put RDP directly on the Internet. There are many solutions available (JIT, Bastion, and other protections which allow easy management). Seriously, don’t open RDP directly to the public internet. It’s only a matter of time before a system is compromised.

It’s extremely easy to find RDP systems online. Scanning for RDP’s default port (TCP/3389) is easy, but Shodan has already done it for you.

Shodan is a search engine for internet-of-things devices across the internet. Shodan can identify devices on the internet based on several characteristics. Shodan works by crawling the internet based on a full protocol-specific handshake to determine whether a port is open or closed. In case of open RDP ports Shodan takes a screenshot of the discovered open RDP ports.

Shodan search based on port:3389 will returns all hits discovered by Shodan. Currently, there are a total of 4.467.430 exposed RDP ports (including honeypots) and counting each day.

Top 10 – country

Source: Shodan.io

Monitoring RDP attacks

This blog post will show you how to use Microsoft Sentinel for detecting brute force attacks based on RDP targeting cloud VMs in Azure, Amazon, or other clouds.

The following is part of the blog:

  • Collect Security Events using the new Azure Monitoring Agent (AMA)
  • Hunting for malicious activity using Microsoft Sentinel
  • Build-in Analytics rules
  • Fusion detection

++ Bonus content

  • Using T-Pot for honeyPot insights
  • T-Pot analyze

Install AMA agent – Collect events

The Azure Monitoring Agent (AMA) is re-written from the ground and the replacement for the Microsoft Monitoring Agent used by Log Analytics. The Azure Monitor agent uses data collection rules (DCR) to configure data to collect from each agent. Data collection rules enable the manageability of collection settings at scale for different groups of environments or machines, which results in less cost and fewer events.

View the following blog for all information related to AMA, DCA, and the new agent: Collect Security Events in Microsoft Sentinel with the new AMA agent and DCR  Below part is a small summary of the details which are explained before.

Multiple options are available for installing the Azure Monitoring Agent, in this blog post the installation based on Microsoft Sentinel is explained. For more detailed standalone install instructions check the following source: Manage the Azure Monitor agent | Microsoft Docs

For Azure cloud machines, no extra Azure Arc configuration is required. For enabling the new connector, take the following steps:

  1. Open Microsoft Sentinel
  2. In the menu select Data connectors (1)
  3. Select the Windows Security event via AMA connector (2) 
  4. Open the connector page (3)

Now from the connector page configure the new data sources. Make sure you have read and write permissions. For collecting security events from Windows agents and installing the AMA agent. Start with creating a new data collection rule (DCR). For creating the new rule click the button Create data collection rule

The Data Collection Rule is the location where the data should be sent. In this blog, we use the Microsoft Sentinel Log Analytics workspace.

Fill in the following values:

  • Rule name: Name for specific Data Collection Rule
  • Subscription: Select the subscription
  • Resource Group: Select resource group ( Data Collection rule is Azure Resource.

Now select the devices or Resource groups/ subscriptions and press Apply. After enabling the installation will be automatically installed on these machines. Selection for single virtual machines is possible or complete resource groups/ subscriptions:

Review the selected resources and go to the tab; collect.

For collecting events select one of the event groups: All Security Events, Common, Minimal, Custom.

  • All events – All Windows security and AppLocker events.
  • Common – A standard set of events for auditing purposes. The Common event set may contain some types of events that aren’t so common. This is because the main point of the Common set is to reduce the volume of events to a more manageable level, while still maintaining full audit trail capability.
  • Minimal – A small set of events that might indicate potential threats. This set does not contain a full audit trail. It covers only events that might indicate a successful breach, and other important events that have very low rates of occurrence.
  • Custom – defining custom queries using Xpath. See this blog for the explanation
Event setCollected event IDs
Minimal1102, 4624, 4625, 4657, 4663, 4688, 4700, 4702, 4719, 4720, 4722, 4723, 4724, 4727, 4728, 4732, 4735, 4737, 4739, 4740, 4754, 4755, 4756, 4767, 4799, 4825, 4946, 4948, 4956, 5024, 5033, 8001, 8002, 8003, 8004, 8005, 8006, 8007, 8222
Common1, 299, 300, 324, 340, 403, 404, 410, 411, 412, 413, 431, 500, 501, 1100, 1102, 1107, 1108, 4608, 4610, 4611, 4614, 4622, 4624, 4625, 4634, 4647, 4648, 4649, 4657, 4661, 4662, 4663, 4665, 4666, 4667, 4688, 4670, 4672, 4673, 4674, 4675, 4689, 4697, 4700, 4702, 4704, 4705, 4716, 4717, 4718, 4719, 4720, 4722, 4723, 4724, 4725, 4726, 4727, 4728, 4729, 4733, 4732, 4735, 4737, 4738, 4739, 4740, 4742, 4744, 4745, 4746, 4750, 4751, 4752, 4754, 4755, 4756, 4757, 4760, 4761, 4762, 4764, 4767, 4768, 4771, 4774, 4778, 4779, 4781, 4793, 4797, 4798, 4799, 4800, 4801, 4802, 4803, 4825, 4826, 4870, 4886, 4887, 4888, 4893, 4898, 4902, 4904, 4905, 4907, 4931, 4932, 4933, 4946, 4948, 4956, 4985, 5024, 5033, 5059, 5136, 5137, 5140, 5145, 5632, 6144, 6145, 6272, 6273, 6278, 6416, 6423, 6424, 8001, 8002, 8003, 8004, 8005, 8006, 8007, 8222, 26401, 30004

RDP Brute-Force Quick Stats

Now it’s time to show the results. If you don’t know RDP brute force attacking is heavily used, you know it after this blog post. First some quick stats to deep-dive into more Sentinel queries and Sentinel events.

Data is based on 3 default Azure VMs including complex admin passwords.

The honeypot was online for 3 days which generates the below events in Sentinel:

EventEvent count
Total logon attempts (eventID 4625)89,285
Total logon attempts username “administrator”62,260
Total logon attempts including the word “admin”74,520
Unique user accounts (eventID 4625)1993
Unique IP’s (eventID 4625)132
Successful authentications0 (complex password and non-default username)

The honeypot was online for 7 days which generates the below events in Sentinel:

EventEvent count
Total logon attempts (eventID 4625)209,335
Total logon attempts username “administrator”172.000
Total logon attempts including the word “admin”185.591
Successful authentications0 (complex password and non-default username)

Top 20 user names: (3 days of data)

UsernameEvent count
Administrator29,791
{servername1{\Administrator13,589
{servername2{\Administrator11,769
{servername3{\Administrator4,290
Admin1,471
ADMINISTRATOR1,430
AZUREUSER1,123
AZUREADMIN997
VMADMIN848
LOCALADMIN837
SYSADMIN825
TESTUSER813
ADMINUSER813
SERVERADMIN811
ADADMIN809
DEMOUSER807
ADMINVM806
ADMIN123804
ADMINISTRATOR1801
AZADMIN799

RDP Brute-Force Quick Stats – Easy password

One of the machines is configured with a separate admin account. There were successful authentications to it. For the majority, attackers didn’t do anything on the machine. Since MDE and Defender for Cloud are enabled there was visibility into what the attacker did, and which alerts are generated from Defender for Endpoint.

This is likely because the initial logons were part of a brute-force attack and they were only looking for systems for which credentials could be guessed.

I will explain this part in a new blog soon, and explain the compromises detected by Defender for Endpoint, Sentinel, Defender for Cloud. Enough content for another part.

It starts with;

Sentinel Hunting

Based on all data we can use Microsoft Sentinel hunting for getting some more insights. The following events are part of the RDP Brute Force attempt and are useful for hunting:

  • EventID 4625: Account Failed to Log on
  • EventID 4624: An account was successfully logged on

Failure reasons:

  • %%2310: Account currently disabled. (531)
  • %%2313: Unknown user name or bad password. (529)

EventID 4624/ 4625 is located in the Security Event table of Log Analytics/ Sentinel. The combination of both events makes it possible to deep-dive for succeeded sign-ins.

Summarize RDP attempt by 1 hour (data from last 7 days)

SecurityEvent
| where EventID == 4625
| where AccountType == "User"
| summarize ['Total Brute Force Attemps']=count() by bin(TimeGenerated, 1h)
| render timechart

Summarize usernames (data from last 7 days)

SecurityEvent
| where EventID == "4625"
| where AccountType == "User"
| summarize count=count() by Account
| render piechart

Summarize IPaddress (data from last 7 days)

SecurityEvent
| where EventID == "4625"
| where AccountType == "User"
| summarize count=count() by IpAddress
| render piechart

Failure code/ victim workstation

Show 4625 event where substatus is 0xc000006A or 0xc0000064 . Including WorkstationName of the attacker.

  • 0xc0000064: user name does not exist
  • 0xc000006A: user name is correct but the password is wrong
SecurityEvent
| where EventID == 4625
| where (SubStatus == "0xc000006A" or SubStatus == "0xc0000064")
| project TimeGenerated, EventID, WorkstationName, Computer, Account, Activity, LogonTypeName, LogonProcessName, LogonType, SubStatus

Attempt including Failed / Succeeded ( succeeded based on EventID 4624)

SecurityEvent
| where EventID in (4625, 4624) and AccountType == 'User'
| summarize Attempts = count(), Failed = countif(EventID == 4625), Succeeded = countif(EventID == 4624) by Account

Suspicious failed logins, by IP address. Event shows: Succeeded, Attempts, Unique account used

Credits: Pixelrobots.co.uk

SecurityEvent
| where AccountType == 'User'
| where EventID in (4624, 4625)
| summarize Unique_Accounts = dcount(Account), Attempts = count(), Succeeded=countif(EventID == 4624), Failed=countif(EventID == 4625) by IpAddress
| where Failed > 0
| order by Succeeded>0, todouble(Succeeded)/Attempts asc, Attempts desc
| project IP = IpAddress, Succeeded, Attempts, Unique_Accounts

Sentinel Incidents

Based on some of the pre-build Analytics rules – Microsoft Sentinel gives a couple of alerts that indicate successful RDP Brute Force attempts.

Analytics rules related to RDP activity

  • Rare RDP Connections
  • RDP Brute Force Attack
  • RDP Nesting
  • ML Behavior Analytics: Anomalous RDP login detections
  • Multiple authentication failures followed by a success
  • Fusion Alert

Fusion alert – Preview: Possible multistage attack activities detected by Fusion

Microsoft Sentinel uses Fusion, a correlation engine based on scalable machine learning algorithms, to automatically detect multistage attacks by identifying combinations of anomalous behaviors and suspicious activities that are observed at various stages of the kill chain.

Recommended: Webinar Fusion ML Detections | Microsoft Security Community

Fusion is enabled by default in Microsoft Sentinel, as an analytics rule called Advanced multistage attack detection.

Sentinel Incident:

It starts with suspicious authentication activity (PreAttack), following (Initial Access) which confirms the successful brute force attack.

Sentinel Investigation:

Multiple authentication failures followed by a success

Identifies accounts who have failed to logon to the domain multiple times in a row, followed by a successful authentication within a short time frame. Multiple failed attempts followed by a success can be an indication of a brute force attempt

Sentinel Investigation:

Sentinel Alert details:

Defender for Cloud alerts

Enabling the Analytics rule “Create incidents based on Microsoft Defender for Cloud” creates incidents coming from Defender for Cloud in Microsoft Sentinel. The following alerts are created:

  • Suspicious authentication activity
  • Successful brute force attack
  • Successful logon from known brute-force source

Defender for Cloud shows all information that is related to the successful brute force attack. Affected resource, number of successful authentication attempts/ failed authentication attempts to host, and more useful information.

Sentinel Investigation:

Custom Sentinel Analytics

Build-in there are rules available for detecting some of the RDP brute force attempts. When needed it is possible to enable custom Analytics which gives an incident/ alert and create custom mappings.

SecurityEvent
| where EventID == 4625
| project TimeGenerated, EventID, WorkstationName, LogonTypeName, Account, Computer, IpAddress
| extend AccountEntity = Account
| extend IPEntity = IpAddress

Bonus content T-Pot Honeypot

T-Pot Honeypot is a virtual machine with multiple Honeypots created by Deutsche Telekom. It is based on docker images which makes it quite easy to deploy, it combines some technologies, such as docker, ElasticSearch, and others. The honeypot daemons as well as other support components are dockered.

More information: Github.com/telekom-security/tpotce

T-Pot can be used for honeypot data collection which is focussing on more public services. T-Pot launched out of the box a standard set of docker containers.

The following honeypots are available:

The Dashboard section contains a list of pre-built dashboards by the T-Pot team. The >T-Pot dashboard will show us all the data together, in one place, while the other dashboards will show only data from a specific honeypot.

T-Pot runs a short time in my demo environment. Interesting is the amount of data that is available (IP mappings/ ASN/ Passwords).

RDPY: RDPY is a pure Python implementation of the Microsoft RDP (Remote Desktop Protocol) protocol (client and server-side). RDPY is built over the event-driven network engine Twisted. RDPY support standard RDP security layer, RDP over SSL and NLA authentication (through ntlmv2 authentication protocol).

Prevent the RDP brute force attacks

With Microsoft Sentinel you can detect the types of RDP Brute force attacks. It is better to prevent an attack from happening. Based on the data explained in the blog; RDP attacks are still heavily used. Organizations should never put RDP directly on the Internet. There are multiple solutions available for protecting against RDP Brute force attacks. 

Features which can be used;

  • VPN
  • JIT (Just-in-time) access
  • Azure Bastion
  • MFA

RDP configuration should be a high-priority item in all IT environments. The next blog will focus more on the attacks performed by attackers.

Tip: Don’t use the default administrator name or anything including admin.

If you have any questions regarding these topics, feel free to reach out.