This title may be a handful from just looking at it, but today I will go about discussing my interaction with Shadow Z118’s Paypal phishing website, certain measures it implemented to avoid bot discovery/web spiders, certain enumeration methods, as well as creating a tool to deliver false information to the host.

     This whole situation began at the start of February, in which I received a phishing email from an unknown source. The email itself was poorly thrown together and should raise red flags for anyone who knows about these types of emails.

Email Received

     Having not received a phishing email in such a long time, I felt the need to satisfy my curiosity and see what was going on with this link.

Initial View:

     Clicking the link, it sent me to a well put together PayPal login form. Nothing overall that would raise flags other than the URL in the address bar. Hell, the website even had SSL configured so it was using HTTPS and had the lock-pad icon to show it was secure. Moving forward, there were two things that I wanted to look into further.

1. What is at the root of this web-server, if anything?
2. What security measures are in place if any?
3. What happens after you send login credentials?

Finding and Analyzing the Phishing Source Code:

     So following my first step on how I want to approach this website, I went ahead and stripped the directories and any extensions from the main URL, just to see what was waiting for us at the root level. Surprisingly enough, we hit the jackpot and found the hosted files.

     The file that interested me the most was, of course, Wanting to be safe, I booted up my Linux VM and downloaded the file so I can see what exactly what we were working with.

Security Measures In Place:

     There are three specific security measures that this website has implemented to avoid detection from spiders/bots, but also measures to throw off users not using a Windows machine. Looking at the measures forbidding bots from accessing any part of the website, we see a list of forbidden IP addresses. Specific hostnames were also barred from accessing the website. Hostnames such as Google, AmazonAWS, Cyveillance, and Phishtank. As seen in the screenshot below, select user-agents are also barred from accessing the website.

AntiBots.php from

     Moving to the next measure in place, we will deal with the User-Agent header within the web requests being sent to the website. When I initially started checking out everything, I was using my Windows machine. So naturally, each web request I had sent contained a User-Agent header of: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64). Nothing seemed out of place until I continued my recon over to my Linux VM. Here, when I tried to request the exact website as I did from my host machine, I got this strange response.

Web Response From Linux VM

     Curious about what was going on, I went and opened up Burp Suite. Setting the proxy up, I went ahead and resent my request to the website one more time. Comparing my requests from my VM and my host machine, the only different thing was my User-Agent header. Here it read: User-Agent: Mozilla/5.0 (X11; Linux x86_64). Taking a guess, I decided to change the header to match what was used with my Windows machine, and sure enough, the normal login page appeared.

     Moving to the last known security measure in place, we need to take a look at the index.php for our main login page. Something is interesting with how this website checks if the information is valid or not. The way it addresses this issue is by assigning a session and dispatch value, appending it to the end of the URL if the phished info is in valid format, as well as certain headers.

Session and Dispatch randomization

     Taking a look at how session and dispatch is created, we can see that if valid information is passed, it will create a session and dispatch value and apply it to a 303 redirect to continue their process. We can test if our values are valid and being passed if we generate a new session and dispatch value each request. With all these measures in mind, I felt I was able to move to my next step. Making a script to render the data received useless by sending false information so the phishers cannot sort which data was from valid sources and which were not.

Moving To Python:

     Before starting this part, I feel I need to make this situation very clear. While I do feel that phishers collecting information like this should not be protected in any way, and face consequences for their actions; I do not believe it is my place to attack or act as a vigilante and take matters in my own hands. This is why I cloned the website to the best of my abilities and conducted the next process on my local machine. Following procedures, I reported the website to ‘’ following this link.  

     Starting off, I needed to figure out what data will be sent to the webserver. Using Burp Suite, I gathered the following parameters: email, password, address, city, state, zipCode, nameoncard, cardnumber, expdate, csc, day, month, year, ssn, and phonenumber.
     Next, I will need to grab the URLs for each of the webpages used. There are 3 key differences between the different pages, all of which are at the end of the URL. The first request is simple, it grabs the users country and language. Next, we encounter the first verification check. This check contains the session and dispatch parameters seen earlier. The last URL uses the session and dispatch parameters as well, but requesting it as from ‘?secure_code=’ vs ‘?verify_account=’. To bypass this measure, we can send the website valid information, grab the redirect URL, and use the tokens on the next URL.

Grab and Append Tokens

Using this method, I was able to grab the tokens for the verification URLs, and  use them to send data to the next webpages available. To ensure data was being collected and sent, I used Wireshark to monitor the network to see if any emails were being sent containing the data within. As suspected, the information was being sent to the email set in one of the php files.

Script Grabbing Session and Dispatch Tokens

If you want to see how the false information is sent, as well as how the data is generated randomly, I recommend checking out my repository for this project on GitHub.

Identifiers For Z118 PayPal Phishing Campaigns:


  1. URL May Contain:
    1. /home/signin/Security/myaccount/signin/?country.x=US&locale.x=en_US
    2. /home/signin/Security/myaccount/settings/?verify_account=session=US&{}&dispatch={}
    3. /home/signin/Security/myaccount/security/?secure_code=session=US&{}&dispatch={}
  2. Login HTML ID:
    1. html id="x_21056351"