Frankenstein's phishing using Google Cloud Storage

Published: 2020-05-27. Last Updated: 2020-05-27 08:39:20 UTC
by Jan Kopriva (Version: 1)
1 comment(s)

Phishing e-mail messages and/or web pages are often unusual in one way or another from the technical standpoint – some are surprisingly sophisticated, while others are incredibly simple, and sometimes they are a very strange mix of the two. The latter was the case with an e-mail, which our company e-mail gateway caught last week – some aspects of it appeared to be professionally done, but others screamed that the author was a “beginner” at best.

The message appeared to come from info[@]orlonvalves[.]com and passed both SPF and DKIM checks. Contrary to popular belief, it is not that unusual to see a phishing e-mail from an SPF-enabled domain[1,2]. Phishing message with a valid DKIM signature, on the other hand, is something, which is usually seen in connection with a compromised e-mail server. Although it is possible that this was the case in this instance as well, I’m not completely sure about that. The reason is that the domain in question was registered about half a year back using Namecheap, neither it nor any existing subdomain appears to be hosting any content and no company of corresponding name seems to exist. In contrast, a company named Orion Valves, which uses the domain orionvalves[.]com, does exist and although we may only speculate on whether the domain was intended to be used for phishing, since the substitution of characters (i.e. “l” for “i”) in lookalike domain names is a common tactic for phishers, I wouldn’t be surprised if this effect was what the domain holder was actually going for.

As you may see, apart from the potentially interesting sender domain, the message was a fairly low-quality example of a run-of-the-mill phishing. It claimed to be from Microsoft, but also from a source at alef.com (i.e. our company domain). The only further small point of interest connected with it was hidden within its HTML code. Even though it is usually not necessary to analyze the code of phishing messages, it may sometimes provide us with at least some information about their authors. In this case, for example, given that there are attributes “data-cke-saved” and “data-cke-eol” present in the code, we may surmise that the author most likely used the CK Editor to create the HTML code (and that he probably used a historical phishing message which pointed to different phishing pages as a base to build it from)[3].

As the code shows, the links in the message lead to the following Google Cloud Storage URL.

hxxps[:]//storage[.]googleapis[.]com/update-securities20420.appspot.com/%2525%2525%2525%2525%2525%2525/login.html

I reported the URL to Google, but since the page is still reachable at the time of writing, you may be able to take a look at it yourself, if you’re interested.

Although web page didn’t look like anything too special at first glance, at the second one it turned out to be quite interesting for multiple reasons.

It was self-contained, with all scripts, styles as well as pictures embedded in the code. This technique is sometimes used by attackers in order to create phishing pages they may use as attachments[4], but isn’t too common for the server-hosted phishing sites (though, given where this page was hosted, use of the technique makes some sort of sense).

It also appeared to be fairly well written – the author expected both a situation when a script blocker would stop JavaScript from executing and a situation when the scripts would be executed. If JS execution was possible, it would “personalize” the contents of the page and pre-fill the users e-mail address in the form, if not, it would stay in a more generic, but still fully functional form.

On the other hand, personalization of the page wasn’t the only thing which the embedded JS would try do.

Another piece of JavaScript contained an encoded version of the entire page (i.e. code identical to the one present in the HTML) and it would try to decode it and write it in the body of the document. This would be a bit strange by itself, since – as we’ve mentioned – both versions of the HTML code were the same and if the code were to run, it would result in the entire contents being present twice (i.e. two complete credential stealing forms on one page). But where it got even stranger was the placement of the JavaScript code – it was placed in a style tag within the head portion of the site, which would result in the code never executing (at least not in any browser I’ve tried). It was also probably supposed to be commented out, though it didn’t end up that way as there was a newline after the comment tag instead of a space… In short, there was no reason for the code to be there as it would never run and the way in which it was embedded was completely wrong even if the author intended it as some sort of backup.

If a target of the phishing were to input his credentials in the page, they would be sent in a POST request to the following URL:

hxxps[:]//hondarebirth[.]com/Zhejiang22320/need.php

After that, the browser would be redirected (HTTP 302) to another PHP script on the same server (go.php) and from there to the domain, to which the e-mail address, which was specified in the form, belonged. Redirection to a legitimate domain after credentials have been gathered by a phishing site is quite a common tactic, since the target may then come to believe that they simply made a mistake while typing the password.

As we may see, the phishing really was a strange mix. On one hand, we have the use of a potential phishing domain with SPF and DKIM set up to send the original e-mail, a well-written phishing page and a fairly standard credential gathering mechanism using a different domain and server from the ones hosting the phishing site itself. On the other hand, we have a very low-quality phishing message trying (though not very hard) to look like it was sent by two different sources at once and a nonsensical inclusion of JavaScript in the phishing page, which would never execute, but if it did, it would completely ruin the appearance of the page as anything even nearly legitimate.

Who knows how this came to be – perhaps the attackers cobbled together pieces of different phishing campaigns they found online and ended up with something functional but resembling the creation of Dr. Frankenstein more than anything else...

 

Indicators of Compromise (IoCs)

hxxps[:]//storage[.]googleapis[.]com/update-securities20420.appspot.com/%2525%2525%2525%2525%2525%2525/login.html
hxxps[:]//hondarebirth[.]com/Zhejiang22320/need.php
hxxps[:]//hondarebirth[.]com/Zhejiang22320/go.php

 

[1] https://isc.sans.edu/forums/diary/Phishing+email+spoofing+SPFenabled+domain/25426/
[2] https://isc.sans.edu/forums/diary/Agent+Tesla+delivered+by+the+same+phishing+campaign+for+over+a+year/26062/
[3] https://ckeditor.com/old/forums/CKEditor-3.x
[4] https://isc.sans.edu/forums/diary/Phishing+with+a+selfcontained+credentialsstealing+webpage/25580/

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

Keywords: Email Phishing SPF
1 comment(s)

Comments

I too have found google (and Microsoft) slow to respond to phishing complaints. It is not you.

Diary Archives