EventID : 119 Event Time : Feb, 28, 2022, 10:48 PM Rule : SOC169 — Possible IDOR Attack Detected Level : Security Analyst Hostname : WebServer1005 Destination IP Address : 172.16.17.15 Source IP Address : 134.209.118.137 HTTP Request Method : POST Requested URL : hxxps://172(.)16.17.15/get_user_info/ User-Agent : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Alert Trigger Reason : consecutive requests to the same page Device Action : Allowed Show Hint

A) My Analysis:

SOC Action in Log Management tab:

1. Verified the IP history; all five connections were allowed, confirming the 'Allowed' status.

Log Example:

Request URL: hxxps://172(.)16.17.15/get_user_info/

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)

Request Method: POST

Device Action: Permitted

HTTP Response Size:: 253

HTTP Response Status: 200

POST Parameters: ?user_id=

2. Unfortunately, I cannot confirm who the user is in the Endpoint Security tab.

3. IP OSINT :

Abuseipdb:

https://www.abuseipdb.com/check/134.209.118.137 —

Last reporting:

silvelo2025–12–15 14:26:20 (3 days ago)

SSH-Attack

Virus Total:

https://www.virustotal.com/gui/ip-address/134.209.118.137/detection Clean IP — some info in the comments

Tried login SSH to Threats6.poisoneye.info

Detected South KOREA TimeStemp : Tue Mar 15 08:19:53 KST 2022 (UTC : Mon Mar 14 23:19:53 UTC 2022)

IP Address : 134.209.118.137 Country : US Login SSH ID : root

SSH Connection Log : pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=134.209.118.137 user=root

Twitter : @Pois0nEy3

Next step — Google search — The 'get_user_info' IDOR attack was confirmed in the article.

https://lipsonthomas.com/insecure-direct-object-reference-idor/

Conclusion :

Classification: True Positive Attack Type: IDOR (Insecure Direct Object Reference) Malicious: Yes (external IP from DigitalOcean, no indication of authorized pentest).

Attack was successful -Yes

Tier Escalation -Yes.

B) Grok Analysis :

Alert Analysis: SOC169 — Possible IDOR Attack Detected (EventID 119)This alert originates from a simulated SOC training environment on LetsDefend.io, a hands-on blue team platform designed for practicing incident response and alert investigation. The details you provided match exactly with a specific training challenge (Alert #119) focused on detecting and investigating Insecure Direct Object Reference (IDOR) vulnerabilities.Key Alert Details Breakdown

• Event Time: February 28, 2022, 10:48 PM
• Rule Triggered: SOC169 — Possible IDOR Attack Detected (triggered by consecutive requests to the same endpoint)
• Hostname: WebServer1005 (internal web server)
• Destination IP: 172.16.17.15 (private RFC1918 address — internal server)
• Source IP: 134.209.118.137 (external attacker IP, hosted on DigitalOcean cloud infrastructure, likely a VPS in a region such as Frankfurt or Singapore based on similar ranges)
• HTTP Method: POST
• Requested URL: /get_user_info/ (a common endpoint pattern vulnerable to IDOR if it accepts parameters like user_id without proper authorization checks)
• User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) — An outdated and suspicious UA string often used in automated scans or exploits to mimic old Windows/.NET clients
• Device Action: Allowed (traffic not blocked — common in detection-only setups)

What is an IDOR Attack?Insecure Direct Object Reference (IDOR) occurs when a web application exposes internal object references (e.g., user IDs, file IDs) in parameters without sufficient authorization checks. Attackers can manipulate these (e.g., changing user_id=123 to user_id=124) to access unauthorized data.In this scenario:

• The attacker sent repeated POST requests to /get_user_info/.
• Logs (in the training platform) show enumeration attempts, e.g., varying user_id parameters (like ?user_id=1, ?user_id=2, etc.).
• Successful responses (HTTP 200 with data) indicate the endpoint leaked user information without proper access controls.

This is classified as a true positive malicious attempt exploiting a public-facing web application (MITRE Technique: T1190 — Exploit Public-Facing Application).Investigation Insights from Similar Cases

• The source IP (134(.)209.118.137) belongs to DigitalOcean, a common hosting provider for scanners, bots, or low-cost attack infrastructure.
• Consecutive identical or similar requests suggest automated brute-force/enumeration (e.g., trying sequential user IDs).
• No post-exploitation activity (e.g., no malicious processes on the endpoint) was observed in the simulation.

Recommended Response (in a Real or Simulated SOC)

1. Confirm via Logs: Review web server logs for parameter manipulation (e.g., varying user_id values) and successful data returns.
2. Threat Intel Check: Query platforms like AbuseIPDB, VirusTotal, or AlienVault OTX for the source IP — similar DigitalOcean IPs often have abuse reports for scanning.
3. Containment: Block the source IP at the firewall/WAF; isolate the affected server if needed.
4. Remediation: Fix the IDOR vulnerability (implement proper authz checks, use indirect references like UUIDs).
5. Mark as Malicious: In LetsDefend, this alert is confirmed malicious — no false positive.

If you're working through this on LetsDefend.io, head to Log Management and Endpoint Security sections to view the supporting HTTP logs and confirm the enumeration.Let me know if you have more details from the platform (e.g., logs) or need help with similar alerts!