Add macOS rule for sensitive data archived via ditto

[clivoa]

This adds a macOS process_creation rule for ditto archiving a path that holds credentials, browser secrets or wallet data.

Why

ditto has no coverage anywhere in the repo. Grepping current master returns zero hits across rules/, rules-threat-hunting/ and rules-emerging-threats/. The LOOBins entry for the binary says the same thing in its own Detections section: "No detection content at time of writing."

It is not an obscure technique. CyberProof's AMOS analysis describes the malware gathering Keychain files, browser credentials and wallet data, then compressing them "into a single archive named osalogging.zip within the /tmp directory using native macOS utilities like ditto". LOOBins lists the staging form under Collection and Exfiltration:

ditto -c -k --sequesterRsrc --keepParent /home/user/sensitive-files /tmp/l00t.zip

The reason stealers pick ditto over zip or tar is that it preserves resource forks and extended attributes, so macOS metadata survives the round trip. /usr/bin/ditto is also signed by Apple (Identifier=com.apple.ditto), so it does not trip anything watching for unsigned binaries.

The rule matches on the archived path rather than on ditto alone. A bare "ditto was executed" rule would be noise, since the binary is in ordinary use for copying application bundles.

Path selection

I followed the approach in Access To Crypto Currency Wallets By Uncommon Applications (f41b0311) and used specific paths rather than a generic keyword. A bare wallet substring was deliberately left out: it matches ordinary user directories and would have driven the false positive rate up for little gain.

Testing

Real process telemetry, captured on macOS 26.5.2 (arm64) while the command ran. Home directory redacted:

TP  CommandLine = /usr/bin/ditto -c -k --sequesterRsrc --keepParent /Users/<user>/Library/Keychains /Users/<user>/T1560.001_keychain_archive.zip
NEG CommandLine = /usr/bin/ditto -c -k --keepParent /Users/<user>/dittotest_ns /Users/<user>/T1560.001_benign.zip

The first archived a real 25 MB Keychains directory into a 7.5 MB zip. The second archived an ordinary directory holding a text file, as a control.

Rule logic checked against both captures and six further cases:

Case	Result
Captured Keychains archive	match
Captured ordinary directory archive	no match
ditto on ~/.ssh	match
ditto on a Chrome Cookies path	match
ditto on an Exodus wallet directory	match
ditto copying an app bundle to a backup volume	no match
ditto -c -k unsigned.app app.zip, the LOOBins Gatekeeper trick	no match
zip -r over the same Keychains path	no match

The Gatekeeper case is worth calling out. It is the other documented offensive use of ditto, it is a different tactic, and it does not match this rule. Anyone wanting to cover it would need a separate rule keyed on the extended attribute behaviour rather than on the path.

Repository checks, all clean:

python tests/test_logsource.py          Ran 3 tests, OK
python tests/test_rules.py              Ran 11 tests, OK
sigma check --fail-on-error --fail-on-issues --validation-config tests/sigma_cli_conf.yml
                                        0 errors, 0 condition errors, 0 issues

There is a companion Atomic Red Team test for the same technique under T1560.001, so the emulation side is reproducible too.