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?
Cannot login to Service Trust Portal
Hi, I'm trying to get some certificates from the service trust portal, but I keep getting "Service Trust Portal no longer support Microsoft Account (MSA) access." I'm using an account registered on Azure and I checked the Azure Active Directory, and the user exists (seeing it's the owner of the account). What am I missing here?Anomalies with Conditional Access Policy "Terms of Use" Failures
Hello Microsoft Community, I'm reaching out with a bit of a puzzle regarding our "Terms of Use" Conditional Access policy, and I'm eager to tap into the collective wisdom here for some insights. In our Entra ID User Sign-In logs, we've identified intermittent "failure" entries associated with the "Terms of Use" Conditional Access policy. Interestingly, even for users who had previously accepted the "Terms of Use". There appears to be no discernible impact, and they continue their tasks without interruption. This observation became apparent during the troubleshooting of unrelated Surface Hub and Edge Sync issues at some client sites. What adds to the complexity of the situation is that for the same users, both before and after these "failure" entries, the Conditional Access policy is marked as "success". Hence, it doesn't seem to be a straightforward case of the policy erroneously detecting non-acceptance of the "Terms of Use". The mystery lies in understanding why these intermittent "failure" entries occur for users who have already accepted the terms, especially when the policy consistently reports "success" for the same users. Furthermore, the Insights for the "Terms of Use" Conditional Access policy show around 1.48k successes and 1.43k failures in the last 90 days, yet there's no discernible impact on user functionality. Observations: "Failure" entries in Sign-In logs don't seem to disrupt users' day-to-day activities. The ratio of successes to failures is balanced, yet users experience no noticeable problems. The issue complicates troubleshooting efforts but doesn't significantly affect the user experience. I'm turning to the community for guidance on interpreting and resolving this discrepancy between "failure" entries in the Conditional Access policy logs and the seemingly unaffected user experience. Any insights into why these failures occur without user impact would be greatly appreciated. For additional context, I've attached screenshots of a user's Sign-In log entry and the insight chart from the Conditional Access policy. Sign-In log of a user (failure): Sign-In log of same user (success): Current Conditional Access insights: Thank you in advance for your time and assistance. I look forward to any guidance or solutions you can provide. Best regards, Leon Tüpker
Insider Builds
I have been an avid Microsoft user for many years with only a couple of small issues every now and again. The 6 weeks have been unbelievably stressful and disheartening. I thought trying samples of New Insider builds and enlisting in Azure for some up to date training for myself to help with what I wanted to roll out for my business. This has been the worst experience i have ever been apart of. I now have multiple computers and hardware in disarray but more importantly the loss of time and patience is paramount . I have come to realise the repetitive responses and requests for data collection on feedback or issues is one-sided The amount of user data submissions is not the issue though. It is the assistance from Microsoft regarding issue via portals, help-desk etc. The inclusion of many backend functions for the purpose of better user experience is heavily flawed. Unless end-user inadvertently has or encounters issues in there OS life is good. Heavily automated program tiggers sit through all OS builds for example. One drive. Regardless whether this is declined or removed it will always be running in the background. If you system had been compromised this is a perfect place for root-kit other Malware to spread. Xcopy: A Microsoft background function which has the ability clone and copy 99% of drivers of operating info structure. Can be controlled by ghost script directives or embedded dll to aid malware. Anti-virus or defender find difficulties identifying or distinguishing authentic and re-pro-ducted data. In time this type of incursion can mimic a vast amount of OS functionality. Microsoft OS validity. I have trailed numerous builds with all sharing this characteristic. Invalid or expired software and driver certificates & TPM flaws even after a full clean reset and TPM turned off in bios. Inevitably this can introduce compromised software without end-user knowledge. The impact leads to unauthorised access in many elements of the OS platform especially data access and embedded .dll which can run inline or above elevated authorisation. A lot of this is undetectable. Once embedded in OS and bios this is impossible to clean without expert assistance and can be very costly. For the most part the inclusion of new AI functionality across the OS platform is very welcomed. Unfortunately there are a large amount of bugs to be ironed out especially in the platform navigation. Advice provided via OS AI can be mis-leading or incorrect. .
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.
New Blog | Upcoming design updates: Microsoft Purview Message Encryption Portal
By Samson Chan The Microsoft Purview Message Encryption portal will undergo minor design updates to align with Purview branding. Microsoft will be updating fonts, colors, controls, and more to align with Purview branding. These changes are designed to enhance the user experience without causing any disruptions. Microsoft will begin rolling out changes mid-October 2024 and expects to complete by mid-December 2024. Users will see minor design changes within the user interface (UI) - fonts, colors, controls, and more are updated to align with Purview branding. Read the full post here: Upcoming design updates: Microsoft Purview Message Encryption Portal
Moving Microsoft 365 authentication to Entra ID Cloud Auth from On-Prem ADFS
Hi Identity Brain Trust, Assuming this would be the right place for my question as I couldn't find any other hub more relevant for this one. We have several applications configured to be authenticated via ADFS. We are looking to move these gradually to Entra ID Cloud auth and decommission ADFS, eventually. I would like to test out how Microsoft 365 can be moved to Cloud Auth from ADFS for a certain group of people. I have tried to use ADFS migration wizard in Entra but 365 app is not showing in the ADFS Application Migration section of Entra ID. I've read this official guide but still couldn't find how this can be manually done when App Migration section won't have the app appearing there. - https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/migrate-ad-fs-application-overview Appreciate any of your inputs on this one! Kev
MFA Issue blocks Global Admin / Data Protection Team disconnects calls
Hi. I have just learned that the Microsoft Authenticator app allows you to create MFA for multiple Global Administrator accounts, but those accounts will not properly transfer when you move to a new Smartphone. I have one tenant that has only one Global Admin Account secured using MFA and the Microsoft Authenticator App. The MFA is no longer working. I have been told to work with the Microsoft Data Protection Team by calling them at 800-865-9408. The weird thing is they keep disconnecting the call before the issue gets addressed. It has happened multiple times. Calling them back results in hold times averaging over 2 hours. Does anyone have ideas how I can get my MFA issue solved perhaps by reaching the proper group at Microsoft in another fashion? Is there some customer advocate resource at Microsoft I can contact?
