Priority Boarding for Hackers? Closing Conditional Access Gaps

Ever feel like airport security is a chore? You are juggling shoes in one hand, your laptop in the other, praying you will not lose a sock in the process. It is inconvenient—but it is also what keeps everyone on board safe. Microsoft’s Conditional Access Policies (CAPs) operate much the same way, verifying users and devices at sign-in before letting them into your organization’s cloud resources.

But similar to someone being able to theoretically sneaking a small contraband item through a busy security line, misconfigured CAPs can leave your Microsoft 365 tenant vulnerable. This post explores how attackers sidestep Conditional Access, why the Intune enrollment gap is so sneaky, and how you can stop malicious actors before they roam your cloud unchecked.

Conditional Access only watches the front door. After someone successfully signs in, CAPs typically do not keep re-validating device compliancy or user identity. If an attacker steals valid credentials—or worse, a Multi Factor Authentication (MFA) session token—they might slip past any future checks like a stowaway.

Organizations often enforce ‘managed device only’ or ‘domain-joined device only’ rules for added security. But if there is even a small crack—like an app that does not require MFA—an attacker can exploit it. All it takes is one misconfiguration or overlooked exception, and the doors to SharePoint, Outlook, or Azure remain wide open for someone with the right token.

Intune, Microsoft’s device management platform, needs to let fresh or factory-reset devices enroll. That means users can download the Company Portal app and sign in—even if their device is not marked as compliant yet. Makes sense for new employees, right?

The trouble is, some attackers have reverse-engineered this enrollment flow to obtain tokens for apps beyond the Company Portal.

As a result, they can misuse these tokens to gain unauthorized access to Microsoft 365 applications. Security researcher Dirk-Jan Mollema first discovered that the Company Portal app, identified by the client ID 9ba1a5c7-f17a-4de9-a1f1-6178c8d51223, could be exploited in this way.

Tools like TokenSmith by JumpsecLabs automate this process, allowing attackers to request a token (intended for Intune enrollment) and then reuse or exchange it for full-blown Microsoft 365 access. If your Company Portal sign-in does not enforce MFA or other strong checks, it is like handing over a master key.

1. Take a clean Windows VM or a personal device not managed by your organization
2. Download the Company Portal app.
3. Sign in with your corporate account.
4. If you are able to get in without being forced to MFA or meet device compliance, you have got a glaring gap.

Many businesses assume the setting ‘only managed devices can access resources stops attackers cold. But as soon as an attacker gets valid credentials, they can poke around to find any conditional access rule that is less strict—like the Company Portal. They can then request an enrollment token and exchange it for full-blown access, neatly bypassing the ‘managed device’ requirement.

From a red team perspective, it is fascinating—and from a security perspective, it is terrifying. Once in, an attacker can read emails, mess with SharePoint permissions, or even escalate privileges.

1. Require MFA on Intune Enrollment
   Even brand-new or freshly reset devices should face an MFA prompt before they can enroll. It is a small inconvenience for legitimate users, but it massively raises the bar for would-be attackers.
2. Set Explicit ‘Block’ Policies
   Do not rely on implicit blocks. If your policy states ‘only managed devices are allowed’, be sure you also define a rule that explicitly denies access when the device is not compliant. Gaps occur when we forget to set ‘Block everything else’.
3. Watch for Suspicious Company Portal Sign-Ins
   If new device enrollments are rare in your environment, look for odd sign-in patterns-like someone enrolling from a random IP address at 2 a.m. or from a suspicious geographic location. Unusual sign-ins to the Company Portal followed by immediate activity on Microsoft Graph or SharePoint should raise red flags.
4. Strengthen Authentication
   Consider passwordless methods like FIDO2 keys or certificate-based authentication. These approaches require cryptographic proof tied to physical devices, making it far harder for attackers to reuse tokens or credentials.

There are several common attack scenarios where attackers can abuse this vulnerability:

1. Phishing & Man-in-the-Middle

Attackers trick a user into a fake sign-in page, capture not just the username/password but also the MFA code. They use that valid session token to log in, bypassing CAP checks after the initial sign-in.

2. Token reuse

Tokens from Intune, Teams, or Outlook can often be exchanged for broader access to Microsoft 365. If your CAP is not reevaluating compliance or MFA at each resource, an old refresh token might open new doors.

3. Brute-forcing policy gaps

Attackers systematically try different client IDs (for Teams, SharePoint, Company Portal, etc.) to see which ones slip past your CAP. Once they find a path, they can quietly exploit it until you notice—or until it is too late.

Conditional Access is powerful, but only if it is configured to block every path attackers might take. If just one enrollment policy or legacy app bypasses your robust checks, it is all for nothing. Attackers know this, and so should you.

Microsoft offers tools like the Conditional Access Gap Analyzer workbook for Sentinel, but it is not a magic bullet. You will need to combine logging data, custom detection scripts, and a healthy dose of diligence to pinpoint vulnerabilities. The Conditional Access Impact Matrix by Jasper Baes complements this by mapping CAPs to users and visualizing their impact, aiding in gap detection and compliance assessments.

While the specifics of log queries and detection mechanisms are discussed in detail elsewhere, the core defensive strategy is to monitor for anomalous sign-ins. In practice, any successful login to the Company Portal from a device that is not fully compliant should trigger an immediate investigation. Look for patterns such as unusual geographies, odd timing (for instance, sign-ins at 2 a.m.), or subsequent activity that quickly escalates privileges.

It is a stark reminder that while Conditional Access policies are robust when configured correctly, every additional path—especially those designed for new device enrollments—needs extra vigilance. The real-world exploit demonstrates that attackers are adept at finding the tiniest misconfiguration. Ensuring that enrollment flows enforce MFA and strict compliance, and that your monitoring systems are tuned to catch these subtle deviations, is paramount.

Treat every access token like a security badge that grants wide-ranging permissions. Enforce MFA everywhere you can, actively block unapproved apps or device states, and pay special attention to those ‘first-time’ sign-ins via the Company Portal. With careful configuration and continuous auditing, you can ensure your Conditional Access Policies do more than just check boarding passes—they will keep the entire flight secure.