Background
Welcome back to the frontlines of Cloud Incident Response, which is of course Business Email Compromise (BEC) incidents. On a serious note we strongly believe that for the majority of organizations in the cloud a BEC is probably the most impacting type of incident. It can happen to every type of organization, doesn't matter the size or industry you're in. The only thing you need to have is a Microsoft 365 account (or Google Workspace) and you can be a target. We have shared lots of resources on BEC in the past and also of course the world renowned Microsoft Extractor Suite. We decided it was time for a new blog to shine light on the recent tactics Threat Actors (TA's) employ when trying to compromise a Microsoft 365 environment.
If you enjoy reading about BEC cases you might also enjoy our training or investigating your own incidents with Cloud Labs.
Summary
Most of the BEC incidents we respond to are detected because all of a sudden a lot of suppliers/contacts of the victim company receive suspicious emails and/or payment requests. This case was no different it started with the simple question: "How is it possible that this user sent out ~1k emails in a timespan of minutes?"
What happened?
The diagram below shows the high level incident flow. It started because our client, let's call them Victim B received an email from Victim A with a request to collaborate on a SharePoint document that was hosted on Victim A's SharePoint. This document was a PDF file containing a link to a fake Microsoft 365 login page. The link leads to a so-called Adversary in The Middle (AiTM) landing page that fools the user into supplying their username/password as well as their MFA credentials.
A few minutes after the victim entered the credentials the threat actor logs in from Nigeria using the infamous OfficeHome application. A few days later the TA uses the compromised user to consent to the also infamous PERFECTDATA SOFTWARE application. This application allows the TA to easily read and exfiltrate all emails from the mailbox of the compromised user, which is what they did.
After that the TA configured a forwarding rule to move replies to a specific incoming email (more on that later) to the RSS folder. Next the threat actor does some research and finds interesting emails that can be used for fake invoicing scams and also uploads a file to SharePoint containing a link to another fake M365 login page.
Finally in an attempt to compromise other organizations, the TA shares the file with the malicious link to all the email contacts of the victim user. Additionally a specific set of contacts receives a modified invoice in an attempt to make some money out of this attack. At this stage the attack was discovered, because legitimate users/contacts start contacting the vicitim that they received weird emails.
.png)
Initial Access
This incident started according to a quite popular tactic that we observed in multiple incidents by sharing a file via SharePoint from an earlier compromised company. This tactic is highly effective, because sharing a file via SharePoint is very common and will not trigger alerts in an email security platform. Especially because this file is shared from someone who has communicated with the victim before. The file can be different in your case, but oftentimes it will be a PDF that either contains a link that the user can click on that leads to a fake Microsoft 365 login page or a QR code that leads to that page. Regardless this leads to a user entering their credentials and MFA, allowing the TA to hijack the session.
Evidence
Unified Audit Log
- MailItemsAccessed (User receives and opens the email that was sent from SharePoint or Exchange with the malicious file)
- FileDownloaded (Only in the tenant where the malicious file was shared from)
- FileAccessed (Only in the tenant where the malicious file was shared from)
- UserLoggedIn
Entra Sign-in log
- Login from an IP-address associated with a VPN (Use tools like ipinfo.io or spur.us to enrich your data)
- Login with the application OfficeHome (Prefered and used by most phishing kits)
- Login with the user-agent axios/1.11.0
Message Trace Log
- Search for emails that were received before the first malicious login occured
Important: When analyzing the Message Trace Log keep in mind that if the email with a collaboration request or sharing of a file was sent from a tenant with a non-English configuration the subject will be in the local language.
Persistence
Once the TA successfully gained access they took their time reading emails and understanding their environment. As you will see in the Impact phase they were particularly interested in invoices that were supposed to be paid by suppliers of the victim companies. In this phase they found an invoice that they thought could be abused. For that purpose they created a new mailbox rule. This rule would move any email originating from a specific domain to the RSS folder of the victim. Initially, we didn't know why this domain was specifically targeted until we analyzed the outgoing emails and found that fake invoices were sent to this domain. This rule would've made sure that if the supplier sent back an email saying the payment was done or that it was weird the victim wouldn't see it. Unless they manually checked the RSS folder.
In a later stage another inbox rule was created that would send any incoming mail to the victim to the RSS folder. This was done at the end of the incident when the attacker send out close to 1k emails. Most likely this was done to prevent discovery of the attack, however due to this rule no incoming mails would be visible to the victim anymore which would most likely lead to discovery.
Evidence
Unified Audit Log:
- New-InboxRule (Most TAs prefer short names for mailbox rules)
Defense Evasion
The TA did their best to make it difficult for us to analyze the phishing emails that they used to gain access to the environment. They performed email HardDelete actions, which purges an email and makes it impossible to restore after 14 days. Within that period, there are multiple ways of restoring as described in this Microsoft blog. The fact that the TA deletes emails is useful for us, because it's quite rare to see HardDelete operations for normal users. Therefore it's a good hunting opportunity and for us it's an easy to find out what emails the TA didn't want us to see. And of course those are the emails we will do our best to restore...
For example this email was sent out to almost 400 email contacts via SharePoint and subsequently it was HardDeleted and removed from SharePoint.
Well who wants to guess where that link leads to if you click on Open?
If you guessed a fake M365 login page you are a winner! More on that in the next chapter.
Evidence
Unified Audit Log:
- HardDelete
Impact
At this stage the TA has been in the environment for a while, one of the ways that they access emails belonging to the victim is by using the PERFECTDATA SOFTWARE application with Application ID ff8d92dc-3d82-41d6-bcbd-b9174d163620. We and others have seen this application being used quite often in BEC cases, it's legitimate software that allows you to read emails and allows the TA to easily read and filter on mails. Most of the time cracked versions of PERFECTDATA Software or EM Client are abused for this purpose.
After this the TA also performed several actions to further breach other organizations. Two methods were used for that purpose:
- Upload malicious file to SharePoint and add people as collaborators
- Email specific orgnizations to get invoices paid
Method 1 - SharePoint sharing
In this method the TA uploads a file to SharePoint with a link to a fake login page and in the sharing menu adds in the recipients. This results in AddedToSecureLink events that can be used to identify which files were shared and who with. Below is an example event:
Method 2 - Direct email
Over the course of the incident the TA identified several suppliers that were paying our victim regularly. They hopped on this train and modified existing invoices and send out requests for payment to a bank account they controlled. They used the inbox rule from the earlier phase to hide any response to the fake invoices.
Due to the barrage of emails this incident was discovered and we were engaged to investigate, this marked the end of the TA activity. One other action we performed was inspection of FileDownloaded events to identify which users downloaded and accessed the malicious files on SharePoint. We wanted to make sure that those users were aware that the links were malicious and additional investigation needed to be performed.
Evidence
Unified Audit Log:
- MailItemsAccessed (Focus on events originating from the App ID belonging to PERFECTDATA SOFTWARE)
- Create (Recorded for new emails)
- Consent to application. (Inspect the App ID to identify malicious ones)
- FileUploaded (The malicious file that is uploaded)
- FileDownloaded (This can be used to identify all the victims that accessed the malicious file and downloaded it)
- Send (Track what emails were sent out)
Message Trace Log:
- Emails that were sent out with invitations to collaborate
Wrap-up
The above BEC incident is not unique we have seen several variations of this in the past months. What makes it so effective is the usage of SharePoint for sharing, which helps getting past email security solutions. This type of incident causes the 'snowball' effect, where if one organization gets compromised the TA abuses the trust and uses SharePoint to avoid detection and this snowballs to the next organization where again all their contacts receive similar phishing emails.
Recommendations
Some ideas to prevent these types of incidents or limit the impact:
- Block user consent for applications in Entra. By default users are allowed to consent to applications such as PERFECTDATA SOFTWARE, we highly recommend disabling this.
- To prevent AiTM attacks, consider implementing strong MFA methods using hardware tokens or software passkeys. These types of tokens require physical access to a token or to the device, which obviously the TA does not have.
- Implement strict Conditional Access policies for example geofencing, where you limit logins from countries you are not active in (e.g. block a login from Nigeria).
- Limit or block external sharing in SharePoint, this is a more tricky one and it depends on your company, but you might consider limiting external sharing in SharePoint.
- Monitor for high impact actions such as consenting to applications, purging emails and the creation of mailbox rules.
Indicators of Compromises
For further details on this campaign, we’ve compiled a list of IOCs and TTPs into a repository on our GitHub.
About Invictus Incident Response
We are an incident response company and we ❤️ the cloud and specialize in supporting organizations in preparing and responding to a cyber attack. We help our clients stay undefeated!
🆘 Incident Response support reach out to cert@invictus-ir.com or go to https://www.invictus-ir.com/24-7