I recently tried to figure out how to detect a RDP Bruteforece attack on Windows Server 2012. In this first part, we will focus on the Windows Server machine logs, and how to integrate them with Azure Sentinel. The second part will be focused on detecting uncommon behaviors.
Let’s get into it by first identifying the data we need to gather. The attack we want to detect is a bruteforce attack, so we need to know what account is targeted by the attack.
We also need the computer name which may be usefull when analysts are dealing with multiple machines. Finally, we need remote IP address to identify the attacker IP (or at least the IP they used for the bruteforce attack). Our final goal is to create the following detection rule :
Create an incident when a successfull authentication from an IP xxx.xxx.xxx.xxx occurs and when the same IP xxx.xxx.xxx.xxx has been previously involved in multiple failed authentication.According to this rule, we first have to gather successfull authentication events. Then, we will need to detect multiple failed authentications from this same IP.
Limits : This rule as it is does not cover the case where the attacker uses a botnet i.e. hundreds or thousands of different IPs. Also, depending on their characteristics, password spreading attacks may not be covered since they involve different user accounts. I might get into these cases in future posts.
Windows Server 2012 Logs
Step 1 — Find successfull authentication logs
Let’s open the Windows Event Viewer. We can see in Microsoft-Windows-Security-Auditing channel successfull authentication events (Event ID 4624). We observe that the IP address, the targeted account and the computer name are recorded. This is what we want.
It is important to note that failed authentication events (Event ID 4625) record IP addresses for non existing accounts only.
So, if an attacker targets an existing account, their IP will not be recorded (c.f. picture below). This is a weird behavior that prevents us from using this channel to detect failed authentications from the same IP. The workaround is developed in Step 2.
Note: there is a way to enable the IP recording for failed authentication on existing accounts, but since it weakens the security posture, it is not presented here. More details in this complete article.
Step 2— Find failed authentication logs
According to what we just found, we still need to collect data for failed authentication. We look for the Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational channel. This channel logs failed authentication events (Event ID 140), and records the IP address and the computer name, as shown on the following picture. Perfect!
You may have noticed that the account name is not recorded, but this is not mandatory since we only need to know that a specific IP sends many connection requests, and that one of these requests is successfull.
Let’s summarize what we have :
- From the channel Microsoft-Windows-Security-Auditing, we can retrieve the targeted account, the computer name and the source IP addresses of successfull authentications.
- From the channel Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational, we can retrieve the IP addresses for all failed RDP authentications.
Now, we must cross the data of the two channels to match the IP addresses. We will do this with KQL in the next section.
Azure Sentinel
Import logs into Log Analytics
The process is simple and has been described by Olaf Hartong in this article.
- TheMicrosoft-Windows-Security-Auditing channel is streamed by default to our log analytics thanks to the Azure Sentinel VM connector. Thus, we don’t need to configure anything for this.
- However, the Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational channel is not streamed by default. To add it, go to the avanced settings of the Log Analytics workspace associated to Azure Sentinel, and copy paste the channel name as shown on the picture below.
Changes should apply after 5 to 10 minutes.
Build the Kusto Query Language (KQL) request
First of all, we need to parse the logs received from the Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational because as you can see on the picture below, data is not presented as we could expect.
In order to parse these data, use the parser proposed on my Azure Sentinel github fork. I saved this parser as RDPAuth. The image below shows the output using the parser. There are many empty colums that are filled according to the event concerned (e.g. the IP column is empty if the event is related to internal errors).
What next ?
This is the end of this first part. We looked into Windows Server 2012 logs to find data that will help us detect bruteforce attacks on RDP. We imported and parsed these data in order to analyse them with KQL.
In the next part, we will take a closer look at the detection rule we can set up to detect brute force attacks.
