{
	"id": "d33b650c-9424-4e4e-8b8d-4bdf839f231d",
	"created_at": "2026-04-06T01:31:43.858062Z",
	"updated_at": "2026-04-10T03:21:27.824509Z",
	"deleted_at": null,
	"sha1_hash": "c8cc519bf97b299b781b24dee4b808f9c6250c77",
	"title": "Zero-Day TCC bypass discovered in XCSSET malware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 747560,
	"plain_text": "Zero-Day TCC bypass discovered in XCSSET malware\r\nBy Jaron Bradley, Stuart Ashenbrenner, Ferdous Saljooki\r\nArchived: 2026-04-06 00:54:28 UTC\r\nMay 24 2021 by\r\nJaron Bradley\r\nStuart Ashenbrenner\r\nFerdous Saljooki\r\nAuthors: Stuart Ashenbrenner, Jaron Bradley and Ferdous Saljooki\r\nIntroduction\r\nIn the latest macOS release (11.4), Apple patched a zero-day exploit (CVE-2021-30713) which bypassed the\r\nTransparency Consent and Control (TCC) framework. This is the system that controls what resources applications\r\nhave access to, such as granting video collaboration software access to the webcam and microphone, in order to\r\nparticipate in virtual meetings. The exploit in question could allow an attacker to gain Full Disk Access, Screen\r\nRecording, or other permissions without requiring the user’s explicit consent — which is the default behavior. We,\r\nthe members of the Jamf Protect detection team, discovered this bypass being actively exploited during additional\r\nanalysis of the XCSSET malware, after noting a significant uptick of detected variants observed in the wild. The\r\ndetection team noted that once installed on the victim’s system, XCSSET was using this bypass specifically for the\r\npurpose of taking screenshots of the user’s desktop without requiring additional permissions.\r\nWhat is the XCSSET malware?\r\nIn August 2020, a new strain of malware dubbed XCSSET was revealed by Trend Micro. This malware targeted\r\nMac developers by infecting Xcode projects as a means of further spreading via Github repositories to expand its\r\nreach.\r\nOne of the more novel aspects of note is the way in which the malware was developed, written in AppleScript - a\r\nscripting language developed by Apple - that facilitates control over script-enabled Mac applications. Much of the\r\ntime the malware author leverages AppleScripts in their attack chain due to the facility in which it handles many\r\nbash commands, even downloading and/or executing Python scripts in an effort to obfuscate their intentions\r\nthrough a confusing use of various scripting languages.\r\nUpon initial discovery, one of the most notable features of the XCSSET malware was that it reportedly utilized\r\ntwo zero-day exploits. This first was used to steal the Safari browser cookies - which are protected by system\r\nintegrity protection; while the second was used to bypass prompts in order to install a developer version of the\r\nhttps://www.jamf.com/blog/zero-day-tcc-bypass-discovered-in-xcsset-malware/\r\nPage 1 of 6\n\nSafari application. Diving further still into the malware, Jamf discovered that it has also been exploiting a third\r\nzero-day to bypass Apple’s TCC framework.\r\nWhat is TCC?\r\nFrom the user’s perspective, TCC is the prompt they receive when a program attempts to perform an action that\r\nApple believes should require explicit permission from the user before allowing the action to occur, as referenced\r\nin the video collaboration example mentioned previously. Other examples of TCC in action are saving files to the\r\nDocuments directory, recording keystrokes, and taking a screenshot. When an application attempts to perform\r\nsuch an action, the user is presented with a prompt asking them if they would like to grant or deny the application\r\npermission to do so. In some instances, users are required to first go into the System Preferences and authorize\r\npermissions to the application granularly before it can perform the action. Upon granting permissions to any\r\napplications, they’re now free to perform that action without prompting the user again until it is manually disabled\r\nin the privacy settings.\r\nThe example below shows the Terminal app prompting the user for permission to run a program that wants to take\r\na screenshot.\r\nThe application can then be given permissions via the system preferences.\r\nThe Bypass\r\nWhile dissecting the malware, Jamf Protect detection team members took note of an AppleScript module\r\ntitled“screen_sim.applescript.” Inside it, they noticed an interesting check called “verifyCapturePermissions”\r\nbeing used which takes an application ID as an argument.\r\nhttps://www.jamf.com/blog/zero-day-tcc-bypass-discovered-in-xcsset-malware/\r\nPage 2 of 6\n\nBy looking at the log comment alone, it seems as though the malicious AppleScript is searching for an application\r\nthat has permissions to capture a screenshot. Not only that, but it celebrates upon successfully locating such an\r\napp.\r\nStepping into the “verifyCapturePermissions” function, Jamf saw that this section of the script is checking for\r\ncapture permissions from the list of installed applications. This list is derived from an earlier check of the\r\nfollowing software appID’s, referred to by the malware as “donorApps”.\r\nAs expected, the list of application IDs that are targeted are all applications that users regularly grant the screen\r\nsharing permission to as part of its normal operation. The malware then uses the following mdfind command —\r\nthe command-line-based version of Spotlight — to check if the appID’s are installed on the victim’s device.\r\nIf any of the appID’s are found on the system, the command returns the path to the installed application. With this\r\ninformation, the malware crafts a custom AppleScript application and injects it into the installed, donor\r\napplication. It does so by performing a number of functions, the most notable being called createDonorApp().\r\nhttps://www.jamf.com/blog/zero-day-tcc-bypass-discovered-in-xcsset-malware/\r\nPage 3 of 6\n\nThe script executes the following actions in this sequence:\r\n1. The XCSSET AppleScript screenshot module is downloaded from the malware author’s command and\r\ncontrol (C2)server (to the ~/Library/Caches/GameKit folder).\r\nhttps://www.jamf.com/blog/zero-day-tcc-bypass-discovered-in-xcsset-malware/\r\nPage 4 of 6\n\n2. Using the osacompile command, the screenshot module is converted to an AppleScript-based application\r\ncalled avatarde.app. When any AppleScript is compiled in this manner, an executable called “applet” is\r\nplaced in the newly created application bundle’s /Contents/MacOS/ directory and the script that the applet\r\nwill execute can be located at /Contents/Resources/Scripts/main.scpt.\r\n3. The newly created Info.plist is then modified by the plutil binary, changing the preference setting\r\nLSUIElement to true. This allows the application to be run as a background process, concealing its\r\npresence from the user.\r\n4. A blank icon is then downloaded and applied to the application.\r\n5. Lastly, the newly created application is placed within the already existing donor application using the\r\nfollowing code:\r\nFor example, if the virtual meeting application zoom.us.app is found on the system, the malware will place itself\r\nlike so:\r\n/Applications/zoom.us.app/Contents/MacOS/avatarde.app\r\nIf the victim computer is running macOS 11 or greater, it will then sign the avatarde application with an ad-hoc\r\nsignature, or one that is signed by the computer itself.\r\nOnce all files are in place, the custom application will piggyback off of the parent application, which in the\r\nexample above is Zoom. This means that the malicious application can take screenshots or record the screen\r\nwithout needing explicit consent from the user. It inherits those TCC permissions outright from the Zoom parent\r\napp. This represents a considerable privacy concern for end-users.\r\nDuring Jamf’s testing, it was determined that this vulnerability is not limited to screen recording permissions\r\neither. Multiple different permissions that have already been provided to the donor application can be transferred\r\nto the maliciously created app.\r\nConclusion\r\nJamf Protect offers a holistic Mac endpoint security solution that provides analytics to detect and prevent anytime\r\nthis vulnerability is potentially being abused. It does this by checking if an application is bundled within another\r\napplication. If a match occurs, it goes on to verify the digital signatures between the two applications, effectively\r\ndetecting mismatches in the process of signing information. Jamf urges users to “patch fast and patch often,” as\r\nhttps://www.jamf.com/blog/zero-day-tcc-bypass-discovered-in-xcsset-malware/\r\nPage 5 of 6\n\nApple recently patched this issue to keep malware like XCSSET from abusing this vulnerability in the future, for\r\nMac computers running macOS 11.4 or later.\r\nIndicators of Compromise (IoC)\r\nDuring Jamf’s research, multiple hashes were found that were previously unidentified by VirusTotal. Some of the\r\nhashes Jamf discovered were already being detected by Apple’s built-in malware detection engine, XProtect.\r\nHowever, additional hashes Jamf’s team identified as being XCSSET malware found their way onto Github,\r\ncompromising the affected repositories. The impacted executables have been noted as having potentially one of\r\nfive possible filenames within the Xcode project.\r\nCommand and Control Domains:\r\ntrendmicronano[.]com\r\nfindmymacs[.]com\r\nadoberelations[.]com\r\nstatsmag[.]com\r\nstatsmag[.]xyz\r\nflixprice[.]com\r\nadobestats[.].com\r\ntitiez[.]com\r\nicloudserv[.]com\r\natecasec[.]com\r\nmonotel[.]xyz\r\nsidelink[.]xyz\r\nmantrucks[.]xyz\r\nlinebrand[.]xyz\r\nnodeline[.]xyz\r\nSubscribe to the Jamf Blog\r\nHave market trends, Apple updates and Jamf news delivered directly to your inbox.\r\nTo learn more about how we collect, use, disclose, transfer, and store your information, please visit our Privacy\r\nPolicy.\r\nSource: https://www.jamf.com/blog/zero-day-tcc-bypass-discovered-in-xcsset-malware/\r\nhttps://www.jamf.com/blog/zero-day-tcc-bypass-discovered-in-xcsset-malware/\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.jamf.com/blog/zero-day-tcc-bypass-discovered-in-xcsset-malware/"
	],
	"report_names": [
		"zero-day-tcc-bypass-discovered-in-xcsset-malware"
	],
	"threat_actors": [],
	"ts_created_at": 1775439103,
	"ts_updated_at": 1775791287,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c8cc519bf97b299b781b24dee4b808f9c6250c77.pdf",
		"text": "https://archive.orkl.eu/c8cc519bf97b299b781b24dee4b808f9c6250c77.txt",
		"img": "https://archive.orkl.eu/c8cc519bf97b299b781b24dee4b808f9c6250c77.jpg"
	}
}