Todas las investigacionesAll investigations
SOC169 · #119Web Attack · IDORWeb Attack · IDOR

Explotación exitosa de vulnerabilidad IDOR sobre WebServer1005Successful IDOR Vulnerability Exploitation on WebServer1005

Un actor externo desde una IP de DigitalOcean reportada en CTI enumera manualmente el parámetro user_id (1 al 5) mediante peticiones HTTP POST en /get_user_info/. A diferencia de un sondeo fallido, todas las respuestas devuelven HTTP 200 OK con tamaños distintos (158 a 351 B), confirmando exfiltración de datos de usuarios. Se contiene WebServer1005 y se escala a Tier 2.

An external actor operating from a CTI-flagged DigitalOcean IP manually enumerated the user_id parameter (1 through 5) via HTTP POST requests to /get_user_info/. All requests returned HTTP 200 OK with distinct payload sizes (158 to 351 B), confirming unauthorized user data exposure. WebServer1005 was contained and the incident was escalated to Tier 2.

Severidad
High
Veredicto
True Positive
Plataforma
LetsDefend
Fecha
19 de oct de 2026
Duración
30 min
Técnicas
03
Severity
High
Verdict
True Positive
Platform
LetsDefend
Date
Oct 19, 2026
Duration
30 min
Techniques
03

Resumen ejecutivo

El 28 de febrero de 2022 se activó la alerta SOC169 — Possible IDOR Attack Detected (Caso #119) tras detectarse múltiples peticiones HTTP POST consecutivas dirigidas al endpoint /get_user_info/ del servidor interno WebServer1005 (172.16.17.15), originadas desde la dirección IP externa 134[.]209[.]118[.]137 (alojada en DigitalOcean, LLC y catalogada como maliciosa por motores de inteligencia de amenazas).

La correlación de los logs HTTP permitió confirmar un Verdadero Positivo (True Positive) con explotación exitosa: el atacante iteró manualmente el parámetro user_id entre los valores 1 y 5, recibiendo en los cinco casos estado HTTP 200 OK con tamaños de respuesta variables (158 a 351 bytes), lo que demuestra la exposición no autorizada de información perteneciente a distintos usuarios. Aun sin observarse ejecución de comandos a nivel de sistema operativo en el EDR, al haberse concretado la fuga de datos se procedió al aislamiento de WebServer1005 y al escalamiento del caso a Tier 2.

Veredicto: True Positive — ataque exitoso (exposición no autorizada de registros vía IDOR). Se aisló WebServer1005 en el EDR y se escaló a Tier 2 para remediación.

Detección inicial y triaje

Campo Valor
ID de Alerta / Regla LetsDefend Alert #119 — SOC169 - Possible IDOR Attack Detected
Fecha del Incidente (Logs) 2022-02-28 (16:45:00 – 16:48:01 SIEM)
Fecha de Investigación 2026-10-19
IP de Origen 134[.]209[.]118[.]137 (AS14061 — DigitalOcean, LLC)
Activo Afectado WebServer1005 (172.16.17.15)
Endpoint / Método POST hxxps://172[.]16[.]17[.]15/get_user_info/?user_id=[1..5]
Acción del Dispositivo Allowed

Hipótesis inicial: Al observar dos primeras peticiones consecutivas (16:45:00 sobre user_id=2 y 16:45:43 sobre user_id=1) provenientes de la misma fuente externa que retornan código 200 OK con longitudes de cuerpo diferentes (253 bytes vs. 188 bytes), se plantea la explotación activa de una vulnerabilidad Insecure Direct Object Reference (IDOR) que expone perfiles de usuarios sin validar permisos de sesión.

Análisis e investigación técnica

Secuencia de peticiones y evidencia de éxito

El análisis de los registros de red sobre 172.16.17.15 reveló una secuencia de 5 peticiones HTTP POST en un intervalo de 3 minutos. En cada solicitud se modificó de forma incremental el parámetro user_id:

POST /get_user_info/?user_id=2 HTTP/1.1   --> 200 OK (253 bytes)
POST /get_user_info/?user_id=1 HTTP/1.1   --> 200 OK (188 bytes)
POST /get_user_info/?user_id=3 HTTP/1.1   --> 200 OK (351 bytes)
POST /get_user_info/?user_id=4 HTTP/1.1   --> 200 OK (158 bytes)
POST /get_user_info/?user_id=5 HTTP/1.1   --> 200 OK (267 bytes)
Host: 172.16.17.15
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Hora URI Solicitada (Defanged) Parámetro Estado HTTP Tamaño Interpretación
16:45:00 hxxps://172[.]16[.]17[.]15/get_user_info/?user_id=2 user_id=2 200 OK 253 B Consulta inicial exitosa
16:45:43 hxxps://172[.]16[.]17[.]15/get_user_info/?user_id=1 user_id=1 200 OK 188 B Prueba de IDOR hacia id=1 exitosa
16:46:14 hxxps://172[.]16[.]17[.]15/get_user_info/?user_id=3 user_id=3 200 OK 351 B Enumeración secuencial (dispara alerta)
16:47:37 hxxps://172[.]16[.]17[.]15/get_user_info/?user_id=4 user_id=4 200 OK 158 B Extracción de cuarto registro
16:48:01 hxxps://172[.]16[.]17[.]15/get_user_info/?user_id=5 user_id=5 200 OK 267 B Extracción de quinto registro

¿Por qué sabemos que el ataque fue exitoso?

  • Código 200 OK + tamaños variables: Si la aplicación hubiera bloqueado el acceso o devuelto un mensaje de error genérico, veríamos códigos 401/403/500 o un tamaño de respuesta idéntico en cada intento. La variación en bytes (253, 188, 351, 158, 267) demuestra que el servidor devolvió efectivamente el contenido de 5 registros de usuario distintos.

Inspección en Endpoint (EDR) y Threat Intelligence (CTI)

  • Telemetría EDR en WebServer1005: Se revisaron los procesos en ejecución, historial de comandos y conexiones de red en WebServer1005 (172.16.17.15), sin registrarse actividad anómala a nivel de sistema operativo. Esto es esperable en un ataque IDOR, ya que la vulnerabilidad reside en la lógica de autorización de la aplicación web y no implica ejecución de código en el host.
  • Inteligencia de Amenazas (CTI): La IP origen 134[.]209[.]118[.]137 pertenece a DigitalOcean, LLC (AS14061) —indicativo del uso de un VPS o VPN— y cuenta con detecciones previas de motores de seguridad (vendor analysis) que la marcan como maliciosa.
  • Huella de User-Agent: El cliente declaró Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) (Internet Explorer 6 sobre Windows XP), un valor obsoleto típico de cabeceras falsificadas o herramientas de prueba HTTP.

Evolución del razonamiento analítico (Autocrítica y lecciones aprendidas)

Documentar cómo evoluciona una hipótesis durante el triaje es clave para afinar el criterio operativo:

  1. Razonamiento inicial: Al observar que las peticiones tenían intervalos irregulares de entre 24 y 83 segundos (enumeración manual, sin escáner automatizado) y que el EDR en WebServer1005 no presentaba ningún proceso malicioso ni movimiento lateral, mi primera inferencia fue considerar que se trataba de un usuario curioso “no malicioso” que había descubierto accidentalmente el parámetro user_id, sin llegar a catalogarlo como una intrusión hostil que requiriera contención.
  2. Revisión y corrección metodológica: Al reevaluar el caso bajo el modelo de respuesta a incidentes, identifiqué dos puntos críticos:
    • Explotación lógica ≠ ejecución en EDR: En vulnerabilidades de control de acceso como IDOR, el objetivo del atacante no es ejecutar un binario en el servidor, sino leer datos ajenos. El hecho de recibir HTTP 200 OK con 5 perfiles distintos significa que el ataque ya tuvo éxito y produjo una brecha de confidencialidad.
    • Origen externo y CTI: El tráfico provino de Internet (134[.]209[.]118[.]137, VPS/VPN en DigitalOcean reportado como malicioso) con un User-Agent anómalo (MSIE 6.0). Aunque el ataque haya sido manual u oportunista (“no planeado” con herramientas masivas), es una acción maliciosa confirmada que exige contener el servidor afectado y escalar a Tier 2.

Contención y recomendaciones

  1. Contención inmediata del activo: Se aisló el servidor WebServer1005 (172.16.17.15) en el EDR para detener la exposición pública del endpoint /get_user_info/ hasta su corrección.
  2. Escalamiento a Tier 2: Se elevó el incidente a Nivel 2 detallando los 5 identificadores comprometidos (user_id=1..5) para auditar qué información sensible fue expuesta.
  3. Remediación de control de acceso (OWASP Broken Object Level Authorization):
    • Validar en el servidor que el usuario autenticado en la sesión activa sea propietario o tenga permisos sobre el user_id consultado, o tomar la identidad directamente desde el token de sesión en el backend.
    • Sustituir los identificadores numéricos secuenciales por UUIDv4 no predecibles.
  4. Bloqueo perimetral: Bloquear la IP 134[.]209[.]118[.]137 en el Firewall perimetral y WAF.

Cronología

  1. 16:45:00Primera petición POST a /get_user_info/?user_id=2 — HTTP 200 OK (253 B)
  2. 16:45:43Cambio manual del parámetro a user_id=1 — HTTP 200 OK (188 B), confirmando acceso a otro registro
  3. 16:46:14Enumeración hacia user_id=3 dispara la alerta SOC169 (#119) — HTTP 200 OK (351 B)
  4. 16:47:37Extracción de información del perfil user_id=4 — HTTP 200 OK (158 B)
  5. 16:48:01Quinta petición exitosa sobre user_id=5 — HTTP 200 OK (267 B)
  6. CierreInspección EDR en WebServer1005, aislamiento del host por fuga de datos confirmada y escalamiento a Tier 2

Mapeo MITRE ATT&CK

T1190
Exploit Public-Facing Application
Initial Access
T1213
Data from Information Repositories
Collection
T1595.002
Active Scanning: Vulnerability Scanning
Reconnaissance

Indicadores de compromiso

defanged
IPv4134[.]209[.]118[.]137Atacante externo · AS14061 (DigitalOcean LLC / VPN)
HostWebServer1005 (172.16.17.15)Servidor web interno contenido
URLhxxps://172[.]16[.]17[.]15/get_user_info/?user_id=1[.][.]5Endpoint vulnerable a IDOR vía HTTP POST
User-AgentMozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)User-Agent obsoleto (IE6 / WinXP) en las 5 peticiones

Executive Summary

On February 28, 2022, the alert SOC169 — Possible IDOR Attack Detected (Case #119) triggered following a sequence of HTTP POST requests targeting the /get_user_info/ endpoint on internal server WebServer1005 (172.16.17.15), originating from external IP 134[.]209[.]118[.]137 (allocated to DigitalOcean, LLC and flagged as malicious by threat intelligence vendors).

Web access log correlation confirmed a True Positive with successful exploitation: the adversary manually iterated the user_id parameter from 1 to 5, receiving HTTP 200 OK responses with distinct body sizes (158 to 351 bytes) on every request—proving unauthorized disclosure of five different user records. Although EDR telemetry showed no OS-level command execution on the host, the confirmed data breach required immediate containment of WebServer1005 and escalation to Tier 2.

Verdict: True Positive — successful attack (unauthorized user data disclosure via IDOR). WebServer1005 was isolated via EDR and the case was escalated to Tier 2 for remediation.

Initial Detection & Triage

Field Value
Alert ID / Rule LetsDefend Alert #119 — SOC169 - Possible IDOR Attack Detected
Incident Timestamp (Logs) 2022-02-28 (16:45:00 – 16:48:01 SIEM)
Investigation Date 2026-10-19
Source IP 134[.]209[.]118[.]137 (AS14061 — DigitalOcean, LLC)
Affected Asset WebServer1005 (172.16.17.15)
Endpoint / Method POST hxxps://172[.]16[.]17[.]15/get_user_info/?user_id=[1..5]
Device Action Allowed

Initial Hypothesis: Observing two initial consecutive requests (16:45:00 with user_id=2 and 16:45:43 with user_id=1) from the same external IP returning HTTP 200 OK with different payload lengths (253 bytes vs. 188 bytes) immediately established the hypothesis of an active Insecure Direct Object Reference (IDOR) attack exposing user records without session-level authorization checks.

Technical Analysis & Investigation

Request Sequence & Evidence of Successful Exploitation

Inspecting the network logs for 172.16.17.15 revealed 5 HTTP POST requests across a 3-minute window, sequentially modifying the user_id parameter:

POST /get_user_info/?user_id=2 HTTP/1.1   --> 200 OK (253 bytes)
POST /get_user_info/?user_id=1 HTTP/1.1   --> 200 OK (188 bytes)
POST /get_user_info/?user_id=3 HTTP/1.1   --> 200 OK (351 bytes)
POST /get_user_info/?user_id=4 HTTP/1.1   --> 200 OK (158 bytes)
POST /get_user_info/?user_id=5 HTTP/1.1   --> 200 OK (267 bytes)
Host: 172.16.17.15
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Time Requested URI (Defanged) Parameter HTTP Status Size Assessment
16:45:00 hxxps://172[.]16[.]17[.]15/get_user_info/?user_id=2 user_id=2 200 OK 253 B Initial successful record retrieval
16:45:43 hxxps://172[.]16[.]17[.]15/get_user_info/?user_id=1 user_id=1 200 OK 188 B Successful IDOR pivot to id=1
16:46:14 hxxps://172[.]16[.]17[.]15/get_user_info/?user_id=3 user_id=3 200 OK 351 B Sequential enumeration (triggers alert)
16:47:37 hxxps://172[.]16[.]17[.]15/get_user_info/?user_id=4 user_id=4 200 OK 158 B Fourth user record exfiltrated
16:48:01 hxxps://172[.]16[.]17[.]15/get_user_info/?user_id=5 user_id=5 200 OK 267 B Fifth user record exfiltrated

Why is this confirmed as a successful attack?

  • HTTP 200 OK + variable response lengths: Had the application rejected unauthorized access or returned a static error page, we would observe 401/403/500 status codes or identical byte counts. The varying sizes (253, 188, 351, 158, 267 bytes) prove that each request returned a distinct user profile from the database.

Endpoint Telemetry (EDR) & Threat Intelligence (CTI)

  • EDR Inspection on WebServer1005: Reviewing running processes, command history, and network connections on WebServer1005 (172.16.17.15) showed no suspicious OS-level activity. This aligns with the nature of an IDOR vulnerability: exploitation occurs entirely within the web application’s authorization logic (data disclosure) rather than through remote code execution.
  • Threat Intelligence (CTI): The source IP 134[.]209[.]118[.]137 belongs to DigitalOcean, LLC (AS14061) —indicating a cloud VPS or VPN exit node— and is flagged as malicious by security vendor analysis.
  • User-Agent Anomaly: All requests carried Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) (Internet Explorer 6 on Windows XP), a legacy signature commonly used in spoofed headers or custom HTTP scripts.

Analytical Reasoning Evolution (Post-Review & Lessons Learned)

Reflecting on how the initial hypothesis evolved during triage highlights an important SOC distinction:

  1. Initial Reasoning: Because the requests were spaced 24 to 83 seconds apart (manual pacing rather than an automated scanner) and the EDR showed zero malicious processes on WebServer1005, my initial inclination was to view the actor as a non-malicious user who stumbled upon the user_id parameter without “exploiting” the server.
  2. Post-Review Methodological Correction: Re-evaluating the evidence against incident response standards clarified two critical points:
    • Application-layer exploitation ≠ EDR process execution: In access control flaws like IDOR, the attacker’s objective is unauthorized data collection, not shell execution. Receiving HTTP 200 OK responses with 5 different user records means exploitation already succeeded and caused a confidentiality breach.
    • External Threat Context: The traffic originated from the public internet (134[.]209[.]118[.]137, a CTI-flagged DigitalOcean VPS/VPN) using a spoofed MSIE 6.0 User-Agent. Even when conducted manually/opportunistically (“unplanned” without heavy automation), unauthorized extraction of user records is a malicious and successful attack that mandates host containment and Tier 2 escalation.

Containment & Recommendations

  1. Immediate Host Containment: Isolated WebServer1005 (172.16.17.15) via EDR to halt ongoing exposure of the vulnerable /get_user_info/ endpoint.
  2. Tier 2 Escalation: Escalated the case to Tier 2 documenting the 5 accessed user IDs (user_id=1..5) to assess the sensitivity of the leaked data.
  3. Access Control Remediation (OWASP Broken Object Level Authorization):
    • Enforce server-side session validation ensuring the authenticated user is authorized to request the target user_id, or derive the user identity directly from the signed session token/JWT.
    • Replace predictable sequential integer IDs with UUIDv4 identifiers.
  4. Perimeter Blocking: Block source IP 134[.]209[.]118[.]137 at the perimeter Firewall and WAF.

Timeline

  1. 16:45:00Initial POST request to /get_user_info/?user_id=2 — HTTP 200 OK (253 B)
  2. 16:45:43Manual parameter change to user_id=1 — HTTP 200 OK (188 B), confirming access to another user record
  3. 16:46:14Sequential enumeration of user_id=3 triggers alert SOC169 (#119) — HTTP 200 OK (351 B)
  4. 16:47:37Unauthorized retrieval of user_id=4 profile — HTTP 200 OK (158 B)
  5. 16:48:01Fifth successful request targeting user_id=5 — HTTP 200 OK (267 B)
  6. ClosedEDR inspection on WebServer1005, host containment due to confirmed data exposure, and Tier 2 escalation

MITRE ATT&CK Mapping

T1190
Exploit Public-Facing Application
Initial Access
T1213
Data from Information Repositories
Collection
T1595.002
Active Scanning: Vulnerability Scanning
Reconnaissance

Indicators of Compromise (IOCs)

defanged
IPv4134[.]209[.]118[.]137External attacker · AS14061 (DigitalOcean LLC / VPN)
HostWebServer1005 (172.16.17.15)Contained internal web server
URLhxxps://172[.]16[.]17[.]15/get_user_info/?user_id=1[.][.]5Endpoint vulnerable to IDOR via HTTP POST
User-AgentMozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)Outdated User-Agent (IE6 / WinXP) across all 5 requests