Supersizing your DUO and 365 Integration
Last Updated: 2022-10-27 22:52:34 UTC
by Tom Webb (Version: 1)
As soon as defenders started implementing multifactor authentication, attackers tried to get around it. One of the most common methods attackers are currently using is Push or Call Annoyance. Attackers try multiple times to authenticate and annoy the user until they accept the request. Several options address this attack method. This article shows how to use more advanced MFA options on a strategically risky subset of users without a massive rollout to your entire organization. This will allow for more agile adjustments and lower helpdesk calls.
With Office 365 and Microsoft Authenticator, their integration and authentication methods based on risk are nice. If you are using Duo with O365, it's more challenging, but we will be upping our game to increase the difficulty for the attackers. Depending on your Duo license, they have additional options for protection on their backend, but this works for all Duo license levels.
Prevent Annoyance Attack
- Only allow code authentication or hardware tokens(No push or call)
- Use Verified Duo Push, MS Authenticator with Number matching (users can not just accept the request)
App Code only authentication is where the only method allowed for multifactor is a passcode from the Mobile App or Hardware Tokens to keep attackers from prompting users. The biggest issue with this is user education and convenience.
The second way, and the way we are going to cover in detail, is the new Verified Duo push method(1). The user will verify their identity by entering a code into the app. The code is displayed on the device you are using to log in. Microsoft version of this tech is called MS Authenticator number matching (2).
While this does continue to prompt the user for authentication by the attackers, without the code, they can not approve access. It would take additional social engineering to get past this process. I believe this is a more user-friendly experience than just using the code in the app.
What if you don't want to apply this to All logins?
With our initial deployment, we didn't want every 365 users to do a Verified push every login. As previously stated, MS and DUO do not have the tightest integrations, so to do this risk-based takes some additional setup. We created 2 Duo integrations, one for "Normal Auth" and one for "Secure Auth." The "Secure Auth" had separate Duo and conditional access policies to meet the new requirements.
1. New Duo 365 Application
You need to create a new Duo application. It will require you to use your 365 global admin account during that process. Name the new application integration something like 365 Secure.
2. Setup a new policy for the Duo 365 Secure App
The policy should look like the below picture as you want this to be very restricted for risky authentications. In this case, it has Verified Duo Push as the only method for authentication. Instead of using the verified push here, you could also use the Mobile code only and hardware token option. Just don't allow SMS, phone, or standard push.
3. Create a new Custom control in MS 365 Conditional Access.
(Following Duo Instructions as needed). But before importing, you need to change the Name and ID like below so you can have two instances of DUO with different names. By default, it wants to use the same name and will error on the import.
4. New 365 Conditional Access Policy
Here is where you should determine what settings you want for the new protections. At a minimum, I think High Sign-in risk. If you do not have many users from outside the US, add location-based too. If you manage and clear risky users, also add that as an option. By tuning the Conditional Access policy right, you will get a few legitimate users that get the policy reducing helpdesk calls while adding much-needed protections.
To get a good idea of what's currently going on with your sign-ins, go to portal.azure.com, search for "security" and select Risky Users, Risky Signs and others on the bottom left.
5. Stop Evil
Below is what would have been a typical annoyance attack that would have been successful without the additional controls in place.
Are you using some sweet 365 settings or a neat way of using Multifactor? Leave us a comment.