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]
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
nmap -Pn -oA RDP-PortScan -iL target.txt -p 3389
xsltproc RDP-PortScan.xml -o RDP-PortScan.html
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
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 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 (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:
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.
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).