Turn On, Tune In, Cop Out: The sorta, not-really, fix for OuttaTune from Microsoft

Hero image generated by ChatGPT

This is a personal blog. All opinions are my own - not my employer’s.

Enjoying the content? If you value the time, effort, and resources invested in creating it, please consider supporting me on Ko-fi.

Introduction

This is a follow-up to my original post detailing a security flaw in Microsoft Intune’s Conditional Access (CA) filtering that allows local admin attackers to bypass CA policies by modifying a registry value.

Although device filtering in Intune is designed to enable precise policy targeting, this implementation flaw lets attackers subvert policy controls, leading to lateral movement and defense evasion.

Microsoft initially classified this as “by design,” despite the security impact.

No screenshots in this post - if you have an M365 E5 tenant with Intune and can record a demo of the exploit, I’d love to include it (with credit).

Security Implications

Lateral Movement & Defense Evasion

• Attackers can masquerade as a different class of device to access sensitive apps.
• This enables unauthorized lateral access within M365 environments.

Privilege Escalation by Policy Bypass

• Local admin rights allow manipulation of registry values tied to device identity.
• This bypasses Conditional Access logic intended to enforce organizational boundaries.

Microsoft’s Trust in Mutable Device Data

• Properties like device.model are entirely client-controlled.
• There is no validation against trusted roots (TPM, UEFI, IMDS, etc.).
• Intune operates largely in userland, making it more susceptible to tampering.

MSRC Timeline

• 2025-03-05 – Reported to MSRC
• 2025-03-06 – Status changed to Review / Repro
• 2025-03-06 – Case placed on hold with no request for further info
• 2025-03-06 – MSRC responds: “By Design”, case closed
• 2025-03-17 – Reopened after escalation: Severity upgraded to “Moderate”
• 2025-03-26 – PoC video requested
• 2025-04-03 – PoC uploaded
• 2025-04-08 – Meeting with Intune/Entra product teams; no fix commitment; documentation updated
• 2025-04-25 – Case closed again, citing lack of PoC demonstrating full breakout

Since Then

I submitted further clarification and a second PoC video.

25 July:
MSRC questioned whether the attack truly bypassed CA without admin rights or control over policy definitions.

26 July:
I clarified:

• The attacker does not need access to Conditional Access policies
• The attacker only needs local admin on their own machine
• The bypass relies on changing client-controlled attributes (e.g., device.model)
• Microsoft’s own documentation now reflects this as an insecure pattern

27 July:
I followed up:

If the issue is considered “moderate,” yet Microsoft has changed its documentation and UX in response, then recognition should follow. Closing the case without this seems unfair, given the demonstrable impact.

Fast-forward to August 4th 2025 – MSRC closes the case again.

This time, a few improvements rolled out:

Microsoft’s Response

Microsoft made documentation and UX changes to clarify which device attributes are trustworthy.

They now:

• Recommend using at least one system-defined or admin-configured attribute
• Display a tooltip warning during policy creation
• Show Conditional Access dashboard alerts if policies rely only on untrusted attributes

These are helpful nudges.

But they don’t prevent an attacker from bypassing Conditional Access by modifying:

• device.displayName
• device.model
• Any other client-controlled registry value

There are no technical mitigations - just UX hints.

The core issue remains: Conditional Access trusts device properties that the device can spoof.

Acknowledgement, But No Bounty

Microsoft has said they will credit me in the Online Services Acknowledgements.
However, it didn’t meet bounty criteria, so there’s no financial reward.

That’s fine. This work was about raising awareness and encouraging stronger platform defenses.

Documentation & UX Changes

I can validate the updates to Microsoft Learn:
Conditional Access: Filter for devices

Important:
Customers should avoid using Entra device properties (like model, manufacturer, or displayName) on their own in filters, as these can be manipulated by the end user. Use them in conjunction with system-defined or admin-configured properties.

UX changes:

• CA Overview alert for weak filter usage:
  

  

• Tooltip during policy creation:
  

  

Conclusion

These changes improve clarity - but don’t solve the root problem.

What Didn’t Change?

There’s still no:

• Hardware-backed attestation (TPM, HWID, etc.)
• Enforcement blocking use of spoofable properties in CA filters

So while I appreciate the engagement and acknowledgement, the structural vulnerability raised in OuttaTune is still live - and still needs fixing.

Mitigations & Defensive Measures

Since Microsoft won’t address the underlying issue, orgs must take action themselves:

1. Require Device Compliance in CA

Don’t filter by device.model.
Use device compliance as the gate for access.

2. Use EDR/XDR to Monitor Registry Tampering

Example Defender ATP KQL:

DeviceRegistryEvents
| where RegistryKey contains "Control\\\\SystemInformation"
| where RegistryValueName == "SystemProductName"

Refine this to avoid triggering on Intune-created updates.

3. Prefer Entra Join State

Build CA policies on Entra-Joined or Hybrid-Joined status, not mutable device properties.

Final Thoughts

It’s tempting to think Conditional Access and device compliance policies are bulletproof.
But when enforcement depends on tamperable client data, trust becomes fragile.

To everyone building security in the Microsoft ecosystem:

Don’t trust the registry. Don’t trust the OS. Trust what you can verify that is immutable in hardware - virtualised or physical

More to come.

As always, thanks for reading–and feel free to leave your thoughts below.