The last post covers everything the first five left out: the rules for Linux and macOS (about 70, scattered across every category), the few forensic-tool rules, and the operational lessons from reading the whole library end to end.
1. Linux: discovery and credential access
Discovery hunt: Inventory checks for Sudoers (sudo -l, reading /etc/sudoers)
Discovery hunt: Unusual access to /etc/shadow behavior (two rules)
Discovery hunt: /etc/passwd used to inventory Possible user and via finger
reading /etc/mtab or /etc/fstab (two rules)
Discovery hunt: uname-mediated os information listing behavior and via the distribution version file
Discovery hunt: Inventory checks for Mounted NFS share
Discovery hunt: ps-mediated process discovery behavior
Discovery hunt: Container inventory
writing to /etc/hosts
reading the bash history file (low, two rules) and Credential-access hunt: Reads of interactive shell records (two rules)
SSH key-pair discovery
Credential-access hunt: Credential searches using grep
Reading /etc/shadow outside system tools is the most meaningful event here, because it is required for offline password cracking.
2. Linux: execution and privilege escalation
- Execution from the /tmp directory, a classic location for dropped binaries.
- Sudo: command enumeration through sudo, and an integer-handling flaw being exploited (medium).
- setuid and setgid: discovery of files with the bits set, and setgid being added to a file.
- Capabilities: file capabilities changed with
setcap, and ELF capability modification. - Kernel modules loaded from a compiled loader and a
.kofile.
3. Linux: persistence
.bashrc and .bash_profile writes persistence
XDG autostart entries (two rules)
systemd service file modification
/etc/ld.so.preload edited HIGH (persistence and injection)
user creation or modification by editing /etc files
SSH authorized_keys modification (lateral movement group)
The ld.so.preload edit is high severity for a good reason: it loads a library into every dynamically linked program, which is a rootkit staple.
4. Linux: covering tracks and moving sideways
clearing logs by cat /dev/null (two rules)
clearing logs by copying /dev/null over a file
log deletion using truncate
log destruction using dd medium (two rules)
SELinux set to permissive mode
System-integrity hunt: Shell executable relocated to a second path
Remote-movement hunt: scp-mediated remote file copy behavior (two rules)
Remote-movement hunt: Linux-originated command run on a remote system low
File-identity hunt: the base64 utility-driven base64 decoding behavior
a compressed archive created with tar
Log tampering on Unix is detected through the concrete commands rather than a single abstract rule, because there is no equivalent of the Windows "log cleared" event. Ship logs off the host quickly so local tampering cannot erase the evidence.
5. macOS
Only a handful of rules are macOS-specific, so this is the thinnest part of the library and the place to invest your own engineering.
Firewall manipulation. The rule watches socketfilterfw, launchctl and kextunload with arguments such as --setglobalstate off, unblockapp, or unloading com.apple.alf.useragent.plist and com.apple.nke.applicationfirewall. Each is a different way to switch off the built-in application firewall. Legitimate admin tooling does this rarely, so alert on any occurrence outside your MDM.
Apple-lookalike processes. Malware names itself after Apple components. The rules fire when the name matches but the signature is not Apple's. The reliable check is the signature, never the name: codesign -dv --verbose=4 <path> should show Apple as the signing authority.
Shell-history and archive rules also apply. Removing, linking or touching .bash_history (the rule excludes OnyX, a known maintenance app) and creating password-protected archives with zip -e or -p include macOS hosts. The default macOS shell is zsh, so extend the history rule to .zsh_history and .zsh_sessions.
Rules to write next, in order of payoff: persistence in ~/Library/LaunchAgents, /Library/LaunchAgents and /Library/LaunchDaemons; keychain access with security find-generic-password or dump-keychain; osascript prompting for a password; and direct edits of the TCC database to grant privacy permissions.
6. Forensic tools
Two custom rules fire when a forensic driver is loaded and when WinPmem, a memory-acquisition tool, runs. They are not attacks: they tell you someone is collecting evidence on that machine, which you want to know about, either because it is your incident-response team or because an attacker is borrowing the tool.
7. What reading all 452 rules taught me
rules 452
unique names 396 (about one in eight is a variant or repeat)
informational 286 (63%)
low / medium / high 48 / 94 / 24
enabled / disabled 437 / 5
rules that ever fired about 100 (22%)
loudest rule nearly 20,000 hits, a temp-folder executable write
five loudest together nearly 50,000 hits
Noise
The loudest rules are all informational and all describe normal behaviour: executables in temp folders, firewall edits, AV and firewall product enumeration, generic system enumeration and crash dumps. Move these out of the alert queue and into a scoring model.
Silence
About three quarters of the rules never fired. That is not proof of safety; it is proof that no event matched. Replay a harmless version of each important technique (log clearing, shadow-copy deletion, LSASS access) at least once a year.
Coverage
The tactic with the most rule tags is Defense Evasion (143), then Execution, Persistence, Discovery and Credential Access. Impact (11) and Exfiltration (8) are the thinnest, so late-stage behaviour needs network and data-loss tools to help.
Severity
Reserve high for events with near-zero legitimate use: credential tools, domain-database access, recovery destruction, a mail server writing web pages. Keep informational rules for correlation.
8. A practical operating routine
1 export hit counts, sort by volume
2 for each of the top 20: could an attacker rely on this firing? if not, demote
3 list rules that fired for the first time in a year and read the events
4 confirm every disabled rule has a written reason
quarterly
5 replay five techniques in a lab; confirm the rules still fire
6 review exclusions; delete the ones nobody can explain
7 compare ATT&CK tag counts; write rules for the weakest tactic
9. Where this series fits
The six posts follow the order of an intrusion: how code starts (1), how it stays and rises (2), how it hides (3), how it steals credentials and moves (4), how it gathers and leaves (5), and how to run all of that sensibly across platforms (6). Between them they cover every behaviour group in the library, with variants of the same behaviour grouped so each idea is explained once.