macOS Malware Persistence: How Attackers Maintain Hidden Access

What if your Mac keeps a hidden door even after you reboot?
Attackers use macOS malware persistence tricks—like LaunchAgents, LaunchDaemons, hidden login items, and shell config hijacks—to stay active without you noticing.
These methods run at login or boot, blend in with legit system files, and often survive simple removal attempts.
This post explains the main persistence techniques, who they affect, and clear signs to watch for so you can spot and remove stealthy implants before they cause bigger problems.

Core macOS Persistence Methods Used by Malware

Malware on macOS relies heavily on LaunchAgents and LaunchDaemons to keep access alive across reboots. LaunchAgents fire up automatically when someone logs in, running with that user’s permissions. They live in three spots: ~/Library/LaunchAgents (just you), /Library/LaunchAgents (everyone on the machine), and /System/Library/LaunchAgents (locked down by Apple since macOS 10.11). These property list files (.plist) tell the system which programs to run or what commands to execute right there in the file. Attackers love them because they don’t need special permissions to drop one in the user directory. And since OSX 10.7 Lion, the user Library folder’s been hidden by default, so casual users browsing around won’t stumble across anything suspicious.

LaunchDaemons work at a deeper level. They kick in before anyone logs in and run with root permissions. The main spot is /Library/LaunchDaemons, which needs admin rights to touch, but here’s the thing: most macOS users are administrators by default. That makes it easier for attackers who trick someone into typing their password. Real examples include the Wireshark ChmodBPF daemon sitting at /Library/LaunchDaemons/org.wireshark.ChmodBPF.plist, pointing to /Library/Application Support/Wireshark/ChmodBPF/ChmodBPF. Apple’s installer cleanup daemon sits there too. Malware like AdLoad and Mughthesec have been caught messing with daemon ProgramArguments or swapping out the target programs completely, scoring root access every time the machine boots.

These methods dominate because they survive restarts, execute without asking the user, and blend right in with legitimate system automation. Attackers typically inject their code by creating a fresh plist or hijacking one that already exists, then replacing or rewriting the binary path or shell command inside. Defenders need to watch writes to these directories and check what each plist is actually launching, since System Integrity Protection (SIP) only guards Apple’s /System/Library paths.

Five signs a LaunchAgent or LaunchDaemon is malicious:

• New or recently touched .plist files in user-writable LaunchAgents directories with no matching app install.
• ProgramArguments pointing to binaries in shared spots like /Users/Shared/ or hidden temp folders.
• Shell commands right in the plist that download or run scripts from external URLs.
• Unsigned or ad-hoc signed binaries called by LaunchAgent/LaunchDaemon plists.
• Vendor labels in plist names that look like Apple or popular software but have typos or weird naming.

LaunchAgent-Based Persistence Across macOS Versions

LaunchAgents are the easiest way in for user-level malware because you don’t need elevated permissions to drop one in ~/Library/LaunchAgents. Attackers who get admin access also hit /Library/LaunchAgents, which affects everyone on the system. Apple’s protected /System/Library/LaunchAgents path stays locked down thanks to SIP, introduced in OS X 10.11 El Capitan. The User Library folder being hidden since OSX 10.7 Lion gives malware natural cover from users relying on Finder to poke around their systems. Manual discovery won’t happen unless someone turns on hidden file viewing.

Malware authors tweak LaunchAgent plists by changing the ProgramArguments array to point at their payload or embedding commands that fetch and run remote scripts. Some campaigns obfuscate entries with base64-encoded arguments or nested shell tricks to dodge simple detection rules. Because launchd automatically loads and runs any valid plist dropped in these directories, attackers get immediate and persistent execution with almost no effort.

Detection means continuously watching file creation and modification in all three LaunchAgent directories, plus checking the binaries or scripts each plist references. Security teams should baseline legitimate LaunchAgent plists on clean systems, then alert on any new entries or changes. Validating code signatures and checking executable paths against known safe locations helps separate good software from malicious implants. Parsing each plist’s ProgramArguments and RunAtLoad keys shows whether the agent runs at login and what command it fires, giving you the context to triage alerts fast.

System-Level Persistence Using LaunchDaemons

LaunchDaemons run before anyone logs in, handing malware root access and the ability to affect every account on the system. The main path, /Library/LaunchDaemons, sits outside SIP protection, so attackers who grab admin credentials can write new daemon plists or modify existing ones. Since most macOS users operate with administrator privileges by default, social engineering that asks for a password often works, elevating malware to daemon-level persistence. Once installed, daemons execute without interaction at boot, running as root unless the plist explicitly says otherwise.

Attackers exploit daemons by replacing the binary in the ProgramArguments key or hijacking legitimate daemons whose executables have loose permissions. The Wireshark ChmodBPF example at /Library/LaunchDaemons/org.wireshark.ChmodBPF.plist shows how unsigned helper tools can get abused if an attacker swaps the real binary with a malicious one. Apple’s installer cleanup daemon proves that even system-level plists can be modified when SIP doesn’t protect the target directory. Malware families create entirely new daemon plists with generic Apple-style names to blend in with system services.

Detection requires watching all writes and changes to /Library/LaunchDaemons and treating unexpected activity as high-priority. Whitelisting based on vendor labels or file names doesn’t work because attackers mimic legitimate patterns and reuse trusted-looking identifiers. Effective defense combines file system monitoring with signature checks of the executables referenced by each daemon, plus runtime analysis of processes spawned by launchd to catch malicious behavior after execution. Security teams should inventory all daemons on clean baselines and investigate deviations, especially those pointing to binaries outside standard app directories.

Login Item Abuse for User-Level macOS Persistence

Modern macOS lets applications register bundled login items inside their app bundles, making them hard to find for users who only check System Preferences. Attackers use this by embedding malicious login items in trojanized apps or directly messing with the user’s login item database. The system stores login item metadata in ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm, a binary plist that needs parsing tools or scripts to read. This hidden persistence layer works independently of LaunchAgents, giving malware another auto-start method that survives reboots and logouts.

Users trying to remove suspicious login items through System Preferences might miss bundled items entirely because the interface doesn’t always show all registered startup tasks. Attackers exploit this gap by packaging their payloads as legit-looking app bundles with embedded LoginItems directories, which macOS launches automatically at user login. The lack of transparency in the backgrounditems.btm file format makes detection harder, requiring defenders to parse the file programmatically or use specialized tools to extract registered items and their launch paths.

Four detection checks for hidden login items:

• Parse ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm with a plist editor or custom script to list all registered login items.
• Inspect app bundles in /Applications and ~/Applications for Contents/Library/LoginItems directories containing unexpected binaries.
• Cross-reference auto-starting applications with known good software and investigate any unsigned or ad-hoc signed binaries.
• Monitor process creation at user login time to spot executables launched from outside standard app paths or temp directories.

Shell Configuration Hijacking for Stealthy Persistence

Shell config files offer stealthy persistence that dodges macOS’s “Background Items Added” notification, which shows up when LaunchAgents get installed. Since macOS Catalina, zsh is the default shell, making ~/.zshrc and ~/.zshenv prime targets. The .zshrc file runs for interactive terminal sessions each time you open a new terminal window, while .zshenv runs for every zsh instance, including non-interactive scripts and background processes. Attackers append malicious commands to the end of these files, ensuring their payloads execute whenever someone uses the terminal or when system processes spawn shell instances.

Threat actors like OceanLotus and the Lazarus Group have used this as a backup persistence layer alongside LaunchAgents. In the 2023 KandyKorn campaign, Lazarus deployed shell config hijacking as a failsafe that would reinfect the system if defenders removed the primary LaunchAgent. A typical setup involves a small C tool (like pers.c) that checks whether the target config file has been modified already, then appends a command to download or run a loader binary. In observed attacks, binaries get dropped in shared locations like /Users/Shared/hack, then a single line gets added to ~/.zshenv that executes the payload. After the user restarts their terminal, the malicious command runs silently, writing system info to disk and proving persistence survived the restart.

Detection means checking shell config files for unexpected appended lines, especially those calling executables from weird paths or containing network activity. File timestamp analysis shows when config files were last touched, helping correlate changes with known compromise windows. Defenders should also watch for suspicious binaries in shared directories and track processes spawned right after terminal launches. Removal involves manually editing the config files to delete malicious entries and removing associated binaries from disk, though attackers might deploy multiple shell config modifications across .zshrc, .zshenv, and .bash_profile to boost persistence resilience.

Scheduled Task Abuse: Cron, At Jobs, and Periodics

macOS still supports Unix-style scheduled tasks that malware exploits for timed execution and reinfection. Cron jobs remain viable, with malware families like AdLoad and Mughthesec actively using them to re-download payloads or trigger secondary stages. Starting with macOS 10.15 Catalina, the system prompts users for approval when creating new cron jobs, but social engineering campaigns often convince people to grant permission by pretending to be legitimate software updates or system maintenance. Once a cron entry’s installed, it runs commands at defined intervals without further user interaction, surviving reboots and relaunching malware even after manual process kills.

At jobs provide single-run scheduled execution, storing tasks in /private/var/at/jobs/ with filenames prefixed by “a” followed by hex identifiers. Attackers use at jobs for delayed execution or to trigger payloads during off-hours when detection is less likely. Although designed for one-time use, malware can rewrite new at jobs as part of each execution, effectively turning them into recurring persistence. Periodic scripts, stored in /etc/periodic/daily, /etc/periodic/weekly, and /etc/periodic/monthly, execute maintenance tasks at regular intervals. Unexpected scripts in these directories, like suspicious files named “uptime” or similar system-sounding names, are strong indicators something’s wrong.

Detection of scheduled task abuse requires continuous auditing of cron tables, at job queues, and periodic script directories. Defenders should inspect /etc/crontab and user-specific cron entries for commands pointing to unusual executables or network activity. The /etc/periodic/ subdirectories should only contain legitimate system maintenance scripts, and any additions or modifications need immediate investigation. Config files /etc/defaults/periodic.conf and /etc/periodic.conf may contain overrides that enable or disable specific periodic tasks, and attackers sometimes modify these to hide their scheduled scripts from standard execution reports.

Detection steps for scheduled task persistence:

1. List all cron jobs with crontab -l for the current user and sudo crontab -l for root and other users.
2. Enumerate at jobs by listing /private/var/at/jobs/ and inspecting files with recent creation timestamps.
3. Audit periodic scripts in /etc/periodic/daily, /etc/periodic/weekly, and /etc/periodic/monthly for unexpected or recently modified files.
4. Review /etc/defaults/periodic.conf and /etc/periodic.conf for overrides that suppress or alter standard periodic task execution.
5. Check file permissions on scheduled task directories to ensure attackers haven’t modified access controls to hide persistence mechanisms.
6. Correlate scheduled task creation times with known compromise events or suspicious user activity to identify attacker-installed entries.

Dynamic Library Injection and DYLD-Based Persistence Vectors

DYLD environment variables let attackers force applications to load malicious dynamic libraries at startup, creating persistent code execution inside legitimate processes. The DYLD_INSERT_LIBRARIES variable tells the dynamic linker to preload specified libraries before the application’s own dependencies, letting attackers inject malicious code into every execution of targeted binaries. This can be configured in LaunchAgent or LaunchDaemon plist files by adding environment variable keys, or by modifying shell config files to set DYLD variables affecting all subsequently launched applications. Because injected libraries run in the host process’s context, they inherit its permissions and can intercept function calls, steal data, or modify app behavior.

Dylib hijacking exploits weaknesses in app library search paths by placing malicious libraries with names matching legitimate dependencies in directories the system searches before the real library location. When an app launches, it loads the attacker’s version first, either executing malicious code directly or proxying calls to the legitimate library after performing malicious operations. Dylib proxying takes this further by creating an identically named malicious library that forwards most function calls to the original while intercepting specific functions to inject malicious logic. This lets attackers maintain app functionality while executing their payload in the background, reducing the chance users will notice broken behavior.

Five common DYLD abuse patterns:

• Setting DYLD_INSERT_LIBRARIES in LaunchAgent plists to inject malware into frequently launched apps like browsers or productivity software.
• Placing malicious dylibs in /usr/local/lib or other writable library paths searched before system directories to hijack app loads.
• Creating proxy dylibs matching legitimate library names but adding malicious functionality before forwarding calls to the real library.
• Modifying shell config files to set DYLD variables globally, affecting all apps launched from the terminal or child processes.
• Exploiting app bundles with weak library search paths by placing malicious dylibs inside the app’s Contents/Frameworks or Contents/MacOS directories.

Kernel Extensions and System Extensions as Persistence Anchors

Kernel extensions (kexts) provide kernel-level code execution that persists across reboots and operates with complete system privileges. Legitimate software like network monitoring tools and security products use kexts to interface directly with the macOS kernel, but attackers have also deployed malicious kexts for rootkit functionality and persistent access. The open-source keylogger logkext demonstrates how kexts can capture keystrokes at the kernel level, bypassing user-space detection. PUPs like MacKeeper have historically included kexts to deepen system integration, though these are harder to create and carry significant risk of system crashes if poorly coded.

Apple has deprecated kernel extensions in favor of System Extensions and DriverKit frameworks, which operate in user space with restricted privileges, reducing the attack surface and system stability risks. Despite this shift, existing kexts remain functional on current macOS versions for compatibility with legacy software. Detection involves listing loaded kernel extensions with the kextstat command and validating signatures to ensure all loaded kexts come from trusted developers. Unsigned or ad-hoc signed kexts are immediate red flags, as legitimate kernel extensions must be signed with an Apple-issued Developer ID and notarized. Removing malicious kexts requires unloading them with kextunload and deleting the kext bundle from /Library/Extensions or /System/Library/Extensions, then rebooting to prevent automatic reload.

AppleScript, Folder Actions, and Mail Rule Persistence Techniques

Folder Actions enable automatic execution of AppleScript code when files are added, removed, or modified within monitored folders, creating a fileless persistence mechanism that triggers on user activity. Attackers configure Folder Actions to execute malicious scripts stored locally or fetched remotely whenever someone interacts with common directories like Downloads or Documents. Because Folder Actions rely on legitimate macOS automation features, they generate minimal forensic artifacts and can stay hidden from users who don’t know the feature exists. Monitoring processes that execute osascript with ScriptMonitor in their arguments reveals active Folder Action execution, providing a detection signal.

Mail rules stored in ~/Library/Mail/V6/MailData/SyncedRules.plist (and the underscore-prefixed variant _SyncedRules.plist) let attackers automatically execute AppleScript when specially crafted emails arrive. This technique enables remote-triggered persistence, as the attacker can send an email matching the malicious rule’s conditions, causing the victim’s Mail app to execute the embedded script. The attack can sit dormant until the trigger email arrives, making it difficult to detect during routine system scans. Detection requires parsing the SyncedRules plist files and identifying any rules that invoke AppleScript or execute shell commands.

The command grep -A1 "AppleScript" ~/Library/Mail/V6/MailData/SyncedRules.plist searches for Mail rules containing AppleScript references, displaying the matching rule and the following line to reveal the script’s action. Defenders should inspect both SyncedRules files and correlate their contents with recent email activity to identify potential remote-trigger attacks. Monitoring osascript execution with command-line arguments containing suspicious keywords like “curl,” “download,” or remote URLs helps detect fileless attacks that fetch and execute payloads from external sources.

Four suspicious indicators in AppleScript-based persistence:

• Folder Actions configured on high-traffic directories like Downloads or Desktop that execute scripts from temporary or hidden locations.
• Mail rules in SyncedRules.plist that trigger AppleScript execution on emails from specific senders or with specific subject lines.
• Frequent osascript process creation with command-line arguments pointing to remote URLs or obfuscated scripts.
• AppleScript files stored in unusual locations like /tmp, /var/folders, or hidden subdirectories within the user Library folder.

Legacy and Rare macOS Persistence Techniques Still Seen in the Wild

Several deprecated persistence mechanisms remain functional on older macOS versions and occasionally reappear in targeted attacks. Apple removed rc.common, launchd.conf, and StartupItems after OS X 10.9 Mavericks, but systems running earlier versions or organizations that delay updates remain vulnerable. LoginHooks and LogoutHooks, which execute scripts at user login and logout events, still function on macOS 10.14 Mojave and can be checked with sudo defaults read com.apple.loginwindow. If the output includes LoginHook or LogoutHook keys with script paths, those scripts need inspection for malicious content. Emond (Event Monitor Daemon), introduced around OS X 10.5 Leopard and still present through at least macOS 10.14 Mojave, monitors system events and executes actions defined in its config files.

Emond receives minimal legitimate use, making any configuration in its directories inherently suspicious. The system LaunchDaemon for emond looks for scripts and rules in the emondClient directory (typically under /private/var/db/emondClients or similar system paths). Historical analysis from 2016 documented emond abuse, and the mechanism remains available on systems that haven’t migrated to newer macOS releases. At jobs, stored in /var/at/jobs/, can be rewritten by malware to create recurring execution despite being designed for single-run tasks. Defenders inspecting these directories should treat any unexpected files as high-priority indicators.

Three rare but dangerous persistence mechanisms:

• LoginHooks and LogoutHooks executing scripts at user session events, detectable via sudo defaults read com.apple.loginwindow.
• Emond configurations in the emondClient directory, which should normally be empty on most macOS installations.
• Rewritten at jobs in /var/at/jobs/ that appear to be single-run tasks but get recreated after execution to achieve persistence.

Forensic Detection and Analysis of macOS Persistence Artifacts

Comprehensive persistence detection requires monitoring file system changes across multiple key directories and correlating those changes with process execution and network activity. Critical paths include ~/Library/LaunchAgents, /Library/LaunchAgents, /Library/LaunchDaemons, /Library/Managed Preferences, ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm, /etc/periodic/, /var/at/jobs/, and system directories containing emond configurations. File system monitoring solutions should alert on creation, modification, or permission changes in these locations, with high-priority alerts for writes to LaunchDaemons and system-level persistence paths.

Behavioral detection complements file monitoring by identifying processes launched through persistence mechanisms. Security teams should track osascript executions, especially those with command-line arguments containing network activity or obfuscated scripts. Processes launched by launchd that originate from non-standard executable paths or unsigned binaries warrant immediate investigation. Parsing Mail rule files with grep -A1 "AppleScript" ~/Library/Mail/V6/MailData/SyncedRules.plist reveals automation-based persistence, while sudo defaults read com.apple.loginwindow checks for LoginHook and LogoutHook configurations. Timestamp analysis of persistence artifacts helps correlate installation times with known compromise events or suspicious user activity.

Runtime context matters as much as static file presence. A legitimate-looking LaunchAgent becomes suspicious when its referenced executable is unsigned, located in a temp directory, or makes unexpected network connections. Defenders should combine signature validation, path analysis, and behavioral monitoring to distinguish legitimate automation from malicious persistence. Whitelisting based solely on vendor labels or file names fails against attackers who mimic trusted naming conventions, so forensic analysis must validate actual binary contents, code signatures, and execution behavior before clearing an artifact as benign.

Six forensic checks for persistence artifacts:

• Enumerate all LaunchAgents and LaunchDaemons, then validate signatures and inspect executable paths for each plist file.
• Parse backgrounditems.btm to list all registered login items and cross-reference them with known legitimate applications.
• Inspect shell config files (~/.zshenv, ~/.zshrc, ~/.bash_profile) for appended commands or unusual modifications.
• Audit scheduled tasks using crontab -l, inspecting /var/at/jobs/, and reviewing /etc/periodic/ subdirectories for unexpected scripts.
• Check Mail rules with grep -A1 "AppleScript" ~/Library/Mail/V6/MailData/SyncedRules.plist for automation-based persistence.
• Monitor osascript and launchd child processes at runtime to detect execution of persistence mechanisms and identify suspicious command-line arguments or network activity.

Final Words

In the action, we walked through the main persistence vectors macOS threats use: LaunchAgents and LaunchDaemons, login items, shell profile hacks, scheduled jobs, DYLD tricks, kexts, AppleScript/mail rules, and legacy hooks.

You got concrete detection and forensic steps—monitor plist writes, inspect backgrounditems.btm, audit cron/at queues, and watch osascript and DYLD environment use.

malware persistence techniques on macOS can be managed with regular scans, simple monitoring, and prompt removal. Stay proactive and you’ll cut the odds of a stealthy re-entry, which is a small upfront effort for much less risk.

FAQ

Q: What are the differences between LaunchAgents and LaunchDaemons?

A: The differences are that LaunchAgents run at user login with the user’s privileges, while LaunchDaemons run pre-login as root and provide system‑level services, making daemons more powerful and harder to restrict.

Q: Where are LaunchAgent and LaunchDaemon plist files located?

A: The plist locations are ~/Library/LaunchAgents, /Library/LaunchAgents, /System/Library/LaunchAgents (SIP protected), and /Library/LaunchDaemons plus /System/Library/LaunchDaemons for system items.

Q: How do attackers hide malicious LaunchAgents or LaunchDaemons?

A: Attackers hide them by obfuscating or packing plists, modifying ProgramArguments to run inline commands, placing files in Application Support or user Library, and altering timestamps or file attributes.

Q: What are the top signs a LaunchAgent or LaunchDaemon is malicious?

A: Top signs include unknown developer signatures, unusual ProgramArguments, executables in Application Support, odd hex or randomized names, recent unexpected plist writes, and mismatched code signing.

Q: How can I detect new or modified .plist persistence files?

A: You can detect them by monitoring writes to LaunchAgents/LaunchDaemons folders with auditd or fswatch, tracking file timestamps, and comparing current plists to a known baseline or whitelist.

Q: How does System Integrity Protection (SIP) affect macOS persistence?

A: SIP prevents modifications to /System paths, so it blocks tampering with SIP‑protected LaunchAgents/Daemons but does not protect /Library or user folders, where most malware still installs persistence.

Q: How do login items get abused for persistence and where should I check?

A: Login items are abused by bundling auto‑open apps and backgrounditems.btm entries; check ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm and inspect app bundles and metadata.

Q: How are shell configuration files used for stealthy persistence and how do I spot them?

A: Shell files like ~/.zshrc or ~/.zshenv are abused by appended startup commands; spot them by checking for unexpected lines, odd timestamps, and references to binaries in /Users/Shared or Application Support.

Q: How do cron, at jobs, and periodic scripts get abused and what should I audit?

A: These are abused by inserting malicious scripts into crontab, /var/at/jobs, or /etc/periodic; audit crontab entries, at job queues, periodic folders, and unexpected scripts like “uptime” or newly added hourly jobs.

Q: What is DYLDINSERTLIBRARIES and how is it used for persistence?

A: DYLDINSERTLIBRARIES is an environment variable that forces apps to load specified dylibs; attackers set it in plists or shell files to inject malicious libraries and alter application behavior at startup.

Q: Are kernel extensions still used for persistence and how do I check them?

A: Kernel extensions are still used but increasingly rare and risky; check with kextstat, verify kext signatures, and look for unexpected kexts or drivers, keeping in mind system extensions have largely replaced kexts.

Q: How do AppleScript, Folder Actions, and Mail rules enable persistence?

A: AppleScript, Folder Actions, and Mail rules can auto-run scripts via osascript or SyncedRules.plist; monitor osascript usage and grep SyncedRules.plist for AppleScript entries that trigger on incoming mail or file events.

Q: What legacy macOS persistence techniques should I still check for?

A: Legacy checks include LoginHook/LogoutHook settings, emond clients, launchd.conf or rc files, and old StartupItems—use defaults read com.apple.loginwindow and inspect emond directories on older systems.

Q: What are key forensic checks for finding macOS persistence artifacts?

A: Key checks include scanning LaunchAgents/LaunchDaemons, backgrounditems.btm, crontab and /var/at/jobs, osascript invocations, unexpected root processes, file timestamps, and comparing items to a trusted baseline.

Q: How should a typical user remove a malicious persistence item?

A: To remove it stop the process, use launchctl bootout or launchctl unload for the plist, delete the plist and binary, verify no other entries remain, then reboot or restore from a clean backup if unsure.