Hero Image generated by ChatGPT
This is a personal blog and all content therein is my personal opinion and not that of my employer.
Enjoying the content? If you value the time, effort, and resources invested in creating it, please consider supporting me on Ko-fi.
Introduction
This post details a security weakness in Microsoft Intune’s Conditional Access (CA) filtering, which allows attackers with local admin privileges to bypass CA policies by simply modifying a registry value.
While Intune’s device filtering is intended to achieve accurate device targeting for policy application, this design flaw allows attackers to evade those features, enabling lateral movement and defense evasion.
Microsoft initially classified this behavior as “by design,” despite its clear security implications.
There are no screenshots in this blog post as I do not have a personal tenant with an M365 E5 licence and Intune licences - if you do have and are willing to record the exploit in action and credit my blog, I will update the blog and credit you for doing so!
What Happened?
While deploying a Microsoft DevBox environment, I wanted to ensure that the DevBox VMs could not access Office 365 apps. This approach would allow developers to work on cloud-hosted environments while preventing them from accessing corporate resources from these less restricted VMs, which often have more software and tools installed than a normal corporate laptop. This was part of a multifaceted approach to prevent exfiltration of sensitive data such as intellectual property.
The initial security control on top of EDR and Secure Web Gateway (SWG) was a Conditional Access policy, configured as follows:
- Block Office 365 access if the device model starts with
"Microsoft Dev Box" - Allow access only from corporate-managed devices
The expectation? Users on DevBox VMs should be denied access to Office 365.
However, I discovered that this policy could be trivially bypassed by modifying the device model registry key–allowing unrestricted access from DevBox environments.
Exploiting the “OuttaTune” Vulnerability
How the Bypass Works
By changing a single registry value, an attacker can trick Intune into thinking the device is not a DevBox, bypassing Conditional Access restrictions.
Steps to Reproduce
1️⃣ Modify the Registry Key
Run the following PowerShell command as administrator to modify the system’s reported device model:
Set-ItemProperty -Path "HKLM:\SYSTEM\ControlSet001\Control\SystemInformation" -Name "SystemProductName" -Value "OuttaTune"
Alternatively, you can modify the command-line arguments of the Set Device Model scheduled task (which Intune creates to run at system startup) and run the task on demand to achieve the same effect. This also gives persistence - not changing this scheduled task means that the Device Model will revert back to the intended value in next restart - the DevBox SKU in this instance.
2️⃣ Trigger a Device Sync
Either restart the machine or manually force Intune to sync the modified value.
This can be done in the UI by clicking on Start > Apps > Company Portal. Within Company Portal, click on Settings > Sync.
Alternatively this be done via a script such as the powershell script below:
$Shell = New-Object -ComObject Shell.Application
$Shell.open("intunemanagementextension://syncapp")
3️⃣ Observe the Updated Device Model in Entra & Intune
After syncing, check the device model in Microsoft Entra ID or Intune–it will now display "OuttaTune" instead of "Microsoft Dev Box...".
4️⃣ Access Office 365 & Bypass Conditional Access
Navigate to https://office.com and sign in.
- Expected result: Blocked by Conditional Access (Error Code 53003).
- Actual result: Access is granted, despite the device being a DevBox VM. Can access Teams, Outlook, send emails etc.
Security Implications
✅ Lateral Movement & Defence Evasion
- An attacker can masquerade as a different class of device to access sensitive applications.
- This enables lateral movement within an organisation’s cloud environment and data exfiltration through M365.
✅ Privilege Escalation Considerations
- While the attacker requires local admin rights to modify the registry, this effectively escalates their privilege beyond what was intended–bypassing organisational access controls.
✅ Microsoft’s Misplaced Trust in Device Data
- The device model value is entirely client-controlled–it is not validated against a trusted control plane (e.g., UEFI, TPM, or Intune backend or even the Instance MetaData Service or IMDS)).
- Any local admin or attacker with privilege escalation can arbitrarily override Conditional Access policies.
- Intune and its configuration on the managed device is, at least in part, in userland rather than in the kernel where it would be less trivial to tamper with it.
Timeline of the MSRC Case
-
2025-03-05 13:46 – Reported to Microsoft Security Response Center (MSRC)
-
2025-03-06 13:43 – MSRC changed status from New → Review / Repro
-
2025-03-06 06:56 – Follow-up sent after case was put on hold without requesting additional info
-
2025-03-06 16:09 – MSRC response: “By Design” classification, case closed
-
2025-03-17 16:57 – MSRC response: Reopened after (I believe) intervention by support escalation engineer in the support case I had opened in parallel. “…the case has been reassessed. Please ignore the previous assessment of ‘By Design’”. Now rated a ‘Moderate’ severity.
-
2025-03-26 22:59 – MSRC response: POC video requested in response to my challenging the severity - I believe it meets the requirements for an ‘Important’ severity.
-
2025-04-03 20:26 – POC Video Uploaded
-
2025-04-08 16:30 – Meeting held with Entra and Intune product group teams. Discussion held about my ideas for potential fixes. No firm timeline for when or if any of those fixes/ideas will make it into the product but documentation change made to Device Filter documentation (see below).
-
2025-04-25 15:07 – MSRC response: Case closed with the below update
Thank you for your patience on this case and apologies for the delay.
The assessment was reviewed. Please see the assessment comments below.
Analysis Notes: The following claim in the report is theoretical and no PoC was provided demonstrating the exploit of breaking out of the CA policy.
“It was possible to breakout/bypass the CA policy when any of the following conditions were true:
User on VM has local administrative privileges
User is able to elevate to admin via an Endpoint Privilege Management tool
User is able to achieve privilege escalation through any other means”
If you could provide a PoC of the above exploit, we would be happy to reopen the investigation and reconsider the severity.
As of now, the case would remain as ‘Moderate’ due to the stated reason and the product team would be fixing the issue in a future release cycle. MSRC will not be tracking the fix until closure due to its ‘Moderate’ severity.
Microsoft’s Response
MSRC determined that this behavior is “by design”, stating:
“The report mentions that by changing registry value an attacker can bypass conditional access policy. However, the POC does not cover how exactly you are changing registry value what permissions are required. This was the additional information that was required initially.
However, upon further investigation, it was determined that this behavior is ‘by design’.
Please find the analysis comments below.
Analysis Notes:
Entra released a Conditional Access filters feature which allows filtering of CA policy targeting using device directory data. Admins author these filters.
The report identifies that Model information on Windows can be spoofed by any admin on the machine by modifying the registry keys used to discover this data.
Intune cannot accurately lock down a device if an admin on the machine is actively working against management.
Further, assignment filters should be used sparingly as they are a customer specified gap in coverage using unreliable data.
Please refer to the documentation below for more info:
Filter for devices as a condition in Conditional Access policy - Microsoft Entra ID | Microsoft Learn
We will be closing this case”
This response is telling. It suggests that Microsoft’s modern device management software isn’t tamper-resistant and simply relies on users not attempting to evade management on a managed device.
They also recommended using Conditional Access filters sparingly, since they rely on device directory data that can be manipulated by an attacker.
In other words: Microsoft acknowledged this risk but did not plan to fix it.
As noted above, my parallel support case seemed to get the attention of an escalation engineer who understood the severity of the issue, which seems have resulted in a reassessment and classification as a ‘Moderate’ severity vulnerability.
I am also, frankly, astounded that not only is a video required of such a trivial to execute exploit, but also that anyone can watch the video and still call this theoretical… 🤦🏻♂️
Whilst I did get to have a teams meeting with the Entra and Intune product managers, which was a very open and productive conversation, ultimately the only action taken by Microsoft as of the date of this post is to change the documentatation for Conditional Access: Filter for devices to add the following information:
Important
Customers should avoid using Entra device properties (ones that can be modified or manipulated by an end user) just on its own when creating a device filter rule. As an example, use of displayName that can be modified by end user or model, manufacturer, etc. sourced from registry entries that can be manipulated by the end user. Microsoft recommends using these properties in conjunction (use of AND clause) with some of the other properties on the device that are not modifiable by the end user when creating a device filter rule in Conditional Access.
I did also raise a Pull Request(PR) to make further changes that clarify which device properties have which degree of mutability - ultimately this was closed as the Product Manager is working on it in the background.
I challenged the ‘Moderate’ severity as follows:
My Challenge To Microsoft
Thank you for your recent update on this case and for reclassifying the reported behavior as a vulnerability.
I appreciate the review so far and the recognition that a fix is being pursued.
After reviewing the assigned Moderate severity rating, I would respectfully ask that the team reconsider this rating and evaluate the case as Important based on the following rationale:
1. This is a Policy Enforcement Bypass, Not Just a Weakening of Posture
The vulnerability allows an attacker to bypass Conditional Access policies intended to restrict access to sensitive services (e.g., Office 365) based on device identity. This breaks a core security control in the Microsoft 365/Entra trust model.
While the bypass depends on having admin privileges, the impact is not just policy weakening–it’s a complete circumvention of enforcement based on device.model, allowing unauthorized access to restricted resources.
2. Local Admin Requirements Should Not Discount Severity
In modern enterprise threat modeling, the assumption that attackers will gain local admin privileges is table stakes. Techniques for achieving local privilege escalation (LPE) are well-known and often automated.
The fact that this attack requires admin privileges should not significantly reduce the severity, particularly when:
- The attacker already has access to a dev environment like DevBox
- Lateral movement from these environments is a known risk vector
- The impact is breaking a boundary between untrusted and trusted devices
The control is still expected to hold, even in the face of local administrative access. Many security features (e.g., BitLocker, Credential Guard, Secure Boot) are designed with this assumption in mind.
3. The Risk is Cross-Tenant, Trivial to Exploit, and Difficult to Detect
- Exploitation is extremely low-effort: a single registry edit or task modification.
- Once exploited, the device syncs and is treated as compliant and trusted.
- There is no out-of-box telemetry or audit log that would reveal the tampering unless an organization has advanced EDR in place.
- The vulnerability impacts any environment relying on device filters in Conditional Access–including those that assume device.model is immutable or derived from a secure source.
4. Severity Criteria Comparison
Using Microsoft’s own vulnerability severity guidelines, this aligns more closely with “Important”:
- Bypass of a key security boundary (Conditional Access / Intune policy enforcement)
- Enables privilege escalation within M365 service boundaries
- Can be used to facilitate lateral movement, data exfiltration, or bypass of data residency/sandboxing controls (e.g., DevBox isolation)
It does not meet the bar for “Critical” (no remote code execution, no unauthenticated compromise), but it clearly goes beyond what would be expected for a Moderate rating.
Given these points, I believe this issue aligns more closely with the Important severity category. I ask that the case be reconsidered accordingly, so that appropriate attention and downstream communication can reflect the true risk to organizations.
Please let me know if any additional information would help inform a reassessment. Thank you again for your time and engagement on this issue.*
Mitigations & Defensive Measures
Since Microsoft won’t fix this, organisations must implement additional layers of security to mitigate the risk:
1️⃣ Require Device Compliance in Conditional Access
- Instead of filtering by device model, enforce device compliance as a prerequisite for accessing corporate resources.
2️⃣ EDR/XDR-Based Real-Time Tamper Detection
-
Use your EDR of choice to monitor registry modifications.
-
Example Defender ATP Rule:
DeviceRegistryEvents | where RegistryKey contains "Control\\SystemInformation" | where RegistryValueName == "SystemProductName"You will probably have to finesse it a little to avoid triggering on when Intune does it, so for example if the value didnt actually change, we don’t care - only if the value changed.
-
Trigger automated device isolation if tampering is detected.
3️⃣ Use Entra Join state instead of device.model
- Require Entra-Joined or Hybrid-Joined devices rather than mutable OS-reported data for access decisions.
Discounted Mitigations
Why Autopilot Doesn’t Work for Virtual Machines
✅ For Physical Devices:
- Autopilot assigns a unique hardware-based Device ID to each physical endpoint.
- This ID is stored in the cloud and cannot be changed by the user, making it a reliable enforcement point for CA.
❌ For Virtual Machines (DevBox, Windows 365, Azure VMs):
- Device ID is not persistent–it can change when a VM is rebuilt or reimaged.
- VM metadata is mutable–attackers (or even legitimate users) with admin access can easily alter registry keys, MAC addresses, and even some BIOS identifiers.
- No TPM-backed attestation–unlike physical endpoints, VMs typically lack hardware-based identity validation, making spoofing trivial.
Why Custom Compliance Policies Fall Short
- Detection Delay (Up to 8 Hours)
- An attacker who modifies the device model registry key can bypass the CA policy immediately and remain undetected for up to 8 hours before the next compliance check marks the device as non-compliant.
- During this window, they can exfiltrate data, move laterally, or establish persistence.
- No On-Demand Compliance Check
- Since compliance checks cannot be manually triggered, an admin cannot proactively enforce compliance upon suspicion of tampering.
- The attacker retains a large operational window before detection.
- No Immediate Conditional Access Enforcement
- Even if the custom compliance policy detects the tampering after 8 hours, Conditional Access policies don’t block the device retroactively–it only applies at the next login or access attempt.
- This means an attacker already authenticated and granted a session could continue operating freely even after the device is flagged as non-compliant.
Conclusion
“OuttaTune” is a fundamental security weakness in Microsoft Intune.
Microsoft’s original “by design” response leaves organisations at risk, as does the lack of any urgency around a fix now that it has been reclassified as a security vulnerability (albeit a Moderate one), but by implementing real-time EDR monitoring, stricter compliance enforcement, and Entra device join status, you can mitigate the impact.
At time of publication, the MSRC case is closed.
There are no case points allocated and there is no public recognition or acknowledgement of my contribution here.
📢 Call to Action:
- Reevaluate any Conditional Access policies that rely on device filtering.
As ever, thanks for reading and feel free to leave comments down below!