Conditional Access Policy Best Practices

To support Inde customers throughout 2023's Cyber Smart Week we will be publishing a blog post each day that details a category of mitigation that you can implement to harden yourself against popular adversary techniques. These blogs are to help technical managers and practitioners get a better grasp on how to manage security risks within their business. Our selection is based upon our practical experience in responding to incidents, researching threat actors and adversary simulation engagements.

Today we'll discuss Conditional Access Policy.

With cloud-based identity providers now widely serving as a primary authentication system for many organisations, threat actors are seeing great return on investment by devising new initial access techniques that leverage such services. An excellent example of this has been seen recently in a cluster of activity designated by CrowdStrike as Scattered Spider.

Scattered Spider Introduction

Scattered Spider is a financially motivated criminal entity with a tendency toward big-game hunting and social engineering. It has attracted much attention after having been attributed to multiple very public incidents, including MGM Resorts in September 2023, which was not long after their affiliation with the ALPHV/BlackCat ransomware-as-a-service program became known.

The techniques they rely upon for initial access include a variety of MFA bypass methods, such as SIM swapping and Push Notification Fatigue. Their campaigns are typically preceded by extensive target research, using both open and closed source data to construct an in-depth understanding of target individuals. Phishing, Vishing, and Smishing are among the techniques used to socially engineer their targets into supplying their login credentials, completing/bypassing MFA challenges, and resetting credentials. Access may also be facilitated with purchased credentials, cookies, and browser fingerprints – such as those sold on the now defunct Genesis Market.

Conditional access blog image Source: Mandiant

Once access to an account has been obtained, they show an aversion toward bespoke tooling, instead opting to “live off the land” and achieve their objectives with legitimate system administrator tools and functions. Furthermore, their comprehension of cloud systems cannot be understated, also abusing native functionality to elevate privileges, set up persistence and exfiltrate data. Examples of these span from basic techniques such as registering new MFA devices and creating users and hosts in target tenants, through to abusing an Okta’s M&A function to create shadow users for cross-tenant impersonation.

You can read more about the group here:

MFA Methods Matter

As demonstrated by actors such as Scattered Spider, Push Notification Fatigue can be very effective at coercing an employee to accept an MFA request. In these attacks, a bad actor will repeatedly send push notification MFA requests to the target until they accept one. Requiring Number Matching MFA instead of push notifications can mitigate the risk of MFA fatigue. In most cases, the employee cannot accidentally authenticate a session, since they do not know the number being presented in the sign-in dialogue. Of course, this may still leave a target susceptible to social engineering vectors (e.g., they are instructed to enter the number over the phone). On the other hand, physical tokens and biometrics are resistant to such vectors, as they require the owner of the authentication method to be present at the session being signed in.

Policy Guidance

The overall objective of your policy should be to define the normal sign-in scenarios of your users and to either challenge or deny those which present risk:

All administrators should complete an MFA challenge upon sign-in, regardless of their location. Ideally, you’d compliment this with Privileged Identity Management for provisioning just-in-time privileged access.
Phishing resistant MFA methods should be required for privileged accounts, e.g. using a FIDO2 Security Key, Windows Hello for Business, or Certificate-based authentication (Multi-Factor) in addition to credentials.
All users should complete an MFA challenge if authenticating from outside of the office or signing into a new device.
Legacy protocols (e.g. SMTP, POP, IMAP) must be blocked as they do not support adequate MFA methods.
Use Entra ID identity protection sign-in risk policy to further enforce MFA requirements based on sign-in and account risk factors. Sign-in risk represents the probability that a given authentication request isn’t authorised by the user. If a user or session is found to have elevated risk, this policy protects the users from registering MFA.
Consider requiring a “compliant device” to only accept sign-in from Azure AD registered devices.
Enforce strong geofencing. If your users only sign in from New Zealand, block connections from all other countries. Set exclusions for required resources/services.

The policy templates provided by Microsoft offer a solid baseline configuration. At the time of writing there are 16 templates which are categorised by use case:

Secure Foundation: Microsoft recommends these policies as a baseline for all organisations.
Zero Trust: supports a Zero Trust architecture.
Remote Work: secures organisations with remote workers.
Protect Administrator: protects against compromise of highly privileged accounts.
Emerging Threats: protects against new methods of compromise.

Common Mistakes

Not considering policy architecture and producing a sprawling ruleset that is both difficult to troubleshoot and suffers gaps in coverage.
Failing to regularly verify that policies are up to date and still fit for purpose.
Unnecessarily excluding accounts from Conditional Access policies or forgetting to remove temporary exclusions.
Confusing the if-then logic of a policy, so the policy does not apply in the expected manner.
Inadequate threat modelling. If potential scenarios are not identified and blocked by a corresponding policy, or logical flaws in a policy permits them (e.g. allowing shared ranges), an adversary may exploit this to bypass your policies.
Overly permissive session sign-in frequency controls for administrators using PIM.

About the author

Chris Campbell

Chris was that notoriously disobedient kid who sat at the back of the class and always seemed bored, but somehow still managed to ace all of his exams. Obsessed with the finer details and mechanics of everything in both the physical and digital realms, Chris serves as the Principal Security Architect within the Inde Security Team. His ventures into computer security began at an early age and haven't slowed down since. After a decade spent across security and operations, and evenings spent diving into the depths of malware and operating systems, he brings a wealth of knowledge to Inde along with a uniquely adversary focused approach to defence. Like many others at Inde, Chris likes to unwind by hitting the bike trails or pretending to be a BBQ pitmaster. He is also heavily involved in the leadership of security events, trust groups and research projects.