Detect Suspicious launchctl Load Patterns

Malware establishes persistence on macOS by creating LaunchAgents or LaunchDaemons and loading them with launchctl load. While monitoring file creation in Launch directories provides one layer of defense, attackers may create malicious plists in other locations and load them directly.

Malware families that use launchctl for persistence include:

• OSX.CoinMiner: Creates mining daemons in /Library/LaunchDaemons/
• Lazarus APT Group: Establishes persistence via LaunchAgents
• OSX.Dummy: Uses LaunchAgents with random names
• FinFisher: Sophisticated spyware with LaunchAgent persistence
• Silver Sparrow: Mysterious malware with persistence mechanisms
• XCSSET: Targets Xcode developers with LaunchAgent backdoors

Common malware patterns:

• Loading plists from temporary directories (/tmp/, /var/tmp/)
• Random-looking plist filenames (verx.plist, init_verx.plist)
• Hex string filenames (a3f5c8d2.plist)
• Loading from user-writable locations outside standard directories

This rule detects suspicious launchctl patterns that are unlikely to be legitimate software but common in malware.

Deployment approach:

1. Start with the Audit rule to understand launchctl patterns in your environment
2. Analyze audit data for 1-2 weeks to identify legitimate non-system loads
3. Add exceptions for legitimate software installers
4. Deploy blocking rules for suspicious locations first
5. Consider the random-name detection rule for advanced protection

Legitimate launchctl load patterns:

• System installers loading from /Library/LaunchAgents/ or /Library/LaunchDaemons/
• User applications loading from ~/Library/LaunchAgents/
• Enterprise management tools (Jamf, Munki, etc.)

The rule allows all System Library loads and only flags non-standard locations.

Legitimate software may trigger these rules:

• Developer testing: Loading test plists during development
• Enterprise software: Some enterprise tools use non-standard plist names
• Package installers: Installers may stage plists in temp locations during installation
• Migration scripts: System migration tools may load plists temporarily

Before blocking:

• Run in audit mode first
• Review Santa events for launchctl usage patterns
• Identify legitimate software in your environment
• Add signing ID exceptions for approved software

Consider allowing specific signing IDs for enterprise management tools.

1. Create a test plist in /tmp/:

   cat > /tmp/test.plist <<EOF
   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
   <plist version="1.0"><dict></dict></plist>
   EOF
   

2. Try to load it: launchctl load /tmp/test.plist (should be blocked)

3. Test legitimate load: launchctl load ~/Library/LaunchAgents/com.example.legitimate.plist (should work if exists)

4. Test random name detection: touch /tmp/a3f5c8d2.plist launchctl load /tmp/a3f5c8d2.plist (should be blocked)

Monitor CEL execution events for launchctl blocks. Focus on:

Suspicious indicators:

• Loads from /tmp/, /var/tmp/
• Random hex string filenames
• Unusual plist names (verx, init_verx)
• Loads outside standard directories

Investigation steps:

1. Examine the plist contents (may be deleted by malware)
2. Check parent process - what triggered launchctl?
3. Review user account - is this a compromised account?
4. Look for related file system activity around the same time
5. Check if the plist references suspicious executables

Legitimate loads typically:

• Come from known installers
• Use descriptive, brand-related names
• Target standard LaunchAgent directories
• Are signed by known developers