User app registration - exploitable for BEC?

Question

Hello. Recently dealt with a case of BEC. I'm not trained in forensics, but doing my best. Appears the hacker used an application called eM Client for their attack, getting access to a user's mailbox and hijacking a thread.

I can see the login from two weeks ago (the incident was only noticed a couple days ago, however) - from a European country that SHOULD have been blocked by Conditional Access. Come to find out, the tenant conditional access was unassigned from everyone. We're not sure how - we re-enabled it, and audited changes, but the only change that appears was us re-enabling it. Which I thought indicates it was never configured right, except we've got a ticket documenting a change to Conditional Access a couple days after the hack that ALSO does not appear in the logs. So... it's likely it was changed, yet I have no record of that change (atleast, not through Entra > Monitoring > Auditing). If anyone knows any other ways of checking this, please advise - but I can't seem to even access our Diagnostic settings, the page tells me I need an Azure Active Directory subscription (I'm on Entra ID P1, which includes AAD.... this might be related to being global admin, and not Security Admin - we don't use that role in this relationship)

ANYWAY, my amateur forensic skills have found that the attacker used an app called eM Client to get access. I'm not sure yet how they obtained the password, and got past MFA... But quick research shows this application (esp it's pro version) is known for use in BEC. The app was registered in Entra, and granted certain read permissions in Entra ID for shared mailboxes, presumably to find a decent thread to hijack. I'm not 100% sure yet there was any actual exploit done using this app, but it's popularity amongst hackers implies it does SOMETHING useful (i think remember that it authenticates using Exchange Web Services instead of Exchange Online, or something similar? Will update when I have the chance to check). We're in the process of improving our Secure Score, and this incident makes me think user's ability to register apps should be locked down. Checked Secure Score for this, and while there ARE recommendations around apps, disabling user app registration is NOT one of them.

Just curious about people's thoughts. I just barely understand App Registration in Entra, but if this is a known attack vector, I would think disabling app registration would be a security recommendation?

vasilmichev · Answer

Yes, you should disable App registrations, regular user have no need for this functionality. And you should also restrict consent to third-party apps, the steps on that are here: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent?pivots=portal
I'd even argue that you should block consent altogether, but that depends on how much third-party apps are in use in your tenant. Regardless, app registrations should be disabled.

matthew levy · Answer

Hi underQualifried&nbsp;Firstly, well done on what you have done so far in your investigations, it's not easy and as an Admin, you have to embark on a massive learning journey to understand what is possible in Entra ID before you can understand the risks and how to mitigate them.
With that said, you do most definitely want to restrict what standard users can do with regards to application registrations, and consenting to permissions for enterprise apps that request access. Some admins go so far as to block user consent altogether as well as blocking app registration.
Because this is a common concern for Microsoft 365 tenant admins at the moment due to recent attacks like Midnight Blizzard, I wrote a two-part blog to help admins that are not app developers understand the risks and I made some recommendations. Check it out:Part 1: Entra ID Application consent - what identity admins need to know
Part 2: Entra ID Application consent - recommendations
Hope this helps
Matt

louis_mastelinck · Answer

Hi underQualifried ,You've already identified the key elements based on your description. To store your sign-in logs, audit logs, and other data, you'll need to write them to a Log Analytics workspace, which functions similarly to a database. From your error, it seems you don't have an Azure subscription yet. An Azure subscription is required to create and manage Azure resources like virtual machines, Logic Apps, or App Services. These resources need to be associated with a subscription so Microsoft can handle billing.No worries—setting up a Log Analytics workspace isn't costly, and it's definitely worth it for its robust investigation and monitoring capabilities.For example, I usually retain the following logs for about six months for thorough analysis and tracking:SignInLogsAuditLogsNonInteractiveUserSignInLogsServicePrincipalSignInLogsManagedIdentitySignInLogsEnrichedOffice365AuditLogMicrosoftGraphActivityLogs&nbsp;&nbsp;If you want to see more evidence who changes your CA policies based on these log you could try the queries in this repo: LouisMastelinck/Monitor-security-policy-changes-or-admin-activitiesAn essential part of your forensics process will involve determining what actions this Enterprise Application performed. Depending on your licenses and whether you're tracking Office activity, you can use the following KQL query in Security.microsoft.com &gt; Advanced Hunting:CloudAppEvents| where OAuthAppId == "" // Insert the App ID of the EIM client| where ActionType == "MailItemsAccessed" // Look for the app accessing mail items, this can all other activities| summarize RequestCount = count() by bin(Timestamp, 1d)| order by Timestamp| render timechartThis query will generate a chart showing how many emails the app accessed over time. If the app sent emails, you'll need to change the ActionType.Another useful query to see which emails were accessed is:CloudAppEvents| where OAuthAppId == "this should be the app id of your eM Client"&nbsp;| where ActionType == "MailItemsAccessed"| extend AffectedMailbox = tostring(RawEventData.UserId)| project-reorder AffectedMailbox&nbsp;&nbsp;Root CauseThe root cause of your Business Email Compromise (BEC) seems to be application consent granted by end users, allowing external applications to access their accounts and data. The two blog posts by Matthew Levy are excellent resources for understanding how to prevent this.&nbsp;

underqualifried · Answer

Hi Louis, thanks so much for the detailed write-up! On further investigation and some collaborative forensics, we've built a pretty solid timeline. Will be checking those posts and implementing a policy going forward. Can you elaborate a bit on the Azure subscription though? We have Entra P1 (and now, P2) - and as I understood it, "Entra" was just the new name for Azure, and the Azure subscription is included within? Based on the docs, I'm wondering if the issue is that I'm global admin - and NOT security admin... Have seen other instances where this caused issues, like in Lighthouse. Can you advise - are you using a global admin, or security admin role? Do you have an Entra subscription, and a separate Azure subscription? MS licensing is... tough.

underqualifried · Answer

Thanks so much Matt, very helpful. When things calm down a bit, I will be sure to read (esp as the user above recommended your posts!)

Forum Discussion

User app registration - exploitable for BEC?

Share

Resources