“ SOC166 — Javascript Code Detected in Requested URL” investigation

5 min readNov 28, 2022

Hello, today I will write about investigation of “SOC166 — Javascript Code Detected in Requested URL” 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.17 belongs to WebServer1002.

o 172.16.17.17 (WebServer1002)

o 112.85.42.13 (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 China Unicom Jiangsu Province Network 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.

We can see from the requested URL that the request contained JavaScript code.

https://172.16.17.17/search/?q=<$script>javascript:$alert(1)<$/script>

Signs that a cross-site scripting (XSS) attack may be occurring.

After that, we asked to determine if the traffic is malicious. I believe the URL gave all the signs of malicious traffic due to obvious JavaScript code and a malicious IP.

We see that the attack type is an XSS attack.

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 112.85.42.13 source address is external to the company network. WebServer1002, 172.16.17.17, 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.

I noticed multiple records of connections being attempted to the WebServer1002 address, 172.16.17.17, while I searched the logs using the malicious address, 112.85.42.13.

Looking at the first two logs, we can see that each log has an increasing HTTP Response Size while maintaining the same HTTP Response Status 200, which denotes an OK, successful request.

When I looked at the third and fourth logs, I could see that they had started testing the search criteria and had been successful in getting an HTTP Response Size of 885 and an OK 200 Response Status. Nevertheless, the following request URL produced no response but instead had a 302 HTTP Response Status, which denotes that the resource is being forwarded to the requested URL.

The cross-site script attempt was detected by looking at the final log connection between the two machines, which produced no HTTP Response but still had a redirected Response Status.