Category: LetsDefend

Intro

This alert highlights the exploitation of CVE-2024049138, a Windows privilege escalation vulnerability.

Alert Details

What is svchost.exe?

svchost.exe is a system process in Windows that hosts and manages various Windows services. Its functions is to group related services together within a single process, which helps conserve system resources. Cybercriminals frequently exploit this service by naming malicious files and processes something similar like svohost.exe.

After taking ownership of the alert and assigning it to ourselves we can start the playbook!

For play 1 we need to select the Threat Indicator.

I selected “Unknown or unexpected outgoing internet traffic”.

For play 2 we need to check if the malware is quarantined/cleaned.

We can check Log Management and Endpoint Security.

First lets look at our Log Management. Lets use the IP address of 172.16.17.207 from the alert in our search.

We know the alert was generated at Jan 22, 2025, 02:37 AM so lets look for any indicators for around that time.

All logs with the filter show a date and time of Jan, 22, 2025, 02:35 PM. I notice that an IP address of 185.107.56.141, which is a public IP outside of our network, is connecting or attempting to connect to our endpoint through 3389. Which is a port used for RDP, remote desktop protocol.

Lets look into the log details.

We see an unsuccessful logon with from guest and then a successful logon from Victor.

We also see that the logon type was 10, which indicates a user logged onto a computer remotely using Terminal Services, Remote Desktop, or Remote Assistance.

Lets now go look at the endpoint logs from Victors machine.

We have different logs we can analyze, Processes, Network Action, Terminal History, Browser History. I know that the process in the alert was svohost.exe so I will start by looking at the Processes tab. Based off the alert I have good idea of what I should be looking for, which is a PowerShell running from svohost.exe.

I found two events that raise suspicion.

Analyzing the event details shows good information:

• Process User is NT AUTHORITY\SYSTEM which has the highest level of permissions.
• Parent Process is svohost.exe which mimics svchost.exe
• svohost.exe lives in the temp directory which is suspicious
• svohost.exe launched PowerShell and ran the whoami command which allows attackers to quickly see if privilege’s have been escalated

We can also check the terminal history.

Based off the logs here it looks like the attacker checks who they are and what privileges they have before downloading the malware. Then after they download the malware they check again to confirm their privilege escalation.

This gives me enough confidence to say the malware is not quarantined/cleaned.

For play 3 we need to analyze the malware using 3rd party tools and assess if it malicious or not.

We have the file hash from the alert. We can navigate to VirusTotal to gather information about the malware.

Based off the VirusTotal report we know this is malicious.

For play 4 we need to check is someone made a request to the C2 server.

We analyzed this earlier when we saw an unknown IP (C2) attempting and successfully logging into our victim machine via RDP on port 3389.

So the answer is Accessed.

For play 5 we need to contain the device!

We can navigate to Victor’s device in the Endpoint Security tab and turn on containment.

Next we can add artifacts before closing out the alert.

I added the C2 Server, Malware hash, and suspicious URL command.

Analyst Notes:

And close the alert!

Thanks for reading!

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.