{
	"id": "2d1fd136-c6d2-40fc-9c1a-bd6874f8d659",
	"created_at": "2026-04-06T00:08:29.375549Z",
	"updated_at": "2026-04-10T13:12:57.803624Z",
	"deleted_at": null,
	"sha1_hash": "03bd5a411b949e6fe1d2f3e6d9679e91f64bcf60",
	"title": "MDM and the Kextpocalypse 2 – Richard Purves",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 59315,
	"plain_text": "MDM and the Kextpocalypse 2 – Richard Purves\r\nPublished: 2017-11-10 · Archived: 2026-04-05 17:15:31 UTC\r\nYes there’s another Kextpocalypse heading the Mac Admin’s way. Unusually it’s going to hit on the next point\r\nrelease of macOS. 10.13.2 is going to have a LOT to answer for, as is Apple.\r\nBefore we continue, I need to reference my sources here as this info isn’t officially public but it’s discussed in\r\nenough public forums not to matter. First up is an open radar called “Please document the new 10.13.2 User-Approved MDM Enrollment and new MDM payloads outside of AppleSeed”\r\nwhich I highly suggest you read first.\r\nNext up is a public Apple Technical Note, number TN2459 to be exact which provides some other information.\r\nTake your time, read both and once you’re done come back to me.\r\n..\r\nWhat the hell Apple? You can’t just introduce wide sweeping technical changes like that with almost ZERO notice\r\nand what notice there was is buried behind the Appleseed program which is INVITE ONLY . I mean, if this\r\nhadn’t got out there’d be so many highly annoyed admins out there scrambling to unbreak what you’re about to\r\nbreak.\r\nMore warning in future please Apple. Ok done. On with the rest of the post. The salient points are as follows.\r\nThere is now “User Approved Mobile Device Management” or UAMDM.\r\nThere is now “User Approved Kernel Extension Loading” or UAKEL.\r\nIf your device is DEP enrolled into an MDM solution, you don’t need to worry about UAMDM but\r\nUAKEL is still a concern.\r\nIf your device isn’t DEP enrolled into an MDM, you will have restricted management options unless the\r\nuser grants them to you.\r\nUAKEL is disabled if you have an MDM for now.\r\nUAKEL can have a whitelist via a configuration profile.\r\nOh and all you non MDM managed devices are utterly screwed if you want to deploy software with kext’s in it.\r\nNon MDM solutions just got a lot nastier to use.\r\nAfter LOTS of chat today in the Mac Admin Slack, especially in #security it can all be summed up as follows.\r\nDEP enrolled into an MDM, with a profile to whitelist kexts or game over.\r\nThis is an enterprise nightmare and I don’t say that lightly. I deal with high security type environments where all\r\nthe stuff the users would approve kexts and apps is disabled by design and also by security requirement. This is\r\nreally going to make life difficult. Again, why is this in a point release? You may have enough time to prepare if\r\nyou all start now.\r\nhttps://richard-purves.com/2017/11/09/mdm-and-the-kextpocalypse-2/\r\nPage 1 of 5\n\nI can’t do much about DEP and I think this is another nail in the coffin of imaging macs, but remember I\r\nmentioned that you can whitelist kexts in a profile. That I can help you with, and I’ve done a lot of work today\r\ntrying to decipher what limited information is available to me.\r\ncom.apple.syspolicy.kernel-extension-policy is the new payloadtype that must be delivered via a User Approved\r\nMDM. (See? Can’t even whitelist the apps you might need unless user says yes or you DEP’d things.) It has three\r\nkeys that are quite important. Let’s go through them.\r\nAllowUserOverrides – This controls is a user is allowed to approve kexts for use that aren’t in the profile\r\nAllowedTeamIdentifiers – This is an approved list of “team identifiers”, so that their kexts will be allowed\r\nto load.\r\nAllowedKernelExtensions – This is a map of “team identifiers” to “bundle identifiers”. You can basically\r\nspecify what kexts for a given vendor you want to load instead of all of them.\r\nA “Team Identifier” is a string that looks like this: “DX1G23M4N5” and appears to be tied to the vendor’s Apple\r\nID. It appears unique to each vendor.\r\nA “Bundle Identifier” is part of the Info.plist inside each kext bundle. It’s actually the CFBundleIdentifier field\r\nand anyone who’s done app packaging should be familiar with it as it’s a unique identifier for that kext.\r\nBut how does that work in a profile? Let’s take a look at one i’ve managed to piece together from the scraps of\r\ninfo out there.\r\n[cc lang=”xml”]\r\nAllowUserOverrides\r\nAllowedTeamIdentifiers\r\nteam id here\r\nteam id here\r\nAllowedKernelExtensions\r\nteam id\r\nbundle id here\r\nunsigned bundle id here\r\nhttps://richard-purves.com/2017/11/09/mdm-and-the-kextpocalypse-2/\r\nPage 2 of 5\n\n[/cc]\r\nI’ve annotated the example to give you an idea of what goes where. The AllowUserOverrides is a boolean\r\ntrue/false condition. The AllowedTeamIdentifiers is an array list of the team id’s and the\r\nAllowedKernelExtensions is a key for the team id then an array of every kext approved made by that team id.\r\nYou wouldn’t, for example, put an id in the AllowedTeamIdentifiers then specify the same id with specific kext\r\nbundle ids in AllowedKernelExtensions. You would mix and match depending on whether you want to whitelist\r\nglobally or for specific kext files.\r\nThe exception is if you’re a developer with an unsigned kext under test, you can leave the key blank and just\r\nspecify the bundle identifier on it’s own. Note, you won’t be able to distribute your kext by Apple without having\r\nit signed first!\r\nSince posting I’ve been informed that the above isn’t the case. Unsigned kexts during development cannot be\r\nloaded on a normal security-enabled system, so the profile cannot allow them to load. Whoops.\r\nThe really hard part is working out what this data is in the first place! I’ve already mentioned how you can get the\r\nCFBundleIdentifier from inside the kext but how do you work out what the Team Identifier is? Well turns out that\r\n“codesign” in terminal is our friend. Using MalwareBytes installed kext as an example .. behold!\r\n[cc lang=”bash”]\r\ncodesign -d -vvvv /Library/Extensions/com.malwarebytes.mbam.rtprotection.kext 2\u003e\u00261 | grep\r\n“Authority=Developer ID Application:” | cut -d”(” -f2 | tr -d “)”\r\nGVZRY6KDKR\r\n[/cc]\r\nSo we can now work out what the Team Identity for a given kext is, we can find the Bundle Identity for a given\r\nkext and we’ve an idea how to configure the whitelist plist … how do you find these things? They can be scattered\r\nall over the place. The answer lies in the following script that I quickly through together today.\r\n[cc lang=”bash”]\r\n#!/bin/bash\r\n# Script to scan a system for kexts and gather the information needed for Apple whitelisting\r\n# richard at richard – purves dot com\r\n# Stop IFS linesplitting on spaces\r\nOIFS=$IFS\r\nIFS=$’\\n’\r\n# Scan the following folders to find 3rd party kexts\r\n# /Applications\r\n# /Library/Extensions\r\n# /Library/Application Support\r\nhttps://richard-purves.com/2017/11/09/mdm-and-the-kextpocalypse-2/\r\nPage 3 of 5\n\necho “Searching Applications folder”\r\napplic=($( find /Applications -name “*.kext” ))\r\necho “Searching Library Extensions folder”\r\nlibext=($( find /Library/Extensions -name “*.kext” -maxdepth 1 ))\r\necho “Searching Library Application Support folder”\r\nlibapp=($( find /Library/Application\\ Support -name “*.kext” ))\r\necho “”\r\n# Merge the arrays together\r\nresults=(“${applic[@]}” “${libext[@]}” “${libapp[@]}”)\r\nif [ ${#results[@]} != “0” ];\r\nthen\r\nfor (( loop=0; loop\u003c${#results[@]}; loop++ )) do # Get the Team Identifier for the kext teamid=$( codesign -d -\r\nvvvv ${results[$loop]} 2\u003e\u00261 | grep “Authority=Developer ID Application:” | cut -d”(” -f2 | tr -d “)” )\r\n# Get the CFBundleIdentifier for the kext\r\nbundid=$( defaults read “${results[$loop]}”/Contents/Info.plist CFBundleIdentifier )\r\necho “Team ID: $teamid Bundle ID: $bundid”\r\ndone\r\nfi\r\nIFS=$OIFS\r\nexit\r\n[/cc]\r\nRun with sudo, this’ll give an output similar to this:\r\n[cc lang=”bash”]\r\nRichards-MacBook-Pro:Desktop richardpurves$ sudo ./findkextinfo.sh\r\nPassword:\r\nSearching Applications folder\r\nSearching Library Extensions folder\r\nSearching Library Application Support folder\r\nTeam ID: EG7KH642X6 Bundle ID: com.vmware.kext.vmnet\r\nTeam ID: EG7KH642X6 Bundle ID: com.vmware.kext.vmci\r\nTeam ID: EG7KH642X6 Bundle ID: com.vmware.kext.vmx86\r\nTeam ID: EG7KH642X6 Bundle ID: com.vmware.kext.vmioplug.17.1.2\r\nTeam ID: FC94733TZD Bundle ID: com.ATTO.driver.ATTOExpressSASHBA2\r\nTeam ID: K3TDMD9Y6B Bundle ID: com.Accusys.driver.Acxxx\r\nTeam ID: NDGSU3WA4Y Bundle ID: com.softraid.driver.SoftRAID\r\nhttps://richard-purves.com/2017/11/09/mdm-and-the-kextpocalypse-2/\r\nPage 4 of 5\n\nTeam ID: DX6G69M9N2 Bundle ID: com.highpoint-tech.kext.HighPointIOP\r\nTeam ID: 8R7PS6VYW7 Bundle ID: com.CalDigit.driver.HDPro\r\nTeam ID: DX6G69M9N2 Bundle ID: com.highpoint-tech.kext.HighPointRR\r\nTeam ID: 34JN824YNC Bundle ID: com.Areca.ArcMSR\r\nTeam ID: FC94733TZD Bundle ID: com.ATTO.driver.ATTOCelerityFC8\r\nTeam ID: 6HB5Y2QTA3 Bundle ID: com.hp.kext.io.enabler.compound\r\nTeam ID: 268CCUR4WN Bundle ID: com.promise.driver.stex\r\nTeam ID: FC94733TZD Bundle ID: com.ATTO.driver.ATTOExpressSASRAID2\r\nTeam ID: GVZRY6KDKR Bundle ID: com.malwarebytes.mbam.rtprotection\r\n[/cc]\r\nRun this script with sudo, so it can work it’s way past any permissions issues. McAfee likes to lock it’s own kexts\r\ndown so nothing can tamper with them, for example. It’ll produce an on screen list that’ll make generating your\r\nown kext whitelist a lot easier than doing it all by hand.\r\nAdd to your MDM, and deploy in the usual way via APNS. That’ll help but remember the big lesson i’ve drawn\r\nfrom this is DEP is now the official way forward for enterprises and we should embrace it very quickly.\r\nSource: https://richard-purves.com/2017/11/09/mdm-and-the-kextpocalypse-2/\r\nhttps://richard-purves.com/2017/11/09/mdm-and-the-kextpocalypse-2/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://richard-purves.com/2017/11/09/mdm-and-the-kextpocalypse-2/"
	],
	"report_names": [
		"mdm-and-the-kextpocalypse-2"
	],
	"threat_actors": [],
	"ts_created_at": 1775434109,
	"ts_updated_at": 1775826777,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/03bd5a411b949e6fe1d2f3e6d9679e91f64bcf60.pdf",
		"text": "https://archive.orkl.eu/03bd5a411b949e6fe1d2f3e6d9679e91f64bcf60.txt",
		"img": "https://archive.orkl.eu/03bd5a411b949e6fe1d2f3e6d9679e91f64bcf60.jpg"
	}
}