The most frequent attack that we often see is an attack on RDP/SSH management port (the brute force attack), and Microsoft provides you with the capability to detect these attempts. Additionally, you don’t need to have these ports open even for legitimate administrative purposes, with Azure Security Center and Azure Sentinel you can detect a brute force attack attempt.
This article will show you how to leverage Azure Sentinel to detect a brute force attack on your servers whether they are running on Azure or hybrid (on-premises and multi-cloud).
A while ago, I blogged about how to automate Just In Time VM Access request with PowerShell. Just-in-Time VM Access is one of many features that is included in Azure Security Center which is something you should consider for your Azure virtual machines which are publicly facing. You can specify rules for how users can connect to virtual machines. When needed, access can be requested from Security Center or via PowerShell. As long as the request complies with the rules, access is automatically granted for the requested time only and then it’s removed.
Azure Sentinel is a cloud-native Security Information Event Management (SIEM) and Security Orchestration Automated Response (SOAR) solution. Azure Sentinel delivers intelligent security analytics and threat intelligence across the enterprise, providing a single solution for alert detection, threat visibility, proactive hunting, and threat response.
Nowadays with COVID-19, with more employees working from home more often, threat actors are taking advantage of the increase of management ports open, which includes RDP and SSH.
An RDP or SSH brute force attack can compromise users with weak passwords and without Multi-factor Authentication (MFA) enabled. In a brute force attack, the perpetrator attempts to gain unauthorized access to a single account by guessing the password repeatedly in a very short period of time. When a server is compromised via brute force, this is just the initial foothold (known as initial access based on MITRE ATT&CK® tactics). Once the threat actors gain access to the target machine, they will continue conducting malicious activities, including data exfiltration and even ransomware attacks.
To follow this article, you need to have the following:
- Azure subscription – If you don’t have an Azure subscription, you can create a free one here.
- Log Analytics workspace – To create a new workspace, follow the instructions here Create a Log Analytics workspace.
- Azure Sentinel – To enable Azure Sentinel at no additional cost on an Azure Monitor Log Analytics workspace for the first 31-days, follow the instructions here. Once Azure Sentinel is enabled on your Azure Monitor Log Analytics workspace, every GB of data ingested into the workspace can be retained at no charge for the first 90-days.
- Configure the Security Events data connector in Azure Sentinel to collect security events (more on this in the next section).
- Windows Server, Linux, or Windows 10 client machines deployed in Azure, on-premises, or in other clouds (known as non-Azure machines) with the Log Analytics agent installed, or the new Microsoft Monitoring Agent (MMA) for Windows or Linux servers.
Collect Security Events
For the remainder of this article, I will be collecting Windows Security Events. If you want to collect and configure Syslog events for your Linux machines, please check the following article.
To collect Windows security events, take the following steps:
From the Azure Sentinel navigation menu, select Data connectors. From the list of connectors, click on Security Events, and then on the Open connector page button on the lower right as shown in the figure below.
Verify that you have the appropriate workspace (read and write) permissions as described under the Prerequisites section on the connector page as shown in the figure below.
Next, you need to download and install the Log Analytics agent, also known as the Microsoft Monitoring Agent (MMA) on the machines for which you want to stream security events into Azure Sentinel. As mentioned previously, you can install the MMA on Azure virtual machines or non-Azure Windows machines (physical, virtual on-premises, or virtual in another cloud provider).
For the purpose of this example, I will be using Azure Windows virtual machines. Under the Configuration section, click on Install agent on Azure Windows Virtual Machine, and then click on the link that appears below: Download & install agent for Azure Windows Virtual machines > as shown in the figure below.
For each virtual machine that you want to connect, click on its name in the list that appears on the right-hand side as shown in the figure below.
And then click Connect as shown in the figure below. The connection might take 5 minutes to complete. When the machine shows “Connected” in the Azure Portal, you will see the Microsoft Monitoring Agent (MMA) service running on the machine which will upload the logs to the Azure Sentinel workspace for your subscription.
Next, you need to select which events to stream:
- All events – All Windows security and AppLocker events.
- Common – A standard set of events for auditing purposes.
- Minimal – A small set of events that might indicate potential threats. By enabling this option, you won’t be able to have a full audit trail.
- None – No security or AppLocker events.
For the purpose of this example, the ‘Common‘ standard set of events for auditing purposes was selected. Please note that after you click update, it may take around 20 minutes until your logs start to appear in the Log Analytics workspace.
Please note that if the Security Events tier configuration is shared with Azure Defender and was already configured there for this workspace. Then you need to change the event set in Azure Defender (Azure Security Center) and it will apply for Azure Sentinel as well. Note that Security events will be collected once and used in both security solutions.
If you navigate to the Log Analytics Workspace where Azure Sentinel is onboarded, you will see the Microsoft Windows security auditing with Error, Warning, and Information logs selected under Settings | Agents configuration | Windows event logs tab.
Azure Sentinel Side
Now that we know we have all the capabilities for collecting Windows security event logs, we can monitor, track and detect suspicious activities and many other Azure Sentinel actions.
Azure Sentinel can provide so many ways to identify RDP/SSH attacks, so let’s create a custom analytic rule with a KQL query.
Create an analytic rule for brute force attack
Open Azure Portal and sign in with a user who has Azure Sentinel Contributor permissions.
Click All services found in the upper left-hand corner. In the list of resources, type Azure Sentinel. As you begin typing, the list filters based on your input.
Click on Azure Sentinel and then select the desired Workspace.
From Azure Sentinel’s sidebar, select Analytics under the Configuration section, then click + Create and select Schedule query rule as shown in the figure below.
Give the analytic rule a meaningful ‘Name‘ and ‘Description‘, then select the following 2 ‘Tactics‘ (Initial Access and Credential Access). Those tactics are based on the MITRE ATT&CK Matrix for Enterprise. Then select ‘Medium‘ for the Severity and then click Next to Set rule logic.
On the Set rule logic page under the Rule query, enter the following KQL syntax to query the security events based on the EventID (4625) which applies to Windows 10 and Windows Server. EventID (4625) audit the account which failed to log on. This KQL is based on the Security Event table.
SecurityEvent | where EventID == 4625 | project TimeGenerated, EventID, WorkstationName, Computer, Account, LogonTypeName, IpAddress | extend AccountEntity = Account | extend IPEntity = IpAddress
You could also add the EventID (4624) that audit the account which was successfully logged on. If you add EventID (4624), you might receive a lot of ‘SYSTEM‘ account new login alerts as Logon Type: 5, which indicates a service was started by the Service Control Manager, so you need to tune your KQL query accordingly. However, by adding the EventID (4624) along with the EventID (4625), you could correlate if the failed log on account was successfully logged on afterward by looking at the Logon Type: 3 for the same account.
Additionally, Security Event ID (4625) can provide useful information, and any Brute force attack contains a lot of failed logins. To identify how many records with Logon Type, SubStatus, and account were part of this attack, you can run the following query:
SecurityEvent | where EventID == 4625 // 0xC0000064 = User logon with misspelled or bad user account // 0xC000006A = User logon with misspelled or bad password | where (SubStatus == "0xc000006A" or SubStatus == "0xc0000064") | project TimeGenerated, EventID, WorkstationName, Computer, Account, LogonTypeName, LogonType, LogonProcessName, SubStatus, Activity
Please make sure to map the entities (Account, IP Address, and Host) as shown in the figure below, as well as the new ‘Custom‘ entity details to enrich the alert for further investigation. I will schedule this query to run every 5 minutes and lookup data from the last 30 minutes. I will not change any other settings in this tab. Click Next to configure the Incident settings.
On the Incident settings page, I will enable Alert grouping to group the alerts into a single incident if all the entities match (recommended), and limit the group to alerts created within 1 day as shown in the figure below. Click Next to configure the Automated response.
On the Automated response page, I will select the automated playbook that I created earlier to post a message in the Microsoft Teams Channel to inform the SOC team members about this brute force attack. Click Next to review and create.
In the Review and create the page, validate the settings and click Create to start the rule creation process.
Simulate Remote Desktop Protocol (RDP) attack
Remote Desktop Protocol (RDP) is a protocol for remote access to Windows systems (SSH is used with Linux). Attackers use automated systems to scan the internet with (Nmap tool for example) for open ports which are only protected via a username and password.
To simulate an RDP attack, there are multiple different options you can choose from. The simplest option is to log on via a Remote Desktop session with a non-existing username and/or password or use Kali Linux to simulate a brute force attack via Hydra.
hydra -l <username> -p <password> <IP Address of the server or client> rdp # You could also use with capital -L and capital -P for a user list and password list.
If you logged on with an existing username and/or password, you will get EventID (4624) as noted in the previous section.
Once you simulate a brute force attack, you need to wait for the incident to appear in the Overview or Incidents page as shown in the figure below which might take up to 5 or 10 minutes to appear.
Once an incident is created, you can view more details of the incident by clicking on the View full details button, then navigate to the investigation page. You can investigate all entities for this alert such as IP addresses, accounts, and so on.
Let’s see if I have received any message on the Microsoft Team channel. After waiting for a couple of minutes, a message popped up in my team channel as shown in the below screenshot.
This means the incident using the new automation rules ran the Logic App playbook automatically, and the SOC team received this message. Please note that this is only one automation scenario I showed you on how to respond to security threats by posting a message on Microsoft Teams, you could also automatically send an email, block the IP address using Network Security Group (NSG), disable the user account if it exists, or isolate the machine from the Internet, change the RDP port, etc…
While the Incident rule(s) are reactive, we can also do proactive hunting via the Hunting (live stream) feature as described in this article. Hunting is using the same KQL query format as the Incident rule(s). Livestream is where you can see in real-time the output of the query, so you can look over the shoulder of the bad actor in real-time.
That’s it there you have it. Happy Azure Sentinel detection!
In this article, I showed you how to detect a brute force RDP attack on your servers by creating an analytic rule query in Azure Sentinel that will trigger an alert before your machines get compromised. The incident will automatically trigger a security playbook to inform the organization’s Security Operation Center (SOC) team of this brute force attack attempt.
Additional resources I highly encourage you to check:
- Learn more about Azure Sentinel, check the official documentation from Microsoft.
- Learn more about how to change Remote Desktop (RDP) Port with PowerShell.
- Learn how to connect Azure Security Center to Azure Sentinel.
- Learn about Analytics Rules, check the official documentation from Microsoft.
- Learn about Playbooks, check the Azure Sentinel’s GitHub page contributed by the community and Microsoft.
The power of Azure Sentinel comes from the ability to detect, investigate, respond to, and remediate threats.
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.