If you’ve found your way to this article, it’s likely because you have found a suspicious application content for eM Client. This is an application that is similar in it’s usage to PERFECTDATA SOFTWARE, but is also distinct. While the exact reason why threat actors use that application is not conclusively known, my examination of it’s behavior has uncovered some features that make it useful for threat actors during a business email compromise.
Methodology
Unlike my investigation into PDS, I did not have to search hard to find eM Client. Simply Google the name, and you will see eM Client’s website as the first result. Once I found the application I downloaded and installed it into a virtual machine running Windows 10. For the accounts, I used two accounts and one shared mailbox, all from my Honeypot Developer Tenant.
The Basics
I describe eM Client as an alternative mail access program. It connects using Exchange Web Services, which is an API that allows non-Microsoft applications to integrate with Exchange Online and On-Premise Exchange. Using EWS, most features you would have with Exchange Online are available, with the option for custom features and settings. These custom features will be relevant later.
eM Client is available for a variety of operating systems, and is available under a free or paid license, though none of the features included with the paid license seem to be particularly notable for use in BEC.
Once you install eM Client, you are given the option to add an email address. eM Client automatically detects the email provider and continues the login process. For M365, this means opening a browser and using the modern authentication login. After logging in, you are presented with a request to accept the application’s permissions.
The exact permissions granted to the applications are your standard permissions for most integrated oauth applications, with the addition of EWS.AccessAsUser.All. This final permission allows eM Client full access to the accounts primary mailbox and any delegated mailboxes. Interestingly, unlike with Outlook desktop where delegated mailboxes usually open automatically, with eM Client delegated mailboxes need to be explicitly added, similar to using OWA. Once added, they appear on the side bar, like with Outlook desktop.
Finally, the browser redirects you back to eM Client to finish the setup process and open your inbox.
Now you can access the mailbox as you would via Outlook Desktop. Since multiple accounts for multiple email providers can be added, this application would allow threat actors to easily switch between many compromised accounts without having to sign in/out.
Interesting Features
As I mentioned earlier, eM Client’s use of EWS means that it has many features and settings that are interesting and potentially useful during a BEC.
- Offline mail storage. The email is not stored in a PST or OST, but is instead stored in a database (or more accurately, several databases) within the user’s appdata folder.
- Email download. eM Client can be used to download all emails that it has access to. This is similar to PDS, but eM Client can only download the emails as individual .eml files. This download works for all mailboxes in the client, primary and shared.
- Mass mailing. eM Client has a built-in Mass Mailing feature, which eliminates the need to use other programs or scripts.
- Option to not mark emails as read. If this feature is used, it is less likely the legitimate mailbox user will notice anything amiss if they happen to be in the mailbox at the same time the threat actor is.
- Option to not place sent emails into the “Sent” folder. This option also effects what the legitimate mailbox user would see, so the threat actor can send email without needing to remember to delete it from the sent mail folder.
- Access and export of contacts, calendar events, and tasks. Access and export of contacts is available in various formats, which are sold as ‘leads’ on darkweb marketplaces. These ‘leads’ are the recipients of future spam and phishing campaigns. (Hint: Massive privacy breach.)
A forensic look at eM Client can be found here. Shoutout to the authors!
Tenant-side Activity and Audit
Using my HoneyTenant and my eM Client installation, I was able to see what the artifacts of eM Client usage would look like in the tenant. I will mention that my tenant has E5 licensing which enables advanced audit logging, so your milage may vary.
Sent Mail
Even if sent mail isn’t viewable within the user’s sent folder, you can still see sent mail via a Message trace. It’s very easy to tell when an email has been sent using eM Client, as it’s Message ID is very different than it would be if the email had been sent from OWA, Outlook desktop, mobile app, etc.
Other than that, I was able to find no notable difference between sent emails.
Email Access
Records for email access under the MailItemsAccessed event came from the ClientInfoString Client=REST;Client=RESTSystem;; or Client=WebServices;eM Client/9.2.2157.0 (ExchangeServicesClient/9.2.2157.0);. If you’re familiar with the MailItemsAccessed record, then you may know the difference between Sync and Bind under OperationProperties. If you aren’t familiar with MailItemsAccessed and Sync/Bind, then AON has a great article that provides an in-depth look into auditing different types of mail access during a BEC. AON advises that the records under the Sync or Bind operation should all be considered compromised, and I do agree. The only problem that I can see, is that the only actions I find in the UAL are the Bind type, while I would expect them to instead be the Sync type.
eM Client seems to connect primarily using two client types, REST (API) and WebServices aka SOAP (also an API). The AON article I linked above does not mention auditing access for either of those, and I was unable to find anything useful.
Email Download
Here’s the bad news. I was unable to find any sign within the audit logs that I had downloaded the emails. I expected this, as my hunch is that the emails are downloaded from the local database, as I was still able to download the emails even with my VM disconnected from the internet. It is a shame, but it makes sense to me that you wouldn’t be able to determine concretely, and should rely on the existence of the Sync/Bind operation. If you don’t have access to the MailItemsAccessed record? Well… check the Assumptions section.
Potential Shared Mailbox Limitations
I didn’t have any success with auditing any notable access to the shared mailbox. Neither the UAL or the Exchange audit logs recorded any access activity. Yet, I know that I definitely did access the shared mailbox.
What does this mean? Well, perhaps I screwed something up. I still need to test more on this point, regardless. As of right now, I don’t have any solid answers on shared mailbox access auditing. After spending hours clicking emails and reading logs
So… Let’s Talk Assumptions
Nothing good, unfortunately.
Until I find more information about auditing API-based mail access, assume everything is compromised. All emails. All shared emails. Everything. I know, that’s a tough pill to swallow.
What Now?
I’m going to steal this section from my article on PERFECTDATA SOFTWARE, because I believe in being lazy when possible. Why try to rewrite something that already works?
What you do now depends on your experience, the data involved, the scope of the issue, and any legal or compliance requirements/legislation that you must comply with.
First, do not delete this application from your tenant. You can go to the application within Azure, go to it’s permissions, and click review permissions. If you designate the application as malicious, Microsoft will provide some handy PowerShell scripts for dealing with the application. It’s important to disable the application but leave it in the tenant, as that will prevent anyone from being able to use it in the future.
If you believe that an administrative account was compromised, it’s important to search through audit logs for any activity. Microsoft offers some guidance on dealing with an email compromise, which includes limited details about administrative account compromises. I personally use the free HAWK forensics tool when investigating BEC, and it gathers helpful information about the tenant as part of it’s initial tenant investigation. Unfortunately, those two options might not be enough. If you are a SMB dealing with this problem, then you should consider contracting third-party forensics.
You should also understand your requirements around compliance legislation. In Canada, any suspected privacy breach needs to be reported to the Privacy Commissioner. If there is a risk of harm related to any stolen personal data, those affected must be notified of the breach. Other countries have similar legislation, but it’s up to C-suite and Legal to determine next steps for those matters.
Finally, this is your sign to make some security improvements to your tenant. Azure AD/Entra ID Premium P1 or P2 are great, so choose licensing that includes one of those. You should also turn on administrator consent requests for risky applications. This prevents end users from granting an app access to more than it should have and allows you to review applications that have been added.
Need Help?
If you read this article and have now come to the conclusion that you are experiencing an email compromise, it’s normal to feel scared or uncertain, especially if you’ve never dealt with something as serious as this before. I have provided a guide for investigating an email compromise, so give it a look if you need. I can also be reached via LinkedIn, Email, or Discord to answer questions.
As always, leave any questions or comments in that lil box below the article, or reach out to me using whatever method you prefer. Thanks for reading!