Nothing but the same old threat? Phishing campaigns always seem to proceed by the same principle: A link or attachment placed in an email redirects to a phishing website to retrieve specific data about the recipient. However, for some users, a certain process has now become established that is designed to expose the traditional phishing tactics. Now the Hornetsecurity Security Lab has discovered a phishing scheme that is designed to circumvent this method.

 

The Procedure

In case of the detected phishing scheme, the entire phishing website is sent to the victim as an HTML attachment and then executed locally in the browser.
While investigating such phishing activity, the Security Lab discovered an interesting tactic in one of the phishing web forms used. In one form, the first password entered by the user is always rejected as incorrect and only the second password is accepted.

This is likely to workaround a methode that some users came up with to protect against phishing. Some users believe that phishing websites will always accept any password. Hence, you can spot a phishing website by entering a wrong password. A phishing website will accept the wrong password, while the legitimate site will reject it as incorrect. This assumption is, however, wrong and the Security Lab will outline why in this article.

 

Background

Phishing via sending victims the entire HTML source of the phishing webpage as an email attachment is nothing new [1]. The general outline is that the victim receives an email with an attached HTML document.
Here we can see a recent example of such a phishing attempt against a bank:

 

 

In the email the user is told that the user profile must be updated otherwise the services of the bank can not be used anymore.

When the user opens the attachment, a form asks for the users credentials or in this case a whole array of private and confidential information:

 

 

The document is even so helpful and checks (locally via HTML5 features) whether the information the user has entered has a valid format, e.g., the email contains an @ symbol, etc.:

 

 

Once the user’s input was locally validated, a HTTP POST request is issued sending the entered information to a remote server:

 

 

This scheme is a great way to prevent your phishing website from being blacklisted, as there is no visible phishing webpage online that a hosting provider could take down. Getting a website banned because it receives HTTP POST requests is a hard one to convey to a hosting provider or owner of a compromised website.

Recently the Security Lab found an interesting new twist to this scheme in a long running scheme of such HTML phishing attachments pretending to be from one the major integrated container logistics and supply chain companies.

 

Analysis

The phishing activity the interesting scheme is part of is going on uninterrupted for month – and in a different form likely for years:

 

 

 

The fact that more emails are send during business days would indicate that this activity is targeting businesses:

 

 

Even though the langauge of the phishing emails is exclusively English, the emails are send predominantly to German, US and UK companies:

 

 

Granted the country distribution is slightly biased by Hornetsecurity’s client base since Hornetsecurity is a market leader in the DACH region.

As an interesting note, the networks from which these emails are send from are as follows:

 

 

With the owners of the 7 AS with the highest volume of send emails being:

Volume ASN ASN owner
5450 199653 ARUBAFR-AS, FR
5425 6697 BELPAK-AS BELPAK, BY
3300 266772 TRIMOTION S.R.L., AR
1450 8374 PLUSNET Plus network operator in Poland, PL
1375 15704 XTRA TELECOM S.A., ES
1275 54290 HOSTWINDS, US
1225 1221 ASN-TELSTRA Telstra Corporation Ltd, AU

 

Asking the user twice

While most of the observed phishing documents follow the scheme previously outlined – except for asking the user only for a password and having the user’s email address already pre-filled in the document – a few other phishing documents in this series, however, come with a twist.

When opening the phishing document the user is asked to input the password to preview some shipping documents:

 

 

Irregardless of what password is entered, the user is immediately presented with another password popup form claiming that the password that was entered is incorrect:

 

 

This is probably done in an attempt to prevent clever users from first trying with a made up password – in case it is phishing – and only entering their
real password when a fake password won’t get them in.

But only that last entered password is send to the remote server:

 

 

Last but not least, the user is redirected to the image hosting service Imgur and presented with an image of shipping documents:

 

 

Obviously, those pictured documents are as fake as the phishing email itself.

 

Conclusion and Remediation

This example shows that the trick proposed by some users to protect against phishing by always entering a false password first and only after that password was rejected enter the correct password, does not work. The logic behind this trick seems to be that most phishing forms will accept any password. So if a system rejects a wrong password it must be legit, how else would it know that the password is wrong. But as this case has shown a phishing form can simply reject your password, too. In fact it could reject all passwords and send all attempts to the attacker in hopes that the victim will hand over all passwords while trying to log into the fake password form.

Remediation is not so simply. Because the phishing webpage is loaded locally into the victims browser, blacklists such as Googles Safebrowsing will not warn the user that a phishing webpage is opened. Another thing is the exfiltration mechanism. The single HTTP POST request is send to a likely compromised WordPress website, making it hard to discover in a busy network and because there is no visible phishing website online also hard to investigate by a network analyst.

The safest way to protect against these HTML phishing webpage attachments is to not allow them into the users mailbox in the fist place. For example, the precise analysis mechanisms of Hornetsecuritys Spam and Malware Protection detect such emails in the first filter instances and block these phishing emails before they can be delivered to a mailbox.

 

References