No pretty screenshots this time, but I’ll try to keep it short and to the point.
- The basics
- Securing the MFA registration process
- No network exceptions
- Block risky identities
- Block unknown devices
- Tweak sign-in frequency and browser session persistence
- Final thoughts
The basics
First - if an organization’s MFA coverage for admin and user identities is below 100%, that’s where to start. All identities used by individuals with a pulse must be secured using MFA - no exceptions. Only requiring passwords in Azure AD really isn’t enough and will eventually cause a disaster.
Securing the MFA registration process
An essential step is to secure the MFA registration process. Users by default have the ability to register MFA methods upon sign-in when triggering MFA requirement - if no current MFA method exists yet for the account. An attacker could potentially sign-in with compromised credentials and enroll MFA right in the Authenticator app - which would definitely be bad.
To prevent this, use Conditional Access policy to secure the MFA registration process by either requiring known/compliant device, or another MFA method like Temporary Access Pass.
No network exceptions
As we keep focusing on Azure AD, require MFA always and from anywhere. Stop excluding MFA from known and “trusted” office networks. Seriously, the internal networks can’t be trusted anymore, it’s 2023 and we need to assume breach, never trust and always explicitly verify! If an attacker already is on the inside, excluding MFA from that network is just helping them potentially compromise the organization’s cloud resources too.
From Azure AD’s perspective, all networks should be treated as the rest of the Internet. Full zero trust.
Block risky identities
Protect Azure AD user accounts further with Identity Protection signals and Conditional Access policies. Block high-risk sign-ins and users - especially if a SOC is present and can act on such events to investigate and quickly remediate both for the sake of security and user productivity.
Medium-risk sign-ins could trigger full re-authentication with MFA, and medium-risk users could trigger full re-authentication with secure password-change through self-service password reset. This would assist users in helping themselves to get out of a potentially bad situation.
Block unknown devices
Going further it’s important to bring in device status. Which device is the user logging in from, is it known to Azure AD either as an Azure AD-joined or registered device, or as a hybrid-joined device for those organizations with AD domain-joined computers. In case of Azure AD-joined or registered device - is it in compliance with the implemented security policies in Intune?
Using Conditional Access policies to block sign-ins from unknown or non-compliant devices might be the protection mechanism fending off an actual ongoing phishing attack at the very last minute. As long as users are allowed to utilize phishable MFA methods like SMS, phone call, OTP and even Microsoft Authenticator - they are at risk to be lured into giving up both their account credentials and MFA challenge on a phishing site running Evilginx2 (as showcased by @janbakker_) or similar tool.
With this Conditional Access policy in place the attacker would be stopped dead in its tracks when signing in with the phished credentials, as the known device requirement can’t be satisfied.
Tweak sign-in frequency and browser session persistence
Deviation from the default sign-in frequency for standard users, which is a rolling window of 90 days, is likely not a good strategy for managed devices in the organization. It may impact user productivity, and will likely annoy users more than securing them.
However, in certain scenarios for specific personas it makes sense to both configure sign-in frequency to a day or less - and to disallow persistent browser session in one go:
- Highly privileged user accounts.
- Users accessing apps from unmanaged devices.
Make sure to understand how these features work by looking at Microsoft’s documentation.
Implement phishing-resistant MFA
Lastly, look into transitioning over to phishing-resistant MFA methods. High-value targets like privileged users and VIPs should be required to use FIDO2 security keys, but it’s even more important to require FIDO2 for any user excluded in the known device Conditional Access policy - as they are much more susceptible at being successfully compromised in a phishing attack.
Final thoughts
There are of course many other measures to consider and features to implement for protecting user identities. Some important things comes to mind, especially within endpoint management, like prevent giving users local admin privileges by default on their computers and instead look into Endpoint Privilege Management, make sure to use all the goodies in Windows like Defender for Endpoint and Credential Guard, look into issuing privileged and secure access workstation for high-impact users, and more.
While we’re talking about Conditional Access policies, I highly recommend looking into Microsoft’s articles on Conditional Access for zero trust - and also this GitHub repo by @claus_jespersen.
That’s it for now, thanks for reading - and keep on securing those identities!
Be sure to provide any feedback on Twitter, LinkedIn or Mastadon.