Daily CEL and FAA rules to harden your macOS fleet against real-world malware
macOS malware is evolving rapidly, with sophisticated threats like Atomic Stealer (AMOS), Shlayer, and APT campaigns targeting everything from browser cookies to messaging history. But defenders often lack practical, production-ready configurations to stop these threats before they execute.
That’s why we’re releasing the Santa Security Advent Calendar: 25 days of battle-tested Common Expression Language (CEL) and File Access Authorization (FAA) rules, each designed to prevent specific attack techniques observed in real-world macOS malware. CEL and FAA are functionality present in the Santa, our open-source binary and file access authorization system, and configurable in Workshop, our flagship enterprise-grade endpoint protection platform. These features are extremely powerful and extensible, and they solve so many security issues that it’s hard for us to limit them to just 25!
Starting December 1st we’ll unveil one rule per day. We’ll cover everything from preventing curl downloads to /tmp and blocking credential phishing via osascript to protecting your Keychain databases and LaunchAgent directories. Each rule includes the complete Workshop configuration, an explanation of the malware it stops, and guidance on deployment.
These rules provide part of a comprehensive defense-in-depth strategy, one gift at a time. By the end of the month you’ll have a stronger security posture that addresses techniques commonly exploited on macOS.
Day 1: Electron Apps on a Short Fuse
Electron apps have a few compile-time feature flags called “fuses” which verify the integrity of bundled resources. Up until recently, those integrity checks would skip V8 heap snapshot files and allow an attacker to run arbitrary JavaScript when the application was opened. The team at Trail of Bits discovered this, and high-profile Electron apps like Slack and 1Password have been updated, but older Electron apps or apps without the integrity fuses enabled can still be backdoored.
But why should any process outside the application be able to write its heap snapshot file? With Santa’s file access authorization (FAA) rules, you can make sure that, say, only 1Password can write to the heap snapshot in its application bundle:
And now Santa will block any attempt to modify the snapshot files.
Day 2: Block Old Browsers
One of the most complicated pieces of software you run that needs to be kept up to date is your browser. Just this year we saw CVE-2025-4664 for Chrome and CVE-2025-2857 for Firefox, and compliance programs like FedRAMP and Cyber Essentials Plus require that software be kept up to date.
Santa’s CEL rules let you enforce a maximum time since an application was signed, and this is one of our favorite examples from our CEL rule cookbook. The cryptographically-secure signing time can be used to evaluate when software was released, and you can create a CEL rule like this:
target.secure_signing_time >= timestamp("2025-05-31T00:00:00Z") ? ALLOWLIST : BLOCKLIST
You can use the EQHXZ8M8AV:com.google.Chrome signing ID for Chrome and 43AQ936H96:org.mozilla.firefox signing ID for Firefox:
Once Santa has downloaded this rule, trying to open an old version of Chrome or Firefox results in Santa blocking the execution.
Day 3: Keep Your iMessages to Yourself
Did you know all of your private iMessage history is stored in an SQLite database in ~/Library/Messages? Apple’s TCC might block new applications from getting to it, but if you’ve already given an application full disk access permission, like your favorite terminal emulator, programs can just go and read it:
$ sqlite3 ~/Library/Messages/chat.db \
"select date, text from message limit 1"
78511514999923|Hey! Did you need my SSN? It's 000-11-2233
Luckily, Santa’s file access rules make it easy to limit access to this directory. Running sudo fs_usage -f filesys -w can show all processes that are able to read this directory. Then, creating a file access rule in Workshop is easy:
Then if, for example, your favorite AI-assisted coding tool tries to access our iMessage conversations, Santa stops it cold.
Day 4: No Touching the Timestamps
One way that malicious software covers its tracks is by timestomping, or setting the timestamps of malicious files to match legitimate ones to make timeline analysis more difficult.
As Jaron Bradely points out, this is commonly done when achieving persistence though the LaunchAgents and LaunchDaemons directories. Malware can use the built in touch command with seldom-used flags, such as -r, which copies the timestamp from one file to another. Luckily, this is pretty easy to block with a Santa CEL rule expression:
args.exists(arg, arg in ['-a', '-m', '-r', '-A', '-t'])
&& args.join(" ").contains("Library/Launch")
? BLOCKLIST : ALLOWLIST
Now, trying to use touch to adjust timestamps in ~/Library/LaunchAgents gets blocked. Of course, this rule won’t be triggered if the malware chdir’s to the directory first. To harden this further, you could use a file access rule, which was demonstrated by Kristin Smith at BSides Canberra 2025 If you really want to be clever build anomaly detection on top of File Access Authorization events like she presented.
Note: In Santa versions 2025.12+ you can write a better rule that accounts for the current working directory (cwd).
args.exists(arg, arg in [
'-a', '-m', '-r', '-A', '-t'
]) && ((args.join(" ").contains("Library/Launch")
|| cwd.contains("Library/Launch"))
|| (cwd.endsWith("Library") &&
(args.join(" ").contains("./Launch") || args.join(" ").contains(" Launch"))))
? BLOCKLIST : ALLOWLIST
While this rule won’t catch everything it will catch a lot. Expect to see more improvements to CEL rules in the near future.
Day 5: Stop Fake Password Popups
It’s the wrong holiday, but do you want to see something spooky?
That’s not a real password prompt! But to a non-savvy user, it might look official enough. These can be generated with osascript, like this:
osascript -e 'display dialog "To perform a security update macOS needs your password." with title "macOS Security Update" default answer "" with icon stop with hidden answer'
And you can block them with a Santa CEL rule like this:
(
args.join(" ").lowerAscii()
.matches(".*\\W+with\\W+hidden\\W+answer.*") ||
args.join(" ").lowerAscii().contains("password")
) &&
args.join(" ").lowerAscii().matches(".*\\W+display\\W+dialog.*")
? BLOCKLIST : ALLOWLIST
Day 6: Hands Out of the Cookie Jar
Why should an app have access to your browser’s cookies file if it isn’t the browser? Infostealers love to steal cookies! But with Santa file access rules, it’s easy to prevent this. This is such a common issue that there’s an example rule for this built into Workshop’s file access rule editor:
For example, by using a file access rule to limit /Users/*/Library/Application Support/Google/Chrome/*/Cookies to EQHXZ8M8AV:com.google.Chrome*, you can make sure only Chrome can get to its own cookies.
This doesn’t just apply to browsers. Apps built with Electron, like Slack, include Chrome and should have access to their cookies limited as well. Check out our cookbook to see the examples
Day 7: Gatekeep the Gatekeeper
The macOS Gatekeeper is a helpful system that prevents the execution of unsigned or malicious applications. But it can be easily disabled with the spctl utility. If you’re hardening a fleet, you can prevent Gatekeeper disabling by creating a CEL rule for the signing ID platform:com.apple.spctl:
[
'--global-disable',
'--master-disable',
'--disable',
'--add',
'--remove'
].exists(flag, flag in args) ? BLOCKLIST : ALLOWLIST
And if you’re using Workshop, you can set up tags to enforce this across your fleet but allow exceptions on demand.
Come back tomorrow for our next installment!