{
	"id": "2c4572ca-2514-448d-8e2e-f320ff8171a3",
	"created_at": "2026-04-06T00:09:08.842888Z",
	"updated_at": "2026-04-10T03:24:18.0285Z",
	"deleted_at": null,
	"sha1_hash": "ea0df56e02ee19bcfa54de4de2c287d5d37fef7d",
	"title": "How Malware Persists on macOS",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 10626101,
	"plain_text": "How Malware Persists on macOS\r\nBy Phil Stokes\r\nPublished: 2019-06-17 · Archived: 2026-04-05 13:06:27 UTC\r\nWhether it’s a cryptominer looking for low-risk money-making opportunities, adware hijacking browser sessions\r\nto inject unwanted search results, or malware designed to spy on a user, steal data or traverse an enterprise\r\nnetwork, there’s one thing all threats have in common: the need for a persistent presence on the endpoint. On\r\nApple’s macOS platform, attackers have a number of different ways to persist from one login or reboot to\r\nanother. \r\nIn this post, we review macOS malware persistence techniques seen in the wild as well as highlighting other\r\npersistence mechanisms attackers could use if defenders leave the door open. Has your IT team and security\r\nsolution got them all covered? Let’s take a look.\r\nHow To Persist Using a LaunchAgent\r\nBy far the most common way malware persists on macOS is via a LaunchAgent. Each user on a Mac can have a\r\nLaunchAgents folder in their own Library folder to specify code that should be run every time that user logs in. In\r\naddition, a LaunchAgents folder exists at the computer level which can run code for all users that log in. There is\r\nalso a LaunchAgents folder reserved for the System’s own use. However, since this folder is now managed by\r\nmacOS itself (since 10.11), malware is locked out of this location by default so long as System Integrity\r\nProtection has not been disabled or bypassed. \r\nhttps://www.sentinelone.com/blog/how-malware-persists-on-macos/\r\nPage 1 of 11\n\nLaunchAgents take the form of property list files, which can either specify a file to execute or can contain their\r\nown commands to execute directly. \r\nSince user LaunchAgents require no privileges to install, these are by far the easiest and most common form of\r\npersistence seen in the wild. Unfortunately, Apple took the controversial step of hiding the parent Library folder\r\nfrom users by default all the way back in OSX 10.7 Lion, making it easier for threat actors to hide these agents\r\nfrom unsavvy users. \r\nUsers can unhide this library in a couple of different ways for manual checks, but enterprise security solutions\r\nshould monitor the contents of this folder and block or alert on malicious processes that write to this location, as\r\nshown here in this example from the SentinelOne console. The threat is autonomously blocked and the IT team is\r\nhttps://www.sentinelone.com/blog/how-malware-persists-on-macos/\r\nPage 2 of 11\n\nalerted to the IOCs, with reference to Mitre Att\u0026ck framework, and convenient links to RecordedFuture and\r\nVirusTotal detections.\r\nPersistence By LaunchDaemon\r\nLaunchDaemons only exist at the computer and system level, and technically are reserved for persistent code that\r\ndoes not interact with the user – perfect for malware. The bar is raised for attackers as writing a daemon to\r\n/Library/LaunchDaemons requires administrator level privileges. However, since most Mac users are also admin\r\nusers and habitually provide authorisation for software to install components whenever asked, the bar is not all\r\nthat high and is regularly cleared by infections we see in the wild. In this image, the computer has been infected\r\nby 3 separate, malicious LaunchDaemons.\r\nBecause LaunchDaemons run on startup and for every user even before a user logs in, it is essential that your\r\nsecurity software is aware of what daemons are running and when any new daemons are written. As with System\r\nLaunchAgents, the System LaunchDaemons are protected by SIP so the primary location to monitor is\r\n/Library/LaunchDaemons .\r\nDon’t just assume labels you recognize are benign either. Some legitimate LaunchDaemons point to unsigned\r\ncode that could itself be replaced by something malicious. For example, the popular networking program\r\nWireshark uses a LaunchDaemon,\r\nhttps://www.sentinelone.com/blog/how-malware-persists-on-macos/\r\nPage 3 of 11\n\n/Library/LaunchDaemons/org.wireshark.ChmodBPF.plist\r\nthat executes unsigned code at the path:\r\n/Library/Application Support/Wireshark/ChmodBPF/ChmodBPF\r\nEven Apple itself uses a LaunchDaemon that isn’t always cleaned up immediately such as\r\n/Library/LaunchDaemons/com.apple.installer.cleanupinstaller.plist\r\nThis points to an executable in the /macOS Install Data folder that could be replaced by malicious code.\r\nRemember that with privileges, an attacker can either modify the program arguments of these property plists or\r\nthe executables that they point to in order to achieve stealthy persistence. Since these programs will run with root\r\nprivileges, it’s important that you or your security solution isn’t just blanket whitelisting code because it looks like\r\nit comes from a legitimate vendor.\r\nPersistence with Profiles\r\nProfiles are intended for organizational use to allow IT admins to manage machines for their users, but their\r\npotential for misuse has already been spotted by malware authors. As profiles can be distributed via email or a\r\nwebsite, tricking users into inadvertently installing them is just another element of social engineering. \r\nhttps://www.sentinelone.com/blog/how-malware-persists-on-macos/\r\nPage 4 of 11\n\nConfiguration profiles can force a user to use certain browser settings, DNS proxy settings, or VPN settings. Many\r\nother payloads are possible which make them ripe for abuse. \r\nProfiles can be viewed by users in System Preferences Profiles pane and by administrators by enumerating the\r\n/Library/Managed Preferences folder. Be aware that neither the pane nor folder will be present on a system\r\nwhere profiles have never been installed.\r\nhttps://www.sentinelone.com/blog/how-malware-persists-on-macos/\r\nPage 5 of 11\n\nCron Still Persists on macOS\r\nThe venerable old cron job has not been overlooked by malware authors. Although Apple has announced that\r\nnew cron jobs will require user interaction to install in 10.15 Catalina, it’s unlikely that this will do much to\r\nhinder attackers using it as a persistence method. As we’ve noted before, user prompts are not an effective security\r\nmeasure when the user has already been tricked into installing the malicious software under the guise of\r\nsomething else. There’s overwhelming evidence to suggest that users escape ‘death by dialog’ by simply clicking\r\neverything without paying attention to what the dialog alert actually says.\r\nMalicious cron jobs are used by AdLoad and Mughthesec malware, among others, to achieve persistence.\r\nKexts for Persistence\r\nKernel extensions are widely used by legitimate software for persistent behavior, and we’ve seen them also used\r\nby so-called PUP software like MacKeeper. An open-source keylogger, logkext, has also been around for some\r\nyears, but in general kexts are not a favoured trick among malware authors as they are comparatively difficult to\r\ncreate, lack stealth, and can be easily removed.\r\nhttps://www.sentinelone.com/blog/how-malware-persists-on-macos/\r\nPage 6 of 11\n\nHow to Find Persistent Login Items\r\nChanges made by Apple to Login Items have, on the other hand, resulted in more attractive opportunities for\r\nmalware persistence. Once upon a time, Login Items were easily enumerated through the System Preferences\r\nutility, but a newer mechanism makes it possible for any installed application to launch itself at login time simply\r\nby including a Login Item in its own bundle. While the intention of this mechanism is for legitimate developers to\r\noffer control of the login item through the app’s user interface, unscrupulous developers of commodity adware and\r\nPUP software have been abusing this as a persistence trick as it’s very difficult for users to reliably enumerate\r\nwhich applications actually contain a bundled login item. \r\nWhile it’s not a simple matter for users to enumerate all the Login Items, admins can do so with a little extra work\r\nby parsing the following file, if it exists:\r\n~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm\r\nA method of doing so was first written up by security researcher Patrick Wardle, but that still requires some\r\nprogramming skill to implement. A more user-friendly AppleScript version that can be cut and pasted into the\r\nmacOS Script Editor utility and run more conveniently is available here.\r\nAppleScript \u0026 Friends\r\nWhile on the subject of AppleScript, Apple’s most useful “swiss army knife” tool somewhat unsurprisingly also\r\nhas some persistence mechanisms to offer. The first leverages Folder Actions and allows an attacker to execute\r\ncode that could even be read into memory remotely every time a particular folder is written to. This remarkably\r\nclever way of enabling a fileless malware attack by re-purposing an old macOS convenience-tool was first written\r\nup by Cody Thomas.\r\nhttps://www.sentinelone.com/blog/how-malware-persists-on-macos/\r\nPage 7 of 11\n\nAdmins with security solutions that do not have behavioral AI detection should monitor processes executing with\r\nosascript and ScriptMonitor in the command arguments to watch out for this kind of threat.\r\nAn even more wily trick leverages Mail rules, either local or iCloud-based, to achieve persistence by triggering\r\ncode after sending the victim an email with a specially-crafted subject line. This method is particularly stealthy\r\nand will evade many detection tools.\r\nDefenders can manually check for the presence of suspicious Mail rules by parsing the\r\nubiquitous_SyncedRules.plist file and the SyncedRules.plist file for iCloud and local Mail rules,\r\nrespectively. A quick bash script such as \r\ngrep -A1 \"AppleScript\"~/Library/Mail/V6/MailData/SyncedRules.plist\r\nwill enumerate any Mail rules that are calling AppleScripts. If any are found, those will then need to be examined\r\nclosely to ensure they are not malicious.\r\nAlso Ran: Forgotten Persistence Tricks\r\nFor those who remember them, rc.common and launchd.conf no longer work on macOS, and support for\r\nStartupItems also appears to have been removed after 10.9 Mavericks.\r\nEven so, other old “nix tricks” do still work, and while we’ve yet to see any of the following persistence\r\nmechanisms used in the wild, they are worth keeping an eye on. These tricks include using periodics ,\r\nloginhooks , at jobs, and the emond service. \r\nhttps://www.sentinelone.com/blog/how-malware-persists-on-macos/\r\nPage 8 of 11\n\nPeriodics As a Means of Persistence\r\nPeriodics are system scripts that are generally used for maintenance and run on a daily, weekly and monthly\r\nschedule. Periodics live in similarly titled subfolders within etc/periodic folder.\r\nListing the contents of each of the subfolders should reveal the standard set of periodics, unless your admins are\r\nusing their own custom periodic scripts. If not, anything additional found in there should be treated as suspicious\r\nand inspected. Notice the unusual “uptime” script here, which will run on a daily basis without user interaction or\r\nnotification.\r\nAlso, be sure to check both /etc/defaults/periodic.conf and /etc/periodic.conf for system and local\r\noverrides to the default periodic configuration.\r\nLoginHooks and LogoutHooks\r\nLoginHooks and LogoutHooks have been around for years and are rarely used these days, but are still a perfectly\r\nviable way of running a persistence script on macOS Mojave. As the names suggest, these mechanisms run code\r\nhttps://www.sentinelone.com/blog/how-malware-persists-on-macos/\r\nPage 9 of 11\n\nwhen the user either logs in or logs out.\r\nIt’s a simple matter to write these hooks, but fortunately it’s also quite easy to check for their existence. The\r\nfollowing command should return a result that doesn’t have either LoginHook or LogoutHook values:\r\nsudo defaults read com.apple.loginwindow\r\nIf, on the other hand, it reveals a command or path to a script, then consider those worthy of investigation.\r\nAt Jobs: Run Once, Persist Forever\r\nA much less well-known mechanism is at jobs. While these only run once and are not enabled by default, they\r\nare a sneaky way to run some code on restart. The single-use isn’t really a problem, since the at job can simply\r\nbe re-written each time the persistence mechanism fires, and these jobs are very unlikely to be noticed by most\r\nusers or indeed many less-experienced admins. \r\nYou can check whether any at jobs are scheduled by enumerating the /var/at/jobs directory. Jobs are\r\nprefixed with the letter a and have a hex-style name.\r\nEmond – The Forgotten Event Monitor\r\nSometime around OSX 10.5 Leopard, Apple introduced a logging mechanism called emond . It appears emond\r\nwas never fully developed and development may have been abandoned by Apple for other mechanisms, but it\r\nremains available even on macOS 10.14 Mojave. \r\nIn 2016, James Reynolds provided the most comprehensive analysis to-date of emond and its capabilities.\r\nReynolds was not interested in emond from a security angle, but rather was documenting a little-known daemon\r\nhttps://www.sentinelone.com/blog/how-malware-persists-on-macos/\r\nPage 10 of 11\n\nfrom the angle of an admin wanting to implement their own log scanner. Reynolds concludes his analysis with an\r\ninteresting comment, though:\r\nConsidering how easy it is to log, run a command, or send an email in a perl script, I can’t see why I’d\r\nwant to use emond instead of a script.\r\nThis little-known service may not be much use to a Mac admin, but to a threat actor one very good reason would\r\nbe to use it as a persistence mechanism that most macOS admins probably wouldn’t know to look for. \r\nDetecting malicious use of emond shouldn’t be difficult, as the System LaunchDaemon for the service looks for\r\nscripts to run in only one place:\r\n/private/var/db/emondClients\r\nAdmins can easily check to see if a threat actor has placed anything in that location. \r\nAs emond is almost certainly not used in your environment for any legitimate reason, anything found in the\r\nemondClient directory should be treated as suspicious.\r\nConclusion\r\nAs the above mechanisms show, there are plenty of ways for attackers to persist on macOS. While some of the\r\nolder ways are now defunct, the onus is still very much on defenders to keep an eye on the many possible avenues\r\nthat code execution can survive a reboot. To lessen that burden, it’s recommended that you move to a next-gen\r\nbehavioral solution that can autonomously detect and block malware from achieving persistence. If you are not\r\nalready protected by SentinelOne’s activeEDR solution, contact us for a free demo and see how it can work for\r\nyou in practice.\r\nSource: https://www.sentinelone.com/blog/how-malware-persists-on-macos/\r\nhttps://www.sentinelone.com/blog/how-malware-persists-on-macos/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.sentinelone.com/blog/how-malware-persists-on-macos/"
	],
	"report_names": [
		"how-malware-persists-on-macos"
	],
	"threat_actors": [
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434148,
	"ts_updated_at": 1775791458,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ea0df56e02ee19bcfa54de4de2c287d5d37fef7d.pdf",
		"text": "https://archive.orkl.eu/ea0df56e02ee19bcfa54de4de2c287d5d37fef7d.txt",
		"img": "https://archive.orkl.eu/ea0df56e02ee19bcfa54de4de2c287d5d37fef7d.jpg"
	}
}