macOS: cover xattr -c in the Gatekeeper bypass rule, add ClickFix stage-3 dropper

[raimurokko]

1. Gap in an existing rule

proc_creation_macos_xattr_gatekeeper_bypass.yml requires both -d and
com.apple.quarantine on the command line. A macOS ClickFix chain we analysed on
2026-08-04 used xattr -c instead, which clears every extended attribute — quarantine
included — and therefore achieves the same bypass without matching the rule.

Added a second selection for -c, -cr and -rc. Level and false positives are
unchanged; xattr -c is about as common in legitimate use as -d com.apple.quarantine
already was.

2. New emerging-threats rule

The stage-3 dropper sequence of the same campaign: a Mach-O fetched into a temporary
directory, dequarantined, marked executable and run, all from a shell the victim pasted
into themselves.

Deliberately narrower than it could be — matching requires the xattr step and a
temporary path and a shell parent. curl and chmod against /tmp on their own
are ordinary developer activity, and six existing macOS rules already cover curl.

Related existing coverage

While checking for duplicates I found
rules-emerging-threats/2025/Malware/Atomic-MacOS-Stealer/proc_creation_macos_malware_amos_curl_post.yml,
which already matches curl POSTs carrying user: and BuildID. Our stage 2 sends
exactly that header pair, which we had observed independently and, until finding that
rule, believed to be undocumented. Neither rule proposed here overlaps it: that one keys
on the exfiltration POST, these key on the dequarantine step and the dropper sequence.

It is also the best corroboration we have for the family assessment, so — thank you to
its authors.

Context

Analysis, indicators and the decoded chain:
https://github.com/raimurokko/macos-threat-tracking/blob/main/campaigns/2026-08-04-cloudflare-clickfix/payload_analysis.md

Sample:
https://bazaar.abuse.ch/sample/29be0f56275f051181ea3ec37ddc3d3807cde34cb65de855709fae0e13786a40/

What these rules do not do

The dropper rule will not fire if the operator drops the xattr step — which is a
reasonable thing for them to do next, since Gatekeeper only evaluates quarantined
binaries and a payload delivered by other means may never carry the attribute.

The family behind this chain is assessed as AMOS lineage but not confirmed: the
stage-3 binary is a self-decrypting loader whose payload was not recovered, and
Microsoft reports the same infrastructure cluster delivering MacSync as well. The rules
therefore describe behaviour, not a family.

tests/test_rules.py, tests/test_logsource.py and sigma check all pass.

[raimurokko]

Small housekeeping note, not a nudge for review.

This PR seems to have missed the triage automation: it carries no labels, and no workflow runs are reported on the branch. Every neighbouring PR from the same days (#6200, #6201, #6203, #6206, #6208) picked up Rules / Review Needed as usual, and my later PR #6209 did too — so this looks like a one-off miss on the opened event rather than anything about the contents. I've merged current master into the branch, which did not re-trigger it, so it likely needs a label by hand to enter the queue.

Flagging it only because an unlabelled PR is easy to lose. No urgency at all, and happy to rebase, split, or drop parts if that suits the review better.