At the Internet Storm Center, we often receive examples of interesting phishing e-mails from our readers. Of course, this is not the only source of interesting malicious messages in our inboxes – sometimes the phishing authors “cut out the middleman” and send their creations directly to us. Last week, this was the case with a slightly unusual (and slightly broken) phishing, which tries to use legitimate pages overlaid with a fake login prompt.

We were not the first ones to receive a similar message[1], however as our example was slightly different to the one recorded before and the servers, which the attackers used, were still active at the time of writing, I thought this campaign might deserve a second look.

The message itself was a fairly generic phishing, using the commonly seen lure of the type “you have quarantined messages, review them now or they will be deleted”.

The only thing of note in the message was the link, which the victim was supposed to open. It pointed to the following, slightly broken URL.

http[:]//'.$domin.'@antiochspore[.]com[.]sg/portal/?handlers@sans.edu&email=handlers@sans.edu&aGFuZGxlcnNAc2Fucy5lZHU=

It seems that the correct value for the $domin variable was not included in the link, which was supposed to start with “sans.edu”, probably so it would look more legitimate. The link contains three parameters, all of which hold the e-mail address of the recipient – one in plaintext, one in Base64 encoded form and one, where the address is set as value for a parameter named “email”. The latter parameter is the only one which is used by the phishing website for personalization of the content and the inclusion of the other two appears to be completely useless – they may be omitted form the link with no impact on its functionality.

After the URL is opened, the victim is supposed to be redirected from antiochspore[.]com[.]sg to en[.]garden-max[.]eu, where they should see a legitimate page, loaded (in an iframe) from the domain to which the address in the “email” parameter belongs, overlaid with a fake login prompt (see the first picture). This technique, though not new, is imaginative and might lead to convincingly looking results in some cases. In others however, it fails quite spectacularly. Most sites which offer web-based access to e-mail (among others) actively block attempts to be loaded in iframes using the X-Frame-Options HTTP header[2]. If the address in the “email” parameter belongs to such a site, the attempt to load the page in an iframe ends with either only the overlay with login prompt being shown, or – depending on the browser used – results in an error message being displayed under the prompt.

It is worth mentioning that even in cases when the page is displayed correctly, the resulting effect might not always be convincing. For some reason, the overlay has a fixed width set to 1366 pixels.

This means that on larger screens, parts of the underlying page are not covered by it, which looks suspicious to say the least.

Although the technique of overlaying legitimate pages with a fake login prompts is not uninteresting and could potentially be effective against users of certain services, due to use of mechanisms which prevent its effective employment on many modern websites, it hardly presents a mainstream threat.

In case of this campaign, this is compounded by the incorrectly created link with unused parameters and the limited overlay used to cover the legitimate page. This would seem to indicate that whoever is behind this campaign either just used a phishing kit and deployed it with “out of the box” configuration or that they just didn’t spend much time testing their creation.

In any case, although the technique doesn’t pose too large a threat when it comes to real world phishing, it might not be a bad choice for use in a security awareness exercise/phishing tests…

Indicators of Compromise (IoCs)
http[:]//antiochspore[.]com[.]sg/portal/
https[:]//en[.]garden-max[.]eu/userfiles/mail/

[1] https://cofense.com/message-quarantine-campaign-overlying-potential/
[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

-----------
Jan Kopriva
@jk0pr
Alef Nula