Research Update Enhanced src/macos-hardening/macos-red-teami...

src/macos-hardening/macos-red-teaming/macos-mdm/enrolling-devices-in-other-organisations.md

@@ -43,15 +43,58 @@ This method allowed the researchers to retrieve DEP profiles for supplied, assig
 
 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>
 
-### Potential Impacts of DEP and MDM Vulnerabilities
+## 2025 Revisit: Rogue Enrollment from a VM
+
+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>
+
+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>
+
+```xml
+<key>SystemProductName</key>
+<string>iMacPro1,1</string>
+<key>SystemSerialNumber</key>
+<string>AUTHORIZED_TEST_SERIAL</string>
+```
+
+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>
+
+```bash
+sudo plutil -p /var/db/ConfigurationProfiles/Settings/.profilesDEPTimerCheck 2>/dev/null
+sudo plutil -p /var/db/ConfigurationProfiles/Settings/.cloudConfigRecordFound 2>/dev/null
+```
+
+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>
+
+### Post-Enrollment Secret Hunting
+
+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>
+
+Useful review targets include:<sup>[[3]](#references)</sup>
+
+- Installed `.mobileconfig` payloads and the Configuration Profiles database.
+- PreStage/bootstrap scripts and packages that create accounts or install EDR/VPN agents.
+- Munki or other package repository URLs, especially query strings containing bearer/SAS-style signatures.
+- Self-service catalogs and their backing policy APIs, including legacy routes that may not enforce the enrollment SSO policy.
+- Shell history and cached policy output for `password`, `token`, `secret`, `Authorization`, webhook hostnames, and vendor API endpoints.
+
+### Hardening the Trust Boundary
+
+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>
+
+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>
+
+## Potential Impacts of DEP and MDM Vulnerabilities
 
 The research highlighted significant security concerns:
 
 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>
 
+
+
 ## References
 
 - [1] [Duo Labs — MDM Me Maybe: Device Enrollment Program Security](https://duo.com/labs/research/mdm-me-maybe)
 - [2] [Apple Platform Deployment — Automated Device Enrollment](https://support.apple.com/guide/deployment/automated-device-enrollment-and-mdm-dep73069dd57/web)
-
+- [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)
+- [4] [Apple Platform Security — Managed Device Attestation](https://support.apple.com/guide/security/managed-device-attestation-sec8a37b4cb2/web)
 {{#include ../../../banners/hacktricks-training.md}}