SOC176 – RDP Brute Force Detected

In this blog post, I’ll walk you through a hands-on exercise from the LetsDefend platform, where you step into the shoes of a SOC analyst. You’ll assign and open an alert, analyze it, respond using predefined playbooks, and determine whether the alert is a true positive or a false alarm. Finally, you’ll close the alert once the investigation is complete. This platform is an excellent resource for learning how to effectively respond to a variety of security incidents. For this specific alert, I’ll be investigating and analyzing a Remote Desktop Protocol (RDP) brute-force attack.

On the practice page we have different tools that we can utilize to help us investigate the alert.

Here is the alert we received:

SOC176 – RDP Brute Force Detected

Field	Details
EventID	234
Event Time	Mar 07, 2024, 11:44 AM
Rule	SOC176 – RDP Brute Force Detected
Level	Security Analyst
Source IP Address	218.92.0.56
Destination IP Address	172.16.17.148
Destination Hostname	Matthew
Protocol	RDP
Firewall Action	Allowed
Alert Trigger Reason	Login failure from a single source with different non-existing accounts

We take ownership of the alert and the assign it to our self. This allows us to view the playbook.

The first step is to gather some context and determine if this source IP is from an external source.

Looking at the alert we are given it is easy to tell this is going to be external. The Source IP is 218.92.0.56 which is in the public IP range. Our endpoint IP is 172.16.17.148 which is a private IP range. We click external and move to second play in the playbook.

Based off VirusTotal this IP is malicious. We click yes and move on.

We search for the IP in Log Management and find multiple failed logon attempts to the target RDP port (3389). The attacker also tried using different account usernames:

-sysadmin

-Matthew

-guest

-admin

The attacker is seen using what appears to be a password spraying technique, a type of brute force attack. We click yes and move on.

Play 4 ask us if the IP address tried to connect to multiple devices on our network.
To check this we can look in our Log Management tab which acts as a SIEM. We can create a filter where the source IP = 218.92.0.56 and Destination = 3389.

We can analyze the logs and determine if the attacker targeted any other endpoints.

From our analysis I determined that the attacker only targeted 172.16.17.148.

For play #5 we need to figure out if the attack was successful. We know our endpoint is a windows 10 machine. So we will check for Event ID 4624 using Log Management.

In our Log Management tab I used filters and found one entry where the attacker IP was used for a successful RDP into Matthews machine.

Play #6 ask if the device should be isolate. Yes, the device should be isolated.

Play #7 wants us to contain the device. We can do so in the Endpoint Security tab which acts as our EDR solution to isolate the device.

Play #8 Lessons Learned.

How did the cyber attack happen?

• An attacker successfully brute forced Matthew’s account, likely due to a weak password.

What would the staff and management do differently the next time a similar incident occurs?

• Tune rules to block this type of attack from happening, such as looking at geolocation anomalies.

What corrective actions can prevent similar incidents in the future?

• Block RDP connections from outside the internal network in the firewall and whitelist trusted IP addresses from outside the network. Also, implement an password attempt policy.

What precursors or indicators should be watched for in the future to detect similar incidents?

• Watch for IP address attempting to log in using multiple different usernames, high volumes of failed logins from the same IP, or login attempts to disabled accounts.