Microsoft Encrypted Restricted Permission Messages Deliver Phishing
Over the past few days, we have seen phishing attacks that use a combination of compromised Microsoft 365 accounts and .rpmsg encrypted emails to deliver the phishing message. At this stage, we are exploring and uncovering different aspects of this campaign and will share here some of our observations to date.
It starts with an email that originated from a compromised Microsoft 365 account, in this case from Talus Pay, a payments processing company. The recipients were users in the billing department of the recipient company. The message shows a Microsoft encrypted message. In the email, the From: and To: email address displayed in the header were the same, but the message was delivered to various third party recipients.
Note the email has a .rpmsg attachment, a Microsoft technology which stands for restricted permission message file. Essentially it is an encrypted email message stored as an attachment. As a recipient, you must be authorized to view the message. This check is performed by some form of authentication by the Rights Management service that was used to protect the file. Your Microsoft email and password might be checked or you might apply for a one-time passcode. The permissions can also extend to whether the recipient can forward the original message.
Note: After this email was sent, Talus Pay, to its credit, sent out an email to its contacts warning that one of its accounts had been compromised and it was investigating.
Viewing the Message
In the message body, behind the “Read the message” button there is a long URL that points to office365.com in order to be able to view the message:
Note the sender email address hidden in that link:
And the Microsoft 365 organization domain:
Clicking the link will show this Microsoft Encrypted message page:
If you don’t authenticate with your Microsoft account, you can ask for a one-time passcode which Microsoft will email to you to be able to decrypt the message.
If you generate a passcode and enter it, you would then be able to view the contents of the message online at Microsoft. The message below has a bogus SharePoint theme.
Landing Page and Redirection
If you clicked the “Click here to Continue,” you would be directed to another fake SharePoint document, this time hosted on Adobe’s InDesign service:
The Phishing Site
If you “Click Here to View Document” on the Adobe document you will be redirected to the final destination, the domain of which resembles the domain of the original sender, Talus Pay. But this domain has a .us TLD and was registered recently on the 16 May 2023.
If you browsed to this site, you would immediately see a “Loading…Wait” in the title bar.
- visitor ID
- connect token (hardcoded from the configuration),
- connect hash (hardcoded from the configuration),
- video card renderer information
- system language
- device memory
- hardware concurrency (# of processor)
- browser plugins installed
- browser window size, orientation, and screen resolution
- OS architecture
Finally, you would be presented the final phony Microsoft 365 phishing credential site.
In addition to the message example above, we have seen two other email examples, and are aware of other URLs as well (for example this Joe Sandbox report). No doubt there are others as well.
The other email examples were very similar in style but were received from a different compromised Microsoft 365 accounts, they had the following subjects:
Farmers and Merchants State Bank 05/18
The messages were almost identical in style to the Talus Pay sample.
The same email address was used in the link:
But they pointed to slightly different Adobe hosting links. Below is the one for Farmers and Merchant’s State Bank, which was still alive at the time of visiting:
For the email relating to the Farmers Bank, the final destination was again a domain related to the sender of the email with a .us TLD, this time registered on 18 May 2032. This link was dead at the time of visiting.
Conclusion and Mitigation
These phishing attacks are challenging to counter. They are low volume, targeted, and use trusted cloud services to send emails and host content (Microsoft and Adobe). The initial emails are sent from compromised Microsoft 365 accounts and appear to be targeted towards recipient addresses where the sender might be familiar.
The use of encrypted .rpmsg messages means that the phishing content of the message, including the URL links, are hidden from email scanning gateways. The only URL link in the body of the message points to a Microsoft Encryption service. The only clue that something might be amiss is the URL has a specified sender address (chambless-math.com) unrelated to the From: address of the email. The link was likely generated from yet another compromised Microsoft account.
In terms of mitigation:
- Consider how you handle inbound messages with .rpmsg attachments from outside parties. Depending on how many you expect, or your users’ need to receive them, you may want to consider blocking, flagging or manually inspecting .rpmsg attachments.
- Monitor inbound email streams for emails from MicrosoftOffice365@messaging.microsoft.com with the Subject: “Your one-time passcode to view the message”. This may give insight into users who have received .rpmsg messages and have requested a passcode.
- Educate your users on the nature of the threat, and not to attempt to decrypt or unlock unexpected messages from outside sources.
- To help prevent Microsoft 365 accounts being compromised, enable Multi-Factor Authentication (MFA).
For Trustwave MailMarshal customers, you can create a rule for inbound traffic, and recognize the attachment type by the FileType “Restricted-permission message” under “Azure IRM protected documents.” You can also use a Filename extension rule with *.rpmsg. In terms of action, you can choose to quarantine, copy, or stamp the message or subject with a warning. We are continuing to track this campaign and are responding with updated protections as needed.
Sender Address used in links in .rpmsg messages:
Intermediate Landing Pages:
Yara rules for Phishing page:
description = "detects JS obfuscation on the intermediate landing page"
$str_conn = "connectURL"
$str_foll = "followRedirectURL"
$str_ctest = "cookietest=1"
$string_fpjs = "https://m1.openfpcdn.io/fingerprintjs/"
all of them
description = "detects the main phishing page configuration"
author = "Trustwave SpiderLabs"
$str_htmltag = "<!DOCTYPE html>"
$str1 = "dumpLocalCookies"
$str2 = "dumpLocalStorage"
$str3 = "WebSocketSubject"
$str4 = "WebSocketCtor"
$str5 = "hookServerURL"
$b64_wss = "d3NzOi"
$str7 = "https://github.com/zloirock/core-js"
all of them