Introduction
If you investigate Business Email Compromise (BEC) incidents, you’ve likely come across a suspicious application called eM Client. This client repeatedly appears in our Incident Response (IR) cases. Given its frequent use, we decided to perform a forensic deep dive in the tool to find out what traces it leaves.
What is eM Client?
eM Client is not malicious, it's legitimate software that can be used as an email client for Windows and macOS. It also provides features for managing calendars, tasks, contacts, notes, and even chat services. For the purpose of this blog we will focus on the email functionality of this tool.
How is eM Client (ab)used in BEC cases?
Threat actors abuse eM Client primarily for persistent access and easier management of compromised mailboxes. eM Client allows attackers to:
- Store a local copy of emails, which remains accessible even if access to the original account is revoked.
- Continue phishing campaigns without needing to log in directly to the M365 web interface.
- Maintain continuous access to compromised email accounts due to the application permissions.
- eM Client has a built-in Mass Mailing feature, that can be used to further spam/phish other users.
eM Client supports full mailbox synchronization, enabling users to download all emails, attachments, and other related data from their mailbox to their local devices. By default, synchronization is enabled with the download scope set to all messages without attachments. However, eM Client can be configured to obtain a full local copy of the mailbox. This means that even if containment measures are applied, a threat actor may still have access to the mailbox's contents.
How does it work?
eM Client can be downloaded from the official website: https://www.emclient.com/download. They offer a free version, but it is somewhat limited, as it lacks features like thread view, mass mail, and attachment view. Because of these restrictions, threat actors are more likely to opt for the paid version. Additionally, the free version only allows two email accounts, whereas one of the key advantages of eM Client is the ability to add multiple victim mailboxes and easily switch between them.
Once eM Client is installed, users are prompted to add an email account. The application automatically detects the email provider and proceeds with the login process. For Microsoft 365 accounts, this involves opening a browser window and using modern authentication methods. After successfully logging in, users are required to grant the application the necessary permissions before access is finalized.
Upon clicking Accept, the eM Client application will be granted the following permissions:
Structure
Let's focus on what a threat actor can do with this app and then we will show you how you can detect it using the available logs. Typically there will be multiple phases to an attack.
- Initial Access
- App registration
- Threat actor sign-in events using eM Client
- Persistence
- Configuring forwarding rules
- Configuring delegated access
- Impact
- Email collection
- Sending out emails
Important to note is that not all of these things need to happen, it's up to the threat actor what they decide to do. This blog is meant to show you for all the options what the log entries will be.
Logging required
The following logging can/should be used for an investigation into potential EM Client activity:
- Entra ID audit Log
- Entra ID sign-in Log
- Unified Audit Log (UAL)
Initial Access
In the first phase of an attack, the threat actor will register the application on behalf of a user and use it to subsequently login to the victim tenant for further actions.
App registration
Before a threat can perform any malicious actions the applications needs to be registered in the victim tenant, this allows the user to login and request tokens from Entra ID to perform further actions. In this phase we will have activity in the following logs:
- Entra ID audit log
- UAL
The log entries will be the same between both log sources, the difference is that the default retention for Entra Audit Logs is 30 days and for the UAL it is 180 days.
eM Client application ID
The eM Client application has the app ID e9a7fea1-1cc0-4cd9-a31b-9137ca5deedd, which is a global unique identifier that remains consistent across all tenants when the application is registered. This allows you to detect its activity using this ID. It’s important to note that when the application is registered, certain operations are triggered in the Unified Audit Log, which can be used for detecting this:
- Add service principal.
- Consent to application.
- Add app role assignment grant to user.
The '.' at the end of the operation name is only present in the Unified Audit Log not in the Entra ID Audit Log.
Add service principal
When eM Client is first granted permissions within a tenant, a service principal is created in Entra ID. This service principal acts as the application's identity, allowing it to authenticate and access user data. The ObjectId field will contain the eM Client app ID e9a7fea1-1cc0-4cd9-a31b-9137ca5deedd. The Source user field will show which user or admin initiated the action. (Tip: Right-click open in new tab on images that are unclear).
Consent to application
This operation indicates that a user has granted an application, such as eM Client, permission to access specific resources on their behalf.
Key details captured in this event include:
- Consent Type:
- IsAdminConsent: Indicates whether an administrator granted the consent (True or False).
- OnBehalfOfAll: Specifies whether the consent was granted for all users or just a specific user.
- Permissions Granted: Lists the exact permissions the application has been authorized to use.
Add app role assignment grant to user
This operation in the Unified Audit Log indicates that eM Client, was assigned a role for a specific user in Entra ID. This grants the application permission to access certain resources on behalf of the user. However, eM Client does not define any app roles. When an application does not declare specific roles, Azure assigns the default app role ID 00000000-0000-0000-0000-000000000000. This serves as a placeholder, signaling that the user has been assigned to the application but without any explicitly defined app roles.
Threat actor sign-in events using eM Client
Once the application has been registered, the threat actor can perform logins on behalf of the victim user. As a result we will see login activity in the following logs:
- Entra ID sign-in log
- UAL
The Entra sign-in log will contain additional details on conditional access policies applied the location of the sign-in and the risk evaluation details, see an example below:
Persistence
Once the threat actor has gained access, there are multiple built-in persistence options with eM Client that we will discuss:
- Configuring forwarding rules
- Configuring delegated access
To perform analysis on whether these actions were performed we need the following sources:
- UAL
Configuring forwarding rules
Similar to Outlook, eM Client allows users to create, modify, and delete forwarding rules.
Whenever a mailbox rule is created, updated, or deleted, an event is triggered with the operation UpdateInboxRules. The RuleOperation field contains the actions performed in other words what was done. We can use the associated User Agent to identify that eM Client was used.
What’s interesting is that when you create a new rule via eM Client, an UpdateInboxRules operation is triggered with the RuleOperation Update for all other rules for the user. As shown in the screenshot below, there were two new rules created, however all existing rules were also updated as shown in the screenshot below:
Configuring delegated access
Another option is to configure delegated access. Which means that the threat actor delegates access to the victim to another account under their control. This will generate an AddFolderPermissions event in the UAL. An example is shown below:
In this example the user Joey@bonacu.onmicrosoft.com is getting delegated access over the mailbox of Korstiaan@bonacu.onmicrosoft.com. The ParentFolder.Name shows you which folders. This is your chance to learn some Dutch ;)
Impact
In the final stage of the attack, we typically see the threat actor performing one of the following actions, accessing emails and sometimes sending emails to new victims. We will analyse the following actions that a threat actor can perform using eM Client, focussing on the evidence it will generate:
- Email collection
- Sending out emails
To perform analysis on whether these actions were performed we need the following sources:
- UAL
- Message Trace Report
Email collection
Let's focus on the most important one, eM Client makes accessing and downloading emails very convenient. When you open the application you can add an account and by default it will download all emails for all time.
The threat actor can decide how much email history they would like to download
MailItemsAccessed
To determine what emails were accessed we need to use the MailItemsAccessed operation within the UAL. To filter on relevant data, use the eM Client application ID e9a7fea1-1cc0-4cd9-a31b-9137ca5deedd. These emails should be treated as potentially unauthorized access.
The first time a threat actor logs in with a new account a lot of MailItemsAccessed operations are triggered, because eM Client synchronizes all emails locally to the client. It's important to note that the MailItemsAccessed operation groups emails accessed within a two-minute window into a single record. In the above example the OperationCount field shows that this event relates to five unique emails that were accessed.
Email downloads
During our testing, we found that emails downloaded by eM Client do not appear in the logs. The Unified Audit Log in Microsoft 365 typically tracks actions related to access, modification, or management of data through Office 365 services like Exchange. This is likely because exporting or saving an email is a local action within the client, rather than an operation that directly interacts with the server or services tracked by the Unified Audit Log. This great blog post on the malicious usage of eM Client reached the same conclusion.
Sending out emails
eM Client can also be used to send out emails to determine whether that happened we can use the build in Message Trace functionality in Exchange. One of the indicators that an email was sent via eM Client is the Message ID format. Emails sent through different platforms, such as Outlook Web App (OWA), Outlook desktop, and mobile apps, generate distinct Message ID structures. By comparing Message IDs, it becomes easy to determine whether a message was sent using eM Client or another method. Let's look at an example:
- Message ID for an email sent using eM Client:
emd76c6165-abe1-47e3-bef8-a6b6a4a6f467@0a9f8b29.com (note how this is starting with em?) - Message ID for an email sent via OWA:
AM8P195MB101102608A810AEFC9ED7087E3C52@AM8P195MB1011.EURP195.PROD.OUTLOOK.COM - Message ID for an email sent via Outlook Desktop:
AM8P195MB1011FBA81BC49F22A42B47E8E3C52@AM8P195MB1011.EURP195.PROD.OUTLOOK.COM
By identifying these patterns, you can detect emails sent through eM Client, even if the sender attempts to hide their activity. Conducting Message Traces regularly helps in uncovering unauthorized or suspicious email activity. With the new Message Trace functionality, extracting message trace logs for your environment is now quick and easy. You can use our free tool to acquire these logs.
Another option is to filter on Send events in the Unified Audit Log.
Prevention
To protect your organization from malicious activities involving eM Client or other similar tools, it is essential to implement a combination of proactive measures, monitoring, and access controls. Below are the steps you can take to mitigate and prevent the abuse of eM Client in Business Email Compromise (BEC) incidents:
- Prevent User Registration of Applications
Disable the ability for end users to register applications within your environment. This can be done by navigating to Entra ID → User Settings → Users can register applications and setting it to No. This helps reduce the risk of unauthorized applications being added to your tenant without administrative oversight.
- Review Third-Party Applications
Regularly audit the applications that have been granted consent within your environment. Identify and review applications such as eM Client and remove any unauthorized or suspicious applications.
- Restrict Third-Party Email Clients
Enforce access policies to allow only trusted email clients, such as Outlook or the native apps, and block or monitor unapproved third-party email clients like eM Client. This can be achieved by using App-based Conditional Access to enforce app restrictions. - Restrict Token Use to Authorized Devices
To reduce the risk of stolen session tokens being exploited, configure session token protection to limit token usage to the device or environment for which they were originally issued. This helps ensure that even if a token is stolen, it cannot be used on unauthorized devices, significantly reducing the chances of attackers leveraging it for malicious activities.
TLDR
By now you should know all the different logs and operations we can use to detect eM Client abuse. But in case you forget or when you need a reminder, this mind map shows you where to look for what.
We hope you enjoyed this in-depth review of the eM Client from a DFIR perspective. If you want to support our work consider taking our training or engage us for a cloud compromise assessment.
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