It can be interesting to see how phishing evolves over time. It was not that long ago that that a phishing message, which didn’t require the victim to click a link in order for them to be directed to a phishing site, but rather contained the entire JavaScript-based credential stealing page in a well-made HTML attachment was noteworthy[1,2]. Nevertheless, over time, this technique, as well as many others, has become ubiquitous, and e-mail security scanners have become more capable of detecting and stopping messages that use it. Similar improvements of course force threat actors who specialize in phishing to continuously improve their creations in order for them to be viable.

I noticed one such interesting improvement in May, while looking at several phishing campaigns that used the same “kit” for building HTML credential-stealing attachments.

First of the phishing messages I’ve seen was sent at the beginning of the month. It had a completely empty body, and besides being sent from a legitimate (i.e., most likely compromised) e-mail server, the only slightly unusual thing about it was a reasonably well-made and personalized (i.e., with embedded e-mail address of the recipient) HTML attachment that tried to appear as an Outlook login portal and included the initial “opening letter” animation.

Although the JavaScript that defined behavior of the login form was obfuscated, one could clearly see two URLs in it, and it would be reasonable (and correct) to expect that one or both of these might be used by the phishing page to send any input credentials to.

The second and third phishing messages that contained attachments made using the same “kit” arrived near the end of the month, and they were somewhat more interesting… And not only because they did not simply contain empty message bodies, but instead used the somewhat more believable “you have a new invoice” and “new documents were added to your account” lures.

What was more interesting were the HTML attachment themselves. Although they would behave (almost) exactly the same as the attachment in the first message, the JavaScript that was embedded in them was protected by a much heavier obfuscation (due to it, these attachments were approximately 250 kB larger than the first HTML file).

Although it is instructive to see this difference between earlier and later versions of the same “phishing page”, this, by itself would not be noteworthy. What was much more unusual was the behavior of the HTML page when it was open in a browser and an attempt at its analysis was made.

Probably the simplest way to discover which URL a page is communicating with is to open the “developer tools” panel in a browser and look at the network tab.

As you may see in the image above, this worked as one would expect with the first HTML file.

In case of the second and third one, however, the behavior was somewhat different. If one tried to open the developer tools on the HTML page, one would be greeted with a message about paused execution overlaying the page and making it impossible to interact with it, and the debugger window would open in developer tools. The same message and debugger window would be displayed even if one tried to reload the page in the browser, thus complicating any attempts at an analysis.

This behavior was caused by the inclusion of an elementary anti-analysis/anti-debugging technique using the "debugger;" statement[3] in the obfuscated JavaScript.

Although the use of JavaScript anti-analysis techniques is not new, and in this instance it would be trivial to bypass it (one would simply have to deactivate breakpoints in the debugger), it is somewhat unusual to see such techniques being used in a run of the mill phishing page.

At least, it was unusual until now. Although they probably won’t become as ubiquitous as the “phishing website in an attachment”, since similar mechanisms are quite easy to implement and can potentially effectively hinder analysis if an analyst is not aware of how they work, I wouldn’t be surprised if we start seeing more phishing sites and other malicious pages using similar techniques…

[1] https://isc.sans.edu/forums/diary/100+JavaScript+Phishing+Page/25220/
[2] https://isc.sans.edu/forums/diary/Phishing+with+a+selfcontained+credentialsstealing+webpage/25580/
[3] https://github.com/weizman/awesome-javascript-anti-debugging/tree/main/OldGenTechniques/debugger%3B

-----------
Jan Kopriva
@jk0pr
Nettles Consulting