← Back to list

Investigate RDP Brute Force Attack

Based on the tutorial by MyDFIR — Soc Analyst Challenge Day 27 Objective: Learn how to investigate a RDP brute force alert

M Haq · 2024-10-03 13:27 · 0 claps · 2.5 min read
#soc-analyst #cybersecurity #kibana #elasticsearch #mydfir
Open on Medium ↗
Wiki topics: 🔒 · Cybersecurity

Investigate RDP Brute Force Attack

*Based on the tutorial by MyDFIRSoc Analyst Challenge Day 27 *Objective: Learn how to investigate a RDP brute force alert

On Elastic → Alerts (under Security) →Filter for RD brute force alert

On Elastic → Alerts (under Security) →Filter for RD brute force alert

Expand one of the alerts to investigate

Expand one of the alerts to investigate

Basic elements to look for when investigating a Brute force attack:

  1. IP — Is this IP known to perform brute force activity?
  2. Were there any other user affected by this IP?
  3. Were any of them successful?
  4. If so, what activity happened after successful log in?
  5. IP — Is this IP known to perform brute force activity? [IPaddress: 91.238.181.8, Target: Administrator]

Known IPaddress for RDP attacks

Known IPaddress for RDP attacks

Do not register as malicious

Do not register as malicious

Conclusion: Yes. This is a known IP address reported for RDP brute force attacks on AbuseIPDB. Although only 26% abuse confidence.

2. Were there any other user affected by this IP?

On Kibana, search for the IPaddress → Filter for user.name

On Kibana, search for the IPaddress → Filter for user.name

Conclusion: No. Only the Adminstrator user was affected

3. Were any of them successful?

Conclusion: Searching the logs for event.code:4624 does not result any ‘Successful’ log ins. Since none of the attempts are successful, 4. looking for activities after a successful log in irrelevant Take action → Mark as closed

Modifying the Elastic rules to push alerts into osTicket

Rules → Detection rules (SIEM) → RDP Brute Force Attempt rule

Rules → Detection rules (SIEM) → RDP Brute Force Attempt rule

→ Edit rule settings

→ Edit rule settings

→Actions → Select Webhook

→Actions → Select Webhook

Body → Same configuartion as SSH brute force alert

Body → Same configuartion as SSH brute force alert

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

→ Save Changes

RDP Brute force alerts are now pushed on to osTicket from Elastic

This concludes investigating RDP brute force alert This guide follows the Youtube video created by MyDFIR, part 27 of a series of videos to help gain practical skills for beginner SOC analysts. The specific video is linked below:

[embed]


메타데이터
post_id
dddd7f4d5048
slug
investigate-rdp-brute-force-attack-dddd7f4d5048
url
https://medium.com/@haq.prg/investigate-rdp-brute-force-attack-dddd7f4d5048
canonical_url
https://medium.com/@haq.prg/investigate-rdp-brute-force-attack-dddd7f4d5048
author_url
https://medium.com/@haq.prg
status
ok
fetched_at
2026-07-22 15:40:29