SOC169 – Possible IDOR Attack Detected
by
🧠 Summary
This investigation began as a SOC169 – Possible IDOR Attack Detected alert.
The alert was triggered due to consecutive POST requests made to a sensitive endpoint: /get_user_info/.
Log analysis revealed sequential manipulation of the user_id parameter, with successful HTTP 200 responses returned for each request.
The activity originated from a DigitalOcean VPS and is consistent with IDOR (Insecure Direct Object Reference) enumeration behavior.
The activity was confirmed as a True Positive – Web Application Enumeration Attempt.
🚨 Alert Overview
- Event ID: 119
- Rule: SOC169 – Possible IDOR Attack Detected
- Severity: Medium
- Hostname: WebServer1005
- Destination IP: 172.16.17.15
- Source IP: 134.209.118.137
- HTTP Method: POST
- Endpoint:
/get_user_info/ - User-Agent: Mozilla/4.0 (MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
- Trigger Reason: Consecutive requests to the same page
- Device Action: Permitted
🔎 Log Analysis
Raw log review shows multiple POST requests to:
https://172.16.17.15/get_user_info/
With sequential user_id values:
| POST Parameter | HTTP Status | Response Size |
|---|---|---|
| user_id=1 | 200 | 188 |
| user_id=2 | 200 | 253 |
| user_id=3 | 200 | 351 |
| user_id=4 | 200 | 158 |
| user_id=5 | 200 | 267 |
🔍 Key Findings
- Sequential manipulation of
user_id - All responses returned HTTP 200
- Response sizes varied
- No 401 / 403 authorization errors observed
The varying response sizes strongly suggest different user data was returned for each ID.
This behavior is consistent with object enumeration.
🌍 Source IP Investigation
- IP: 134.209.118.137
- ASN: 14061
- ISP: DigitalOcean LLC
- Type: Data Center / Transit
- Country: United States
VirusTotal analysis showed no security vendor detections.
However, cloud-hosted VPS infrastructure is commonly used for automated probing and enumeration attacks.
The IP classification does not indicate a residential or corporate user.
🖥 Endpoint & Host Review
The affected host (WebServer1005) was reviewed for compromise indicators:
- ✅ Processes reviewed – No suspicious activity
- ✅ Browser history reviewed – Clean
- ✅ Command-line history reviewed – Clean
- ✅ No signs of malware execution
- ✅ No related phishing or email campaign indicators found
No evidence of host-level compromise was identified.
The activity appears limited to the web application layer.
🧠 What is IDOR?
Insecure Direct Object Reference (IDOR) occurs when:
- An application exposes internal object identifiers (e.g., user_id)
- Without validating whether the requester is authorized to access them
- Allowing attackers to modify parameters and retrieve unauthorized data
Example:
POST /get_user_info/
user_id=2
If authorization checks are missing, an attacker can enumerate:
user_id=3
user_id=4
user_id=5
And retrieve other users’ information.
🎯 MITRE ATT&CK Mapping
- T1190 – Exploit Public-Facing Application
- T1087 – Account Discovery
📊 Risk Assessment
| Category | Assessment |
|---|---|
| External Source | Yes |
| Enumeration Behavior | Confirmed |
| Successful Access | Likely |
| Data Exposure Risk | High |
| Host Compromise | Not Observed |
| Alert Classification | True Positive |
🛡 Conclusion
The alert represents a web application–level IDOR enumeration attempt.
Sequential manipulation of the user_id parameter combined with successful HTTP 200 responses indicates potential unauthorized access to user records.
Although no host compromise was observed, the behavior demonstrates a likely authorization control weakness in the /get_user_info/ endpoint.
The activity is classified as:
True Positive – IDOR Enumeration Attempt
🔐 Recommendations
- Implement strict authorization checks per user object
- Enforce session validation for user-specific endpoints
- Add rate limiting for repeated object access attempts
- Deploy WAF rules for abnormal parameter enumeration
- Monitor for additional enumeration attempts
tags: