Pushing a rogue trusted root to the fleet: Intune profile MITM

Intune configuration profiles are how a fleet gets its proxy, Wi-Fi, and trusted certificates. That same trusted channel can deliver a rogue proxy and a rogue trusted root, which is the recipe for fleet-wide TLS interception.

How the attack works

An operator with configuration rights creates a profile bundling a rogue proxy or VPN, a Wi-Fi profile, and an attacker-controlled trusted-root certificate, then assigns it to an all-devices group. As devices check in, they silently install the trusted root and route traffic through the rogue proxy. With the rogue root trusted and traffic proxied, corporate TLS sessions can be intercepted and decrypted across the fleet. This is Adversary-in-the-Middle, T1557, paired with Modify Authentication Process, T1556.

Why it works

Proxy, Wi-Fi, and certificate profiles are normal Intune content, so each piece looks routine. The combination is what matters: pairing a rogue proxy with an unrecognized trusted root, pushed to all devices outside any change process, is the tell, but devices apply the profile without prompting because trusted Intune delivered it.

How to fix it

Cleaning the one laptop an analyst flagged leaves every other device trusting the rogue root and proxied. Two moves stop it: remove the profile from assignment to halt deployment, then rotate or distrust the pushed trusted-root certificate so any intercepted TLS can no longer be trusted. For the class fix, restrict who can create and assign configuration profiles, especially trusted-root and proxy settings, require change approval for all-device assignments, and alert on profile creation and assignment.

Practice it

We built this as a GraphLattice Range scenario so administrators can rehearse spotting a malicious profile, unassigning it fleet-wide, and breaking the rogue trusted-root trust.