I Started With One Missing Rule
ClickFix is the technique where a victim is talked into pasting a prepared command into their own terminal. A fake error message, a fake CAPTCHA, a fake driver update, and the instruction to copy this and run it to fix the problem. The user authorises everything. No exploit is involved at all.
SigmaHQ, the open-source detection rule project, covers it well on Windows. Thirteen rules, including the RunMRU and TypedPaths registry artifacts the Run dialog leaves behind, the whitespace padding attackers use to push the malicious part of a command out of view, the FileFix variant, and the finger.exe delivery trick.
On macOS the same technique runs through Terminal instead of the Run dialog, and it is in active use. The only file in the macOS ruleset matching the word "clickfix" is an Atomic Stealer rule where the word appears in a reference URL rather than in any detection logic.
So I wrote one. A rule for the chain where content is fetched with curl, decoded with base64 or gunzip, and piped into a shell, with the decode step as the thing that separates it from the legitimate installer one-liners that Homebrew and rustup use. I submitted it to the project in October.
Before submitting I had to check it did not overlap anything existing, which is a project requirement. That check is what started this. I went looking for three or four neighbouring rules and ended up counting the whole ruleset.
This note is not about ClickFix. ClickFix is where I started, and it turned out to be a clean example of something structural: macOS detection coverage is not merely thinner than Windows coverage, it is built on a single kind of observation. Of the 76 macOS rules in the project, 71 watch the same thing happen.
What the Ruleset Showed
Sigma rules declare a logsource, which names the platform the rule applies to and the kind of event it reads. That makes the ruleset countable. I cloned the repository and counted rules by declared platform across the three rule directories: the main set, emerging threats, and threat hunting.
| Platform | Rules | Share | Event Categories |
|---|---|---|---|
| Windows | 2,878 | 89.9% | at least 20 |
| Linux | 249 | 7.8% | several |
| macOS | 76 | 2.4% | 2 |
The ratio is the headline, but it is the least interesting number here, because a reader can fairly object that Windows is the bigger target and has more attack surface. That objection is real and I deal with it in the next section.
The comparison that is harder to explain away
Linux has 249 rules. That is 3.3 times the macOS coverage, and Linux desktops are considerably rarer in the enterprises these rules are written for.
What Linux has that macOS does not is instrumentation. Linux endpoints are overwhelmingly servers, and servers are monitored by default: auditd, eBPF tooling, and a long tradition of shipping logs somewhere. Macs are desktops sitting on the laps of designers, marketers and engineers, managed by an MDM for patching and otherwise unobserved by anyone in a security role.
What this count does and does not show. These figures describe the SigmaHQ repository as cloned in October 2026, counted by the product: value each rule declares in its logsource block. The three platforms shown sum to 3,203 rules; the full ruleset is larger, because rules targeting cloud and SaaS platforms declare other products and some rules declare none. The Windows category figures below are the twenty largest, which account for 2,481 of the 2,878 Windows rules, so the remaining 397 sit in categories not listed. Sigma is one project rather than the whole of detection engineering. Commercial endpoint products carry macOS detections that are not public, and this count says nothing about those.
Two Categories Out of Twenty
The second thing a logsource declares is the category: what kind of event the rule reads. Process creation, file events, network connections, DNS queries, and so on.
Windows rules span at least twenty of them. Process creation is the largest at 1,426, which is 50% of the Windows total. The other half is spread across registry writes, PowerShell script blocks, library loads, network connections, named pipes, DNS queries, driver loads and more.
macOS rules span two. Seventy-one process creation, five file events, and nothing else.
So Windows detection has roughly twenty ways of noticing something. macOS detection has one, plus a trace of a second. That is a difference in kind rather than in degree.
Giving Windows its due
Some of those twenty categories have no macOS equivalent, and it would be dishonest to count them as missing coverage. There is no registry on a Mac, no PowerShell, no WMI. Those categories account for 564 Windows rules, and I set them aside.
The rest do have equivalents. A Mac loads libraries, opens network connections, resolves DNS names, reads other processes' memory, and deletes files. These are not Windows concepts. They are things every operating system does.
| Event Category | Windows | macOS | Exists on macOS |
|---|---|---|---|
| process_creation | 1,426 | 71 | Yes |
| file_event | 221 | 5 | Yes |
| image_load | 125 | 0 | Yes |
| network_connection | 61 | 0 | Yes |
| process_access | 29 | 0 | Yes |
| dns_query | 28 | 0 | Yes |
| file_delete | 14 | 0 | Yes |
| file_access | 13 | 0 | Yes |
| registry_set | 227 | 0 | No |
| ps_script | 181 | 0 | No |
| wmi_event | 3 | 0 | No |
Two hundred and seventy Windows rules sit in categories that apply identically to a Mac, and macOS has none of them. No rule anywhere in the project watches a macOS process load a malicious dylib, open a connection to a command-and-control server, resolve a suspicious domain, or read another process's memory.
Not because those things do not happen on Macs. Because nobody has the data to write the rules against.
The Door Everyone Uses
Five file-event rules is a small enough number to read in full, so here is what macOS file-based detection consists of, in its entirety.
| Rule | Watches | Type |
|---|---|---|
| MacOS Emond Launch Daemon | emond persistence | Legacy mechanism |
| Startup Item File Created | StartupItems persistence | Legacy mechanism |
| Atomic MacOS Stealer | AMOS persistence paths | Campaign indicator |
| Axios NPM Compromise | Campaign file paths | Campaign indicator |
| Python Path Configuration | .pth file creation | Generic technique |
Two of the five are campaign indicators: lists of paths and filenames from one specific piece of malware. Those stop working the moment the operator changes a directory name. Two more watch emond and StartupItems, both superseded by launchd long ago. One, the Python .pth rule, is a genuine generic technique.
What is missing from that list is the mechanism almost everything actually uses. On macOS, persistence means a property list dropped into ~/Library/LaunchAgents or /Library/LaunchDaemons. MITRE tracks it as T1543.001. It is the first thing a stealer does.
It is covered, but only from one side. Three rules watch the process side: running launchctl, using PlistBuddy to modify a plist, and unloading security tools. One file-event rule covers it, and that is the Atomic Stealer campaign rule.
Why the process side is not enough. An attacker does not have to run launchctl. A plist written into LaunchAgents is picked up by launchd at the next login with no command executed at all; launchctl is only needed to load it immediately in the current session. So malware that is willing to wait for the user to log out, which is most of it, writes a file and nothing generic fires.
The same shape, everywhere I looked
This is not confined to persistence. The project's coverage of npm supply chain attacks, which is the current route onto developer machines, consists of four rule sets, one per campaign: Shai-Hulud, the Axios compromise, TanStack, and the TeamPCP backdoor of LiteLLM.
Every one of them is a list of indicators. The Shai-Hulud rule matches a hardcoded inventory of roughly eight hundred package@version strings, and it was last extended in October 2026, which means somebody is maintaining that list by hand.
None of them detects the behaviour underneath: a package manager installing from a remote URL rather than from the registry, which is what lets a tarball with a malicious install script run in the first place.
Indicator rules are not wrong. They are fast to write, they fire accurately during a live campaign, and they are often all the information available in the first week. But they decay, and a ruleset composed mostly of them is a record of past campaigns rather than a defence against the next one.
What a Defender Can Actually Use
The reason for all of this is not that nobody noticed Macs. It is telemetry.
Windows detection engineering runs on Sysmon. It is free, it comes from Microsoft, it installs anywhere, and it emits process creation with full command lines, image loads, network connections, DNS queries, registry writes and named pipes. Anyone can put it on a test machine, write a rule, and confirm it fires in ten minutes.
macOS has Apple's Endpoint Security Framework, which requires a notarised system extension and is consumed mostly by commercial endpoint products, each mapping it to its own schema. There is no free, universal, install-anywhere equivalent. So a rule author cannot easily test a macOS rule, and the field names a rule should use depend on which product the reader happens to own.
That explains the shape precisely. Process creation is the one category almost every macOS agent exposes in a comparable way. So that is where the rules are. Not because process creation is where the threats are, but because it is where the data is.
Defensible takeaway. If your Mac fleet is covered by open detection content, that coverage is almost entirely one signal: a process starting with a suspicious command line. Anything that does not involve launching a process is, in open rules, invisible. That includes the most common macOS persistence mechanism when established by file write.
Three things follow. Know which category your Mac telemetry actually delivers before assuming a rule pack covers you, because a rule that reads image loads is inert if your agent does not emit them. Treat file-event coverage as a gap to close explicitly, starting with LaunchAgents and LaunchDaemons, since that is one directory to watch and it catches the step nearly every stealer takes. And prefer behavioural rules over indicator lists where the behaviour is stable: package names rotate weekly, but installing from a URL instead of a registry does not.
What I would want to know next
Three questions this count raises and does not answer.
Whether commercial coverage has the same shape. These figures are from open rules only. If vendor-maintained macOS detections are also concentrated in process creation, the gap is an industry-wide consequence of the telemetry rather than a property of one open-source project.
Whether the ratio is changing. A single snapshot cannot show direction. The same count run against the repository's history, year by year, would say whether macOS coverage is catching up, holding steady, or falling further behind.
And what a file-event rule for LaunchAgents would cost in false positives. Legitimate software installs launch agents constantly, so the question is whether path, filename and writing-process together separate the two cleanly enough to be usable. That is the rule I would try to write next.
I came to this intending to add one macOS rule. The more durable finding was upstream of that: a platform can be well defended against malware and still be almost entirely unwatched, and the shape of the detection that does exist is decided by the shape of the telemetry rather than by the shape of the threat.
Rule counts, platform shares and category distributions from the author's own research against a local clone of the SigmaHQ repository, counted in October 2026 across the rules, rules-emerging-threats and rules-threat-hunting directories. Platform counts are files declaring product: windows, product: macos or product: linux in their logsource block, giving 2,878, 76 and 249 respectively, summing to 3,203; the repository contains more rules than this, as rules targeting cloud and SaaS platforms declare other products. Category counts are category: declarations within those files. macOS resolves to 71 process_creation and 5 file_event, with no other category present. Windows category figures are the twenty largest, totalling 2,481 of 2,878, so 397 Windows rules sit in categories not listed here; of the twenty, registry_set, ps_script, registry_event, ps_module, pipe_created, create_remote_thread, ps_classic_start, registry_delete, driver_load, create_stream_hash, wmi_event and registry_add have no macOS equivalent and account for 564 rules, which are excluded from the 270 figure. The thirteen Windows ClickFix rules and the absence of a macOS equivalent were counted by the author during overlap review for a rule submitted to the project in October 2026. The five macOS file_event rules are listed in full. launchd coverage determined by searching all three rule directories for launchctl, LaunchAgents and LaunchDaemons, returning three process_creation rules and one campaign-specific file_event rule. Launch agent persistence and its loading behaviour: MITRE ATT&CK T1543.001. Emond is tracked separately as T1546.014 and is described by Apple and by MITRE as a legacy mechanism; StartupItems has been superseded by launchd. npm supply chain rule sets counted as Shai-Hulud, Axios NPM Compromise, TanStack Supply Chain and TeamPCP LiteLLM; the Shai-Hulud package inventory was counted from the rule file itself. Sysmon and Endpoint Security Framework characterisations from Microsoft and Apple developer documentation respectively. This count reflects one open-source project at one point in time and makes no claim about detection content maintained privately by commercial vendors. This field note represents independent research produced for educational purposes.