You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/macos-hardening/macos-red-teaming/macos-mdm/enrolling-devices-in-other-organisations.md
+45-2Lines changed: 45 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -43,15 +43,58 @@ This method allowed the researchers to retrieve DEP profiles for supplied, assig
43
43
44
44
The exploitation process was automated using Python with the LLDB API, making it feasible to programmatically inject arbitrary serial numbers and retrieve corresponding DEP profiles.<sup>[[1]](#references)</sup>
45
45
46
-
### Potential Impacts of DEP and MDM Vulnerabilities
46
+
## 2025 Revisit: Rogue Enrollment from a VM
47
+
48
+
Black Hat Asia 2025 research demonstrated that the original trust-boundary problem can still matter at the **MDM layer**: instead of patching `cloudconfigurationd` with LLDB, the researchers ran macOS under QEMU/KVM with OpenCore and supplied the candidate identity through the VM's SMBIOS. The unmodified macOS enrollment stack then performed the encrypted Apple exchange. Publicly leaked serials and valid-looking candidates can therefore be tested without possessing the corresponding physical Mac; a hit still requires that the serial is assigned to an organization and that the organization's enrollment path is insufficiently authenticated.<sup>[[3]](#references)</sup>
49
+
50
+
For an authorized lab device, the relevant OpenCore `PlatformInfo` values include a product model and serial (real deployments also keep the ROM and UUID internally consistent):<sup>[[3]](#references)</sup>
51
+
52
+
```xml
53
+
<key>SystemProductName</key>
54
+
<string>iMacPro1,1</string>
55
+
<key>SystemSerialNumber</key>
56
+
<string>AUTHORIZED_TEST_SERIAL</string>
57
+
```
58
+
59
+
The same research identified `CheckProfilesFetchRateLimit` state in the private file `/var/db/ConfigurationProfiles/Settings/.profilesDEPTimerCheck`. Because the check was maintained on the client, modifying the stored time values defeated it. These paths are undocumented and version-dependent, but they are useful reversing pivots when assessing a current macOS build:<sup>[[3]](#references)</sup>
The second artifact can disclose the cached activation record, including whether the flow uses a direct `ConfigurationURL` or an authenticated `ConfigurationWebURL`. Test both the advertised flow and any MDM-specific legacy enrollment endpoints: enabling SSO only on the main web flow does not protect a parallel direct endpoint. For the complete protocol sequence, see the [macOS MDM overview](README.md).<sup>[[3]](#references)</sup>
67
+
68
+
### Post-Enrollment Secret Hunting
69
+
70
+
A rogue enrollment is only the entry point. After enrollment, inspect every delivered profile, bootstrap policy, package-repository configuration, agent installation script, and self-service item. The 2025 research recovered examples of Wi-Fi credentials, shared local-administrator passwords, signed cloud-storage URLs, webhook URLs, security-agent activation data, and MDM/API credentials. A tenant API credential in a delivered script can turn one rogue endpoint into control over other managed devices, so search both the live filesystem and downloaded/cached policy content.<sup>[[3]](#references)</sup>
- Installed `.mobileconfig` payloads and the Configuration Profiles database.
75
+
- PreStage/bootstrap scripts and packages that create accounts or install EDR/VPN agents.
76
+
- Munki or other package repository URLs, especially query strings containing bearer/SAS-style signatures.
77
+
- Self-service catalogs and their backing policy APIs, including legacy routes that may not enforce the enrollment SSO policy.
78
+
- Shell history and cached policy output for `password`, `token`, `secret`, `Authorization`, webhook hostnames, and vendor API endpoints.
79
+
80
+
### Hardening the Trust Boundary
81
+
82
+
Treat a serial number as an inventory/routing attribute, **not** proof of possession. Require user authentication for enrollment and self service, generate unique per-device local administrator passwords, and never embed tenant API credentials or reusable infrastructure secrets in profiles or scripts. Keep any unavoidable bootstrap token short-lived and restricted to the single action and device being provisioned.<sup>[[3]](#references)</sup>
83
+
84
+
On Apple-silicon Macs running macOS 14 or later, Managed Device Attestation can cryptographically bind identity to the Secure Enclave. Its Apple-rooted attestation can carry a fresh nonce plus the serial number, UDID, OS version, SIP state, and secure-boot state; ACME can then issue a hardware-bound client identity. Use that identity to protect the MDM channel and gate high-value certificates, VPN access, and other resources, while retaining separate user authentication because device attestation proves the device rather than the operator.<sup>[[4]](#references)</sup>
85
+
86
+
## Potential Impacts of DEP and MDM Vulnerabilities
47
87
48
88
The research highlighted significant security concerns:
49
89
50
90
1.**Information Disclosure**: By providing a DEP-registered serial number, sensitive organizational information contained in the DEP profile can be retrieved.<sup>[[1]](#references)</sup>
51
91
92
+
93
+
52
94
## References
53
95
54
96
-[1][Duo Labs — MDM Me Maybe: Device Enrollment Program Security](https://duo.com/labs/research/mdm-me-maybe)
-[3][Black Hat Asia 2025 — Impostor Syndrome: Hacking Apple MDMs Using Rogue Device Enrolments](https://i.blackhat.com/Asia-25/Asia-25-Molnar-Impostor-Syndrome-Hacking-Apple-MDMs.pdf)
0 commit comments