Recently, one of our customers reported an email that struck them as being fishy. The email came from a trusted external source, and included a whole host of recipients with whom they had been conversing for a while. What stood out, however, was that in order to view the email itself, the user was prompted to save and open an attachment “message.html” and follow the instructions inside. Before opening the attachment, the user decided it best to forward the email to a helpdesk employee, who in turn reported it to the Spotit am I phished service for further investigation.

Image 1: Suspicious email as reported by the customer.

Upon initial analysis, some interesting features were extracted from the email. First and foremost, any HTML attachment sticks out like a sore thumb. These should, in almost any circumstances, be blocked by default, as they’re rarely legitimate, and many alarms get raised when Outlook opens a web browser. Additionally, it is strange when one user sends a suspicious email to multiple separate recipients from different companies, and can be indicative of business email compromise (BEC).

Next, a review of the main body content raises some questions as well. Why are there no Microsoft logos? Why does the layout appear so strange? Even the selected font family stands out: Segoe UI Semilight, Segoe UI, Segoe, Helvetica, Tahoma, Arial, sans-serif; compared to the official font family from microsoft.com – “Segoe UI”,SegoeUI,”Helvetica Neue”,Helvetica,Arial,sans-serif. While the text itself does not play on the typical sense of urgency, scarcity, or intimidation, it still prompt the user to save and open the attachment, and to log in with their work email address.

The attachment itself, when opened, looks similar to the email content, and provides the option to sign in with a Microsoft account, or using a one-time passcode (OTP), which is then sent to the user’s email address. Suspiciously, when you click on either option, a fake “Loading, please wait…” message appears, and remains there for an approximate 10 seconds before the next page actually loads in.

Image 2: Suspicious attachment message.html prompts for user authentication.

The page that is loaded in for authentication, which is required in order to view the encrypted message, is benign as the domain belongs to Microsoft: https://outlook.office365.com/Encryption/signinpage.aspx

Image 3: Sign in with a Microsoft account.

This makes it clear that the attachment makes use of the legitimate authentication service. Even further, when the user chooses to sign in with a work or school account, the page redirects to https://login.microsoftonline.com/login.srf for the official login form.

So, this makes it clear that the email is legitimate then? Well, not necessarily… It is uncertain what message is behind the authentication. A file on Google Drive may not be shared publicly, but that does not mean that the file itself is benign. And so the encrypted message may, once decrypted, still prove to be malicious, and direct to user to another domain owned by the threat actor, requesting the user to submit their Microsoft credentials again.

At this point, many things indicate that the email might be malicious, or at least suspicious. There’s the strange layout, the odd font family, the HTML attachment, the fake loading, … On the other hand, the email has the Sensitivity label marked as confidential, and there is an option in Microsoft to automatically encrypt confidential emails in this way, providing a HTML attachment for the recipients, known as the Office 365 Message Encrytpion (OME).

Unfortunately, the investigation of the SOC analyst stops here, as authentication of the recipient is required to view the message’s content. As it is unclear whether the message itself is safe or malicious, and keeping in mind the previously mentioned suspicious features, it is better to err on the side of caution and provide a malicious verdict to the customer. In this case, Spotit prompted the customer to verify with the sender (via known trusted channels) if the communication was intended and legitimate, which was later confirmed to be the case.

This technique for phishing campaigns was discovered earlier and explained in great detail by Trustwave back in May of 2023. In their blog post, they explain how a compromised email account sent out an email with a .rpmsg attachment, a Microsoft technology which stands for restricted permission message file. Post authentication, the decrypted message shows a bogus SharePoint theme, which redirects to a fake SharePoint document, hosted on Adobe’s InDesign service, which in turn redirects to the phishing page, presenting the user with a phony Microsoft 365 login.

Finally, below is some advice to help mitigate these types of phishing emails:

  • You may want to block or flag emails with .rpmsg attachments from the outside. Additionally, consider blocking HTML attachments outright.
  • In order to gain insight into what users are receiving a one-time password, set up monitoring for emails from [email protected] with the Subject: “Your one-time passcode to view the message”.
  • On the topic of user awareness: inform users of the dangers that coincide with these encrypted messages from the outside.
  • As always recommended as protection against phishing, enable Multi-Factor Authentication (MFA) as an additional layer to prevent account compromise.