Day 27 : Investigating RDP Brute Force Attack

On day 27, I conducted a high level investigation into SSH brute force attacks onto the Ubuntu server. Today, I will be following the same methodology to conduct a similar high level investigation into brute force RDP attacks onto the exposed windows server.

Performing a High-Level Investigation of a Brute Force Attack

I opened my Elastic GUI and navigated to left menu > Security > Alerts and filtered for MyDFIR-RDP-Brute-Force-Attempt-DanialAli03.

Just like day 26, I will pay attention to the following things in this investigation:

• What is the source IP of the attacker?
• Is this IP known to perform such attacks?
• Did it affect any other users?
• Were the attacks successful?
• If yes, what did the attacker do after gaining access?

I expanded the first entry and began my investigation for it.

The source IP for this alert is 124.29.215.64. I opened abuseipdb.com and looked up this IP:

It is clear that this is a malicious IP that has been reported 74 times for brute force attack and port-scanning. I also checked greynoise.io for the same:

Even though greynoise doesn't know the intent of this IP, it suggests that this IP is scanning the internet. So that answers the 2nd question-

Is this IP known to perform such attacks? Yes.

Next, I opened Elasticsearch and looked at the associated usernames with this IP addresses by searching for it and clicking on the user.name field on the left.

It looks like this IP address specifically tried to brute force for only the Administrator account. So, did this IP affect any other users? No.

Next, I checked if this IP ever succeeded in it's brute force attempts. I used event.code: 4624 since it corresponds to successful RDP logins.

So, were the attacks successful? No. And consequently, no steps were taken post successful attack.

Performing a High-Level Investigation of My Own Simulated Brute Force Attack from Day 21

The source IP for this attack was 103.69.14.143. I opened abuseipdb.com and looked up this IP:

This IP seems to be rather harmless, and has once been reported for spam. I also checked greynoise.io for the same:

Greynoise has not observed this IP scanning the open internet. So that answers the 2nd question-

Is this IP known to perform such attacks? No.

But that raises a different suspicion because this could suggest that this attack was specifically aimed at our exposed Windows server(which is true since we directed or simulated brute force attack specifically at this machine).

Next, I opened Elasticsearch and looked at the associated usernames with this IP addresses by searching for it and clicking on the user.name field on the left.

It looks like this IP address specifically tried to brute force for only the Administrator account. So, did this IP affect any other users? No.

Next, I checked if this IP ever succeeded in it's brute force attempts. I used event.code: 4624 since it corresponds to successful RDP logins.

So, were the attacks successful? Yes.

The next step is to figure out what happened after the attack was successful and access was gained.

• timestamp: Sep 22, 2024 @ 21:49:22.949 UTC

Next, I copied different values of winlog.event_data.SubjectLogonId from the displayed matching events to find meaningful information using the following query structure:

103.69.14.143 and event.code: 4624 and host.name: "mydfir-win-danialali03" and user.name: Administrator and LOGON_ID        

I concluded that the successful attack happened on Sep 22, 2024 @ 21:49:22.949 UTC.

On Day 28, I will be going further into the investigation and investigate the Mythic Agent itself and how it was used in the attack.

Updating Alert Actions

Previously, we had defined rules and alerts without specifying any action to be taken once an alert is triggered. Now, it's time to link these alerts with the ticketing system so that the triggering of any alert automatically generates a ticket in osTicket.

To do this, I navigated to left menu > Security > Rules > Detection rules (SIEM) > MyDFIR-SSH-Brute-Force-Attempt-DanialAli03 and clicked on Edit rule settings.

On the next screen, under the Actions tab, I selected Webhook.

In the webhook settings, I set the Action frequency to For each alert - Per rule run and for the body of the webhook, I used the following:

<?xml version="1.0" encoding="UTF-8"?>
<ticket alert="true" autorespond="true" source="API">
    <name>Elastic</name>
    <email>[email protected]</email>
    <subject>{{rule.name}}</subject>
    <phone>318-555-8634X123</phone>
    <message type="text/plain"><![CDATA[Please investigate rule : {{rule.name}}
    Link: {{rule.url}}]]></message>
</ticket>        

Where {{rule.name}} and {{rule.url}} are variables. I then saved the rule.

This rule will also generate alerts in osTicket from now on.

Conclusion

With invaluable guidance from Mr. Stevens at MYDFIR (his website) and his YT video outlining Day 27 of the 30-Day SOC Challenge, I successfully investigated an SSH brute force attack and linked Kibana rules and alerts with osTicket.