“ SOC169 — Possible IDOR Attack Detected” investigation

Hello, today I will write about investigation of “SOC169 — Possible IDOR Attack Detected” alarm from letdefend.io.

The alert is appears in our investigation channel. After that, we proceed to build the case.

Let’s start the playbook.

The first step of the playbook is asking us to understand why the alert was triggered.

To understand the alert, we are supposed to examine the rule name.

The next step then asks us to determine the traffic path on which it is occurring.

The playbook’s next phase instructs us to Collect data.

· Ownership of the IP addresses and devices.

Checking the Endpoint management displays that the address 172.16.17.15 belongs to WebServer1005.

o 172.16.17.15 (WebServer1005)

o 134.209.118.137 (Internet Address)

· If the traffic is coming from outside (Internet);

Ownership of IP address (Static or Pool Address? Who owns it? Is it web hosting?)

We can verify that it is a Static Address. We are able to determine that the device is being web hosted on the DigitalOcean ISP using abuseIPDB, a centralized database for abusive IP addresses.

Reputation of IP Address (Search in VirusTotal, AbuseIPDB, Cisco Talos)

Malicious

Next, we are advised to look for probable web attack payloads in the HTTP traffic.

The next step is to determine whether the traffic is malicious. We are able to mark the traffic as malicious simply based on the IP address and its reputation. We can perform log analysis in the log management to verify our suspicions.

We start our search for the 134.209.118.137 IP in the Log Management section, and we find several logs that show communication between the Web server and it.

The Requested URL, https://172.16.17.15/get user info/, is the same as that specified in the alert when we look at the pair of Raw Logs, but the POST Parameters are where the malicious activity occurred. The two POST Parameters for user id=2 and user id=5 are clearly visible, suggesting that the attacker is attempting to access the data for the users with user ids of 2 and 5, respectively. The HTTP Response sizes changing with each attempt to obtain user information is a sign that IDOR attacks are effective. The user ids and HTTP Response Sizes were changing with each request, according to all the logs between the two devices, indicating successful IDOR attacks.

This would be considered an IDOR attack since we can see that the POST Parameters and the user ids are being successfully modified for each attempt.

We see that the attack type is IDOR.

Search for associated artifacts from the alert in Mailbox, such as the source IP, destination IP, or server name, but nothing appears to be connected, therefore this was not planned.

We are required to determine the direction of traffic while look back to the alert.

The alert’s 134.209.118.137 source address is external to the company network. WebServer1005, 172.16.17.15 , is the internal destination address. This denotes a direction flow on the Internet → Company Network.

We are next instructed to determine whether or not the attack was successful.

Since we can see the HTTP Response Sizes changing, we can likely say that the attacks were successful.

Before completing the case, we continue by adding the findings we found during the review phase to close it.

Since I found the attack to be successful, Tier 2 Escalation is necessary for a more experienced analyst.

Summary: