[Paper] Analysis of security vulnerabilities in Microsoft Office 365 in regard to SAML


[BugBounty] Decoding a $😱,000.00 htpasswd bounty


A Private Bug Bounty Program had a globally readable .htpasswd file. I cracked the DES hash, got access to development and staging environments and was rewarded a shitload of$.

[Tools used]

dirbuster https://www.owasp.org/index.php/Category:OWASP_DirBuster_Project

John http://www.openwall.com/john/

[\Tools used]

Today I want to share something with you that I recently discovered in a private Bug Bounty Program. Due to private program restrictions, I am not allowed to disclose the identifying details of the bug, so I’m just going to share my techniques and how I discovered it.

So, as a first step, I looked for potential vulnerable subdomains using a Google Dork query: site:*.REDACTED.com -www and then looked for interesting stuff. One particular domain caught my attention and so I had a look at it, admin.REDACTED.com. Upon review, the site looked pretty unspectacular and so I decided to use the tool „dirbuster“ to look for the juicy stuff. I was about to give up when I saw the tool discovered a .htpasswd file with an HTTP status 200. With a bit of excitement, I visited the URL and was pretty surprised to the file rendered.

Ohne Titel


So what exactly is this? As some of you may know, several webservers offer a mechanism called Basic Authentication. While I now knew the username was us3r, the password was still encrypted… Now, in similar cases, I’ve seen passwords simply being Base64 encoded but here, the encryption didn’t look like anything I was familiar with. After some Googling, I realized it was DES (Data Encryption Standard).. Based on what I read, while DES is now considered insecure and susceptible to theoretical attacks (thanks Wikipedia), there are no trivial methods known for DES cracking. So instead, I used a simple password cracking tool called john with the help of @nijagaw Nico who pointed me to a nice wordlist (Link) to crack it.

Loaded 1 password hash (descrypt, traditional crypt(3) [DES 128/128 SSE2-16])

After some time i finally had the encrypted password.

But what now? The website itself didn’t use any kind of .htaccess and, admittedly, I was a bit lost. However, thanks to the awesome @mongobug, I was able to figure out that each of the following was using Basic Authentication:

  • thestageingstuff.*.domain.com
  • developmentworkshere.*.domain.com
  • quark.*.domain.com
  • devsfavourite.*.domain.com

Additionally, the fun thing was the Username and Password I discovered worked on each and every one of them. In other words,I had access to the company’s development / beta environments.

The next step? Report it to the program owner who responded quickly, and resolved the issue even quicker. Kudos to them.

End of the story 🙂

rawraw (1)


[Research] Phishermans Friend – Getting control over a phishing backend

Dear Readers, once in a while I enjoy blogging about things unrelated to bug bounties. And so, as it happens, on a quiet Thursday night as I was about to go to bed, I received the following e-mail:

It roughly translates to: Your Attention is needed, there has been an unwanted login from a location near Berlin.

Hmmm unwanted login from a location near Berlin? My younger brother lives in Berlin, I wondered if he logged in to my PayPal Account. I doubted it, so I decided to visit the link in the email. Clicking on it brought me to the following site:

Bildschirmfoto 2016-06-10 um 11.11.56

Interesting, http://paypal.de-conflict.ru/ <- as you probably notice, this is definitely not something we should trust, it’s a phishing site. So ,as you may or may not know, I like to use the awesome tool dirbuster. After firing it up and targeting this address, I quickly find some juicy stuff:

  • info.php <- PHP Info
  • /classes/ <- misconfigured folder
  • /backend/ <- Login Form
  • /backend/install <- ;-)….

I hope this makes you smile too. First, I looked at the info.php and the system description revealed: Linux fox.hidden-server.ru 2.6.32-673.8.1.lve1.4.3.el6.x86_64 #1 SMP Wed Feb 10 08:57:30 EST 2016 x86_64.

So, based on the .ru, seems it’s a Russian service for criminal activities.

The directory  /backend/ was just a simple login form asking for username and password -> I didn’t feel like wasting my time so figured this was a dead end.

Then I found the funniest part, the directory /backend/install:

Translates to: Installation Successful Username, Password

Translates to: Installation Successful Username, Password

Okay, good to know, apparently super criminals use the username admin and the password 123456. Think it’ll work on /backend/? Needing to know, I went back to /backend/ and tried the newly discovered credentials 🙂 Sure enough, I was logged in!

Bildschirmfoto 2016-06-10 um 00.59.09

Tadaaaa the beautiful back end of a Paypal phishing service. As you can see in the charts on the bottom, there had been three visitors by the time I accessed the dashboard. I browsed through the dashboard and found a link to “data sets”, which included the phished Paypal credentials, Credit Card Numbers etc.


Bildschirmfoto 2016-06-10 um 01.05.35


At the time, there were three entries, one from me, one of a victim and the first one ever submitted, which could be a test :-). On that note, if you’re developing a site, what’s the first thing you typically do after installing a new service? You test it out. Turns out, the owner of this was stupid to enter some credentials on the website to test the site, but didn’t realize, or care, that his IP address was saved too.  I’ve censored the IP-Address because I  can’t be 100% sure it was the one of him though.

After two hours of monitoring the website, there were a couple of real data sets of German phishing victims.

Phished Data including Username, Password, Birth Date, Credit Card Number, Address and everything else needed for online criminals to ruin someones life

Phished Data including Username, Password, Birth Date, Credit Card Number, Address and everything else needed for online criminals to potentially ruin someone’s life.

Hmm, it seemed as if more and more people were falling for this scam, so I decided to take some action against it… how you ask?

Well 🙂 I included on every place I could the phrase „Your IP is 85.25.*.*“ and went to bed to see what happens next.

Datasets on the left and the Note i left in the middle

Datas ets on the left and the note I left in the middle

Waking up on Friday, the first thing I did was go online see how many more data sets there were… and it turned out.. the site was gone 🙂

Bildschirmfoto 2016-06-10 um 10.05.29

That’s it 🙂 the site is gone and the Russian criminal is now (hopefully) scared that someone recorded his actions and kept evidence of his online identity.

Further Work: 

I know several of my e-mail addresses are likely in a database of phishing targets, as I receive similar emails almost daily. Those scam campaigns are mostly based on the same commercial sold phishing CMS system, my plan is to collect as many phishing sites I can find to test if those are similarly designed.


This post is intended for educational purposes and not meant to promote, incentivize or encourage any action which may or may not be considered illegal. None of the described actions are in any relation with my past, current or future employers.


Q = What happened to the harvested credentials?

A = I contacted the victims via mail (4 at that time) and each of them took care and followed the steps I suggested (change Password, contact Paypal, contact Credit Institute, lock the credit cards). Three out of the four contacted persons had a feeling that something strange was going on on that site but decided not to do anything. By the time I contacted them, they knew something strange was going on, and they were glad I took action and contacted them.



[BugBounty] Sleeping stored Google XSS Awakens a $5000 Bounty

Dear Readers,

Today I want to share a short write-up about a stored cross-site scripting (XSS) issue I found on the Google Cloud Console. I consider it a lucky find. Some of you may remember the tweet I sent to  Frans Rosén  after he discovered a vulnerability on Google Payments:

Screenshot 2016-05-16 at 21:41:38

As it turned out, among the unsuccessful XSS payloads I saved on my Google account, there was one that actually fired. But unexpectedly. When I was originally testing my payloads, I never managed to trigger the execution until recently and inadvertently. But let’s start from the beginning.

As you may know, Google is offering a 60 day  free trial  with a budget of $300 and all that is required is entering (correct) payment information to prove you are not a robot. So, I did that a few weeks ago and started entering XSS payloads in every field I could find … and nothing fired, I failed. A situation I assume we’ve all been in, right? Well, after two months or so, I received an invoice from Google and a notification that my free trial what ending. Wanting to avoid the charges, I quickly logged into my account and deleted my project, which was titled “> <img src = x onerror = javascript: alert (1); … and boom, my payload got Executed!

Screenshot 2016-05-04 at 13:41:51

As it turned out, Google was not filtering the error message once a project which canceled. Astute readers may question why this was not classified as a low level self XSS. This issue was escalated because the Google Cloud Platform can be used by multiple users; if a user creates a project with a malicious XSS payload, that payload could be used against the project administrator to execute malicious javascript (if they delete the project, which seems likely).

For those unfamiliar, and the knowledge hungry, here’s how the payload gets reflected in the content of the site: the first quote and angle bracket, “>” close the preceding HTML tag which allowed my injected <script> tag to be rendered in the page source. For this POC, I simply used the img src = x payload. Since x is not a valid url, this is designed to fail immediately with a 404 HTTP response, which will then invoke the onerror event to execute a javascript function. However, thanks to @Jobert from HackerOne for noting, that it’s possible this could have returned a 2xx or 3xx redirecting to a 2xx in which case my payload would not have fired. In my testing, I just added the function alert to create a popup but malicious users could have used a cookie stealer  or the Browser Exploitation Framework Project (BEEF) to escalate this issue (I did not have to tell Google did though).

Screenshot 2016-05-04 at 14:06:56

Here’s the video POC I sent in for the Google VRP:

That’s it 🙂


Screenshot 2016-05-16 at 21:51:54



Thanks to Peter  @yaworsk for editing :-)! Follow him and support him by buying his book ! For more technical writeups have a look at ERNW’s  Insinuator  blog, I blog there now and then about Mobile Security and IPv6.

If you have any questions please feel free to contact me at patrik.fehrenbach (at) it-securityguard.com