MS Spear Phishing Attack simulator can potentially expose your users' passwords

Quite some time since my last post, but I had some pretty nice case recently, and because MS support seems not really interested to make deeper investigation by themselves, I wanted to put this piece of information somewhere, so others can also be aware about the potential security flaw in the tool called "Spear Phishing (Credentials Harvest) Account Breach" in the Attack simulator set of tools. You can find these tools on the Office 365 Security & Compliance portal in Threat management section.

First of all, what this tool is and what it does? In a very short, this tool allows you to send a specially crafted message to your users , which contains links to a quasi-malicious page disguising the genuine Office 365 login page. Why "quasi-"? Because in fact these pages are on the MS controlled domains, however not really used for real MS services. Example links from the tool: http://portal.docdelivaryapp.com, http://portal.hardwarecheck.net or http://portal.docstoreinternal.net.

The tool is aimed to check if your users are vulnerable to the phishing attacks by collecting statistics of how many users clicked on the link and how many of them provided the login and password on the fake page. The example below is only a test, not presenting any of the real results.

No HTTPS? May not be a problem, ... 

First thing you notice, is that those links direct to non-encrypted pages. I assume it was done intentionally, to give users a basic indicator of the potentially malicious message. I will not discuss the effectiveness of such decision in this post, but I should mention that nowadays there is no problem to make the malicious page have a valid SSL/TLS certificate.

Anyways, what attracted my attention to the security of this tool was a possibility to eavesdrop the credentials which were sent to the fake page. Your user can receive the phishing email being in public place, connected to some public hotspot, and they could rely on the usual encryption of the MS portals, which leads us to the risk of the real password leakage while only simulating the phishing attack.

However, it turned out that MS developers made their job to avoid this situation, so every time user submits the password, it is changed by script to a static value of "PasswordSupplied" prior to be sent.

Each time user submits the credentials, the tool does not collect and does not check if the password is correct, but just indicates in statistics that user has it provided. Thus, lack of https in this case may not be a problem, ...

... however :)

In some circumstances users' passwords can be sent unencrypted to the attack simulator page. And the circumstance is ... a password manager! It's paradoxical, but the tool that aimed to keep your passwords secure can help make them exposed. How?

As you know, from user's perspective the Office 365 login process consists of two steps (without MFA). First you provide an "Email, phone, or Skype", click Next, and only then you provide a password, and click Sign in.

It was found out (with user's help, btw), that if user tells the password manager to fill in the credentials on the first page, where usually you provide the login only, the password manager also fills in the hidden "passwd" field. And because on the first page there is no password replacement script, when user clicks Next, it submits the password, provided by the password manager, via non-encrypted connection.

This behavior was confirmed with the built-in Chrome password manager and with Bitwarden.

I would suggest the tool's developers to change autocomplete="off", which obviously does not help, to autocomplete="new-password". Alternatively, to add the PreCheckBeforeSubmit() function to the form on the first page also. The solution depends on what you want to achieve with this field.

I submitted the case to MS support, with the brief description of the problem, but they wanted me to run the debugging tool before they escalate this to backend team, which I think is rather their job and waste of my time.

Nevertheless, the Spear Phishing Attack simulator is very much worth to try, and as it does for me, it may open your eyes on the phishing attacks vulnerability scale, and also make a solid ground for the awareness training for your users. If you concern the potential password leakage risk, you can mitigate it by two things. First, you can send the post-attack-simulation message notifying users to change their passwords if they clicked and provided the password, and second, but which is more important, if you still haven't enabled MFA for your users, do it ASAP!

Stay safe!