Mobile — Rooted Android Device on Corporate MDM
Defender for Endpoint's Mobile Threat Defence detected a BYOD personal Android device registered to the corporate Entra ID tenant had been rooted. The device was enrolled exclusively for Microsoft Teams access. Root cause confirmed as sideloaded software. The IT team severed corporate network access and the user performed a factory reset. Classified as a policy violation, not malware-induced. Detection to network removal in 32 minutes — fastest response in this portfolio.
Android rooting is the process of obtaining superuser (root) permissions on an Android device, typically achieved by exploiting firmware vulnerabilities or using specialist unlocking tools (Magisk, SuperSU, KingRoot). In a corporate MDM context, rooting is a critical security concern: root access bypasses the Android application sandbox, removes the separation between managed and personal data spaces, can disable MDM containerisation, and enables extraction of authentication tokens stored in Android's secure Keystore.
Defender for Endpoint MTD detects rooted devices via device health attestation signals — specifically the Android Play Integrity API, which provides hardware-attested OS integrity verification. When rooting is detected, Intune marks the device as non-compliant. Under a correctly configured Conditional Access policy, this would automatically revoke corporate resource access at the moment of detection — without requiring analyst escalation.
The BYOD context is important: this was not a corporately managed device. It was a personal phone registered to the Entra tenant solely to enable Microsoft Teams access. BYOD devices registered for corporate resource access are within the MDM monitoring perimeter and subject to the same integrity requirements as managed endpoints — a boundary that is not always clearly communicated to users.
The affected device was a personal (BYOD) Android phone registered to the corporate Entra ID tenant — not a fully managed corporate asset. It was AAD/Entra registered solely to enable Microsoft Teams access. Rooting detection was triggered by a health attestation signal: specifically, an OS integrity state inconsistent with the device's enrolled baseline as reported by the Android Play Integrity API.
A rooted device in a Microsoft 365 environment presents the following specific risks: Intune Company Portal and all managed applications lose their policy enforcement guarantees, as app protection policies rely on the Android OS security model that root access bypasses; authentication tokens stored in Android's Keystore can potentially be extracted using root-privilege tooling; corporate email content, SharePoint documents, and OneDrive files accessible from the device become accessible outside the managed container.
The device was connected to the corporate network at the time of detection. Network removal by the client's IT team eliminated the risk of corporate data being accessed or exfiltrated via the compromised endpoint during the post-detection window.
Root cause was confirmed following the client's internal investigation: the rooting was triggered by sideloaded software installed on the personal Android device. This closes the incident as a policy violation rather than a malware-induced root escalation — an important classification distinction that determines whether a broader threat hunt is required. Since this was deliberate user action (sideloaded software), no broader hunt was warranted; the follow-on action shifts to BYOD policy enforcement.
No risky events were present in the AADUserRiskEventsTable for the associated user account, suggesting the rooting had not been leveraged for credential or access abuse at the time of detection.
| Type | Indicator | Notes |
|---|---|---|
| Device | [REDACTED]_android | BYOD personal Android — Entra registered for Teams access; rooted OS detected via Play Integrity API |
| MDM Compliance | Non-compliant (rooted) | Intune compliance policy violation — device integrity failure |
| Network Status | Connected at detection time | Risk of corporate data access existed until network removal confirmed |
| Root Cause | Sideloaded software (confirmed) | BYOD personal device — policy violation, not malware-induced root escalation |
| Tactic | Technique | ID | Observed |
|---|---|---|---|
| Defense Evasion | Subvert Trust Controls: Disable / Modify Tools | T1562.001 | Rooting disables MDM enforcement, app sandbox, and mobile security controls |
| Privilege Escalation | Exploitation for Privilege Escalation | T1068 | Root access = OS-level privilege escalation on Android device |
| Credential Access | Steal Application Access Token | T1528 | Root access enables extraction of authentication tokens from Android Keystore (risk) |
| Exfiltration (Risk) | Data from Local System | T1005 | Corporate data in managed apps accessible at root level |
// Confirm device compliance state and rooting signal
DeviceInfo
| where DeviceName contains "[REDACTED_ANDROID]"
| project Timestamp, DeviceName, OSPlatform, ComplianceState, IsAzureADJoined, ManagedBy, OnboardingStatus
// Check for corporate data access before network removal
CloudAppEvents
| where AccountObjectId == "[USER_OBJECT_ID]"
| where DeviceName contains "[REDACTED_ANDROID]"
| where Timestamp > ago(24h)
| project Timestamp, ActionType, ObjectName, Application, AccountDisplayName
// Verify no AAD identity risk events
AADUserRiskEvents
| where UserPrincipalName == "[USER_UPN]"
| where TimeGenerated > ago(7d)
| project TimeGenerated, RiskEventType, RiskLevel, IpAddress, AdditionalInfoFastest triage-to-response cycle in this portfolio — detection to client confirmation was 32 minutes. The BYOD context is the most important clarification: this was a personal phone registered for Teams access, not a fully managed corporate device.
Root cause confirmed as sideloaded software — closes as policy violation. That distinction closes the threat hunt question entirely.
The most important structural advisory remains the Conditional Access gap: device compliance blocking on Entra-registered BYOD devices would have automated containment the moment Intune flagged non-compliance, without requiring analyst escalation.