Forum Discussion
Why are Microsoft Data Centres logging in to my Office 365 accounts? Activity Alerts - BAV2ROPC
Interesting new development, UnifiedAuditLogs in Europe have failed to update UserLoggedin records since around 25/11/2020, logged a case with MS, have seen AZ auditlogs re-feed old data to unifiedauditlogs but username is not the email address but the SID, so this looks like they have a problem and a bug. I added a P1 lic to one of my 12 Tenants and checking Get-AzureADAuditSignInLogs in stead, will let you know if this is more accurate regarding the incorrectly recorded MS sites.
MS has fixed the Azure log feed into UnifiedAuditLogs last week, which gave me the opportunity to look at the Azure logs (the source logs) in depth again, which confirmed that the False Positive is already present in the Azure UserLogin logs. Unfortunately the Azure logs content itself proves no better, even worse as the (MS internal) IP lookup does not even identify/log their own datacentres (so you have something to filter on). So I am back to extracting the UnifiedAuditLog, running it by an IP lookup and ignoring ISP=Microsoft Data Centres, as these are all false positives. Have managed to catch several hacked accounts this way, if customers would only pay the eu5 extra for P1, so we can use MFA (and Registered Locations) and the likes as prevention is always better than detection after the hack has already taken place.
So does this indicate an account compromise, malicious attempts to authenticate, or false positive? Apologies for the confusion.
My personal opinion and experience is that useragent=BAV2ROPC from ISP=Microsoft IP addresses (only) are failed login attempts (including from deleted userids), but are still logged in the Azure Logs, and thus causing a false positive.
On several blogs I have read that even MS is recommending to ignore these.
I have never encountered a hack based on these, but have seen hacks on everything else (not BAV2ROPC from MS IP's). I am monitoring every 4 hours across 30 Tenants, 2 -400 users varying across 5 countries
so like everyone, I have noticed a huge increase in these connections; however some of mine are not from just Microsoft IP addresses, but also from normal public IP addresses. When looking at the AAD logs, it can be seen that the client application linked to this useragent is IMAP/POP.
However, I have seen a successful logon from a public IP using the BAV2ROPC useragent, where IMAP/POP was turned off.
So Im wondering whether the connection was actually successful (both AAD and UAL show it was) and if it was, what client application could use it that wasn't using IMAP and POP
Hi there.
To be honest I still don't know for certain.
It appears it's ok, and MS told me it was ok, but I still don't know why it's happening.
If MS could chime in that'd be great.
- The bad actors are hitting you probably via Exchange On Line (EXO) basic authentication facilities or its coming from a VM in aa Azure tenant. Its remarkable easy to get a cloud resource on AWS, Azure, etc.. to launch your attacks.
First - Please report it - https://msrc.microsoft.com/report/abuse
You can use the O365 Admin Center to disabled basic auth.
https://admin.microsoft.com
Goto Settings/Org settings/Modern Authentication and uncheck all the basic auth stuff. This will break old versions of Outlook and other older mail apps on phones and such.
Also, get at least P1 licensing and use conditional access policies to MFA everyone. And don't use SMS for MFA. Use the Microsoft Authenticator app which is much more secure.
Any user that is being attacked should be aware in case a bad actor does get a good password the end user does not need to be approving MFA for something they did not attempt.
Train you users. Test you users. You users are part of your solution.
