This is a re-post of my old research testing (non-instrusively) for security flaws across a number of banks. It also details me being contacted via The World Bank (one of the most evil corporations ever) due to them reaching out over the Open Bug Bounty platform. I am going to be making the occasional post like this for historical purposes. Hopefully another purpose of this re-post will show how I’ve matured over the years, both in general and in terms of my hacking abilitites (as you should be able to tell, the stuff I find here is pretty n00by ;D )

For those who have seen my twitter profile recently, you may be aware of the fact that I am in the process of developing a web-based framework for emulating advanded spear phishing campaigns. This tool will have both a free version, and a paid/premium version.

I’ve already written a tutorial explaining several advanced spear phishing techniques, explaining how they work and the benefits and drawbacks of using them, and additionally I’ve written a tutorial demonstrating live against eBay how to perform an XSS-Based spear phishing attack in order to harvest login credentials… so, with that in mind, and with our new spear phishing framework soon being released, I decided it would be a cool idea to re-post the results of my vulnerability identification (for the specific purposes of hypothetical spear phishing) within the banking sector, in order to show you the specific categories of vulnerability one would look for if attempting to carry out a spear phishing campaign.


Most logically, XSS and Open Redirects are the ideal vulnerabilities to be identifying if you’re looking for endpoints to use within a spear phishing campaign, although I cover a few other unrelated useful methods too, which you’ll see further within this post.

I’ll start up with some of the more minor vulnerabilities, while the banks generally do tend to have good XSS filters in place, they seem to forget about the dangers of redirects (in some of these cases the redirects can easily be turned into XSS).

The banks I start with are JPMorgan / Chase, within 5 minutes I found some open redirect vulnerabilities, with no authorisation required to redirect to an external site, and no warning message to tell the user they’re about to be redirected. Below are the examples (redirecting to for the case of this example):

  • It should be noted that none of the other HTTP GET params need to match any particular value. It is only the URL param that needs to be modified to create a open redirection scenario
  • The “etrack.ashx” file was being ran across a few different banking sites / applications
  • in some instances, // was triggering a HTTP 500 response and thus the redirect would not take place.
  • To get around that, it’s worth remembering that a URL doesn’t actually need any slashes. For example is equivalent to doing – so with that in mind, the HTTP 500 triggered by use of slashes was trivial to bypass:

After seeing multiple sites were running this, I looked more into “etrack” and specifically their ASP.NET documentation. Turns out it’s a plugin used across many sites for tracking email links. So, this is actually an (incredibly low-impact) 0day exploit affecting an ASP.NET plugin. Some other examples of affected sites outside of the banking sector would be The Irish Times (a major broadsheet newspaper from the Republic of Ireland), Informa (Australia’s leading event management company), and additionally a large number of digital asset companies.

My first attempt after finding these redirects was to escalate them to DOM-Based XSS, but sadly that was not a possibility. Content forgery via redirection to a data: uri scheme on the other hand was a viable (but less impactful) alternative.

For those who aren’t already aware of this, you can redirect directly to a data: URI with a base64 encoded input cotaining your HTML/JavaScript, allowing you to build the fake login page in the context of the victims browser itself rather than within the context of another site. It could be argued that this offers further obfuscation as the victims address bar won’t display a phony URL but will instead just display ‘data:’ (assuming that padding is added to the uri, in which case the base64 encoded inputs will not be displayed in the address bar). It should be noted that the JS you execute via this manner is executing within a null context, rather than within the domain context of the target website.

An example payload would look something like:


the first part of the string is telling the browser what kind of data to be expecting, and the second part of the string (after the comma) is the base64 encoded input that would contain your HTML for your phishing page or whatever you decided to use on the victim,

to break that down:


is a base64 encoded version of:


I am base64 encoding it and specifying the data type as text/html;base64 in order to obfuscate my payload and to circumvent any potential WAF or other filters that could be applied. In order to use regular HTML/JS in your payload, you can just specify data:text/html, without following it up with “Base64” – any HTML after the comma once you’ve specified your data type value will be rendered within the victim’s browser.

A live example of the URL can be found here:;base64,PHNjcmlwdD5hbGVydCgvWFNTUE9TRUQvKTwvc2NyaXB0Pg==

It should be noted that the above URL is only working in Firefox. Here is another example in another large bank (HSBC):;base64,PHNjcmlwdD5hbGVydCgvWFNTUE9TRUQvKTwvc2NyaXB0Pg==

When this original post was made, Flash was still relatively widely-used and was enabled by default within Google Chrome, so another logical area to search for DOM XSS in banks would be SWF files. Several well-known banks were vulnerable to DOM XSS via clickTag, with the most popular bank vulnerable to this being American Express (two different examples of the same vulnerability can be found below):

Another flash-based vulnerability was identified within JPMorgan. This one didn’t abuse native ActionScript functionality for DOM XSS but instead it is loading a malicious XML file from the attacker’s server with a custom crossdomain.xml policy setup, and within the malicious XML file there is a CDATA value containing the HTML/JavaScript to trigger the XSS:

For an explanation as to how the above flash-based XSS works, take a look at our blog post covering the topic.

A few additional Open Redirects in banks and credit card sites were identified, but sadly these could not be escalated to DOM XSS (despite this fact, they still have uses for spear phishing since you’re able to redirect the victim from the real website to your evil website). The first one I found was in American Express:

and one in Visa:

Fun fact: the “offerID” param here was also vulnerable to IDOR, allowing you to get discounts on items that you should not be able to receive a discount for (but, of course this doesn’t have any uses for spear phishing)

During this testing, I met someone (via who works in infosec for the World Bank and after a week or so of chatting, we quickly became friends. I talked to this friend about how easy it seems to be to identify such vulnerabilities within the banking sector. This same friend happens to do security for the World Bank, which, while not a conventional bank, is a huge organization. He assured me that spear phishing campaigns via similar vulnerabilities to the ones in other banks would be near impossible within the website. He assured me that since he audits it for vulnerabilities, nothing would have slipped past him… so of course I took this as a challenge!

With permission, I began to dig around on * and almost immediately found a vulnerability. It is a DOM-Based XSS similar in nature to what I found on the other sites (y’know, what he promised me I wouldn’t find?) – additionally, they didn’t have HttpOnly enabled, making session hijacking even more simple.

Here is the vulnerable URL:

Screenshot of document.cookie output:


The next URL I found in was something I initially believed to be an Open Redirect. I attempted to test the param to see if I could redirect to my own website or to a javascript: uri, which I could not… but it turns out it was vulnerable to something far more serious.

The URL was the following:

The “corridorgenpdf” script is used to take a URL as input, and generate a PDF based on that URL… so, sure, it could be used for some form of spear phishing by having it load a PDF file that looks like it’s coming from but really isn’t… but, as soon as I saw what this script was doing, “SSRF” came to mind immediately.

Here is an example of it generating a PDF based upon a user-supplied input:

The user-supplied input ( is converted to PDF format, and then supplies it as a download link, as seen here:


Now the risk associated with this is that a user could be served content as a PDF from a trusted source (world bank) and that PDF could contain contact information that puts the victim right in touch with a fraudster or links them to a phishing website. It would just be a case of setting up the output you want to be served to the user on one of your servers, then setting it as the input for ?URL= param. Pretty interesting vector (comparable to the CEMI aka CSV Excel Macro Injection bugs that have been floating around lately), but still not too high of a security risk – probably about the same level as the redirects to data: URI’s as displayed at the start of this post.

But… what if I could have it fetch local URL’s rather than just remote URL’s?

Naturally, that’s what I tried next – to attempt direct SSRF. I started out with XSPA, and attempted to probe port 25, like so:

It works as expected, outputting the version of the SMTP Daemon running on Port 25:


Now again, but with the MySQL port (3306):


Once again, working with no issues — the MySQL version outputted, as expected.

My final test before moving on was an attempt at Local File Disclosure via the file:/// uri scheme:

and again, works just fine:


I’m sure RCE is also a possibility, but I didn’t want to attempt to escalate this further – after all, my goal was to find links that could be utilized for spear phishing. While looking at I did come across another instance of LFD though – this time via directory travesal rather than via SSRF. This was in – I first attempted a regular directory traversal LFD payload, like so:


That triggered a WAF, and gave me a HTTP 403, so I played around with the payload a little and noticed it was the forward-slashes that triggered the WAF response, so i attempted the following payload:


No WAF response this time, but no passwd file either, as it is attempting to append a file extension to the input. This can be circumvented via CR/LF chars (or nullbytes / null-terminator char), like so:


Third time’s the charm! passwd file downloaded, despite it (weirdly) throwing a 404 error:


After identifying the instances of LFD and SSRF, I came to the conclusion that I’d went off on a tangent and strayed away from my initial goal of finding stuff that could be utilized for spear phishing. I decided to email over the LFD and SSRF so that they could be patched, and decided to continue looking for stuff that could be used for spear phishing… little did I know, but I was about to report the LFD/SSRF and find stuff useful for spear phishing, at the exact same time.

While looking for a contact email, I came across the following URL:


I enter my own email address as the recipient’s email, then I enter as my own email, as seen below:


I enter the captcha and click ‘send’ and instantly get a prompt confirming that the mail has been sent:


I check my email to confirm, and here we go, a message from telling me that has sent me a message:


The fact someone has INTENTIONALLY made this is kinda scary, a site like this should not have such incompetent sysadmins. This could be paired with the XSS in to effectively hijack cookies or launch other attacks, here is an example attack scenario:

  • Attacker obtains a list of email addresses associated with
  • Attacker then sends out mail seemingly from to the emails in the list
  • Emails contain a link to the XSS with a payload setup to hijack cookies and store them on the attackers server
  • victims click link
  • ???

Generally it would be time consuming for an attacker to obtain a list of emails associated with a site, but in the case of world bank it’s trivial, simply request the page to view a list of email notification subscribers:

Full list of subscribers available for anyone to read:


Not only that, but if an attacker wanted to personally tailor the emails to a target, they can find out their personal information by simply clicking their name within the subscriber list:

I know this writeup has kind of been all over the place, but itt’l hopefully give you an idea of what kind of stuff an attacker would be looking for if carrying out a spear phishing campaign, and if paired with my other two posts related to spear phishing, you should have a pretty good idea of advanced methods, ways to set up such methods, and the nature of vulnerabilities to carry out such methods.

I’ll be doing a “Part #2” on my “advanced/obscure spear phishing methods” post soon too, which will tie in to some of the stuff mentioned here (namely utilizing DOM XSS and redirects, among a few other things).

./mlt –out