Azure Sentinel ‘Brute Force RDP Attack’

This blogpost is about a real-world use case where we will explain almost all Azure Sentinel functions. Because we want this blog to have real-world data for every reader to reproduce, we start with the setup of our honeypot (a honeypot is a system intended to mimic a target of cyberattacks to detect unauthorized access) system.

Honeypot setup

We install a virtual machine (Windows in this example but this could also be Linux for SSH brute force attacks) in Azure IaaS (Infrastructure as a Service), in the section Networking we add an ‘Inbound port rule’ with Destination port 3389 allowed.

We can use NMAP (Network Mapper) to verify if the port is accessible from the internet.

The ‘-Pn’ parameter (no Ping) is required to access Azure IaaS Virtual Machines (host enumeration disabled)

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 for open ports which are only protected via a username and password.

Shodan is an internet port scanner which show more than 4M ports open on the internet with the Netherlands on #5 (see figure above). Because of the automated attack framework, malicious RDP connections will come in, this can be verified in the Windows Event Viewer (Event ID 4625 – An account failed to logon). If you cannot wait, an option is to logon via a Remote Desktop session or use Kali Linux to simulate a brute force attack via Hydra.

Capital L and P can be used for the use of wordlists.

Use a ‘non-existing’ username and/or password else we get an Event ID 4624 (An account was successfully logged on), this can be used for another use case but for now our focus is ‘brute force RDP attacks’.

Azure Sentinel functions setup

This document assumes Azure Sentinel is up-and-running (Azure Log Analytics workspace is available) and will describe the required steps we need to proceed.

The first step is to connect to required Data connector.

If the virtual machine is installed in the same Azure Log Analytics workspace, log data is available, and the connector will get the status  connected. If the virtual machine is installed in another log analytics workspace, add a 2^nd log analytics workspace via the Microsoft Monitoring Agent – Azure Log Analytics (OMS) tab in the Control Panel.

The Workspace ID and Workspace Key can be found in the Security Events Data Connector page.

Log analytics

The second step is to create an Incident rule (use case), personally I always create and fine-tune a rule via the Logs section and verify the attributes we want to use for entities. Entities are required for investigation and dashboards for example.

• Select Analytics
• Create – Scheduled query rule

When the rule is created, we wait for the first incident to appear in the Overview or Incidents page.

Investigation

After we receive an incident, we can select the incident to see the incident details (this is a SecOps task). An option is to select the investigate button to get a graphical overview of the incident for triage.

Hunting

While the Incident rule(s) are reactive, we can also do pro-active hunting via the Hunting feature. Hunting is the same KQL query format as the Incident rule(s).

A new feature is Livestream where we can see in real-time the output of the query (we can look over the shoulder of the bad actor in real-time). An incident response team first wants to get the whole picture (root cause analysis) of the breach before stopping the bad actor.

Workbook

The last feature I want to discuss are Workbooks. A workbook is a dashboard (I hear you say: oh no not another dashboard), but the workbook feature can help with mitigation. As an example, I created a workbook for the RDP Brute Force attack.

With the entity Account we know the username used by the attackers to try to logon (we can also use the IP but for now we use the username for the Workbook). The KQL query used is:

If we look at the workbook, we see that the username Administrator (in different formats like capitals and/or with the domain option via ‘.\’ which is used often for the local machine domain. By default you cannot use the username Administrator (or Admin) in Azure, this is why.

Advise: rename the default Active Directory Administrator account to a different name. As we all know we should never user the ‘break-glass’ account, but use named accounts for traceability. we can monitor its usage via Event ID 4624 (or via Azure ATP – Honeytoken) and an Azure Sentinel Incident rule to get an alert if the account is used successfully.

Mitigation

Although Azure Sentinel can detect different types of attacks, it is always better to prevent an attack from happening. In this example our advice is to use Azure Security Center – JIT (Just-in-time) access. This feature disables the remote access port(s). An admin can enable the port via MFA verification and the port is set to open for a pre-defined amount of time (e.g. an hour) and only accessible from the Source IP-address of the Admin.

Summary

As you have seen in this short introduction to Azure Sentinel with a real-world use case, how easy it is to setup Azure Sentinel and create incident rules and workbooks. Mitigation via playbooks are also easy to setup (e.g. block account or create a message in Microsoft Teams). The real power of Azure Sentinel is to connect the Microsoft ATP (Advanced Threat Protection) and other Security products but also non-Microsoft Security products can be connected (e.g. direct like AWS or via a Syslog server).If you want to know more about Azure Sentinel or Microsoft Security in general, please contact the InSpark Security team.