Cross Site Port Attack - A Stranger’s Call

Jerry Shah (Jerry)
5 min readMar 21, 2021


Summary :

Cross Site Port Attack is an abbreviation of XSPA. In this attack an application processes user supplied URLs and does not verify or sanitize the back end response received from remote servers before sending it back to the client. An attacker can send crafted queries to a vulnerable web application to proxy attacks to external Internet facing servers, intranet devices and the web server itself. The responses, in certain cases, can be studied to identify service availability like open ports , banner versions etc. and even fetch data from remote services in an unconventional ways.

It allows attackers to abuse available functionality in most web applications to scan port of intranet and external Internet facing servers, fingerprint internal (non-Internet exposed) network aware services, perform banner grabbing, identify web application frameworks, exploit vulnerable programs, run code on reachable machines, exploit web application vulnerabilities listening on internal networks, read local files using the file protocol and much more.

My target website was built in WordPress (I found it using wappalyzer) and the most common xmlrpc.php file was enabled. Most XSPA attack occurs when xmlrpc.php file is enabled. I exploited the file and got an IP address and when I visited that IP address there wasn’t any content on it but when I used directory traversal payload I was able to call /etc/passwd file.

Attacks You Can Perform Using XSPA :

  1. Port scanning remote Internet facing servers
  2. Port scanning Intranet
  3. Port scanning local web server
  4. Exploit vulnerable programs running on intranet or on local web server
  5. Attacking internal and external web applications that are vulnerable to GET parameter based vulnerabilities such as SQLi
  6. Reading local web server files using the file:/// protocol handler

How I found this vulnerability ?

  1. I went to my target website and added an endpoint /xmlrpc.php and as usual it gave me an error

2. Then I changed GET verb to POST verb and got a weird response

POST Response

3. I searched for the exploit and found a blog on xmlrpc.php file exploitation, I used the exploit and got some methods in response

Exploit xmlrpc.php
Exploit xmlrpc.php

4. As mentioned in the blog I found the method, I opened my burp collaborator client for XSPA attack and copied the collaborator URL

Burp Collaborator Client
Collaborator URL Copied

5. Then I used the exploit of method and got a weird response again


6. Then I checked my collaborator client and got a successful DNS and HTTP request, so it was confirmed that the website is vulnerable to XSPA attack

HTTP and DNS Request

7. Then for a cross check, instead of burp collaborator client I used for a callback and even there I got a successful callback

Callback on hookbin
Callback on hookbin

8. Then I used my ngrok server for checking XSPA attack again

Ngrok Web Interface

Here you can is in the response the faultCode value is 17, which means that the port is open. If you hit the value (faultCode) greater than 0 means that the port is open.

Now usually you get the internal IP address but the IP that I got wasn’t internal but it was owned by my target company when I checked the whois record. I visited that IP which was and found an empty page and I randomly added a directory traversal payload and got a listing.


Impact :

This kind of attacks are used to perform Denial-Of-Service, Port Scanning, Remote Code Execution, Reading Internal Files etc.

Mitigation :

There are many mitigations against XSPA attack and some of those are :

  1. Unauthorized URL access should be restricted
  2. Restrict connectivity to internal ports
  3. Blacklist internal IP addresses and internal host names
  4. Disable unwanted protocols

Exploit Codes :

  1. For directory traversal :

2. For listing all available methods :


3. For exploiting method :

<?xml version=”1.0" encoding=”UTF-8"?>
<value><string>URL of your server</string></value>
<value><string>Target URL with an endpoint</string></value>

In exploit, the <methodName> is and the first <string> value is the URL of your server and the second <string> value is the URL of your target with any of its endpoint. It is mandatory to use the endpoint of the target website otherwise it will give you below mentioned error.


Here the error says “The specified target URL cannot be used as a target. It either doesn’t exist, or it is not a pingback-enabled resource.” This error came because I used the target URL without any endpoint. (for eg. instead of

It happens because the pingback methods are usually enabled where the blog links are mentioned.

For eg : If we have two websites and both of them have pingback enabled on blog endpoint, so if website 1’s owner mentioned any of your blog in there comment section you will get a pingback on your server and vice versa.

To know more about pingback you can visit :

Great thanks to : for xmlrpc.php exploit.



Jerry Shah (Jerry)

|Penetration Tester| |Hack The Box| |Digital Forensics| |Malware Analysis|