{
	"id": "3e4a1b38-9c4f-4b00-b364-1094755cc02c",
	"created_at": "2026-04-06T02:13:14.208889Z",
	"updated_at": "2026-04-10T03:23:51.384811Z",
	"deleted_at": null,
	"sha1_hash": "c7b83dfd1157c6e499a99a334fb9b229976cf7f1",
	"title": "Persistent Credential Theft with Authorization Plugins",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 68948,
	"plain_text": "Persistent Credential Theft with Authorization Plugins\r\nArchived: 2026-04-06 02:01:32 UTC\r\nCredential theft is often one of the first tactics leveraged by attackers once they’ve escalated privileges on a\r\nvictim’s machine. Credential theft on OSX has become more difficult with the introduction of System Integrity\r\nProtection (SIP). Attackers can no longer use methods such as extracting the master keys from the securityd\r\nprocess and decrypting the victim’s login keychain. An example of this can be seen here. SIP prevents any user\r\n(even root) from modifying system files, directories, and processes. This might lead an attacker to use other\r\nmethods for credential theft including keylogging, prompting the user for credentials, or triaging the local file\r\nsystem for plaintext credentials. However, there is another alternative called authorization plugins.\r\nAuthorization plugins are used to extend the authorization services API and implement mechanisms that are not\r\nnatively supported by the OS. A legitimate use case would be implementing multi-factor authentication with 3rd\r\nparty software such as Duo. Each plugin can have several mechanisms, or functions contained within the plugin\r\nthat implement custom logic to perform authorization. These mechanisms are also present in the policy database.\r\nThis database contains definitions for various authorization rights. The definition for a particular authorization\r\nright can reference several mechanisms, each paired with their corresponding authorization plugin. Apple briefly\r\ndescribes how this works during the logon process here. Essentially, the loginwindow process tries to obtain the\r\nsystem.login.console right. The definition in the policy database lists several mechanisms that are executed when\r\nthis happens. A custom plugin, along with its mechanism, can be inserted into this list. The position of the entry in\r\nthis list will determine when it will be executed and should be determined based on how the plugin will interact\r\nwith the OS during the logon process. Additionally, a plugin can be configured to run in a privileged or un-privileged context. This is indicated by the entry string within the policy database. For privileged execution,\r\n“,privileged” will need to be appended to the mechanism entry. An author may choose to use an unprivileged\r\nplugin if they wish to access the UI and present a prompt to the user. Additional information on plugin context\r\nissues can be found here.\r\nAn interesting (especially for attackers) feature of authorization plugins is the ability to pass context values\r\nbetween plugins. These values contain important details about the user, including, the home directory, uid, and\r\neven the password in clear-text. This feature exists so that developers who wish to utilize both a privileged and un-privileged plugin, can share data between the two in a relatively easy way. Authorization plugins are an ideal\r\ncredential theft and persistence mechanism for attackers. Persistent credential theft with the ability to execute code\r\nat any point during the login process is invaluable. Installing an authorization plugin is a relatively easy process,\r\nwhich we’ll cover in the next section.\r\nInstallation\r\nAuthorization plugins are comprised of two components; the bundle file that contains all of the plugins code, on\r\ndisk, and an entry into the authorization database. The authorization database is used by the security server to\r\nauthorize specific rights for a given user, based on rules/policies contained within the database. Applications may\r\nchange the rules at any given time using the AuthorizationRightSet, AuthorizationRightGet, and\r\nhttps://xorrior.com/persistent-credential-theft/\r\nPage 1 of 4\n\nAuthorizationRightRemove API calls. When adding an entry to the database, the AuthorizationRightSet function\r\nshould be called with a reference to a NSDictionary containing keys and values for each authentication\r\nmechanism. An example is shown in the Apple documentation here. Alternatively, the AuthorizationRightGet\r\nfunction can be used to obtain the NSDictionary value for an existing right. Then modify the dictionary and add an\r\nentry for the custom authorization plugin using the AuthorizationRightSet function. A python example of this can\r\nbe seen here.\r\nThe authorization database can also be modified via the security command line tool. If an attacker wanted to add a\r\nmalicious plugin to the system.login.console policy, they would need to first read the policy from the authorization\r\ndatabase into a plist file:\r\nsecurity authorizationdb read system.login.console \u003e\u003e system.login.console.plist\r\nThen insert their bundle as one of the mechanisms in the following format:\r\n\u003cstring\u003e[Plugin Name]:auth,privileged\u003c/string\u003e\r\nPlistBuddy can also do this with the following command:\r\n/usr/libexec/PlistBuddy -c “add :mechanisms:[HomeDir Offset] string [bundlename]:login,privileged” \u003cPlist filen\r\nOnce the plist file has been updated, sync this change to the database with the following command:\r\nsecurity authorizationdb write system.login.console \u003c /path/to/plist/file\r\nWeaponization\r\nLet’s walk through creating a plugin with Xcode and then add in logic for payload execution. In this example\r\nwe’ll use a shell command to launch an Apfell payload, but a python empire payload will work as well.\r\n1. First open Xcode and choose the “create a new xcode project option”.\r\n2. Under macOS, select the bundle template. Give the project a name and then click next.\r\nXcode Bundle Project Template\r\n3. Next, download and save all three files listed here in the project folder. Add all three files to the project by\r\nright-clicking the project folder in the navigation pane and then select add files to “[your project name]”.\r\nAdding files to the project\r\n4. Then, setup Apfell and generate a JXA payload. Refer to this blog post by @its_a_feature_ for setup and\r\npayload creation instructions.\r\n5. Copy the JXA one-liner that begins with osascript -l JavaScript and drop it into the appropriate location.\r\nAdding the JXA payload to the project\r\nhttps://xorrior.com/persistent-credential-theft/\r\nPage 2 of 4\n\n6. Select product from the top menu bar and then select build. The resulting bundle will be shown under the\r\nproduct directory on the left navigation pane. Right-click on the bundle file and then select show in finder.\r\nCopy the file to an accessible location of your choosing. Building the project\r\nShow the bundle's location in finder\r\nNow the plugin should be ready for installation. Use the command line tool or the Authorization APIs described in\r\nthe installation section to accomplish this.\r\nOnce the plugin is installed, either restart or complete a logon/logoff cycle to trigger execution. Note that the\r\nplugin will be loaded into the authorizationhost process located here:\r\n/System/Library/Frameworks/Security.framework/Versions/A/MachServices/authorizationhost.bundle/Contents/MacOS/a\r\nNow for a quick demo of installing and executing an authorization plugin. You can find the Xcode project used for\r\nthis demo here.\r\nDetection\r\nFor detection considerations, a solid starting point would be to create rules based on file creation in the\r\n/Library/Security/SecurityAgentPlugins directory. Authorization plugins can only be installed in that directory. An\r\nexample osquery rule for file creation events should look like this:\r\nSELECT * FROM file_events WHERE target_path LIKE '/Library/Security/SecurityAgentPlugins/%' AND action = 'added\r\nCommand line signatures based on usage of the security binary to modify the authorization database should be\r\nmoderately effective for detection. Additionally, for non-enterprise user’s, I would highly recommend installing\r\nsome of the security software offered by Objective-See. KnockKnock, the persistence scanner, has had detection\r\nrules for authorization plugins since 2015!\r\nhttps://xorrior.com/persistent-credential-theft/\r\nPage 3 of 4\n\nKnockKnock Changelog\r\nAuthorization plugins are a high risk/reward method of persistence and credential theft. If something goes a wry\r\nwith the the plugins’ installation, the victim user will almost certainly be suspicious and may alert defenders to\r\nyour presence. On the flipside, they provide an effective method for credential theft and code execution. Attackers\r\ncan continually harvest credentials even in the event that the end-user changes their password. Similarly, you can\r\naccomplish this on windows with mimikatz and it’s Security Support Provider.\r\nSource: https://xorrior.com/persistent-credential-theft/\r\nhttps://xorrior.com/persistent-credential-theft/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://xorrior.com/persistent-credential-theft/"
	],
	"report_names": [
		"persistent-credential-theft"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775441594,
	"ts_updated_at": 1775791431,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c7b83dfd1157c6e499a99a334fb9b229976cf7f1.pdf",
		"text": "https://archive.orkl.eu/c7b83dfd1157c6e499a99a334fb9b229976cf7f1.txt",
		"img": "https://archive.orkl.eu/c7b83dfd1157c6e499a99a334fb9b229976cf7f1.jpg"
	}
}