Why are Microsoft Data Centres logging in to my Office 365 accounts? Activity Alerts - BAV2ROPC

[casualbob]

Hello, I have an activity alert set up to email me whenever a log in is detected from one of my 12 office 365 email users. These emails contain the username logging in and the IP address the log in originated from.

Until the end of 2019, all IP addresses were expected, either being that of the office, the Vodafone mobile network or the home addresses of the sales guys.

In 2020, I have started getting log in alerts, which according to https://whatismyipaddress.com/ are from Microsoft Datacentres in Ireland, Holland and Austria, all with "Microsoft Corporation" as the ISP and sometimes with the same for the Organisation and sometimes with "Microsoft Azure". e.g 40.101.88.221 (Amsterdam), 40.101.102.149 (Dublin).

Worried about potential breaches, I contacted Microsoft Support (who by the way are always ON IT, thank you) who helped me find info in the audit log to say the User Agent is BAV2ROPC, which lead me to this page https://www.reddit.com/r/Office365/comments/bl90gw/bav2ropc_user_agent_in_logs/ where someone's found it means "Business Apps v2 Resource Owner Password Credential", which is apparently the User Agent for an updated version of Outlook Mobile.

I have a couple of questions / observations and wondered if anyone could shed any light on this.

1) My users don't know their passwords so it's highly unlikely they've been phished, so I don't think these are breaches.

2) My email account has triggered log ins from Microsoft IP addresses, and I have 2 factor authentication turned on where I received a text message code to my mobile. I have not received texts in relation to these logins, so again I don't think it's a breach.

3) I don't use Microsoft Outlook on my mobile, so don't think I'd be generating this BAV2ROPC user agent (but I am on the Activity Alerts).

4) If it was a device I was using causing this user agent, why aren't the Activity Alerts logging my IP address from my device's location?

5) My account is used to sign in programatically in a piece of software I wrote, so that could explain it for my account, but I'm also getting alerts for users who only access their email on their android phone on the built in email app.

6) The frequency I'm receiving Activity Alerts from Microsoft IP addresses is increasing. I get a few a day now.

In summary, I don't think there's anything untoward goin on, but as a responsible admin, I'ld like to understand exactly what's occuring.

Many thanks,

Dave

[#2]

@Aquilius 

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

[#3]

@BdCvC 

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

[#4]

@bobster95 my customer has a generic sales account that is showing up with this user agent. The unified audit log shows me that it has logged in successfully once a day, but no other events are recorded. Its weird

[#5]

@bobster95 We started setting up Authentication Policies to disable Basic Auth (ahead of MS MC204828 mid 2021), but came across the following challenges in doing so, it may help others in their attempt to secure their Tenants (and hopefully stop BAV2ROPC occurring/logging):

Some admins were using PowerShell scripts and we had to exclude those individuals from the Policies. Also had to exclude users that were still using IMAP, POP3 and/or old phones configured with Exchange Activesync (in stead of the more secure O365 account) setup. And then there were the few using Office2013 (I know!) that could not upgrade as yet, and needed a Registry Hack or exclusion again.

[#6]

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

[#7]

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. 

Mine also says 

"authenticationMethodDetail": "Password in the cloud",

authenticationMethodDetail

String

Details about the authentication method used to perform this authentication step. For example, phone number (for SMS and voice), device name (for Authenticator app), and password source (e.g. cloud, AD FS, PTA, PHS).

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

[#8]

Good thing I had mfa, so far I believe this is definitely a password brute force. Besides monitoring an setting up conditional access, I blocked OWA, legacy exchange/outlook on the Exchange server itself. 

--https://docs.microsoft.com/en-us/Exchange/clients/outlook-on-the-web/mailbox-access?view=exchserver-...

Monitoring to make sure it has been resolved. Last attack 12-6 15:22. I initially blocked OWA at the AD side yesterday and because Teams and all these other apps depend on OWA I was locked out of my mobile apps. I had to go back and block it at the Exchange server this morning.  

I definitely think that the password was compromised, and I had MFA so there was no breach, but this morning since the password was change, the failed MFA error was no longer there on new attacks. Now it is saying that password or username is incorrect, account has been locked. 

Now let's make sure it is stopped now that OWA and legacy is blocked.

[#9]

No more threats so far. Anyway, you see them coming in on "clientAppUsed": "IMAP4", so I suspect the previous fix has resolved it. I will keep you updated. 

[#10]

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.