{
	"id": "2b323f9a-0185-493f-8fbf-9147e5168237",
	"created_at": "2026-04-06T00:22:23.055397Z",
	"updated_at": "2026-04-10T03:21:07.633114Z",
	"deleted_at": null,
	"sha1_hash": "5c0e2e9b3761fe79e9ef1a8d5b5413a7ff972453",
	"title": "How AppleScript Is Used For Attacking macOS",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 7530594,
	"plain_text": "How AppleScript Is Used For Attacking macOS\r\nBy Phil Stokes\r\nPublished: 2020-03-16 · Archived: 2026-04-05 22:27:17 UTC\r\nWhen we think about security on macOS and the tools used by offensive actors, whether those are real in the wild\r\nattacks or red team exercises, we tend to think of things like python scripts, shell scripts, malicious documents,\r\nshady extensions and of course, the fake, doctored or trojan application bundle. There is much less attention in the\r\nsecurity field on AppleScript – a built-in macOS technology – despite the fact it’s been around for as long as\r\nPython and predates macOS 10 itself by 8 or 9 years.\r\nAs I’ll show in this post, AppleScript is widely used by offensive actors. This includes its use in adware, its use for\r\ntasks such as persistence, anti-analysis, browser hijacking, spoofing and more. Worryingly, given the lack of\r\nattention paid to AppleScript in the research community, that is all without even leveraging some of AppleScript’s\r\nmost powerful or unique features, some of which we’ll cover below (others I’ve written about before here).\r\nWhy Have the Good Guys Ignored AppleScript?\r\nUnlike Bash and other shell languages, and unlike Python, a cross-platform, beginner-friendly scripting language\r\nthat has achieved widespread adoption and praise, AppleScript is a language peculiar to macOS; not only can you\r\nNOT use it on other Desktop operating systems like Windows and Linux, you can’t even use it on Apple’s other\r\noperating systems like iOS and iPadOS.\r\nAs a language, AppleScript has a reputation for being quirky, slow and difficult to develop even simple scripts\r\nwith. It’s quirky because it attempts to use “natural language” but in a grammar that is entirely artificial, often\r\nhttps://www.sentinelone.com/blog/how-offensive-actors-use-applescript-for-attacking-macos/\r\nPage 1 of 12\n\ninconsistent and frustratingly unintuitive. It’s also incredibly verbose. Compare the code for the simple task of\r\ncounting the number of items in /usr/bin directory. As ever, a shell script will always be the most concise:\r\nls -l /usr/bin | wc -l\r\nPython is a little more verbose, but still fairly clean and familiar:\r\nimport os\r\npath, dirs, files = next(os.walk(\"/usr/bin\"))\r\nprint len(files)\r\nThe AppleScript version, however, is something of an entirely different nature.\r\ntell application \"System Events\"\r\nset theFiles to name of every file of folder \"bin\" of folder \"usr\" of startup disk\r\ncount of theFiles\r\nend tell\r\nAppleScript is also slow in execution because, among other things, the underlying technology involves\r\nconstructing and sending Apple Events through an archaic interface called the Apple Event Manager that was\r\nwritten for Apple’s System 7 operating system (released in 1991) and not optimized for performance even back\r\nthen.\r\nSource: AppleScript Overview,  © 2002, 2007 Apple Inc.\r\nAnd it’s historically been difficult to develop scripts with AppleScript because most people who come to it will\r\nattempt to use the free, built-in but notoriously spartan (Apple)Script Editor.app, which lacks almost every and\r\nany feature developers normally expect and need. There’s no debugger, there’s no variable introspection, there’s\r\nno code snippets or effective code completion, to name just a few missing features.\r\nhttps://www.sentinelone.com/blog/how-offensive-actors-use-applescript-for-attacking-macos/\r\nPage 2 of 12\n\nUntil recently, the only 3rd party alternative to Script Editor was priced at $200 and had a time-limited, 20-day\r\ndemo period.\r\nIn short, the investment in time, effort and money required to produce something that still, after all that, can only\r\nbe used on the macOS Desktop, effectively puts AppleScript at the bottom of the list for most people when it\r\ncomes to choosing a useful or productive programming language. As a result, despite being with us for nearly 30\r\nyears, AppleScript is barely used by the majority of Mac admins, Mac developers or Mac end users. Indeed,\r\nAppleScript may have a good claim to being the Most Unloved and Unlovable Programming Language Ever.\r\nSo Why Do the Bad Guys Love Using AppleScript?\r\nAppleScript was designed for automation and interapplication communication: the goal being to allow ordinary\r\nusers to chain together repetitive tasks and execute them without further user interaction. For example, you can\r\nhave Mail.app automatically trigger a script when it receives an email from a certain sender, or with a particular\r\nkeyword in the subject line or content, extract whatever details you want from the email, and then populate a\r\ndatabase in Excel or Numbers with the desired information, formatted and sorted on-the-fly as the data comes in.\r\nThere’s no need for the user to be involved in any of this once the script is set up.\r\nAnd as it turns out, automating interapplication communication and sidestepping user interaction is a godsend for\r\nmalware authors. What could be more useful than bending popular applications like email clients, web browsers\r\nand the Microsoft Office suite to your will without needing to involve the user (aka in this scenario, the victim)?\r\nAnd so, despite its general lack of appeal in almost all possible audiences for a scripting or programming\r\nlanguage, there is one audience that does use AppleScript widely, if not particularly artfully or cleverly, and that is\r\nhttps://www.sentinelone.com/blog/how-offensive-actors-use-applescript-for-attacking-macos/\r\nPage 3 of 12\n\nthreat actors. Let’s look at some examples.\r\nRecent Examples of AppleScript in macOS malware\r\nA recent browser hijacker targeting Safari installs a hidden LaunchAgent that, via a shell script, loads, compiles\r\nand executes AppleScript.\r\nIt starts with a shell installer script packaged inside a DMG that’s supposed to contain an application called\r\n‘PDFConverter4u’. But in a hidden .assets folder on the disk image is a first stage shell script:\r\n5f198e82c0cf9a9f7d7a8d01273a6ad75a17a95960d8996dcdd028922b3d97bc\r\nThis unpacks and executes a second stage shell script:\r\n55529224e9f70f5cab007e2ca98f6aec5cf31eb923fdfc09f60c01cc45c80666\r\nWhich eventually produces the hidden launch agent that executes another shell script containing the following\r\nAppleScript code, launched via osascript .\r\ncdaa2121d79031cf39159198dfe64d3695a9c99ff7c3478a0b8953ade9052ecc\r\nhttps://www.sentinelone.com/blog/how-offensive-actors-use-applescript-for-attacking-macos/\r\nPage 4 of 12\n\nThe purpose of the AppleScript is to replace the user’s search query on popular search engines google, bing and\r\nyahoo, with one provided by the attacker’s shell script. It’s a quick and easy way for bad actors to make money\r\nout of clicks which negatively impacts the victim’s productivity.\r\nWhile this particular sample comes packed in a separate file, many others write their AppleScript directly into a\r\nMachO binary, either in plain text strings or in obfuscated base64 or similar encoding.\r\nThe following strings extracted from a Bundlore installer show that the code tries to force enable JavaScript\r\nexecution in Google Chrome, then uses AppleScript to execute it in the active tab of the browser’s front window.\r\nStrings from 41e0d31d52cb93f6a5020a278e8f360a6e134e6cc7092b4a5e575ac8b96a8d74\r\nThe next sample is a variant of a Pirrit malware.\r\n21331ccee215801ca682f1764f3e37ff806e7510ded5576c0fb4d514b4cf2b7c\r\nhttps://www.sentinelone.com/blog/how-offensive-actors-use-applescript-for-attacking-macos/\r\nPage 5 of 12\n\nThe authors use both plain text AppleScript and base64 encoded AppleScript, targeting Safari, Chrome and\r\nFirefox browsers.\r\nHere’s some of the decoded base64 targeting Firefox and attempting to perform automated keystrokes to copy the\r\ncurrent URL to the user’s clipboard before replacing the URL to that of the attacker’s choice:\r\nhttps://www.sentinelone.com/blog/how-offensive-actors-use-applescript-for-attacking-macos/\r\nPage 6 of 12\n\nUsing AppleScript Without Apple Events\r\nSpeaking of base64, the next example illustrates something that many ordinary users and developers have\r\noverlooked about AppleScript, but which offensive actors have not: you can use AppleScript to execute any other\r\nkind of script, including python scripts like this one which drops the Empire exploit kit.\r\nAnd what’s true of AppleScript and Python, is true of AppleScript and Perl, AppleScript and Bash and indeed\r\nAppleScript and absolutely any command line tool at all: you can call them all and bring their functionality into\r\nyour AppleScript and combine that with other utilities.\r\nhttps://www.sentinelone.com/blog/how-offensive-actors-use-applescript-for-attacking-macos/\r\nPage 7 of 12\n\nThe examples above all use what we might call ‘vanilla AppleScript’. That is, the native AppleScript language\r\nthat’s been around since the early days of the platform. But starting in Yosemite, 10.10 and continuing up to and\r\nincluding the most recent version of macOS, AppleScript has been given increasing power through access to\r\nCocoa frameworks, and this opens up the possibility of creating full-blown, powerful programs and applications\r\nwith nothing other than AppleScript itself. Objective C executed through AppleScript is, speed-wise, more or less\r\non a par with Objective C executed in a MachO binary.\r\nAnd interestingly, although we haven’t seen threat actors making use of these powerful capabilities so far, there’s\r\nat least two reasons why we may well do so in the future: first to avoid detection, and second, because of the easy\r\navailability of a good development environment.\r\nUsing AppleScript to Avoid Detection\r\nAvoiding detection on execution is a primary objective for all malware (even ransomware, which doesn’t want to\r\nget noticed until after execution). AppleScript offers offensive actors a plethora of ways to execute. In addition to\r\nsimply executing a .scrpt file, you can run AppleScripts from Mail rules, from a shell script, in memory, from\r\nthe command line, from within a MachO, in a plain text, uncompiled file, from an Automator workflow, from a\r\nFolder Action, a Finder Service or from a Calendar event.\r\nhttps://www.sentinelone.com/blog/how-offensive-actors-use-applescript-for-attacking-macos/\r\nPage 8 of 12\n\nBecause of AppleScript’s ability to execute Objective C code without needing a compiled binary, this opens up a\r\nnumber of interesting attack possibilities. It also potentially opens up the ability to bypass detection tools based on\r\nApple’s new kextless security framework introduced in macOS Catalina 10.15.\r\nIn an excellent post by Cedric Owens called Taking the macOS Endpoint Security Framework For A Quick Spin,\r\nOwens sets out to test what can and cannot be detected using three recently developed 3rd-party security tools that\r\nleverage the new Apple Endpoint Security framework.\r\nOne of the interesting things that Owens found was that if you tried capturing the user’s clipboard via osascript\r\nand vanilla AppleScript, this activity would be easily picked up by all the tools he was testing.\r\nosascript -e 'the clipboard'\r\nHowever, when using the native Cocoa API, NSPasteboard, none of the Endpoint Security framework-powered\r\ntools Owens tested appeared to capture that activity. But now, of course, we can execute NSPasteboard natively\r\nfrom AppleScript, too!\r\nhttps://www.sentinelone.com/blog/how-offensive-actors-use-applescript-for-attacking-macos/\r\nPage 9 of 12\n\nNotice that our one line, simple but also detectable osascript has turned into about 14 lines of complex-looking\r\nAppleScript-ObjC. Few people, certainly not I, would want to try and construct that kind of code in Script Editor.\r\nHowever, the problem of developing complex AppleScripts is now more or less a thing of the past. The 3rd party\r\nalternative mentioned earlier in this post now has an unlimited free trial version and retails at half of its old price;\r\nmore importantly, it also allows you to drag and drop a great deal of boilerplate code like that used in the script\r\nabove straight into your scripts. And it provides developer-friendly functionality like code completion and API\r\nlookups that really take the pain out of developing AppleScript code.\r\nLet’s look at another example. A lot of offensive operations want to avoid targets that are running particular\r\nsoftware. Little Snitch is a prime example, various VM software is another. We can easily get a list of running\r\napps by name and test for those, again directly by calling into Cocoa APIs, this time via NSWorkspace.\r\nhttps://www.sentinelone.com/blog/how-offensive-actors-use-applescript-for-attacking-macos/\r\nPage 10 of 12\n\nIf we just want a true/false test for the existence of specific apps, we can just put the app names in a list and return\r\ntrue on the first hit.\r\nhttps://www.sentinelone.com/blog/how-offensive-actors-use-applescript-for-attacking-macos/\r\nPage 11 of 12\n\nIn other words, by leveraging AppleScript’s hook into Cocoa frameworks, we can execute native code without the\r\noverhead of building MachO binaries or MachO apps (although you can do both of those with AppleScript, too!).\r\nWe can do this filelessly so that we don’t get caught by new ‘kextless’ tools such as those tested by Owens, and\r\nwe can execute this code in far more ways than any other kind of code available on macOS, whether that’s shell\r\nscripts, Python scripts or native macOS bundles.\r\nConclusion\r\nThe upshot here is that the main reasons why the good guys have typically eschewed AppleScript are in fact no\r\nlonger relevant or true. Since we’ve already seen threat actors taking advantage of AppleScript despite those\r\nobstacles in the past, it’s only reasonable to assume that they may delve deeper into what this unique language has\r\nto offer in the future. Thanks to the native hook into Objective C and the powerful Cocoa frameworks, the variety\r\nof execution methods and now the availability of an excellent, free-to-use IDE, AppleScript has become a tool that\r\nis powerful, versatile and easy-to-develop with.\r\nAttackers will always look to exploit the things defenders ignore, and to say that AppleScript has been ignored by\r\nthe security community thus far is an understatement. I have elsewhere described AppleScript as “the PowerShell\r\nof macOS”. Certainly, it’s time we stopped thinking of AppleScript as the Most Unlovable Programming\r\nLanguage Ever and recognize that it may actually be the One macOS Programming Language to Rule Them All.\r\nSource: https://www.sentinelone.com/blog/how-offensive-actors-use-applescript-for-attacking-macos/\r\nhttps://www.sentinelone.com/blog/how-offensive-actors-use-applescript-for-attacking-macos/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.sentinelone.com/blog/how-offensive-actors-use-applescript-for-attacking-macos/"
	],
	"report_names": [
		"how-offensive-actors-use-applescript-for-attacking-macos"
	],
	"threat_actors": [],
	"ts_created_at": 1775434943,
	"ts_updated_at": 1775791267,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/5c0e2e9b3761fe79e9ef1a8d5b5413a7ff972453.pdf",
		"text": "https://archive.orkl.eu/5c0e2e9b3761fe79e9ef1a8d5b5413a7ff972453.txt",
		"img": "https://archive.orkl.eu/5c0e2e9b3761fe79e9ef1a8d5b5413a7ff972453.jpg"
	}
}