Your Conditional Access Is Stuck in 2018

image

You get a phone call from a client one Sunday morning in February. One of their bookkeepers had clicked an invoice link the previous Friday afternoon, signed in like normal, and gone home for the weekend. By Monday, the attacker had set up an inbox rule, watched a fortnight of email traffic, and sent a payment-redirect note to a supplier — from the bookkeeper’s actual mailbox. Eighty thousand dollars walked out the door before anyone noticed the wire details had quietly changed.

The tenant had MFA enforced. It had a Conditional Access policy. It had cyber insurance, renewed in January on the strength of those two things. None of that mattered.

The attack moved. The configuration didn’t.

Adversary-in-the-middle phishing kits don’t try to beat the MFA prompt anymore. They wait for the user to complete it, then steal the session token and replay it from somewhere else. Microsoft’s threat intel team disclosed an April campaign that hit thirty-five thousand users across thirteen thousand organisations in twenty-six countries — a single month, a single operator. Every one of those users had MFA. None of them had session controls tuned to actually defend the session.

This is the bit MSPs need to sit with. Conditional Access in Entra was never built as an MFA tickbox. It is the session control surface — the place where you decide what a signed-in user can do, from where, on what device, for how long. The grant and session controls in that same blade — the ones most SMB tenants have never opened — are what break this attack. We have spent five years building a defence for 2018 and leaving it deployed in 2026.

Four switches, all in the same blade

There are four controls inside Conditional Access that meaningfully change the outcome of a token theft, and most Business Premium tenants pay for all of them and use none.

  • Sign-In Frequency, set deliberately rather than left at its sliding ninety-day default, collapses the lifetime of a stolen token. Most tenants I look at have it set backwards — managed users get prompted constantly while unmanaged sessions ride for weeks.
  • Require-compliant-device on Exchange Online forces the attacker’s browser session to fail at the grant, not the prompt.
  • Phishing-resistant authentication strength — passkeys, FIDO2, Windows Hello — closes off the credential path to begin with.
  • Token Protection, even in report-only on Windows native apps, gives you the telemetry to spot a session being replayed from a country your user has never visited.

None of this is theoretical. Microsoft auto-rolled Conditional Access into more than half a million tenants in late 2023 specifically because tenants were not configuring it themselves. That auto-rollout sets the floor. The four controls above sit above the floor, and they are the ones that change the renewal conversation with your insurer.

The unit economics finally work

The honest reason most MSPs haven’t retuned their CA baseline is that per-tenant identity work used to be uneconomic. That changed. With GDAP and Microsoft Lighthouse, an MSP can review CA policy, push report-only changes, and watch sign-in telemetry across every client tenant from one pane. Pair that with a Loop page or a Teams channel for your security pod and the review cadence stops being a heroics exercise.

The bookkeeper followed her training to the letter. What let her down was a tenant configured for the threat landscape we had four years ago. When the next breach lands in one of your tenants, it will not be the MFA prompt that failed. It will be the session controls nobody touched. That is where the work is now.

End to End email protection with Microsoft 365–Part 4

This is part of a series of articles about email security in Microsoft 365. Please check out previous articles here:

End to End email protection with Microsoft 365 – Part 1

End to End email protection with Microsoft 365 – Part 2

End to End email protection with Microsoft 365 – Part 3

These articles are based on a model I have previously created, which you can read about here:

CIAOPS Cyber protection model

designed to help better explain expansive security included with Microsoft 365.

In previous parts, we covered how an external email was delivered into the Microsoft 365 service and all the protections that it passed through until it finally came to rest in the Data container (user’s inbox) ready to be viewed. The next step in the process will therefore for the user to fire up their device to read the email. This article will therefore focus on the protections available for that device.

For the sake of simplicity we’ll focus on that being a modern device running at least a Windows 10 Professional. Of course, email from Microsoft 365 can be viewed on just about any devices these days, Windows or not, and all of these have unique and overlapping protections. However for the sake of brevity let’s just focus on the more common Windows 10 device for now.

A range of hardware device protection is available and recommended including:

and should already be in place to protect the device.

We will also assume that the Windows device is fully up to date

How to keep your Windows computer up to date

The device in question should also already live inside the Device container as shown in the above model. This is largely achieved thanks to being joined to Azure Active Directory (AD):

Azure AD joined devices

Join your work device to your organization’s network

Tutorial: Join a new Windows 10 device with Azure AD during a first run

When that device is turned on we want it to complete the:

Secure Windows boot process

Once the machine has booted and before the user has logged into the machine, thanks to being Azure AD joined, Microsoft Endpoint device policies have already been pushed and implemented on that machine per:

Manage device security with endpoint security policies in Microsoft Intune

Such policies could be enforcing disk encryption, implementing Attack Surface Reduction (ASR) and so on.

Importantly, you can also enforce device compliance policies to ensure devices meet a security standard before they are allowed to access any data:

Use compliance policies to set rules for devices you manage

All of this is achieved via:

Microsoft Endpoint Manager

which I have also written a whole series of articles to help provide a better understanding of the role that it plays with device security. You can read these articles here:

Modern Device Management with Microsoft 365 Business Premium–Part 1 of 10

Assuming that the device has booted and successfully completed all the protection processes associated with that have been correctly applied, it is now time for the user to login to that devices. This means that we now follow the User connector in our model shown above, into the Service container from outside, then onto the Device Container and so on.

The user’s identity is protected inside the Microsoft 365 service via a variety of mechanisms. When logging into a Windows 10 device they will typically need to provide their account and password details that were set up with the service. However, best practice would now be to use Windows Hello for Business.

Windows Hello for Business Overview

Windows Hello addresses the following problems with passwords:

  • Strong passwords can be difficult to remember, and users often reuse passwords on multiple sites.

  • Server breaches can expose symmetric network credentials (passwords).

  • Passwords are subject to replay attacks.

  • Users can inadvertently expose their passwords due to phishing attacks.

Many mistakenly believe that the Windows Hello PIN is all that protects a users access to device and the service when at login. That is in fact not the case as Windows Hello leverages the TPM hardware to provide a highly secure login to the service.

Why a PIN is better than a password

How Windows Hello for Business works

These days just a login and password are not enough to secure any identity, you MUST implement Multi Factor Authentication (MFA). Why? As Microsoft will tell you:

Your password doesn’t matter, but MFA does! Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA.

Your Pa$$word doesn’t matter

All your creds are belong to us!

So MFA, along with a number of other recommended steps, are what can be done with Microsoft 365 to protect user identity.

Five steps to securing your identity infrastructure

Windows Hello for Business requires all users perform multi-factor authentication prior to creating and registering a Windows Hello for Business credential. Importantly, Windows Hello for Business replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and uses a biometric or PIN. Many don’t appreciate that correctly configured Windows Hello for Business DOES provides MFA when users access their devices, while making the device login process seamless. If you are however still concerned about this ‘single credential’ being compromised then you can also implement:

Multifactor Unlock

It is also important to remember that MFA is provided FREE on all Microsoft 365 accounts and support a variety of methods including authenticator apps, hardware token and more.

Enable multi-factor authentication for free

Once the user has correctly provides a login and password, then completed their MFA challenged (or equivalent thanks to Windows Hello for Business) they would then be subject to Azure AD Conditional Access.

It is important to remember that Azure AD Conditional Access is evaluated AFTER a successful login from a user, not before! This means that it can’t be used to block things like Password Spray Attacks.

Conditional Access policies at their simplest are if-then statements, if a user wants to access a resource, then they must complete an action.

Conceptual Conditional signal plus decision to get enforcement

What is Conditional Access?

For example, user account access can be blocked if it comes from outside a specific country or region.

Conditional Access: Block access by location

and enforcing MFA

Conditional Access: Require MFA for all users

Conditional Access: Require MFA for administrators

Once any Conditional Access policies have been met the user will be able to login to their device. At this point additional Microsoft Endpoint Manager policies will be applied to that specific account now logged in. Such policies could restrict applications the user has access to, limit Windows functionality and so on.

Remember, all of these protections have taken only during the user has logging onto their device. They have not as yet run an application like Outlook to read the inbound emails. That is what is going to happen next and I’ll cover that process in the next part of the series, so stay tuned.

End to End email protection with Microsoft 365–Part 5

Need to Know podcast–Episode 262

Security is big this week and you’ll get it all here. Our cloud news will provide you with all the latest information you’ll need to understand the Solar Winds attack. in this episode we also speak with Daniel Chronlund around Conditional Access. Daniel shares his extensive knowledge around this service and how it can improve your security posture. He also has some great scripts available on his Github repository, so check them out!

I take this opportunity to wish listeners happy holidays. Stay safe and thanks for all your support in 2020. Onwards to 2021 we go, hi ho, hi ho.

This episode was recorded using Microsoft Teams and produced with Camtasia 2020.

Take a listen and let us know what you think – feedback@needtoknow.cloud

You can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-262-daniel-chronlund/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.

Resources

@danielchronlund

Daniel’s blog

Daniel’s GitHub

@directorcia

A moment of reckoning: the need for a strong and global cybersecurity response

Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack, and how Microsoft Defender helps protect

SolarWinds Post-Compromise Hunting with Azure Sentinel

Ensuring customers are protected from Solorigate

Microsoft Defender for Office 365 investigation improvements coming soon

A “quick wins” approach to securing Azure Active Directory and Office 365 and improving your security posture

4 ways Microsoft 365 is improving the experience for Mac users

Sleeping Tabs in Microsoft Edge: Delivering better browser performance

Guest Access in Yammer using Azure AD B2B is now in preview!

Stay current with in-demand skills through free certification renewals

Microsoft Clarity | Free behavioral analytics product for website managers

CIAOPS Patron community