YARA

A rule has strings, such as text, hex patterns, or regular expressions, and a condition that combines them, such as 'any 2 of these' or 'file size under 200 KB'. You run yara with a rules file against a folder or process. Measure a rule by true hits on known samples and false hits on a clean corpus.

Good rules key on things the author is unlikely to change: a distinctive decoder routine, a configuration key name, a rare string. Test against clean copies of WordPress core, popular plugins, and your own theme before deploying.

After cleaning three webshells that all contain the string 'x-auth-k' and an assert(base64_decode(...)) call, a rule is written requiring both plus a file size under 20 KB. Run across 61,000 files on a hosting account, it returns four hits: the three known shells and a fourth in a forgotten staging copy.

On a clean WordPress download the rule returns zero hits, so it is safe to schedule nightly. The fourth hit is the real find; the rule only exists because someone saved the first three samples.

A hash matches one exact file and fails when a single byte changes. A YARA rule matches a family of files by shared traits, so renamed or lightly edited copies still hit. A hash is cheaper and has no false positives; a rule trades some precision for reach.

Writing rules from one common string like eval that hits legitimate code. Not testing on clean files. Matching on a variable name the attacker changes next week. Over-tight conditions that miss a one-line edit. Treating a rule as the whole defense instead of a net for one family.

Keep samples of what you have cleaned, write a rule for each family, and test it on clean installs before scheduling. Review hits manually at first. Share rules with your host or team so the same family is caught on the next site.