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.
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.
I haven't finished investigating yet, but none of the login attempts I have found were successful, however, I noticed they were trying MFA from several different phone numbers.
I am treating this as an active attack, seems they are trying to login to exchange. I have received phishing emails attempting to spoof my email recently as well. Not sure if they are related.
The way I am solving this is directing cloud traffic through my onprem VPN concentrators. Seems silly to have to come through the network and leave, but that way you can whitelist the traffic that is allowed or use a cloud gateway. Either way it will cost money.
Other information to help prevent these attempts:
https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/
https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authenticati...You can query the Graph API for more information.
https://developer.microsoft.com/en-us/graph/graph-explorer
https://graph.microsoft.com/beta/auditLogs/signIns
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
