User app registration - exploitable for BEC?
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?
MS Sensitivity labels mail sending MIME format Header
I selected the Sensitivity labels in OWA and checked the value exposed in Chrome developer mode when sending an email. When sending mail (C#-EWS sending test), i confirmed that the message was encrypted by additionally coding the header with the information below. ## Header Sample X-MS-Exchange-Organization-ModifySensitivityLabel: 00000000-0000-0000-0000-000000000000;6e4f02ee-0f9f-44eb-9f14-57b7d505f382 msip_labels: MSIP_Label_6e4f02ee-0f9f-44eb-9f14-57b7d505f382_Enabled=True;MSIP_Label_6e4f02ee-0f9f-44eb-9f14-57b7d505f382_SiteId=a23af047-ccd4-43c4-b36d-5303e9f04b12;MSIP_Label_6e4f02ee-0f9f-44eb-9f14-57b7d505f382_SetDate=2024-03-18T00:20:34.940Z;MSIP_Label_6e4f02ee-0f9f-44eb-9f14-57b7d505f382_Name=Confidential;MSIP_Label_6e4f02ee-0f9f-44eb-9f14-57b7d505f382_ContentBits=0;MSIP_Label_6e4f02ee-0f9f-44eb-9f14-57b7d505f382_Method=Privileged; ## Question - If only msip_labels is applied, the sensitivity label is displayed, but the message is not encrypted. Adding X-MS-Exchange-Organization-ModifySensitivityLabel will enable message encryption. Can I code it like this? - The msip_labels guide is provided by [concept-mip-metadata] Where can I find the specifications for X-MS-Exchange-Organization-ModifySensitivityLabel? - What are the limitations of development if implemented only by adding a header? Thanks in advance
SMTP XOAuth authentication and Microsoft authentication libraries
Due to the upcoming deprecation of basic authentication our company is looking to move all our products to modern authentication protocols for sending emails but we have some unusual usage scenarios that have me running in circles. I have been through all available documentation multiple times and I'm stuck. The problem is that we have on premise web applications that are running on multiple client servers and not a central location. This creates a problem when using standard OAuth flows since there is no fixed URL to use as a redirect URI. Because of this I have created a separate API on a fixed URL that will serve as the redirect URI for all clients and instances of our web applications. This breaks the standard usage of MSAL library and I had to go around chasing my tail to even be able to implement something that could possibly work. I have been able to do it using Microsoft.Identity.Client MSAL library but I hit a problem since I need to use the ConfidentialClientApp.AcquireTokenByAuthorizationCode call to redeem the access code obtained after user login but apparently SMTP does not allow confidential clients to login. We need the application to be able to send emails from any account any tenant or personal accounts. I have obtained the access token for a personal account but SMTP rejects it with this error: 535: 5.7.3 Authentication unsuccessful [AM8P251CA0016.EURP251.PROD.OUTLOOK.COM]. If I switch to PublicClientApplication then there is no AcquireTokenByAuthorizationCode method and I can't even use client secret so I'm not even sure how this works in redeeming a code. I am going by instructions on this page: https://docs.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth and it mentions no requirement of a public client application. It states I can use authorization code flow and the documentation on authorization code flow states it can be used by web apps and desktop apps. Well how am I supposed to use it when SMTP won't accept a confidential app and the PublicClientApplication does not have a method to redeem it? If I drop the authentication library and go for pure REST API call implementation, which application credentials should I use that the acquired tokens will be accepted by the SMTP server? Also I would like to know if office 365 users still have to disable security defaults and enable STMP Authentication to use SMTP with OAuth 2? This would defeat the whole purpose of migrating to OAuth 2 and the blog about deprecation states that moving to OAuth 2 is the way to prepare your app for this deprecation, but I've seen instructions on SMTP OAuth that state SMTP Authentication still needs to be enabled.Purview Information Protection for internal and external emails
I'm working with an organisation that is starting to use sensitivity labels. They have Office 365 E3 licenses. The current plan is to set up a default label for documents and emails called "Internal Only". This label will encrypt contents and grant co-author permissions to all staff. The challenge will be when emails include external recipients. Ideally, the user will change from the default label to one that grants access to any recipients. However, I can imagine that there will be many cases where they forget to do this. If we had Office 365 E5 licenses, we would have the option to create a DLP policy to show a policy tip. I I would expect this would reduce the incidents of mislabeling. I have seen recommendations to avoid encrypting by default and only use it where needed. However this client is keen to use encryption to protect as much content as possible. One suggestion could be to change the default email label to only grant access to the sender and recipients, regardless of whether they are internal or external. I'm interested in any real-world feedback on how others have tackled this issue.Exchange online - Records Management & Use parent folder policy
Good day, We are in the process of testing and evaluating using Exchange online & Records management to mark items as a records for an x amount of years so that users cannot delete or edit the items during the retention period. Afterwards the items will be removed. We are now seeing the following: Mails that are labeled with a record label restricts the user to edit or delete the mail with the following notification "Outlook cannot delete one or more items because of a retention policy" However when a user navigates to Assign policy and select Use parent folder policy the record retention label gets removed and the user can indeed remove a mail that was actually not meant to be removed. All of the default retention tags were removed from the Default MRM policy except move to Online Archive after 2 years. Is this by design? Or is there a way to disable or remove "user the parent folder policy" option?
When running New-DkimSigningConfig getting "Error in retrieving encrypted key"
I am trying to configure Dkim for a new custom domain name I have added to my tenant but receiving the error "Error in retrieving encrypted key" New-DkimSigningConfig -DomainName mydomainname.com -Enabled $false Error in retrieving encrypted key. + CategoryInfo : InvalidArgument: (:) [New-DkimSigningConfig], ValidationException + FullyQualifiedErrorId : [Server=PN2P287MB0256,RequestId=118bbafe-fead-42f2-b0de-ca595eba53b9,TimeStamp=25-08-2022 07 :28:38] [FailureCategory=Cmdlet-ValidationException] 2C2648B2,Microsoft.Exchange.Management.SystemConfigurationTasks.N ewDkimSigningConfig + PSComputerName : outlook.office365.com
Custom Rule to qurantine emails in M365 based on total Number of Recipients
Lately we have been getting thousands of emails from Gmail which have pdfs and links. Last week we were hit with around 1.5 million emails which the ATP could not stop( we have A5 license). We created rules which says if attachment has specific name example Oddname.pdf then delete the email. We are not in position to block gmail domain or block all emails which has pdf attachments. Can we have a custom rule which based on number of recipients. Example --->if email has more then 100 recipients and gmail.com domain then quarantine the email or delete them.Sending over SMTP using OAuth 2.0 still requires office 365 users to disable security defaults
Sending over SMTP using OAuth 2.0 still requires office 365 users to disable security defaults and enable SMTP Authentication!!! This makes no sense and is definitely not an improvement on security. Documentation on basic authentication deprecation states that we need to migrate to secure authentication flows but using OAuth on SMTP requires clients to enable basic authentication as well. I know they can be disabled separately by an admin and only XOAUTH left enabled but that is complicated and completely unnecessary. SMTP with XOAuth authentication should be enabled by default. All this does is force us to use Graph API to send emails, which is in no way related to security. If every email provider decided we have to use their APIs to send emails and not a standard protocol, we would need a new developer just for implementing sending emails which should be a trivial matter. I would really like an official response to this and understand the logic behind it!
