For a long time now, we’ve focused on limiting our attack surface in the cloud by limiting the countries from which accounts can be logged in. We do the same for email, limiting the countries from which we will accept email. Together these settings dramatically reduce the number of attempts on accounts and the volume of phishing emails. But recently, we’ve noticed more USA based attacks. As always, the bad guys have gotten smarter, and they have found a way to circumvent yet another of our protections.
Looking at the activity logs in Microsoft 365, we can glean some information on the types of attacks and the devices that are being used to launch the attacks and figure out what the bad guys are doing now. We can then configure Microsoft Cloud App Security to block them. This means that we have a viable way to prevent attacks being launched from within the USA.
Digging into Activity Logs
Opening up the activity logs and searching for failed log on in the United States brings a long list of attempts on our accounts. Open enough of those up and you begin to see some similarities.
Below we see that the device type is Unknown(BAV2ROPC). Clicking in to view the user agent string it is BAV2ROPC. We’ll use that information when building our rule. According to available documentation BAV2ROPC is an Outlook mobile client using non-modern authentication.
In this one, notice that the device type is PC,Windows. When you click that device type link you get the User agent string for that device type. In this case the user agent string is Windows whereas a Windows 10 computer’s user agent string is Windows 10. Since our company doesn’t use anything other than Windows 10 we can use this in our rule too. Previously we’ve also seen the user agent string Windows 7 and we’ll include that one in our rule also.
Below is what the difference between a device reporting just as Windows and a device reporting properly Windows 10 will look like in the User agent string.
Build a rule
Now that we gathered the information it’s time to create a rule. The rule that we will build will block log on by user agent strings that are not in use in our company, namely Windows, Windows 7, Firefox 63.0 and BAV2ROPC. This will shore up our protections from in-country attacks.
We’re going to create the rule type Activity. Although Activity filtering can be delayed, it was my firsthand experience that because these are repeated log in attempts that the suspension of the account actually happens rather quickly. Yes, you read between the lines correctly; I locked myself out nearly immediately after enabling this rule the first time around. I have since refined the rule to prevent this from happening.
Create a new rule in Microsoft Cloud App Security. Choose the category Threat Detection but do not use a template. Give your policy a name that you’ll remember, set the severity level and add a description. Next set the rule to act upon a single instance of a matching activity. As you see I have the severity level set to low because anything caught by this rule will have been blocked.
Now we set the filtering. For this rule we will add the User agent strings that we want to block. We will exempt IP addresses that are known to our organization and the activity type that we want this rule to trigger on is any type of log on. Use the figure below to guide you in building your rule. Pay special attention to the words, User agent string contains, IP address does NOT equal and Activity type does NOT equal. Regarding the activity type, search for the word Log on and select it. This will then include all 251 items for you.
Next in your rule building you’ll create the type of alert that you want to receive when this rule is triggered. Then finally, if you are licensed to do so, set a Governance action to suspend the Office 365 account.
Once the rule is in place you will quickly find it triggering on USA based attacks. Some of these will have user names, some won’t. Many will be Exchange Online attacks, some will be Office 365 generally. They will be from within the United States because conditional access rules are blocking attempts from outside of the Country and those are processed first.
Microsoft Cloud App Security (MCAS) is a powerful tool for protecting accounts. I like it because it is aware of activities, agent string, IP addressing, Countries, applications, data, ISP’s, connectors, OAuth and more. I think of it as a modern firewall. Configuring policies in MCAS lets you plug up holes in your security net that others leave open.
If you like this content please join our Endpoint Manager, Lighthouse & Defender group. https://www.facebook.com/groups/endpointmanager
All we do is support IT professionals. Help for IT Pros, Super Secret News, Security community, MSP Legislation community, Kits, papers, MSP training and more. https://www.thirdtier.net
5 thoughts on “Using user agent string to block USA based attacks”
Which licensing is required for CAS? I’m assuming the tools/steps shown in this article are not possible with M365 Premium? Great read however! Thank you.
Microsoft 365 Business Premium only comes with the App Discovery portion of MCAS. To get the rest you need a license of MCAS. It’s cheap and powerful. $3.50 a month. If you want to take action upon the users then the users need a license. If what you want is access to the logs and alert then the admin needs a license. At least that is how I interpret it.
If you really want to see how powerful this can be then add the EMS e3 license too or go wild and just switch to M365 E5. It’s a real eye opener.
Thanks Amy
Why do you want to suspend account on failed rather than successful logins? It would think it would be the opposite to avoid rampant account lockouts. Not to mention failed logins already lock the account.