Spammers have been getting craftier with how they get through the bayesian and other heuristic filters many mail providers use to deliver only legitimate emails to recipients. One of the ways they do this is by encoding or encapsulating patterns into base64 or some other encoding mechanism. This allows the email client to render a message with text that would have been blocked by a spam filter as the filter usually can’t comprehend the encoded strings. These usually come down in the form of htm or html attachments where the email client effectively acts as a web viewer to render data to the screen.
If we take a sample of one of these attachments, as seen above, decode the base64, and view them in terminal, we see that the html file is calling a javascript and unescaping characters. So not only is this an html file that contained base64 encoded text, but then it escaped portions in order to hide even more stuff. Even if we told a filter to decode text, which would be more computationally expensive and delay messages stuck in a filtering queue, we’d then have to parse out other junk, often resulting in new base64 encoding text.
We can’t outright block html because most mail clients create messages in html. But we can block html attachments with a nice message back to the sender. To block a message with an html attachment in Office365, we add a rule in the mail flow section of a tennant. To do so, open the Office365 admin interface and then click on Exchange to open the Exchange admin center. Then, click on Mail flow in the side bar and then click on Rules.
From the Rules screen, click on the plus sign to create a new rule. At the “Set rules conditions” screen, provide a name (I chose Block htm and html) and then set the “Apply this rule if” option to “Any attachment” and define those as ‘htm’ and ‘html’. For the “Do the following” field, select reject message and include a message about why the message was blocked, just in case there’s a legitimate need to send the necessary attachments. Alternatively, the messages could just get bounced with no message, but there’s a chance that a legitimate piece of mail will be assumed to have been delivered.
Once the filter is created, hit Next, then Next for the rule settings and the review screen. Once created, don’t forget to enable the rule. To do so, click on the rule and slide the little slider to Enabled.
Regretably, javascript can be embedded in a lot of things, including a pdf. There, we can drill down a little further into the contents of an attachment. As seen here, we scan for content that includes a word with the word being javascript.
And yet… spammers are crafty. A compressed pdf or encoded blob can still have the word javascript in it, but hey, at least we’re making progress. Office365 has attachment options for “is executable”, which blocks other known extensions (e.g. .exe), and an option for what to do with messages that didn’t complete scanning or those that couldn’t be inspected. But banks and other websites can send unscannable files to initiate an authentication or authorization flow (especially if they’re using older platforms to do so, and given the time to implement tech with all the regulations they have to adhere to, plenty do). So ymmv with angry users the more roadblocks you put in place.
Contrast this with the options for handling attachments in Outlook, which are based on email address in the Junk settings, or just a boolean “has attachment” option in the rules, and users can’t really be expected to implement their own filters to block such traffic…
