Skip to main content

LD-Javascript Code Detected in Requested URL

Table of Contents

Alert
#

 1EventID :               116
 2Event Time :            Feb, 26, 2022, 06:56 PM
 3Rule :                  SOC166 - Javascript Code Detected in Requested URL
 4Level :                 Security Analyst
 5Hostname :              WebServer1002
 6Destination IP Address : 172.16.17.17
 7Source IP Address :     112.85.42.13
 8HTTP Request Method :   GET
 9Requested URL :         https://172.16.17.17/search/?q=<$script>javascript:$alert(1)<$/script>
10User-Agent :            Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1
11Alert Trigger Reason :  Javascript code detected in URL
12Device Action :         Allowed

Identification
#

Is the traffic coming from outside?
#

The source IP 112.85.42.13 is an external address belonging to China Unicom Jiangsu province network (AS4837, Nanjing, China). The destination 172.16.17.17 is an internal address. Traffic direction is Internet to Company Network. This was confirmed not to be a planned test.

Is the source malicious?
#

AbuseIPDB shows the IP has been reported 45,324 times with a Confidence of Abuse of 0%. The high report volume is notable despite the low confidence score - this is a Fixed Line ISP address rather than a cloud VPS, which is less common for attacker infrastructure but not unusual for compromised residential/business connections used as proxies.

AbuseIPDB

VirusTotal returned 0/94 detections - no vendor flagged the IP as malicious. However, 1 file was detected communicating with this IP, and the community score is -15, suggesting prior negative community reports.

VirusTotal

What type of attack was attempted?
#

Firewall logs show eight consecutive inbound connections from 112.85.42.13 to 172.16.17.17:443 between 06:34 PM and 06:56 PM, all permitted.

Firewall logs

Reviewing the raw log for the triggering request confirmed an XSS payload in the q parameter:

Raw log

The full request history on the /search/ endpoint reveals a systematic XSS probing sequence - the attacker started with a benign q=test request (HTTP 200, 885 bytes) to confirm the endpoint was live, then escalated through multiple injection techniques:

1q=test                                              - HTTP 200 (baseline probe)
2q=prompt(8)                                         - HTTP 302
3q=<img src=q onerror=prompt(8)>                     - HTTP 302 (img onerror)
4q=<svg><script ?>alert(1)                           - HTTP 302 (SVG vector)
5q=<script>for((i)in(self))eval(i)(1)</script>       - HTTP 302 (obfuscated eval)
6q=<script>javascript:alert(1)                       - HTTP 302 (unclosed tag)
7q=<script>javascript:alert(1)</script>              - HTTP 302 (final payload)

This pattern is consistent with manual or semi-automated XSS fuzzing - testing multiple bypass techniques to find one that evades server-side filtering.

Did anyone else get targeted?
#

All connections targeted exclusively 172.16.17.17 on the /search/ endpoint. No other internal hosts were involved.

Did the attack succeed?
#

No. Only the initial baseline request (q=test) returned HTTP 200 with a response body of 885 bytes. Every subsequent XSS payload returned HTTP 302 with a response size of 0 - indicating the server redirected the request without processing the payload, consistent with server-side input sanitization or a WAF blocking the injection. No successful script execution was observed.

Triage Decision
#

True Positive. The attack did not succeed - all XSS payloads were blocked with HTTP 302. No Tier 2 escalation required.

What is the impact level?
#

Low. The server correctly rejected all injection payloads. However, the attacker successfully fingerprinted the endpoint as live and tested multiple bypass vectors, which may inform follow-up attempts with more advanced payloads.

Containment
#

Is the attacker still active?
#

The last observed request was at 06:56 PM on Feb 26, 2022. No further connections from 112.85.42.13 were observed after the triggering event.

Is the vulnerable endpoint still exposed?
#

The /search/ endpoint on 172.16.17.17 remains externally accessible. While the current sanitization blocked these specific payloads, the endpoint should be reviewed for completeness of input validation against advanced bypass techniques.

Actions taken
#

112.85.42.13 was blocked at the firewall. The /search/ endpoint was flagged for the application security team to review input validation coverage.

IOCs
#

IPs
- 112.85.42.13 - attacker IP - 172.16.17.17 - targeted IP
URLs
- hxxps://172.16.17[.]17/search/?q= - targeted endpoint
User-Agent
- Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1

MITRE ATT&CK
#

TacticTechniqueID
Initial AccessExploit Public-Facing ApplicationT1190
ExecutionCommand and Scripting Interpreter: JavaScriptT1059.007
DiscoveryNetwork Service DiscoveryT1046